读书笔记《代码整洁之道——程序员的职业修养》

这部书老早的都该翻完了,结果因为各种的使其overdue。另外,关于这本书,实际上并不是《代码整洁之道》,二更是偏向于后面的程序员职业修养的部分。其中的内容呢,更多的是作为工作中的“指南手册”。让我想到前面的一本书《时间管理–写给系统管理员》,里面写的是在工作时候的事情处理,以及一些情况的应对。

所以,这篇文章给这本书收个尾。

书的前言

书的前言,使用“挑战者”号的失事事件为引子。陈述了在一个巨大体系中的管理的问题。由于管理人员自已以为自己是专业人士,忽略工程师一次又一次的警告和建议。这些问题的一点又一点的积累最终导致了这灾难的发生。

即使工程师们早就知道这种问题的存在,最后还是没有改变结果。管理人员心存侥幸,希望一切相安无事,认为自己才是专家,他们的恐慌,希望,直觉才是准的。刚刚好遇上现在的《Chernobyl》,一个个的错误,导致了灾难。

遇到不合理的事情,需要及时的质疑,不能因为自己心中所想的“他是专业人士”来默默的吞掉疑问,无条件信任。一个专业人士的态度不应该是:“我们尽力而为吧”。而会以“这是我们的承诺,如果你想调整,请随时联系我们”。

如何变得专业

去承担责任,不要破坏代码的结结构,代码本身的结构要;可能的灵活,避免代码结构的僵化。

不能铭记过去的人,注定要重蹈覆辙。

坚持学习,不断涉猎新的技术。另外,没事的时候可以做做Kata来练练脑子。

同意或拒绝

这个在前面那本时间管理的书里面又提到过的。

能就是能,不能就是不能。不要说‘试试看’。

奴隶没有权利说不。但是专业人士应该懂得说不。事实上优秀的经历总是对敢于说不的人求贤若渴。敢于说不,才能真正做成一些事情。因为试试看是一句模糊的话,一方有着百分之八十的期待,一方只有百分之二十的把握,这样往往会导致,“还没完成?”,“还需要些时间”这种灾难性结果。

当无法明确完成的时候,和经理确定最低的可能的期望功能。所以,敢于说不。


作出承诺包含三个步骤:口头上说自己将会去做,心里认真对待作出的承诺,真正的付诸行动。书里面写了很多的有趣的场景:

- 问“为什么网络这么慢”,回答“我们是得再弄点路由器了”
- 老板说:“我们进度需要快点”,“好”

我们总会有器官的感觉,觉得大多数的时候他们并没有全力去兑现呢?在这些承诺里面都有给自己开脱的词汇:“需要/应当”,“希望/但愿”,“让我们”。

尽可能地使用正式承诺,确保各方能无误地理解承诺地内容。

编码的技巧

关键在于具备信心,和出错感知能力
代码需要:

  1. 能工作
  2. 解决客户问题
  3. 和系统结合
  4. 代码易读

在心烦意乱的时候,千万不要敲代码!。


中断的恢复,结对工作,或者是使用TDD,来进行开发驱动。

不要对十天之内全部完成特性开发抱有任何期望,这种期望有可能杀死整个项目。

测试驱动开发

使用TDD,Java有了30秒一次的运行周期。使用测试样例来控制正确需求。TDD的确可行,此时已有定论,争论已经结束。

TDD的三个原则

  • 编好失败单元测试之前,不写产品代码。
  • 一个单元测试失败了,就不要写测试了。来解决它先
  • 产品代码恰好让当前的失败通过即可。

需求沟通

很多时候,出现了过早的精细化过迟的模糊性,前者指的是过早的精确后面要得到什么,使得一味的向目标靠近反而浪费了成本。过迟的模糊化导致在最后需求已经被完成后不符合单方预期,导致需求双方的分歧。

时间管理

番茄工作法

拒绝杂事

适时离席

项目立会,每天一个会议,每次不超过十分钟。“昨天干了什么,今天打算干什么,遇到什么问题”。

凡是不能再五分钟内解决的整论,都不能靠辩论解决

留下点什么吧