《高效程序员的45个习惯》notes

 

多看上看的，写的是一些开发中常常遇到的问题以及解决方案，整理出来，以xxx个习惯的方式呈现。 

命名学的是《高效能人士的7个习惯》，岔开说一句，中文读起来很有山寨鸡汤感，其实内容都是不错的。

内容上，对于刚开始开发的人会有不错的指导作用，如果经验不是很多的话，先照着做，然后在实践中一点点去体会和修正也是不错的。 

对于有一些开发经验的人来说，对于里面的每一个小点，可能都了解甚至实践很多，但是不妨从另外一个视角来看，就是系统性，起码我个人来说，能集中的过一遍开发中涉及的方方面面，去反思和抽象，也很有收获。这个文章里也就从这几个方面来看这些： 
真实和事实为大 

在实际开发中，需要一直面向真实的结果，并在点点滴滴中警惕这一点，比如文中提到的： 

- 痴迷于方法，而导致空做了很多动作（甚至很多可以说是标准实践），最后真实的项目进度没有进展 

- 使用了大量的设计模式，导致问题并没有以最高质量最高效的解决（包括运行效率和开发效率） 

- 前期收集了客户需求，随着时间的变化，客户的想法变了，或者市场情况变了，但依旧没有做相应的调整 

- 随着时间的变化，计划受到冲击，去没有做到实际的调整 

所有这些可以说是有无穷多的变种，实际项目中也遇到大量的失败案例. 

就个人的经验来看，原则性的始终要保持对这些问题的敏感是不错的： 

- 当前重要的问题是什么 

- 我们是否朝着正确的方向前进，在这些方向上进度如何 

看起来并不难，这背后有两个因素需要我们去深度注意： 

- 面对事实谦卑的心–不要固执己见等等，错了就是错了，面对事实，尽可能的让事情向好的方向去发展即可 

- 对于真实情况的洞察 

- 大量经验的积累，反思，总结，向更优秀的人的学习。。。 

- 把握合理的火候，不多不少

坦率，务实与行动 

团队需要有一个务实坦率的风格，能够做到对事不对人，这个知易行难，大部分情况，少非议别人的失误，是一个职场生存之道，不管多少人旗帜鲜明的反对”会做人“这一点，在一个一般性团队中，务实坦率就是非常的困难，但就个人所见这不是不可能。 

引用查理芒格的反向说法：这的确是人之常情，但是如果你能克服这一点，你或你的团队就是会有长足的进步。 

所以，团队一旦迈出了坦率与务实这一步，接下来就会迎来下一个进展，更容易面向真实的情况，比如书中提到的：
不能让不写代码的人担任架构师：实际情况中的确有，因为种种原因，一个人掌握着项目的技术方向，但是自己却不写代码，不写代码就会导致代码能力和判断力的稳步下降，再到后面，也不敢写了，身居要职，写出让大家嘲笑的代码怎么办？
无惧错误，只有不做事的人才不会犯错误，大家平和的看待，理性的对待就好
行动胜过千言万语

分而治之 

分治这就是一个非常好的智慧，无需多言。 

在实践中的例子非常多： 

- 持续集成，自动构建，自动测试，持续迭代 

- 保持一直有一个可玩的版本（游戏业如此，比如naughty dog，其他行业就是一个可用的版本） 

- 工作中，把事情进行分解，然后一步步去实现和反馈。。。 

论证分而治之为何有效就没必要了，实际项目中，有这两个问题会影响大家去运用这个原则： 

- 嫌麻烦：嫌一个个小东西的麻烦，最后导致一个大型的麻烦，甚至导致开发的东西被cancel掉，这其实是糖果实验里的那种情况（小孩给3个糖，5分钟不吃就再给两个，否则就不给），不到不得已不会行动这种情况，有时候或许是无解的。 

- 自负：小东西没劲，来个大的才爽，其实这个并不是一个绝对的不好，这样可能会稳步的增加自己hold住大模块的能力，但是具体事情上么，个人觉得随着实践的增加，会发现这其实没必要，引用涨工资对于乔丹”花哨运球“的说法： 

”打篮球到后来，都是大道至简，举重若轻。艾弗森2001年都不像1997年那么花哨了。为什么？用不着了。1997年总决赛第一场，乔丹最后那个绝杀。三分线外接球，右手拍了三下球，重心是往右走的；忽然换到左手，脚步调整了一下，是要起速或原地投篮的架势；拉塞尔重心刚来的及侧到乔丹左手边，乔丹左手运一步，忽然急停跳投，拉塞尔都来不及起跳，绝杀。这个球里，包含了向右走、向左走、原地投篮三个假动作选项，最后又用一记突破假动作钉住了拉塞尔下盘，最后一个投篮。 

而且时间把握得刚刚好，球进钟响。 

什么叫分寸、精确、老练，都在里面了。 

如果能这么举重若轻解决问题，为什么还要跟街头斗牛一样，把自己腿拧成麻花来晃人呢？“

好的实践 

这里就比较杂了，列一下：
代码要简洁优雅
文档恰到好处，如果代码可以自解释，就无需文档了
团队协作，注意人与人之间的关系，礼貌，和把注意力集中在事情上（起码第一优先级不应该是谁应该对此负责，谁应该被责备上）都是非常有力的
代码review，这个好处非常多，一些顶尖的优秀公司是严格遵守这一条的， 

review情况下，总的质量和开发时间（如果不review，可能更多地时间来处理问题等等），这个也是赞同的，但是实际情况中需要考虑本文的第一原则，项目的真实情况和重点所在，如果实现过程中，需要快速搞定（美术协作，过milestone决定项目生死），那么先fast&dirty，然后回头整理的借贷式开发是更优的选择（http://blog.csdn.net/toughbro/article/details/22776277）
转载自：http://blog.csdn.net/toughbro/article/details/46872877