读完《程序员修炼之道》后我想做什么

第一章——实用主义哲学

第二章——务实的方法

第 3 章 - 基本工具

第四章——务实的偏执狂

第五章 弯曲，还是折断

第六章 - 并发

第 7 章 - 编码时

第 8 章 - 项目之前

第九章——务实项目

我加入了一个读书俱乐部，读完了《程序员修炼之道》，这是一本我认为你一定要读的名著。
这本书里有很多实用的建议，你可以从今天开始借鉴。读完这本书后，我对我的日常工作和职业生涯有了不同的视角。

我把这本书给我留下最深刻印象的部分都记了下来。
我现在正在把学到的知识运用到工作中，希望能从这本非常有用的书中学到更多。

🔖 这个表情符号代表我从现在开始想做的事情。✅
这个表情符号代表我读完这本书后所做的事情。

第一章——实用主义哲学

承担责任

你应该对自己和自己的行为负责。不要轻易相信或依赖任何像网红一样的人，也不要责怪他人或事，或者编造借口，因为这既不专业，也低效。

足够好的软件

以下三点是不专业的。

• 忽略用户需求，只简单地添加新功能
• 承诺不可能的时间表
• 为了满足最后期限而削减基础工程

我有时会承诺不可能完成的时间表，甚至为了赶上最后期限而偷工减料。即使我承诺了这些，我也知道这是不可能的，但项目经理经常要求我按时完成，所以我觉得我必须这么做。
这毫无道理，而且没人会满意，因为产品可能按时完成，但无法满足管理层和用户的质量期望，这会带来问题。因此，现在我更有可能在觉得无法按时完成时告诉项目经理。✅
坦诚地讨论进度安排

建立你的投资组合

作者建议定期阅读书籍来完善你的作品集。这对我来说很有道理，因为通过阅读，我可以得到一些实用且有条理的建议，所以我正在努力阅读更多书籍。🔖
阅读技术和非技术书籍

交流！

读完这个主题后，我回顾了我编写提交信息的方式。这本书没有提到提交信息，但我认为提交信息是沟通工具之一。所以我开始使用 约定式提交。到目前为止，它还不错，因为它更容易理解提交日志。✅
已实施约定式提交

第二章——务实的方法

ETC

技巧 14 好的设计比坏的设计更容易改变

ETC（Easier to Change，易于改变）原则是一种价值观，它能帮助你做出决策。它并非规则，而应该引导你走向正确的方向。
为了获得这一价值观，你应该时刻意识到需要强化它。

有时，你不知道如何让代码更容易修改。在这种情况下，你可以做两件事。

1. 尽量使你写的内容可替换
2. 请注意，当您不确定在工程日记中要做什么时

我遇到过一些情况，我不知道该怎么办，但我从未把它们写下来。所以我无法回顾和评估这些情况。🔖
当我毫无头绪时，记录下来，并进行回顾和评估，以克服工作中的障碍。

干燥

只有一种方法才能可靠地开发软件，并使我们的开发更容易理解和维护。那就是 DRY 原则。
这仅仅是代码重复吗？不。这是知识和意图的重复。这只是巧合，而不是重复。
如果一个简单的修复就导致其他代码发生变化，那么就有可能违反 DRY 原则。

当您加入新团队或项目时，我们在读书俱乐部讨论了以下 DRY。

• 通过 Pull Request 审查来共享知识，以防止违反 DRY
• 与团队分享你要做的事情
• 用工具检测一下，但可能太多了

准确度如何才算足够准确？

截止日期越短，估算听起来就越准确。
但是，当你被要求估算截止日期时，你应该说“我会回复你”。这样几乎总能得到更好的结果。

第 3 章 - 基本工具

贝壳游戏

本节讨论的是 GUI。你也应该使用 CUI，因为 GUI 环境通常受限于其设计者所期望的功能。🔖
避免仅使用 GUI

调试

当我读到这部分内容时，我突然想在自己还是初级开发人员的时候也读一读。调试时有很多有用的事情你应该做。

调试时您应该执行以下操作：

• 不要恐慌
• 调试时谨防近视
• 确保你正在编写的代码是干净构建的
• 尝试解决任何问题时收集所有相关数据
• 可能需要采访报告错误的用户，以收集比最初提供的更多的数据
• 读取错误消息
• 向其他人解释这个 bug。你可能会突然对这个问题有了新的认识
• 不应该首先怀疑操作系统、编译器或第三方产品
• 不要假设，要证明

