几天来，程序都快被BUG烤糊了，经历了一系列细节崩坏的过程后，我对程序质量的问题有了一种全新的认识，如何建造健壮高效的软件？
责任心？机智？经验？工匠精神？
还是从具体的方法和执行过程研究自身吧……
1 对需求的掌控程度太浅（需要二次确认后对代码进行review）
从开第一次需求串讲开始，到底对需求研究过几次？
这个问题我现在必须重视，想当然的做了一些功能，因为靠想象和别人忙碌时口头的确认作为需求依据，功能完成后又是口头确认，原本不会出现的问题就只会依赖别人的严格测试和队友偶尔发现的状况去发现和确认，但隐藏在代码细节处的问题基本就变成了黑暗角落，封存在隐秘地带，直到一个关键时刻，这个地方的炸弹就会突然飞出，让你措手不及，因为问题就是问题，不因为你不去看他就消失。
2 学习测试思想
总觉得技术工具箱是面向实现的这种想法很有问题，收集了实现只是找到了零件和工具，做出的东西目的是要用的，谁在用怎么用，要从最简单的情景跳出来，推演至少三遍以上，也就是创造分支，实际上以前张博士说的多加判断捕获异常还不够，还要在第一遍推演的基础上继续进行推演，利用正反馈原理迭代设计。
3 工期的判断
什么时候完成设计？什么时候完成codeing？什么时候提交测试？在心里有个数，如果目标工期到了，提交测试的代码如果不能做到已经自测50%以上，则不能轻易交由测试人员接管质量保障任务，因为这时成品根本没有质量可言。
如果提交了测试，那么测试人员会对你的功能错误提出很多疑惑，这时会浪费很多不必要的时间，这对质量是致命的，时间浪费了！如果把和别人解释的时间、对设计推倒重来的时间、沮丧的心情带来的低效工作时间、赶工出现新BUG的修改和确认时间等浪费的时间都算上，也许你重新做一个软件可能更有价值。
4 制定代码review和重构计划
代码提交测试了以后该干嘛？
扯皮？悠哉？购物？休息？
不，这些还不能干，花两小时时间，详细将程序清单整理出来，对着至少看一遍，相信我，很容易能看出来不对劲的地方，然后你会很庆幸做了这件事。
说说我都看见过什么吧。
在一个后台项目正常业务跑通的情况下，我以为完成任务了，直到我看了看BUG列表，有一些我认为很小的问题，到后面一翻代码，大大小小的逻辑漏洞就出现了，由一个分支和一个点联系到许多地方的调用判断和实现方式都有问题，于是就开始了打补丁的过程。
从测试初就开始打补丁，一直打到了测试结束，心里还是没有踏实下来，真的很折磨人，虽然这种惊慌和恐惧可能并不应该出现，如果心里对所有做过的东西有个底的话。
这时候程序清单能帮助程序员心里有底，因为做过的东西都列在那儿，
看一遍觉得命名看着不爽
看两遍觉得封装的参数有些多余，如果靠类型或数组传递会更有扩展性。
看三遍觉得多个类中的公共方法应该抽出来扔一个地方维护。
看四遍觉得有些实现用泛型应该会实现得更容易使用。
看五遍觉得业务的扩展性如果能用基类和接口做以后能省不少事。
看六遍就觉得这代码简直扔到垃圾箱里都可以，还是重新做一遍比较舒服。
然后就没有然后了。
5 是什么让我没做到以上这些
没做过，所以没做到，比如现在，你觉得我在思考、研究追寻真理，其实我是在扯皮。。