开发的几条想法

1. 测试驱动可以显著提高质量，并可以帮助架构的自然产生。但对开发人员的要求较高，并会增加开发时间，但从整个产品周期角度是值得的。
2. 开发语言的选择，应以开发人员最熟悉为前提，再以可以胜任并能尽快完成工作为原则。如果使用开发人员不熟悉的开发语言，即使语言的开发效率高，也有框架支持，但当遇到问题时损耗的时间将会超过语言节省的时间。
3. 设计模式应作为参考，不能生搬硬套，更不能为了显示水平为了使用而使用。设计模式会增加代码的理解难度，有时会降低效率。
4. 架构是一个过程，不可能一次完成，也不可能不改变。一个原则是，不要过度设计，不要为未知的需求而烦恼。
5. 重构应在每个模块甚至每个类完成后立即开始。但要注意不应过早重构。
6. 不要在新加功能的同时重构或修复bug，否则会陷入更糟糕的代码之中。
7. 除非软件简单（如小工具），否则必须做原型开发。原型将会为之后的开发提供有力的技术支撑。不做原型在开发过程中修改的次数会更多。
8. 原型可以提高设计质量的原因是，好的代码至少需要写两遍。第一遍一般比较匆忙，对需求理解不是很透彻。第二遍时已经对需求有了比较深刻的理解，同时会避免设计上的一些缺陷。
9. 开发人员经常陷入开发语言孰优孰劣的争吵之中。目前各种语言都是图灵完备的，所以从功能上没有本质的区别，主要的区别是在IDE和类库的完善。就像比较中文、日语、英文的好坏，当然是母语最好。
10. 测试驱动的过程中，UT是推导出模块设计的直接动力，也是影响扩展性的直接原因。
11. “不会C++的程序员算不上程序员”虽然有些偏激，但会C++的程序员更清楚程序运行的原理。
12. 始终记住程序是写给别人看的，如果不希望被别人骂，还是写人看得懂的代码。
13. 注释写要做什么（what），而不要写如何做的（how），代码已经说明了一切。
14. 代码规范开始不习惯，但习惯以后会发现能显著提高生产力和质量。
15. 尽量让程序支持自动化测试，可测试的程序代表可维护和可扩展。
16. 结对编程可以帮助提高质量，因为在写代码同时也在做code review。对需要创造性的编程，两个人要比一个人更有思路，在交流过程中也会产生更好的想法。如果一个人不熟悉所做的工作，可以达到知识传递的作用。
17. 结对编程不适于长时间使用，对没有技术难点的一般性开发没有帮助，反而耗费人力。