上周项目上线，生产上又出了不少bug，领导为此大发雷霆。但我写的功能又"幸免于难"，领导不由感叹"还好你的功能没出问题，我们项目组的这个核心功能一直也都保持稳定，挺让人欣慰的！"
在受到表扬的同时，我也不禁开始思考，我是否可以趁着这股"高兴劲头"来做一个工作总结，经验的巩固。
于是我理出对于如何保证功能的质量，大概有以下几个要点。
1.注重设计
我们都知道接到一个需求，要先做设计再动手写代码。
然而，实际工作中，很多时候我们并不能很好地去执行"设计"。甚至有时候会觉得边写边想也是一个不错的工作方法。
我们也一定有过不少写到中途发现预想的实现方式不对的经历，有过一开始设计不周全导致后期的优化过需求变更时无比痛苦的教训。
其实这都是一开始设计工作做的不充分或设计经验不足造成的。
所以我认为不管一个功能有多复杂，我们都要尽可能先做好设计，养成好习惯，有一个"注重设计"的意识，这对于长期的进步十分有帮助。
注重设计意味着我们要花足够的时间去思考如何编码，不要怕浪费时间。
那么如何去做好设计呢？
首先仔细分析需求，并结合整个项目，站在产品经理的角度去彻底的理解需求，然后再对功能实现方式做整体设计，比如表结构怎么设计，数据权限的控制方式，是否有现成的轮子可以使用，如何封装公共接口等。
实际上当我们在脑子里做好了设计，这个功能也就实现了一大半，剩下的工作就是把思考出来的设计用代码表达出来罢了。
但如果不重视设计，很可能会出现后期返工、bug频发，需求变更适应力不强等问题，这样不仅浪费时间，还不利于最后的代码质量。
2.提版工作要仔细
设计好了代码噼里啪啦一顿敲，三下五除二就把功能写完了。结果让测试一测，bug一大堆。在修复bug过程中，少不了多次提交代码到git或svn代码库。甚至，对于采用敏捷模式的项目，可能还会有很多次的用户需求优化(变更)等着我们，所以实际工作中，代码提交是十分高频的动作。
我们时常有发现很多bug不是什么代码逻辑问题，而仅仅是因为调试过程中的"工作代码"或者"打字失误"，又或者是本地测试与生产测试环境某些参数设置的差异造成的，等等。
不要小看了这些小错误，细节里出魔鬼，常常一些诡异的bug正是这些意想不到的小错误造成的，但他们也经常耽误了工作进度甚至给我们带来了重大问题。
其实，我们本可以通过一个简单的小习惯就能避免的，这个小习惯就是在代码提交时快速的浏览一遍代码差异，从而达到检查代码的作用。
3.上线脚本"时刻写"
对于上线依赖的sql脚本或shell脚本一定要一边开发一边记录收集，然后最后统一整理与测试。如果完全等到最后回过头来编写很可能会遗漏。
这不仅个人的经验之谈，也是来自于同事的血的教训！
4.测试驱动开发
如果项目组有要求TDD(测试驱动开发)那最好，简单说就是在编码前先思考测试场景写测试案例，再根据测试案例来编写功能代码。
如果做不到，作为开发，也要尽可能站在测试的角度去思考问题，深刻全面的去测试自己写的功能，甚至有时候测试也有"不靠谱"的时候，我们作为开发去思考测试角度，能很好的保证测试周全。
总之，就是要培养多角度多方位反省自己代码的能力。
5.注重演练测试
与功能测试不同，演练环境的测试更接近生产环境，并且也更容易检验出上线脚本的问题。并且很多可能在sit环境不会出现的bug却可能在演练测试时发现，所以重视演练测试这一关，对于保证最终项目质量非常关键。
6.细节上严格要求自己
这一条也可以作为本文的一个总结。实际上，程序员的工作成果就是由无数行代码无数个细节最后累加起来的，一个有些良好用户体验的产品绝不仅仅是因为它用到了一个很高大上的算法，使用了多么时髦的技术，而是在整个系统的稳定与可靠的基础上不断迭代出来的。
很多程序员技术也并不差，但"产出"就是提不上来，做出的功能质量也总是无法让用户满意(休息，用户体验不好不全是产品经理的锅)，实际上就在于那无数个我们原本可以轻易做到却由于一次次的"没注意到"的细节里。
提升工作能力的不二法门，关键在于长期坚持，多多总结。
多年以后，我们一定能看到那些事事严格要求自己的同事有着惊人的成长力！
共勉。