前言
我有一个梦想，我写的代码，可以像诗一样优美。
我有一个梦想，我做的设计，能恰到好处，既不过度，也无不足。
这种带有一点洁癖的完美主义就像一把达摩克利斯之剑，时刻提醒我不能将就、不能妥协。
完美主义的代价是在很长时间里持续的迷茫和焦虑。甚至一度，我对软件行业是失望的，怀疑在软件的世界里，到底还有没有优雅的代码和整洁的架构。如果有的话，为什么所有的业务代码都像一座座“屎山”，既不优雅也不整洁，既晦涩又难懂呢？
这里说的“所有”准确的说是指，我亲自参与开发过的Apple、eBay、American Bank和阿里的部分业务系统代码，以及从朋友嘴里听来的腾讯、Facebook和Amazon等公司的部分系统代码。
每每看到这些像面条一样缠绕在一起代码，我都会感到气愤、懊恼和羞愧。气愤的是，为什么代码要被写的如此复杂；懊恼的是，不知道如何才能有效的治理混乱、控制复杂度；羞愧的是，我俨然能听到这些丑陋代码向我发起的嘲笑声：“hey boy，你的梦想还在吗？”
怎么办？一边是无止尽的业务需求，一边是补丁加补丁的业务代码，开发人员被夹在中间像一只困兽，向左走，还是向右走？方向在哪里？我倍感困惑，我不明白为什么我花了那么多时间来学习技术，可还是写不好代码。为什么我们花了这么多时间加班，还是应对不了复杂度。
就像Robert C. Martin说的：“不管你们有多敬业，加多少班，在面对烂系统时，你任然会寸步难行，因为你大部分的精力不是在开发需求，还是在应对混乱。”
我发现，这不仅仅是我个人的困境，而是很多心有不甘的技术人员都有的困惑。不是我一个人的痛，而是很多技术人共同的痛。与其做一个困兽，不如主动出击。通过大量的学习、研究和实践，我们花了很多时间研究复杂性的根源，随着对复杂性理解的不断深入，我们发现造成软件复杂性的罪魁祸首主要有以下因素：
-
软件的本质复杂性——《人月神话》的作者Fred Brooks曾说：“软件的复杂性是一个基本特征，而不是偶然如此”。因为问题域有其复杂性，而软件在实现过程中又有很大的灵活性和抽象性，导致软件具有天然的复杂属性；
-
缺少技艺——“写代码”作为一种技能，入门并不是很难，北大青鸟三个月就可以做到。但是要想像大师那样优雅的“写好代码”，则并不是一件容易的事。需要持续的学习和实践，很多的软件复杂性都是因为技艺缺乏而导致的随心所欲的复杂性；
-
糟糕的技术氛围——在一个技术团队中，如果技术管理者们只在乎分配给你的任务有没有实现，从来不关心代码的好坏，又怎能指望团队写出“干净的代码”；
-
教条——我们总认为有什么灵丹妙药，在不恰当的场景使用了不恰当的解决方案，造成了不必要的复杂；
-
妥协——我们向自己妥协，向产品经理妥协，向工期妥协，向技术债妥协，我们总有很多借口把设计糟糕、混乱丑陋的代码发布上线。
念念不忘，必有回响；不忘初心，方得始终。通过我们坚持不懈的努力和探索，终于在2018年迎来了一些阶段性的成果，我们找到了一些切实可行的控制复杂度的办法，并沉淀了COLA框架（Clean Object-oriented and Layered Architecture，整洁面向对象分层架构）。COLA的诞生给了我们很大的鼓舞和希望。就像是在茫茫大海上漂流，终于看到了远处的灯塔。
在COLA日趋成熟之际，我第一时间，迫不及待的想要将这些发现和应用整理成册与您分享。因为，在探索复杂度治理的相关工作和研究中，我不止一次感叹，如果我能更早的了解这些知识，更早的掌握这些方法该有多好。这样我就能避免很多不必要的焦虑，少做很多有缺陷的设计，少写很多丑陋的代码了。我相信你看完本书，也会有同样的感受。
有这样的信心，是因为我相信对代码的极致追求，是每个技术人员的基本动力和诉求。我们都知道“写出好代码”是比“写出代码”要难得多的更高要求，一个程序员最大的美德就在于他是否能为后人留下一个看得懂、可维护性好的代码。
好的代码技艺不是一蹴而就的，而是一个系统化的工程，它不是看几本书，写几年代码就能轻松习得的。它需要我们对自己的思维习惯，学习方法，工程实践进行彻底的反省和重构。而这本书，正是记录了一个普通码农，如何通过认知升级、知识重构、持续学习继而转向工匠的过程。作为一个技术人，我有义务将这个过程分享出来，以期给同样在路上的你带来一些启发，缩短你从“码农到工匠”的探索路径。
受制于我们本身认知水平的局限，本书的很多观点可能也只是一家之言。因此，请不要无条件接受书中的每一个观点。实际上，我更希望大家带着批判的眼光去看这本书，挑对你有用的进行吸收，对有疑问的地方，提出质疑和见解。因为在软件的世界里，很少有确定性的东西，除了代码最终会被转换成0101的指令被机器解释执行这件事是相对确定的以外（量子计算出来之后，这件事可能也将变得不确定），其中间过程充满着无数的变数和不确定性。
灵活性和没有银弹（Silver Bullet），也是软件这个行当好玩的地方之一，在这个行业里，任何一个问题都有很多种解法，即使是最简单的函数也至少可以写出10种不同的代码实现。因此，知识储备、判断力和思辨力是软件行业给我们提出的更高要求，任何不区分上下文和情景的教条，都有可能在实施过程中遭遇惨败。所以，我真诚的期待大家对书中的内容进行批评和指正，如果对本书或者COLA有什么好的想法和意见，也可以通过下面的微信公众号让我知道。
总之，软件设计不仅仅是“技术”（technique），也是一门“技艺”（Craftsmanship），要想控制复杂度，防止系统腐化。我们不能只满足做一个搬砖的“码农”，而是要坚持自己的技术梦想和技术信仰，怀有一颗“匠人”之心，保持专注和持续学习，每天进步一点点，唯有如此，我们才有可能“从码农到工匠”！
本书的结构
本书是一本专门为专业程序员而写的书。整本书的目标只有一个，就是介绍如何化解复杂度，写出更好的代码。全书分为三个部分：技艺部分、思想部分和实践部分。
技艺部分有七章内容，详细介绍了一些有用的编程技巧和方法论，并配以详尽的代码案例，掌握这些方法论可以有效的提高我们的编程素养，帮助培养更好的编程习惯，写出更好的程序。具体章节内容如下：
第1章 命名，好的命名可以极大的提升代码可读性和可理解性，这一章主要介绍命名的重要性，命名要注意什么，以及我们如何对不同的软件Artifact（构建）进行命名。
第2章 规范，在Google的Code Review实践中，代码是否符合规范（他们叫norms）是他们最重要的检查项，本章中，我们需要哪些规范，如何制定规范，以及如何贯彻规范的实施。
第3章 函数，有时候，即使你不采用任何OO（面向对象：Object Oriented)技术，就仅仅把函数写好，代码也会呈现完全不一样的风貌，在这一章中，我们介绍了大量的如何写函数的技巧和方法，非常实用。
第4章 设计原则，本章介绍了很多前人总结的优秀设计原则，当然最著名的还是SOLID，它给我们提供了非常好的OO设计指导原则，比如，扩展性的终极目标是满足OCP（开闭原则：Open-Close Principle），我个人特别推崇DIP（依赖倒置：Dependency Inversion Principle），它也是架构设计的重要指导原则。
第5章 设计模式，了解设计模式很重要，因为它能提供恰到好处的灵活性和优雅性，当然工程师之间的沟通变得简单，本章没有详细介绍GoF的所有24中模式，而是重点挑出几个日常使用频率高，实用性强的设计模式来介绍。
第6章 建模，建模非常重要，因为软件工程就是一个对现实世界的问题进行分析、抽象、建模。然后再转换成计算机可以理解的语言，解释执行，实现特定业务逻辑的过程。本章主要介绍了什么是模型，在软件工程中常见的建模方法论，以及如何运用这些模型为软件服务。
第7章 DDD的精髓，领域建模是面向对象技术的精髓，本章主要大部分的思想都来自于DDD（领域驱动设计：Domain Driven Design），但是并没有教条的照搬，而是结合了我们的实践，对DDD进行了改良、萃取和优化。
思想部分有四章内容，思想是比技艺更高层次的能力要求，如果说技艺是“术”的话，那么思想就是“道”，领悟这些道理，对我们的职业发展会大有裨益。
第8章 抽象，抽象能力也是工程师最需要的核心能力之一。在本章里，我们介绍了什么是抽象，什么是抽象的层次性，以及如何进行抽象，如何培养结构化思维和抽象思维。
第9章 分治，分治思想的伟大之处在于，面对一个很复杂的问题域，我们总是可以分解成多个相对独立子问题，然后再各个击破，这个思想在软件领域可谓是无处不在。
第10章 技术人的素养，做一个优秀的工程师不容易，然而还是有一些特质我们是可以习得的。本章主要介绍了技术人应该具备的一些素养，以及如何培养这些素养。
第11章 技术Leader的修养，兵怂怂一个，将怂怂一窝。一个技术Leader的技术味道在很多程度上，决定了团队的技术味道和技术追求，一个优秀的工程师不一定是一个好的技术Leader，本章将介绍我在技术管理上的一些心得。
“Talk is cheap, show me the code”，一本没有实战的技术书是说不过去的。如果说思想是务虚的最高境界，那么实践就是务实的最低要求。实践部分主要包括两章内容：
第12章 COLA架构，本章主要介绍了什么是架构，重点会介绍COLA（整洁面向对象分层架构：Clean Object-oriented and Layered Architecture)，阐述了COLA背后的设计理念和设计原理。
第13章 工匠平台，本章通过COLA在工匠平台这个实际业务场景中的落地，介绍如何使用COLA来搭建一个完整的应用架构，以及如何通过领域建模来实现业务逻辑。
本书特色
本书区别于其它技术书籍的地方是：虚实结合，即既重视思想又重视实践：
重视思想，所谓的思想，是我们分析问题、解决问题所需要的底层能力。我花了很大的篇幅介绍抽象、批判思维、辩证思维、以及程序员的素养等。正是因为这是我们构建技术大厦的底层基石，是我们不得不掌握的底层能力。它超越了软件行业的范畴，是一种哲学和世界观。
COLA应用架构，从某种意义上来说，这不仅是一本技术书，也是开源框架COLA的技术指导手册。到目前为止，我还没有看到比COLA更轻量、更简洁、可直接应用到生产系统中的应用框架。看完本书，我相信你对什么是COLA，以及如何应用COLA进行应用架构和复杂性治理，会有一个全面的了解。
本书面向的读者
本书的目标读者是专业程序员，也就是哪些以编写软件为生的人。理论上来说，它是和编程语言以及人员岗位无关的。因为写好代码、追求卓越、工匠精神是我们每个程序员都应该具备的优秀品质。的确，书中关于如何命名、如何写函数、如何抽象、如何建模等内容是具有一定的普适性的，也就是说，不管你是否使用Java语言，不管你从事的业务应用开发，前端开发，还是底层技术开发（Infrastructure），都能从书中获益。
但是，本书最最适合的读者是有一定经验的、从事以Java语言为主的业务应用开发人员。主要有两个原因：
1） 首先，书中的所有的示例和讨论，都是用Java编写的，熟悉Java和面向对象技术，将为你理解本书提供帮助，特别是第一部分的第5章、第6章和第二部分的内容。
2）其次，因为COLA是面向业务应用的框架，最后一章的实战也一个基于COLA和SpringBoot的业务项目，所以有一定工作经验，从事业务开发的同学会更加有体感。
最后，我想特别对以下不同类型的读者，说几句话：
-
新程序员：如果你是在校的学生或者是初入职场的新人，在追求技术宽度的同时，请一定要养成“写好代码”的习惯，写好代码不是一件容易的事，好好的利用本书，让自己一开始就能在一个比较高的起点上。
-
老程序员：对于职场的老人，本书能有幸和你结缘，说明你和我一样，还怀有一颗“不安分”的心。种一棵树最好是在十年前，其次是现在，在追求卓越的路上，我们都没有迟到，现在上路也还不晚。更何况，我们能这么多年一直坚持写代码，本身就是一种胜利，向老兵们致敬！
-
架构师：熟悉我的人都知道，我不赞成在业务团队设置专门的架构岗位，我认为架构是一种能力，而不是职位。专门的架构岗可能会“无中生有”、对开发团队产生负面影响。如果恰巧，你就在这样的岗位上，那么请一定不要画完架构图就算工作完成，要深入到代码细节中去，这样才能发现设计问题，赢得程序员的尊重。如果你对技艺部分已经比较熟悉，可以重点看下思想和实践部分。
-
技术团队管理者：管理者的一个很重要的技术命题是帮助团队成长，包括制定规范和技术传承。我们有一章专门介绍如何做技术Leader，可以看一下。倘若你和我一样，不仅仅定位为一个“管理者”，那么请参考“老程序员”部分。