《高效程序员的45 个习惯》读书笔记

[align=center][img]http://t.douban.com/lpic/s4073509.jpg[/img][/align]

本书和其他的"怎么写好出优秀的程序"的书籍基本没有什么两样. 如果说要有些区别的话, 就是里面添加了一些敏捷的元素.
另外为了说明某个问题, 里面的一些比喻非常有趣.

对于里面一些觉得对自己有益的东东, 做了一些笔记.

你深知怎样才是正确的, 或者至少知道目前的做法是错误的. 要有勇气向其他的项目成员, 老板或者客户解释你的不同观点. 当然, 这并不容易. 也许你会拖延项目的进度, 冒犯项目经理, 甚至惹恼投资人, 但是你都要不顾一切, 向着正确的方向前进.

做正确的事, 要诚实, 要有勇气去说出实情. 有时这样做很困难, 所以我们要有足够的勇气.

不停的问为什么, 不能只满足于别人告诉你表面现象. 要不停地提出知道你问明白问题的根源为止.

问问题, 你有可能会跑题, 问了一些与主题无关的问题. 就好比是, 如果汽车启动不了, 你问是不是轮胎出了问题, 这是没有任何帮助的, 问"为什么", 但是要问到点子上.

"这个, 我不知道"是一个好的起点, 应该由此进行进一步的调查, 而不应该到此戛然而止.

以固定有规律的长度进行迭代, 也许刚开始你要调整迭代的长度, 找到团队最舒服可行的时间值, 但之后就必须要坚持.

好的设计应该是正确的, 而不是精确的, 也就是说, 它描述的一切必须是正确的, 不应该涉及到不正确或者可能会发生变化的细节, 它是目标, 而不是具体的处方.

你依赖单元测试, 如果代码没有测试, 你就会觉得很不舒服, 就像是高空作业没有系安全带一样.

开发代码时, 更应该注重可读性, 而不是只图自己方便, 代码阅读的次数要远远操作编写的次数, 所以在编写的时候值得花点功夫让它读起来更加简单. 实际上, 从衡量标准上来看, 代码清晰程度的优先级排在执行效率之前.

注释有时候是为了帮写的不好的代码补漏.

代码必须明确说出你的意图, 而且必须富有表现力, 这样可以让代码更易于被别人阅读和理解. 代码不让人迷惑, 也就减少发生潜在错误的可能. 一言以蔽之, 代码应意图清晰, 表达明确.

应该让自己或团队的其他任何人, 可以读懂自己一年前写的代码, 而且只读一遍就知道它的运行机制.

解释代码做了些什么的注释用处不那么大, 相反, 注释要说明为什么会这样写代码.

编写代码的时候, 要经常留心可以改进的微小方面, 这可能改善代码的可读性. 也许你会发现可以把一个方法拆成几个更小的方法, 使其更易于测试.

在写几行代码之后, 你会迫切地希望进行一次构建/测试循环, 在没有得到反馈时, 你不想走得太远.

如果你和测试循环花费的时间过长, 你就不会经常运行他们了, 要保证测试可以快速运行.

优雅的代码第一眼看上去, 就知道它的用处, 而且很简洁.

代码几乎总是可以得到进一步精炼, 但是到了某个点之后, 在做改进就不会带来任何实质性的好处了.

当然简单的解决方案必须要满足功能需求. 为了简单那而在功能上妥协, 这就是过分简化了.

假定把所有的衣服都扔到抽屉里, 当需要找一双袜子的时候, 要翻遍里面所有的衣服:裤子, 内衣, T恤等, 才能找到. 这很麻烦, 特别是在赶时间的时候. 现在假定所有的袜子都放在一个抽屉里面(而且是成双放置的), 全部的T恤放在另外一个抽屉中, 其他衣服也分门别类, 要找到一双袜子, 只要打开一个抽屉就可以了.

类也要遵循内聚性, 如果一个类的方法和属性共同完成了一个功能(或一系列紧密相关的功能), 这个类就是内聚性的.

