1.重构是程序员的主力技能。

是的，我之前经常也提到一点，就是好多设计模式不是提前就设计出来的，而是重构出来的。很多情况是我们在做设计的时候考虑不到的，是写代码时也考虑不到的，只有在项目上线后，客户使用过程中才会反应出来，这个时候就需要对项目进行扩展，版本升级，这时就体现老程序员实力的时候了，就是根据已有的情形，结合新的客户需求，使用合适的设计模式，使得代码能够优雅的扩展。 

2.工作日志能提升脑容量。

这个我没有什么体会，我平时也写工作日志，但是那是项目工作的需要，不是我本人的主观意愿。不过我个人觉得技术博客能够提升脑容量才是真的。很多项目中遇到的问题，解决了，也许以后还会再次遇到，也许别人也会遇到，那么就写成博客，自我总结，方便以后自己或者其他程序员遇到同样的问题。 
3.先用profiler调查，才有脸谈优化。

是的，我之前也专门做过SQLServer的性能优化，很有体会，Profiler是第一步。如果做.net代码的优化，也有对应的Profiler工具，这个可以帮我们快速的定位瓶颈在哪里。找到了瓶颈才有接下来的优化工作。 

4.注释贵精不贵多。

杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释，实际就是背景噪音。我不是很同意这个说法，还有更极端的观点是不需要注释，命名就是注释，好的命名就能注释一切。我觉得好的命名那是必须的，但是在复杂的逻辑中，我们有必要在代码中注释我们的思路，为什么会用这样一种写法。 

5.普通程序员+google=超级程序员。

确实，很多不懂的，解决不了的就Google吧，一般Google会告诉你，Stackoverflow知道答案。 
6.单元测试总是合算的。

这个观点我赞同，也许对于很多程序员来说，单元测试就是浪费时间，但是当项目复杂了以后，真的很需要单元测试，尤其是在不断的hotfix和版本升级的过程中。 
7.不要先写框架再写实现。最好反过来，从原型中提炼框架。

这个就是我前面第一点提到的一样，很多框架设计好了，但是不一定适应当前这个项目，那就是画蛇添足。
8.代码结构清晰，其它问题都不算事儿。

这个就是编码规范的问题，代码写的漂亮，让Debug没那么痛苦，让别人Review你的代码也没那么痛苦。 

9.好的项目作风硬派，

一键测试，一键发布，一键部署; 烂的项目生性猥琐，口口相传，不立文字，神神秘秘。这个也是我最近在研究的CI（持续集成），适应TeamCity可以把测试，发布，部署都自动化搞定。 

10.编码不要畏惧变化，要拥抱变化。

基于接口的编程，我们只关注接口，实现嘛，随时可以变。 

11.常充电。程序员只有一种死法：土死的。

好吧，程序员的命就是这样，技术变化太快了。 

12. 编程之事，隔离是方向，起名是关键，测试是主角，调试是补充，版本控制是后悔药。

面向接口，控制反转与依赖注入，都是编写复杂的软件的必备良药。测试，调试，没啥可说的，必备。版本控制，那是必须的！即使是只有一个开发人员的项目，也需要版本控制。 

13. 一行代码一个兵。

形成等建制才能有效指挥。单位规模不宜过大。千人班，万人排，容易变成万人坑。这里说的一个关于函数的规范问题，有一种说法是一个函数的内容不应该超过7行，如果超过7行，那么肯定是把多个Function合并到一个函数中的，应该拆分成多个函数。这个要求可能有点高，很难做到。不过上百行，上千行的函数那是不应该的，必须拆分！

14. 重构/优化/修复Bug，同时只能作一件。

这个我还是有点体会的，把多个目标合并到一次修改中，那是多么困难的事情，真的不好做。最好是分开，先重构，保证重构后的功能和原来的功能一致，然后再Fix Bug。 

15. 简单模块注意封装，复杂模块注意分层。

面向对象编程基本要点，封装，企业应用架构的基础就是分层。最经典的三层架构做企业应用的应该都知道。 

16. 人脑性能有限，整洁胜于杂乱。

读不懂的代码，尝试整理下格式; 不好用的接口，尝试重新封装下。还是说到编码规范的问题，简洁易懂，接口要清晰。 

17. 迭代速度决定工作强度。

想多快好省，简化开发流程，加快迭代速度。软件工程中的快速迭代，敏捷开发，涉及到前面提到的持续集成。 

18. 忘掉优化写代码，忘掉代码作优化。

因为过早优化，往往事倍功半; 不通过全局性能度量，优化也难有建树。不是很认同，有经验的程序员，在写代码时采用的就是最优的算法，最好的查询方式。没有什么忘掉优化写代码的事情，在写代码时，想到的就是最优的算法，因为在他看来就这种算法才是对的。

19. 最好的工具是纸笔;其次好的是markdown。

纸和笔只适用于在Face 2Face的交流过程中，交流后顶多拍照留存，根本无法建立有效的知识库，以后想到之前的讨论，怎么检索？怎么修改？。写Wiki才是王道，Markdown只是一种写Wiki的方式罢了。 

20. leader问你任务时间，你答不上来。很可能是任务拆分不够细。

细分到没有疑问吧。应该是的，如果不知道任务时间，那么说明要么你根本不懂这个任务怎么做，完全不会，要么就是任务太大了，不好估计时间。