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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

警告即错误

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

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

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

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

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

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

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

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

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