告诫各位处于开发第一线的朋友，千万不要受本文的误导，把规范和设计文档不当回事。

我的看法：
1、文档的多少和深度决定于项目环境。
    如果是大项目，比如二三十开发人员，架构文档、需求文档、代码规范等都是必须，否则开发人员不能迅速了解项目技术和业务特点，从而无法快速开发，也即是规范可以降低培训成本和团队沟通；另外，项目开发中后期可能根本不可控，谁都看不懂其它人的代码。部署时看到的一些bug无法及时修复，因为到处都有地雷。我以前经历过这样的项目，最后加班都没用。

    如果是产品型，规范更重要。当然我说的产品可能是2.0版以后，因为这时候的产品基本得到了市场的认可。而在初版时，代码写得烂都没关系，因为你不不知道用户会不会买单，也不知道能否按进度开发完成。而在后续版本，如果没有规范文档，维护的成本都不亚于重新开发。特别是处于一线的开发人员会怨声载道：为什么要我来收拾残局？那么，这样的士气，开发效率怎么会高，项目质量怎么会高？

2、成熟型大公司那套做事流程，可能高手受不了，但可能是最优的方案。因为，到项目后期维护，往往只是一些业务功能的删减改进，不需要技术高手，这个过程可能漫漫几年，项目维护成本会非常高，雇佣高手一来他不愿意干二来也不需要这种人，如果项目代码还维持在一种“秩序”，初中级开发人员就可以胜任，有什么不好呢？
   项目上线时，是为了追求利润。项目维护期，是为了省成本。

3、刚入道的朋友，最好是按规范来，就像学武术，先要学套路。否则，养成的编程坏习惯，比如文件名叫Aaa1.java，代码没有缩进。过几年非常难改。而好的编程习惯，可以提升开发效率，还能让自己思维清晰。
   学技术阶段，一定要注意代码的可维护性、健壮性及灵活性，只有养成对代码精益求精的态度，你才可能成为技术高手。技术学好，做技术管理就有了基础，而且别人也会服你。