一个更具有内聚性的组件不会有太多导致其变换的原因, 也因此更加稳定.

面向过程的代码取得信息, 然后做出决策, 面向对象的代码让别的对象去做事情.

作为某段代码的调用者, 开发人员绝对不应该基于被调用对象的状态来做任何决策, 更不能去改变该对象的状态, 这样的逻辑应该是被调用对象的责任, 而不是你的. 在该对象之外替他做决策, 就违反了它的封装原则, 而且为bug提供了滋生的土壤.

假定送报男孩来到你的门前, 要求你付给他本周的报酬, 你转过身去, 让送报男孩从你后屁股兜里掏出钱包, 并且从中拿走两美元(你希望是这么多), 再把钱包放回去. 这个过程中, 送报男孩作为调用者应该告诉客户付给他两美元, 他不能探究客户端财务状况, 或者钱包的厚薄, 他也不能代替客户做任何决策. 这都是客户的责任, 而不属于送报男孩. 敏捷代码也应该以同样的方式工作.

要遵循里氏替换原则, 相对基类的对应方法, 派生类服务(方法)应该不要求更多, 不承诺更少, 要可以进行自由的替换, 在设计类的继承层次时, 这个一个非常重要的考虑因素.

记录问题的日志内容:
问题发生的日期
问题简述
解决方案详细描述
应用文章或者网址, 以提示更多细节或相关信息.
任何代码片段, 设置或对话框截屏, 只要他们是解决方案的一部分, 或者可以帮助更深入地理解相关细节.

记录问题的时间不能超过解决问题的时间. 要保持轻量级和简单, 不必达到对外发布式的质量.

要记录团队做出一个重要决策的原因, 否则, 在6~9个月之后, 想要重新回顾决策过程的时候, 这些细节就很难再记得了.

警告即错误

在解决问题时, 要将问题域与周边环境隔离开, 特别是在大型系统应用中.

由于大家都是在团队中一起工作, 每个人都要修改自己的个人编码习惯, 来适应团队的其他成员.

关于站立会议
要保证会议议题不会发散, 每个人都应该回答下述三个问题:
昨天有什么收获?
今天计划要做哪些工作?
面临哪些障碍

只能给予每个参与者很少的发言时间(大约两分钟), 也许要用计时器来帮助某些收不住话头的人, 如果要详细讨论某些问题, 可以在站立会议之后, 在召集相关人员(在回忆中说"我需要跟Fred和Wilma讨论一下数据库"是没有问题的, 但是不要是深入讨论细节.)

一般来说, 在大家到公司之后的半个小时到一个小时之内举行, 是个不错的选择.

每日站立会议的好处:
让大家尽快投入到一天的工作中来
如果某个开发人员在某一个点上有问题, 他可以趁机将问题公开, 并积极寻求帮助.
帮助TL了解哪些领域需要更多的帮助, 并重新分配人手.
让团队成员知道项目其他部分的进展情况.
帮助团队识别是否在某些东西上有重复劳动而耗费了精力, 或者是不是某个问题有人已有现成的解决方案.
通过促进代码和思路的共享, 来提升开发速度.
鼓励向前的动力:看到别人报告的进度都在前进, 会彼此形成激励.

注意事项:
站立会议的时间最多不能超过30分钟, 10~15分钟比较理想.
虽然大多数团队需要每天都碰头, 但是对于小型团队来说, 这样做可能有些过头了, 不妨两天举行一次, 或者一周两次, 这对小团队来说足够了.
如果觉得站立会议是浪费时间, 那可能是大家都还没有形成真正的团队意识. 这并不是坏事, 有利于针对问题进行改正.

最基本的code review列表
代码是否被读懂和理解
是否有任何明显的错误
代码是否会对应用的其他部分产生不良影响?
是否存在重复的代码?
是否存在可疑改进或重构的部分?

代码复查需要积极评估代码的设计和清晰程度, 而不只是考量变量名和代码格式是否符合组织的标准