本书介绍了如何让简约设计的思想回归到计算机编程中，如何打造高效的软件开发团队。整本书的主旨是帮助读者成为一名更好的软件开发者。本书主要包括以下内容：开发者的基本素质、软件的复杂与简约、团队里的工程问题、理解软件和软件测试、持续改善软件。
无
我从2008年开始在www.codesimplicity.com网站上撰写博客，这么做的原因只有一个—想要让全世界的软件开发变得更好。做这件事不是为了成名，不是为了获得工作机会，也不是为了将自己的想法强加于他人。我的初衷是为了帮助他人。
我发现在软件工程领域中存在大量与软件开发相关的各种建议，但缺少一定数量的事实和一些基本的原则。这个说法对有些人来说可能有点骇人听闻，因为基于我们对工作内容的认知，软件开发可以算作一门科学学科—我们需要借助高科技设备和许多复杂系统来完成工作。所以它毋庸置疑和科学有关，不是吗？
问题在于如果某类事物想要被纳入科学的范畴，它的背后必须要有科学定律，以及基于这些定律形成的结构化的信息系统作为支撑。一般来说，你要证明你的定律和系统在现实的物理世界中能够完全按照预期方式来工作。所以对于技术来说，仅有事实还不够，还必须有基本原则。
有非常多的方式能够推导出这些基本原则。最流行和接受度最高的方式莫过于借助于科学的方法论。当然也存在其他的途径。无论你选择什么样的方式，整个过程都离不开一个更大的主题—认识论，解释起来就是“研究知识是如何被发现的”。举个例子，你肯定知道你的名字叫什么，但你是怎么知道那就是你的名字的？你怎么知道它的确是你的名字？如果你想要学习构造一幢房子，你要如何学习这方面的知识？等等。
关于认识论，我表述得过于简略了，鉴于我并没有真正地对认识论及对它的使用做出解释，或许有些哲学系教授会对我的说法给予批评，但是我希望我所写的这些内容足以让大部分读者意识到，我需要的是一些能够引导基本原则的发掘的方法论。而认识论中的各类方法论，包括其中的科学方法论，都能够给予我这方面帮助。
我的第一本书《简约之美》就是对软件开发中的这些基本原则的汇总讲解。但除了这些基本原则之外，需要了解的内容远远不止这些。你当然可以从《简约之美》中叙述的内容推导出其他有关软件设计的林林总总，但既然我都准备好了，为什么不直接和你分享呢？
本书是自《简约之美》出版后，对我后续所写的博客文章的再一次汇总出版，还包括在《简约之美》出版之前所写的但又不适合收录在其中的一些内容。本书的大部分文章都能在我的网站上找到，但是在本书中为了最大化可读性，它们被重新组织、规划以及再编辑。同时，以图书形式阅读它们也更容易理解和消化。
本书有一章没有（也永远不可能）出现在我的网站上—这一章名为“杰出的软件”。作为《简约之美》第一版草稿中的一部分，我在很多年前就已经编写完毕了，但从来没能说服自己将它免费发布出去。
你大可不必按照书中文章的顺序来阅读。如果能按照页码顺序或者章节的顺序来阅读当然很好，但是如果你觉得某部分内容看上去更有意思，你也可以跳跃式地直接去阅读你感兴趣的内容。
为了同时满足两部分读者的需求，我将整本书的内容分成了几个部分。这样，按照先后顺序阅读的读者能感受到一致性，想要跳读的读者也能做到对每一部分涵盖的内容心中有数。
本书的前三部分内容首先聚焦的是程序员应该了解的基本原则，然后是关于软件的复杂性和简约性的各个方面。在此之后，第四部分介绍代码调试。接着是第五部分，包含一整套全新的原则，都是我在《简约之美》出版之后陆续整理出来的，基于的是我将《简约之美》中的原则成功应用在大型工程团队内的经验。
接下来第六部分叙述的是软件设计原则背后的哲学。其中包含一章“测试的哲学”，讨论的是有关软件测试的基本原则，比我在第一本书里讲解得更加透彻。
最后迎来的是第七部分，内容都是围绕我所有博客中最受欢迎的文章来编写的。开篇首先解释了为什么“持续改善”应该作为软件开发中产品管理的哲学，然后讨论的是如何让你的软件持续改善，以及成为一名更好的程序员的具体方法。
总的来说，整本书旨在帮助你成为一名更好的软件开发者，这也是本书唯一的主旨。我倾向于活在一个软件简单易用、快速稳定、设计良好还易于开发的世界里，你不也希望如此吗？在《简约之美》和这本书中，我会告诉你应该通过何种方式来达成这个目的—你所需要做的仅仅是将我传递给你的这些知识在工作中应用起来。
祝你好运！
马克斯·卡纳特-亚历山大
2017年8月
计算机/软件开发
本书涵盖了程序员的职业素养、软件复杂性和简单性、调试以及软件工程等方面的内容。更重要的是，作者从计算机的体系结构到软件测试的哲学，分享了自己所理解的软件，让人耳目一新。虽然是多年的博客文集，但阅读起来并不觉得过时和乏味。相信本书可以帮助广大读者更好地理解什么是软件。
——姚琪琳，ThoughtWorks资深咨询师，敏捷技术教练
书中“为什么说程序员糟糕透了”是我颇为欣赏的一个章节。现今，我们所处的行业涌入大量的程序员，他们缺乏编写整洁代码的追求。他们之所谓糟糕，正是因为他们不知道、没了解过软件设计。有一小部分程序员甚至不知道他们在做什么，只会复制代码。书中总结了作者多年的软件开发经验，提及一系列软件设计指导和持续改善原则，值得大部分程序员去阅读，并进行刻意的练习。特别是关于维护成本和软件复杂性的内容，值得我们去思考。
——黄峰达（Phodal），ThoughtWorks 高级咨询师，《前端架构：从入门到微前端》作者
在本书中，富有传奇色彩的编程大师马克斯·卡纳特-亚历山大（Max Kanat-Alexander）将会向你展示如何让简约设计的思想回归到计算机编程中。马克斯会解释程序员为何会感到力不从心，以及应该如何持续改善。世界上存在太多复杂的事物。复杂并不可取，因为它会给我们的工作带来隐患。
马克斯从他久负盛名的技术博客Code Simplicity中精选了一部分文章，对如何在软件行业工作以及取得成功给出了自己的想法和建议。相信这43篇文章能够让你学会如何在工作中避免复杂，拥抱简约，从而让你的职业生涯更加顺利和成功。
马克斯扎实的技术功底、对于技术的洞见，为他赢得了代码大师的美誉。相信他的思考也会给你带来启发，帮助你找到面对挑战的正确方向。
通过阅读本书，你将了解：
如何让简约设计始终贯穿在编程工作中，以及如何在编程工作中取得成功
复杂的软件设计有哪些特征——如何构建杰出软件
简约软件设计
程序员为何会感到力不从心，应该如何持续改善
成为明星程序员的秘密
马克斯对于软件行业的观察和洞见
软件缺陷与代码调试
程序员应该知晓的编程原则
在还没开始翻译之前，我对于这篇译者序就已经有了规划：先聊聊我翻译这本书的原因，再大致把这本书里的内容叙述一遍，最后重点推荐一些我个人认为有价值的章节。但是在后续润色的过程中（其实也相当于重读了），我发现当初的设想是不可能实现的，因为整本书涉及面太广了—代码调试、策略测试、团队协作、效能提升、待人接物无所不谈。
你肯定也疑惑了，那么本书究竟想介绍什么？难道没有一个统一的主题吗？
答案是“有”，用两个字—原则总结就够了。本书涵盖的是所有你在开发中可能会运用到的各式各样的原则。在本书的前言和第1章中，作者就开宗明义地指出，本书的目的是帮助你成为一名更好的开发者。通过书中作者在过往工作中总结下来的这些经验，希望能够让你在成长的路上少走弯路。
多谈些主义
关于如何对待编程领域中这些和编程间接、直接相关的知识，我见过两种极端的态度：有的人只看结果，只关心“写代码”，而对“写好代码”一无所知；第二类人深谙各种架构设计、整洁代码之道，但对于当下代码中遭遇的问题却没有落地的方案。
在互联网公司的多年工作经验让我个人更习惯于从第一种人的视角看待问题，毕竟这是行业性质决定的，跑马圈地、快速扩张才重要，行业不允许你有时间思考。但是抛开行业、抛开公司，单纯地看编码这件事，我作为程序员最大的疑惑是：为什么我在每一家公司接手的代码库都如此难以维护？为什么总有人写出500行代码的函数和1000行代码的组件？为什么每一个迭代的最后总是要加班加点，研发、测试、产品经理都叫苦不迭？为什么问题年复一年地发生，却没有人想做些什么来改变现状？
DRY—Don’t Repeat Yourself。别忘了这可是我们自己说的。
我观察到程序员存在一种战略上的惰性，对学习新技术和新框架，对阅读源码有发自内心的推崇。我不否定这种行为，新技术能给我们的项目带来便利，能给我们的简历增添浓墨重彩的一笔，这无可厚非。但技术背后的编写思路演化至今的原因，同样值得了解，它们和技术的语法本身同样重要。仔细回想和思考就不难发现，工具的好坏和代码的好坏，与项目将来适应需求变化的灵活能力没有关系，从写Vanilla JavaScript的年代，到BackboneJS，再到React，你看到团队中能把代码写好的人真的是越来越多吗？
不同行业对于软件质量的要求是不同的。且不说你所在的行业有没有意愿和资源解决这些问题，如果有，你应该去哪里寻找方案？
在我看来，前人留下的经验是最值得我们借鉴的宝贵财富，无论这种经验是来自传统软件行业还是其他互联网公司。我们遇到的问题，尤其是对传统软件行业而言，他们在十年前甚至二十年前就已经遇到了，所思所想比我们更深远。然而这些经验也并不神秘，其中有一部分经典就是你已经耳濡目染的各类编程法则和开发模式，而另一类更实际的内容就散落在不同渠道的文字和口述当中，例如本书中。
但让人望而却步的是，大部分原则听起来都过于抽象了，甚至有些是反直觉的。
我明白抽象带给人的挫败感，你肯定听说过不少，甚至它们的名字都可以信手拈来，例如可维护性、可扩展性、可读性、KISS、YANGNI等。但什么样的代码才称得上可读性好，KISS应该如何在代码中实施？
反直觉的实践也比比皆是。如果我告诉你，在每一次正式开发代码前，提前对代码做一些重构工作，那么无论是短期还是长期来看，你整体付出的开发时间是下降而不是上升的，你愿意相信吗？相信之后又敢在工作中尝试吗？
遗憾的是有一些原则背后确实存在复杂的知识体系作为支撑，哪怕我用思维导图把背后涉猎的概念一五一十地列举出来，你的内心可能依然毫无波澜。因为其中的很多原则需要你看到相似的代码后才能心领神会，轮扁斫轮的寓意也是在此。但还有一些并不是，比如在判断一个函数长度是否恰当时，我们有一些实打实的评判标准，其中一条是函数是否能在一个屏幕之内显示完毕。
Uncle Bob Martin在他的“The Principles of OOD”系列文章中谈到过糟糕设计（Bad Design）的几个特征：
僵化（Rigidity）：代码难以修改，因为改动会影响到的地方太多。
脆弱（Fragility）：当你做出修改时，系统中预期之外的地方会遭到破坏。
难以修改（Immobility）：代码很难被复用，因为它与当前系统中的功能耦合在了一起。
这一系列简单扼要的描述，就将编程中涉及的原则和代码中具体的症状联系到了一起。
学习这些知识难吗？一点也不难。想要了解它们很简单，但想要在编程中灵活运用它们则是另外一回事，毕竟提升编程技能靠的不是死记硬背，而是反复刻意的练习。但再困难，也会比将来回过头设法挽回代码造成的损失要简单。
如果他们错了怎么办
我无法否认这种可能性。但也请允许我问另一个问题：当需要在一个团队内对某个技术方案进行决策时，决策应该是专制的还是民主的？
不如我再把这个例子具象化一些，假设在一个新建的项目中，我们需要制定webpack关于chunk打包的策略，那么很多与chunk有关的配置，比如hash、cacheGroups，应该如何配置？
解决这个问题的过程不太可能是民主的。首先人们需要对webpack涉及哪些chunk配置，以及每一个配置的可选项背后对应解决的问题场景有所了解；其次还要对项目的现状、站点内静态资源加载的需求有清晰的认识。
这些决策的前提知识，并不是每个人都具备的。
大部分时候—我说的是大部分时候，技术的决策是专制的。如果我在这个技术领域有丰富的经验，如果我解决过足够多的问题，哪怕是我在这个项目中待的足够久，那么对于当下任何一个新的问题，我就能想得更多，看得更远。当然如果团队的时间和人员充足，可以抱着培养新人的心态，放手把问题交给一个从没有接触过这方面领域的人来解决。
很多时候这些原则不一定是错的，而是让你听上去以为它是错的。就拿注释这件事来说，大部分程序员会认为注释是消除代码“恶臭”的灵丹妙药，但是：
Martin Fowler在《重构》里告诉你没事别写注释。
Uncle Bob Martin在《代码整洁之道》里告诉你没事别写注释。
Jeff Atwood在codinghorror技术博客里告诉你没事别写注释。
那你还有什么理由要继续写注释？
现在依然半信半疑的你该何去何从？
你可以去了解这些建议背后的动机。在这些建议的背后他们都给出了各自的理由，以及替代的解决方案是什么。“start with why”有助于理解，神奇地让你从对立面转向认同他们的观点。
但有一些知识可能找不到出处，或者只是团队中留下的实践，这种实践还是以代码的形式给出的。在这种情况下，你或许需要的是“信仰之跃”（Take a leap of faith）。也就是说此时你需要无条件地相信，日后再慢慢验证，慢慢理解。
还有一种选择，那就是置若罔闻，但可能需要承担惨痛的、后患无穷的代价。
如果你依然对书中的原则将信将疑的话，不得不提我翻译这本书的另一个原因：书中很多内容与我在实际工作中总结出的经验不谋而合。
我个人在从独立开发者的视角转向关注团队、关注项目、关注流程的视角的过程中，发现技术问题已不再是我眼中需要解决的首要难题。
因为哪怕你找到了整治项目的灵丹妙药（某种最佳实践），也需要整个团队的力量来帮助你落地且一如既往地保持下去。项目里不需要英雄，即使团队中真的存在能写一手好代码的高手，他的辛苦结晶也很快就会被庸才们“孜孜不倦”的“劳动成果”所打败。
迫切地希望团队中有“救世主”角色出现是一个危险的信号，而且通常这个时候救世主也派不上什么用场。另外，即便有灵丹妙药，你有没有考虑过团队里的每个成员能否“咽得下”这颗灵丹妙药？基于同样的原因，仅仅只有几个人能够理解这套方案并且在项目里实施起来是不够的。所以灵丹妙药要怎么选？底线在哪？说白了，底线就是团队能力的下线。
如何提升团队效能？如何帮助团队中的成员成长为明星程序员？这些都是在本书中会谈及的问题。
多研究些问题
还记得我在开头提及的第二种人吗？他们同样是危险的。如果抛开实现，单纯地把问题抽象到某种高度，可能会让问题陷入一种什么都解决得了或什么都解决不了的极端局面中。前者相当于“不就是”，后者等同于“又怎样”。万事万物都可以套用“不就是”与“又怎样”的句式，这样的描述看似是无敌的，但仔细想想又破绽百出。
“不就是微前端嘛”—不好意思你说的是哪一种微前端？不同框架下组件间的通信问题是如何解决的？构建时集成流水线的粒度如何？组件间互相依赖的版本管理策略如何？
“又怎样”的心态更是可恶，当代码稍有改善时，就会有悲观主义者“友善”地“提醒”你：这种杯水车薪的改善又能怎样呢？现在整个代码库依然身陷囹圄。
这种思考问题的方式一点都说不通，代码腐化是一个持续的过程，但为什么我们却想在某个时间段内一劳永逸地把问题解决？
实话实说大部分代码库都是满目疮痍的，问题在于你要如何挽救它，从哪里开始挽救它。无论我们是引入committer机制还是代码评审会议，总有一天会无法坚持下去，最坏的情况无非是我们没有让它变得更好，但也保证了在尝试的过程中它不会变得更差。
前面所说的开发人员的能力困境“不就是”温伯格的咨询第二定律：不管一开始看起来什么样，它永远是人的问题。
它够不够抽象？够。够不够深刻？够。够不够有哲理？够。但说实话对于解决我们当下的问题并没有太大的帮助。如果瓶颈真的在团队的成员上，我们想知道的是：怎样才能提升团队成员的编程能力？再实际一些，作为一家创业公司，我无法提供非常有竞争力的薪水来招到顶级的人才，或者迫于交付压力我无法花太多的时间在培训、代码审查、重构上，那么我的代码应该如何被拯救？
在我看来本书的魅力正是摆脱了高高在上的姿态，在“说白话”，作者并非只是凭空扔给你一句话（每一句话高深到每个词你都认识，但连起来就读不懂那种）之后让你慢慢参悟。对于一些概念，甚至是常见的概念，作者会进行澄清和定义。如果他提出的是一条建议，那么他还会解释这条建议的来龙去脉和它所适用的范围。对于在实施过程中可能遭遇的阻碍，他也做出了适当的预测并给出了解决办法。
我不敢苟同他在书中提出的每一个观点，最终是否适合你还需要你自行判断，毕竟在这个领域内没有银弹。但相信这些内容能够给你带来启发。
译者序
前言
关于作者
第一部分 程序员应该了解的基本原则
第1章 在你开始之前 3
第2章 工程师的态度 5
第3章 成为明星程序员的独特秘密 7
第4章 两句话总结软件设计原则 9
第二部分 软件的复杂性和它的起因
第5章 复杂性的蛛丝马迹 13
第6章 创造复杂性的方法之一：违反你承诺过的API约定 15
第7章 什么时候不值得向后兼容 19
第8章 复杂是牢笼 23
第三部分 简约与软件设计
第9章 设计要从头抓起 27
第10章 预测未来的准确度 29
第11章 简约与严格 33
第12章 两遍已太多 37
第13章 健壮的软件设计 41
第四部分 调试代码
第14章 什么是bug 51
第15章 bug的源头 53
第16章 确保它不会再发生 57
第17章 调试代码的基本哲学 63
第五部分 团队里的工程问题
第18章 高效工程开发 71
第19章 量化开发效率 79
第20章 如何应对软件公司内代码的复杂性 85
第21章 重构与业务功能有关 91
第22章 善意和代码 97
第23章 运营开源项目社区其实非常简单 101
第六部分 理解软件
第24章 什么是计算机 113
第25章 软件组件：结构、操作和结果 117
第26章 重新审视软件：SAR/ISAR概念详解 119
第27章 软件即知识 123
第28章 技术的使命 127
第29章 简单地聊聊互联网隐私 129
第30章 简约和安全 135
第31章 测试驱动开发和观察循环 139
第32章 测试的哲学 143
第七部分 持续改善
第33章 成功的秘密：持续改善 157
第34章 如何找到持续改善的空间 161
第35章 拒绝的力量 165
第36章 为什么说程序员糟糕透了 169
第37章 快速编程的秘诀：停止思考 175
第38章 开发者的傲慢 181
第39章 “一致”并不意味着“统一” 183
第40章 用户有困难，开发者有方案 185
第41章 即时满足=即时失败 189
第42章 成功来自执行而非创新 193
第43章 杰出的软件 195
