在网上看到蔡为东写的“没有奇迹的内建质量”，真是不能再同意了。曾经我也经常听到并曾相信过：“***局点要开局/升级了，这半个月测试团队冲刺测试或者再给我一个月时间测试团队努力测试，就会得到一个质量好的软件”，但后来发现这都是一厢情愿，突击工作最多只能对质量做一些微调，改变不了更多。软件质量的形成过程中没有奇迹，软件的质量形成于项目运作的每一天，质量不是测出来的，而是生长出来的，质量需要内建。
质量内建的两个观点：（1）测试不是一个阶段，当然也不应该开发结束之后才开始。如果把测试留在最后，那就为时晚矣，因为可能根本没有时间修复那些刚被发现的问题。（2）测试也不纯粹或主要是测试人员的领域。交付团队的每个人都应该对应用程序的质量负责。
质量内建常提到的方法：持续集成、全面的自动化测试和自动化部署都是为了在这个交付流程中尽早地发现问题（越难的事情越不想做的事情就要提前做长期做），然后修复它们，越早发现缺陷，修复它们的成本越低。如果在没有提交代码到版本控制之前，我们就能发现并修复缺陷的话，代价是最小的。
今天听到整洁代码的分享，大家都觉得做这件事情是有价值的，但是为何落地就很难呢？这个活动中长期收益高，短期效果不明显。并且由于门槛挺高的，需要不断练习形成习惯后方能无招胜有招的应用到代码编写过程中，而刚开始做的时候由于不熟练应用时效率会受阻，担心影响个人的考评，这个可能也跟环境导向有关系，也跟自己的选择有关系。