二进制砍伐

我了解到 Git 中有一个二进制分割功能，叫做 git-bisect。

第四章——务实的偏执狂

契约式设计

为什么DBC没有得到更广泛的应用？
我认为有两个原因。

1. 实施起来很困难
   1. OOP 不支持继承断言，因此存在创建重复的方法
   2. 使用后置条件的前提条件无法保存
2. 每个人都有不同的要求

如果要实现动态连接 (DBC)，就应该考虑先决条件、后置条件和类不变量。这些因素迫使我们思考并投入大量时间。投入时间的回报是构建一个可靠的系统，但并非所有系统都希望获得这样的回报。
我认为这类似于这个问题：静态类型和动态类型哪个更好？静态类型语言使用得越多，系统就越安全。但并非所有人都使用静态类型语言，因为每个人的需求都不同。
这就是 DBC 没有得到更广泛应用的原因。即使不使用 DBC，你或许会提前检查输入值，这与先决条件类似，或者你可能会进行测试，这与后置条件类似。因此，你可以说你部分实现了 DBC。
此外，DBC 的概念很重要，因为你可以决定在合约中应该做什么，这样会更安全。

断言

我在谷歌搜索“断言”时，看到一些文章说应该在生产环境中关闭断言功能。但作者说，应该只关闭那些真正影响性能的断言。这很有道理。我觉得在生产环境中关闭断言很奇怪，因为我们甚至不知道性能是否受到影响。

第五章 弯曲，还是折断

解耦

解耦很重要，因为它也更容易更改（ETC）。我们在第二章学习了ETC。
本节将介绍TDA（告知，不询问）原则。通过将对象的值告知为方法，开发人员无需询问对象的值。
但这仅仅是一个帮助我们识别问题的模式。你不应该仅仅遵循它。在每个应用程序中，都有一些通用的顶层概念。

迪米特法则

应用程序中的任何内容都应被视为可能发生变化。因此，访问某些内容时，请尽量不要使用多个“.”链。

玩弄现实世界

引入了一种名为 FSM（有限状态机）的策略。它使用一个数组表来管理状态和事件。这是一种处理工作流需求的好方法，并且能够将状态保存在外部存储中。🔖
查找 FSM 策略的应用

第六章 - 并发

我在实践中没有太多使用并发，也没有注意到任何事情。

第 7 章 - 编码时

重构

重构不是偶尔为之的活动，而是日常活动。
如果你想重构，我认为它需要测试用例。这意味着如果你不测试，重构就太难了。下一个主题是关于测试的，它是编程中非常重要和核心的东西。我可以从这本书中学习。

测试代码

你为什么要测试？只是为了找bug吗？不。“技巧66：测试不是为了找bug”
测试有很多有用的活动。例如，思考编写测试让我们从外部审视它，你可以减少代码的耦合度并提高灵活性。测试是你代码的第一个用户。它非常重要也很有用。
有一种实现软件编程的方法叫做测试驱动开发（TDD）。它对刚开始接触测试的人有好处，但你不应该成为TDD的奴隶。不要忘记时不时停下来看看大局。
我认为测试是编程中非常重要的一部分。如果你不做测试，你就无法重构、找到损坏的窗口、减少耦合等等。相反，如果你做了测试，你的系统就有很大的改进空间。

第 8 章 - 项目之前

需求是一个过程

需求并非绝对。因此，客户和开发人员之间互相沟通，比单打独斗或单打独斗效果更好。需求是在反馈循环中学习的。本书将其表达为“探索”。🔖
探索。不要强加你的想法或建议。

结对编程

读书俱乐部的一位参与者问起结对编程，感觉就像消耗了两个人力资源。一位熟悉结对编程的人回答道：

• 从长远来看，这将带来良好的回报，因为低技能的人可以向高技能的人学习，从而弥补水平差距。
• 结对编程时，你可以在 Pull 请求中指出你想说的评论。这值得两个人的资源投入。

第九章——务实项目

椰子不切

软件开发没有单一的计划可以遵循。所以当我成为高级开发人员时，我应该避免只遵循一个计划。我认为，如果我们能够从计划中汲取优点，并与团队成员沟通改进，那就太好了。

让您的用户满意

无论我的头衔是什么，我都希望成为一名问题解决者并让用户满意，而不仅仅是编写代码。

《傲慢与偏见》

🔖 拥有自豪感！