「你因为两个原因来读这本书：首先，你是位程序设计师。再者，你想成为一位更好的程序设计师」

取自: Clean Code (p.1)

前言

• 本系列文笔者尝试将大神 Robert C. Martin (aka Uncle Bob，为敏捷软件开发的初代推手之一、SOLID 设计原则提出者) 笔下三本经典大作浓缩，并以简单的程序范例及补充，将 "Clean" 开发理念分享给各位读者。接下来我们将依序导读:
  • 无瑕的程序码：敏捷软件开发技巧守则 (Clean Code)
  • 无瑕的程序码番外篇：专业程序设计师的生存之道 (The Clean Coder)
  • 无瑕的程序码－整洁的软件设计与架构篇 (Clean Architecture)

什麽是 Clean Architecture?

• 整洁软件架构 (Clean Architecture) 的目的说穿了只有一个 － 最小化『建置和维护系统所需的人力』
  或者，我们也许能说，是为了最小化在整个软件专案生命周期中，为了达到相对应业务需求所需投入的资源及成本 (包含资金、开发 & 维运人力、时间、运算资源...等)

  "The goal of software architecture is to minimize the human resources required to build and maintain the required system."

• 并不是为了一昧 解耦 (Decoupling) 而硬是为软件画分出无数的层次 (Layers) 和边界 (Boundaries) 。这导致为了完成很简单的需求，却需要一并为沿途来回所经过的无数层次处理相对应的资料结构和通讯方法

  「实际上，最大的错误是 『过度架构 (Over-Architecture)』 。层数比我在这里描述的还要多许多，这大大降低了团队的生产力。整个工具被废弃了，取而代之的是一个小团队所编写的一个可爱小应用程序」

• 也不是为了避免程序码重复 (Duplicate) 而不考虑元件 (Component) 和类别 (Class) 的设计原则、依赖关系...等，直接将所看到的共用程序码都提取到父类别或者某些介面。导致软件的 可扩展性 (Extensibility) 下降

  「架构师往往会陷入一个陷阱 － 这个陷阱取决於对重复 (Duplication) 的恐惧」

• 除此之外，魔鬼也藏在实作细节中。你能想像团队只要误用某一种修饰子 (Access Modifier)，就有可能导致精心设计的架构遭到严重破坏吗?

  "The net result is that if you ignore the packages (because they don’t provide
  any means of encapsulation and hiding), it doesn’t really matter which architectural style you’re aspiring to create."

• 而谈到细节 (Details)，现代软件工程提供了各式各样的 Web & GUI、Databases、Frameworks，身为好的软件架构师，又该如何考量呢?

  「优秀的架构师会小心地将细节从策略中分离出来，使策略与细节测底脱钩，不以细节为依据。尽可能地延缓有关细节的决定」

最後以软件架构与设计作为前言结尾，现代软件工程随着时间发展出了许多的架构...

