Day 14: 【架构篇】 设计与架构、软件的两大价值 (待改进中... )

「软件架构的目标是最小化 『建置和维护系统所需的人力』」

「架构的规则都是一样的！ 年轻设计师可能会认为这是无稽之谈，可能会坚定认为现在的一切都是新的、是不同的。很不幸，他们错了。即使出现那麽多新语言、框架、范式...，现在的规则与 1946 年 Alan Turing 写下第一个机器码时，并无分别」

「本书就是要来讲述这些规则的 － 那些永恒、不变的规则」

取自: Clean Architecture (p.10 & pp.xi-xiii)

CH1: 什麽是设计与结构

• 图 案例
• 公司倒闭
• TDD

迷思: 编写紊乱的 Code 可以在短期走得更快，只有长期下来才会变慢

• 过度自信: 认为未来有能力将制造的紊乱清除乾净
• 制造紊乱总是比保持整洁的开发速度还要慢
• 走的快的唯一方法是走的好

CH2: 两种价值观的故事

• 软件系统的两种价值
  • 行为 (业务价值)
  • 架构 (技术价值)

迷思: 软件系统「能动」比「好改」还重要

(原文: 软件系统能够工作比较重要，还是软件系统更容易变更比较重要?)
论证一:

1. ...
2. ...

• 确实有系统实务上不可能再改变，因为改的成本超过了带来的利益

论证二: Eisenhower 矩阵

• 困境: 业务经理没有能力评估架构的重要性
• 为架构而战
  • 软件开发团队: 必须为对公司是最好的事情而争斗
  • 软件开发团队: 有责任主张架构的重要性高於功能迫切性

「如果架构最後才出现，那麽开发系统将变得更昂贵。系统的最终修改将变得几乎不可能」

取自: Clean Architecture (p.15)

P.S. 挑战的第 14 天，笔者进入到本书後压力挺大的。下班之余常反覆翻阅 Clean 系列书及 Design Patterns、搭配 Google 查找案例，以求将本书精华呈现给读者们 (且不能误人子弟)，下笔时又常觉得废话太多掩盖了重点、排版太乱导致阅读体验不佳，或不知道该如何阐述想法 (况且自身对 Clean 的理解本来也就不是挺深的 QQ)

接下来笔者会像重构程序码般反覆重构自己的文章的。