多看上看的,写的是一些开发中常常遇到的问题以及解决方案,整理出来,以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)