划重点：
1、详细设计文档没必要全部都要写
并不是软件所有的模块都需要写详细的设计文档的，如果该模 块的实现方法已经很成熟，成为项目组的“常识”，这些内容没有必要额外再写文档
2、在有限时间内给出最合适的解决方案，而不是最好的
实际上我们不太可能做出一个“最好”的或者说“完美无缺”的设计，因为有以下的条件限制：
1.有限的项目工期。
2.有限的项目预算。
3.项目成员的能力条件限制。
软件设计是高难度的技术活，需要你做出适当的取舍和平衡，做出一个合适的设计。
3、高性价比
但高性价比的设计意味着：
1.公司项目的利润更加大，公司赚钱更多了，咱们能分到的钱也就更多了。
2.项目工作更加简单，项目组不需要加班或少加班就能完成工作。
3.高性价比设计是挑战智力的工作，会让你的工作更加有愉悦感和成就感。
所以为了公司好、你好、大家好，向“高性价比设计”的目标进发吧！
4、设计文档要从实际应用角度出发
设计文档应该达到这样的效果：对项目当前的工作有用，能帮助我立刻解决问题！如果设计文档不能达到这样的效果，就不能驱动项目组写好设计文档。
设计文档必须先保证对自己、对项目组本身的当前工作有用，在这前提下有条件才去考虑对自己的将来有用、对别人有用。也只有立足于这个出发点下，才可能写出有实际价值的文档，文档不是摆设，是要立马在工作中用上的。
5、需要写设计文档的地方
一般在以下情况下才写该模块的详细设计文档：
1）算法比较复杂；
2）想法不太成熟；
3）负责该模块的程序员是新人等。
4.用户体验设计文档一般也不可缺，但文档的内容一般不会覆盖软件的全部内容，成为“常识”的内容不需要写。
6、规则的可执行性
有效有用的编码规范可以很简单，最开始的时候可以一页纸就搞定！
我们只需要总结出当前编码中出现的问题，针对性地定出规范，只制定当前能执行的规范，不能执行的不要写进去，这样很快一页纸的规范就可以定出来，并且大家都愿意执行。规范不在于长短，不在于参考了什么“伟大”的标准，关键是能不能执行！
7、代码评审早点做
代码评审应该在早期就做，高手评初手，评审主要目的不仅仅为了发现和解决问题，更重要的是提升程序员的水平。程序员水平提升后，评审就可以减少次数甚至不需要。
8、程序员对自己代码要有基本要求
作为程序员来说必须做到以下两点的最基本质量要求：
1）你的程序能编译通过；
2）你的程序能通过“冒烟测试”。
通过冒烟测试是指：
1）模拟用户的最常见的正常操作，程序不会出错。
2）点击所有能点击的按钮、菜单等，程序不会出错。
这个冒烟测试是程序员自己做的，程序员们要自己擦干净自己的屁股噢！
9、测试真的很重要
测试至少要成为第二熟悉需求的人
项目中最熟悉需求的人通常就是项目经理，或者是需求分析师（产品经理）
10、拒绝半个人
不少项目后期才安排测试人员进入，而且测试人员还需要同时负责另外一个项目的测试，你最多只能得到“半个测试工程师”。
测试需要从项目的一开始就介入，并且每个项目至少要配备一名“完整”的测试。
11、在必要的地方写测试用例
我们只需要对比较复杂的、容易出错的、有难度的地方，写出相应的测试用例，测试用例的描述在于描述清楚测试思路，不需要事无大小都写下来。
当条件成熟的时候，公司可以逐步建立测试用例库，对常见的情况建立测试指南，让所有的测试人员去学习和参考，项目中遇到类似的情况就可以直接参照用例库了，不需要再写一次测试用例。
12、优秀的测试也是一名优秀的开发
我的观点是：一名优秀的测试同时也应该是一名优秀的开发，一名优秀的开发同时也应该是一名优秀的测试！
但目前常见的现状是：
1）能做好测试的优秀开发有，但数量不多；更多的是没有测试意识、代码质量很差的程序员。
2）测试大部分是不懂开发的，我们认为优秀的测试往往也是不懂开发的。
13、项目管理是全员的事情
项目管理是每一个人的事情，而不仅仅是项目经理的事情，每一个人至少需要做到：
1）全力完成工作，要保证工作质量；
2）要主动报告进度，遇到风险和问题要主动提出来；
3）要主动管理好自己的工作产品；（做好自己工作产品的配置管理）
4）要主动协助同事完成工作；
5）要主动沟通。
14、项目管理者最优先要做的事情：
就是保证大家都在做正确的事情