• 水平横向分层架构 (Horizontal Layer Architecture)
• 服务导向架构 (Service-oriented architecture)
• 六角形架构 (Hexagonal Architecture)
• C4 Model (Context, Containers, Components, and Code)
• 领域驱动设计 (Domain-Driven Design)
• 整洁的软件架构 (Uncle Bob's Clean Architecture)
• ...

我们是否能归纳出一些共通的本质呢?

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

在後面的文章，我们会慢慢开始揭露这些如蜂巢、如洋葱般的层层设计架构。在这之前我们先来思考......

为什麽要解耦? (Decoupling)

• 虽然过度追求解耦可能衍生过度设计 (Over-Design) 的问题，了解耦合性相关的议题仍然是学习软件架构的重要入门课

• 软件模组间的依赖性 (Dependency) 高会发生什麽? 直接看一个真实的例子:

  • 80年代某不愿具名软件公司的内部统计资料:
    工程人员的增长:
    
    同一时期的生产力:
    
    每行程序码的平均成本:
    

• 我们可以看到

  • 随产品释出的次数与版本增加，参与专案的人员数、产值，以及开发成本之间的非线性关系
  • 即便工程师们持续加班，程序的产能几乎没有增加
  • 此时，专案重构的成本已经大於打掉重建了......

「当对程序码的整洁程度或设计的结构没有多少想法时，那你就会跟这条曲线一样走到最终悲惨的结局」

取自: Clean Architecture (p.6)

为什麽要写 Clean Code?

承上，甚至我们可以看到更严重的後果：

「我知道有一间公司在 80 年代後期开发了一个杀手级应用，但後来发行的周期开始拖长，程序里的错误也无法在下次发行之前修复，程序载入的时间与崩溃机率也愈来愈长和高。不久，这家公司就倒闭了。我问他当时发生了什麽...」

「急於将产品上市，导致他们的程序码变得一团糟，当他们加入愈来愈多的产品特点时，程序码就变得愈来愈糟糕，一直到他们再也无法管理这团混乱。劣质的程序码导致了这家公司的倒闭」

取自: Clean Code (p.3)

乾净的代码深入实作细节来探讨如何透过编程风格与惯例，写出好读 (Readable)、易改、易维护的程序码。接下来的导读中，我们将从最基本的「命名」、「注解」、「缩排」开始探讨好读的程序码应该要注重哪些细节。事实上，只要引入整齐一致的缩排和命名风格就能够大大地增加程序码的可读性了

至於什麽叫做 「乾净的程序码」 ? 判别指标其实很单纯，最小化它就是了:

「唯一有效的「程序品质」度量单位: 每分钟骂脏话的次数 (WTFs/m) 」

什麽是 Clean Code?

上述指标纯属玩笑，让我们援引各方大师的说法。更具体点来说...

「Clean Code 是可被原作者以外的开发者阅读与增强的。它应当包含单元测试与验收测试」

「减少重复、具有高度的表达力、并及早建立简单抽象概念，这些对我而言，就是撰写 Clean Code 的方法」

「当每个你看到的程序，执行结果都与你想得差不多，你会察觉到你正工作在 Clean Code 之上」

取自: Clean Code (pp.10-13)

为什麽要当 The Clean Coder?

最後是软性议题。回归开发者本身，面对种种的开发需求、甚至杂事、无效率的会议、何时该说 Yes or No?、专案时程与进度的控管、团队协作开发......等，也是作为一位工程师非常重要的一部分。在此篇中不会提到任何程序码，笔者可将其当作软件工程师的职涯经验谈，至於书中内容是否适用於每种情况则见仁见智了

「学会作一位 Clean Coder 比学会写出 Clean Code 还要难的多」

此外，书中作者对於 「流态区 (The Flow Zone) 」 的看法也是满值得思考
究竟过於高度的专注是否真的有利於长期的程序开发呢?

「关於『高效率状态』人们已经写了很多，通常被称之为『流态(flow)』。这是一种意识高度专注但思维视野却会收敛到狭隘的状态」

「他们会感到自己绝无错误、感到自己效率极高。然而这种意识状态并非真的极为高效，这其实只是一种浅层冥想。为了追求所谓的速度，理性思考的能力会下降。你其实没有顾及全域，你很可能会做出一些後来不得不摧毁的决策」

取自: The Clean Coder (p.95-96)

最後作者谈到对 「会议」 的看法时，更是让人会心一笑：

关於会议，有两条真理:

1. 会议是必须的
2. 会议浪费了大量时间

取自: The Clean Coder (p.148)

未来我会持续、缓慢地反覆编辑并重构这一系列文章，为各位导读这三本书的精随。欢迎读者每隔一段期间就来翻阅一下，或者一起交流~

後记

2021.11.
...

2021.09.16
下笔的当下就开始极度後悔选这个主题了QQ... 要想一次把三本书中的内容都融会贯通并写成系列文章发布，对笔者本身的程序底蕴和内功、职涯经验有很高的要求。以我目前的程度，这系列文只能算是心得纪录而已，对 "Clean" 理念的诠释如有不足，敬请各位大神们包涵 ( _ _ )