总体评价

整本书有点标题党，是想蹭《修改代码的艺术》的热度吧。整本书实质上是作者在敏捷和TDD实践过程中的一些心得。不少观点也很有启发意义，还是值得一读的。

阅读感悟

  • 许多bug都是只在集成阶段才会出现，所以越早集成就越能发现风险。（敏捷的理由）

  • 软件与建筑的区别是盖房子不会想着将来会怎么再加装一层，而软件必须要面向扩展去构建。

  • 过期的注释比没有注释更加糟糕，这会使得代码成为谎言。

  • 注释应该去描述代码的缘由而非解释代码的行为，代码的行为应该是自解释的。

  • 繁复的流程会让各个环节对立，各个环节的对立会引来不信任，不信任会导致更多的流程。复杂的流程并不能帮助软件项目成功。

  • 软件开发过程本质上是一个创造过程，流程无法支配创造力。

  • 掌握一门编程语言并不能使你成为软件开发者，正如掌握一门自然语言并不能使你成为作家。

  • 80%的软件开销花费在软件初始版本发布之后：软件初始版本（20%），发布后的错误修正（17%），各种优化（60%）以及其他。PS：这个数据作者没有注明来源，但符合我的经验。
  • “精益”理论认为，所有已经开展但尚未完成以至无法为客户创造价值的开发任务就是软件行业的浪费——正如传统制造业仓储的浪费一样。
  • 保留独立的质量保证过程，让开发者把软件交给测试人员验证，这是昂贵而且低效的。保留这样的行为然后实施站会或者两周迭代并不会取得多大改进。
  • 故事的目标是引发对话，而且让对话的主题从如何去做变为做什么和为什么这么做，从而激发软件开发者的原动力。
  • 敏捷本质上是范围控制。范围越小，就越容易预估、实现和验证。
  • 日常世界的东西是有弹性的，是能容错的，但是软件代码却是错了一个拼写都会出问题。所以软件开发是反直觉的。
  • 度量软件开发的7个策略。PS:这7个指标让人大开眼界
    • 度量产生价值的时间：从开始要做到最终用户感受到价值之间的时间。可以用来衡量效率。
    • 度量编码时间：有多少时间是花在了编码上，而不是在开会、写报告等等。可以用来衡量组织/流程是否合理。
    • 度量缺陷密度：每千行代码里有多少个缺陷。缺陷表面是是由程序员写出来，但深层次原因是开发流程的问题。可以用来衡量开发流程是不是出问题了。
    • 度量发现缺陷的时间：从代码写出来，到发现代码里的缺陷中间的时间有多长？这是真正的降低风险和成本的指标。
    • 度量功能的客户价值：我们都知道功能的客户价值不同，但在真正的开发过程中有没有向高价值的功能上倾斜呢？
    • 度量未交付功能的损失：不做会有什么损失？这个指标结合上个指标是衡量这个功能要不要做，该以什么优先级做的思维逻辑。
    • 度量反馈回路的效率：迭代的目的是为了快速得到反馈，那么反馈回路通畅吗？效率如何？PS:看的我大汗淋漓
  • 故事应该短小、专注、目的单一、最小化依赖、容易验证。
  • 把持续集成当作项目的心跳。
  • 伙伴编程：每天的最后一个小时里，你和你的伙伴对一天的工作进行代码审查。每天或者每周轮换伙伴。PS:值得尝试
  • 何谓整洁？C内聚、L松耦合、E封装、A自主、N没有冗余。
  • 重构是在不改变外部行为的前提下修改设计的过程。
  • 最佳实践之一：在问如何做之前先问做什么，为什么做、给谁做。
  • 最佳实践之二：小批次构建。
  • 最佳实践之三：持续集成。
  • 最佳实践之四：协作。
  • 最佳实践之五：编写整洁的代码。
  • 最佳实践之六：测试先行。
  • 最佳实践之七：用测试描述行为。
  • 最佳实践之八：最后实现设计。PS:作者的意思是先去实现，然后回过头来再来考虑设计，然后再来重构。有一定道理
  • 最佳实践之九：重构遗留代码。

书籍信息

中文书名：修改软件的艺术
英文书名：Beyond Legacy Code
作者：[美] David Scott Bernstein
译者：李满庆