chore: save

public/becoming-a-better-programmer-part-1/index.md

@@ -30,13 +30,13 @@ spoiler: "如何成为更好的开发者"
 
 1. 简洁：充分利用上下文。
 
-```
+```typescript
 class Widget {
   // ❌ NO GOOD
-  public numberOfWidget
+  public numberOfWidget;
 
   // ✅ YES
-  public size
+  public size;
 }
 ```
 
@@ -94,6 +94,7 @@ YAGNI 原则：you aren‘t gonna need it（你不会需要它）。不要写多
 对旧代码感到不舒服是一件耗时，它表明你已经学习到了新知识并有所提高。
 
 > 小故事
+>
 > ”只有傻瓜才会从自己的错误中吸取教训，聪明人从别人的错误中吸取教训“
 
 ![image](./images/the-ghost-of-a-codebase-past.png)
@@ -105,7 +106,9 @@ YAGNI 原则：you aren‘t gonna need it（你不会需要它）。不要写多
 正常构建只需要一个步骤，而且构建过程不需要人工干预。
 
 > 是否用简单、单一的步骤就能构建整个系统，还是需要多个单独的构建步骤？构建过程是否需要人工干预？如果只修改代码的一小部分，那么是否可以只构建修改的部分？还是必须重新构建整个项目才能处理这个小改动？
+>
 > 最终的发布版本是如何构建的，它是否与开发版本有相同的构建过程？还是必须遵循一组非常不同的步骤？
+>
 > 当构建运行时，是否输出合适的日志信息？
 
 带有好测试的代码通常也经过了很好的分解、思考和设计，这些测试是进入代码一个很好的途径，能够帮助理解代码的接口和使用模式。
@@ -392,15 +395,18 @@ YAGNI 原则：you aren‘t gonna need it（你不会需要它）。不要写多
 缩短反馈循环。
 
 > 小故事：
+>
 > 开发者：团队中没有“我”，只有我们
+>
 > 测试者：提 bug 的时候，没有“你”不行
 
 ![image](./images/testing-times.png)
 
 ## 12. 应对复杂性
 
-> 简单是一种美德，需要努力工作才能实现。需要经过学习才能学会欣赏，但人们更愿意为复杂埋单。
-> Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."——艾兹格.迪杰斯特拉
+> 简单是一种美德，需要努力工作才能实现。需要经过学习才能学会欣赏，但人们更愿意为复杂埋单。——艾兹格.迪杰斯特拉
+>
+> Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
 
 代码是复杂的，我们每天都在和复杂性做战斗。
 
@@ -468,3 +474,107 @@ YAGNI 原则：you aren‘t gonna need it（你不会需要它）。不要写多
 
 > 小故事：
 > ![image](./images/coping-with-complexity.png)
+
+### 设计之城
+
+> 功能总是决定形式
+>
+> Form ever follows function —— 路易丝.沙利文
+
+基本的项目决策是在早期做出的，以确保代码能轻松地增长，保持内聚。这些决策包括文件结构、如何命名、符合惯用法的编码风格、单元测试框架的选择以及支持基础设施等。
+
+### 合理放置功能
+
+由于一开始对系统架构有了清晰的概述，因此新功能被一致性添加到合理的功能区域中。
+
+系统架构需要开发人员投入更多，这种额外努力工作的回报就是：当需要维护或扩展系统时，工作会变得容易得多，几乎不会遇到太多的坎坷。
+
+系统架构能够帮你找到正确的位置：哪里需要添加功能，或是修改已有功能。它提供了一个模板，用来将低代码插入系统，也提供了一张地图，用来在系统中导航。
+
+### 一致性
+
+整个系统是一致的。每一层的每一个决定都是以整体设计为背景做出来的。开发人员从一开始就有意这么做，这样产生的代码都是完全匹配设计的，并且匹配已有代码。
+
+> 清晰的系统架构设计造就一致的系统。所有的决定都不应该离开系统架构的上下文。
+
+顶层设计的优雅会自然而然渗透到下层，即使在最底层。代码同样风格统一、排版整齐。清晰的设计可以保证没有重复，采用常见的设计模式，接口设计合理、符合习惯用法，每行代码都基于系统设计的上下文而编写。
+
+> 清晰的架构有助于减少功能的重复
+
+### 架构的演进
+
+系统设计被认为是可以改变和可重构的。开发团队的核心原则之一就是保持灵活敏捷（没有任何东西是刻在石头上一成不变的），因此系统架构按需而变，这鼓励我们保持设计简单可变。因此，代码可以快速增长并保持良好的内部结构。
+在系统中增加新的功能从来不是问题。
+
+> 软件架构不是一成不变的，如果需要，就可以改变。
+>
+> 想要改变，架构必须保持简单。
+
+### 延缓设计决策
+
+YAGNI 法则：如果你不需要它，就保持不变。
+
+> 当需求还不清晰时，不要做设计决策，不要猜测。
+
+### 保持质量
+
+相信系统设计，并且认为它需要被保护。设计的所有权属于团队每一个人，并愿意为之承担责任。
+
+### 管理技术债
+
+为了保证项目按时交付，一些走捷径的做法被特别批准了，为了避免在版本面临发布时再进行高风险性的更改，有细微瑕疵的代码或设计缺陷被允许合并代码库。
+这些瑕疵会被明确地标记为**技术债务**，这些缺陷是如此地明显，以至于开发人员都想除之而后快，这就是开发人员对设计质量的责任感。
+
+> 技术债（Technical Debt）类似于金融领域的贷款概念，在开发软件过程中为了快速完成某一项进度而采取的一些不规范或者不完美的实现。
+>
+> 贷款总是要还的，还款的时间越长，付出的代价就越大。
+>
+> 从长远来看，较低的代码质量意味着较长的开发时间，但是负责任的短期贷款可以加快开发速度。有时编写不够完美的代码可以被认为是“务实的”，但是务实的选择和草率的选择是有区别的。
+>
+> 有意识地管理技术债将对你大有帮助，不要让债务堆积起来，时刻让它处于显眼的位置，像真正的贷款一样，尽早偿还，避免额外付出成本。
+
+### 测试方案设计
+
+> 为系统软件一组良好的自动化设计。能够以最小的风险进行基本架构调整。同时能给你带来架构调整的运作空间。
+
+单元测试显著地影响了代码设计，保证了良好的代码架构。每个组件单元都被设计成定义良好且可独立存在的实体——必须在单元测试中单独构建该组件，而无须构建与其相关的系统的其他部分。编写单元测试可以确保每个模块都高内聚，并与其他系统松耦合。
+
+### 设计时间分配
+
+金发姑娘法则：凡事须有度，不要超出极限，刚好就行。
+
+系统设计时间刚刚好就行，既不太长也不太短。如果时间太长，程序员通常会想创建心目中的杰作（看起来总是差一点，但从来没有真正实现过）。有一点压力是好事，紧迫感有助于把事情做好。如果时间太短，就不能做出真正有价值的设计。
+
+> 良好的项目计划能带来优秀的设计你。分配足够的时间才能创造架构上的典范——这可不是即刻就能完成的事。
+
+### 与设计同行
+
+虽然项目代码规模很大，但它具有良好的一致性，易理解。开发者可以快速掌握。没有不必要的交互连接，也没有奇怪的遗留代码。
+
+因为编写代码过程问题较少，项目工作进展保持顺利。团队成员保持稳定。一定程度上是由于开发人员拥有设计的所有权，并不断改善它。
+
+团队中的每个人都不拥有专属的设计领域，任何开发人员都被期望参与到系统设计的优化中。这是反向的康威定律，优秀的软件使得团队凝聚在一起。
+
+> 团队的组织形式对生成的代码有不可避免的影响，随着时间的推移，架构反过来会影响团队协作。
+
+### 那又怎样
+
+好的软件架构来源于很多因素：
+
+1. 编写代码之前，设计先行
+2. 系统设计师的素质和经验
+3. 在开发过程中，要保持设计清晰可见
+4. 授权团队成员参与到整体设计优化中
+5. 勇于做出改变，没有什么东西是一成不变的
+6. 团队拥有合适的成员关系，确保开发团队规模合理，确保团队内部有健康的工作关系
+7. 在适当的时间做出决策，当需求不明确时，就退出决策时机
+8. 良好的项目管理和合理的项目期限
+
+> 小故事：第二系统效应
+>
+> 1.  我一直希望我的计算机像我的电话一样好用
+> 2.  梦想成真了，因为我已经不会用我的电话机了 
+>     ![image](./images/a-tale-of-two-systems.png)
+
+> 时间并不能治愈一切
+> ![image](./images/time-is-not-a-great-healer.png)