我有一个梦想，我写的代码，可以像诗一样优美。我有一个梦想，我写的代码，可以像诗一样优美。
我有一个梦想，我做的设计，能恰到好处，既不过度，也无不足。
这种带有一点洁癖的完美主义就像一把达摩克利斯之剑，时刻提醒我不能将就、不能妥协。
完美主义的代价是在很长时间里持续的迷茫和焦虑。甚至一度，我对软件行业是失望的，怀疑在软件的世界里，到底还有没有优雅的代码和整洁的架构。如果有的话，为什么所有的业务代码都像一座座“屎山”，既不优雅也不整洁，既晦涩又难懂呢？
这里说的“所有”准确的说是指，我亲自参与开发过的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，可以看一下。倘若你和我一样，不仅仅定位为一个“管理者”，那么请参考“老程序员”部分。
有 0 个人打赏文章最后发布于: 2019年06月21日 10:59:51展开阅读全文 《代码精进之路：从码农到工匠》——抽象阅读数 555
写本文的原因是，抽象是软件设计中最重要的概念，但抽象这个概念本身又很抽象，值得我们花时间去好好探究一番。抽象的力量没有抽象思维，就没有人类光辉灿烂的现代文明。原始人看到一片树林，不会给它们一个名字，比…博文来自： 我的新书《代码精进之路：从码农到工匠》
chenvincent4周前#4楼请问在哪买？
he0371个月前#3楼期待这本书，什么时候可以买到
zheyangnayang1个月前#2楼很期待这本书，做为一个做业务系统的程序员，这也是我一直思考和头疼的问题。
Ydoing1个月前#1楼写的这么好，必须顶一下。什么时候能买到书呢？2登录 查看 4 条热评复杂性应对之道 – 领域建模阅读数 1万+
为什么要领域建模软件的世界里没有银弹，是用事务脚本还是领域模型没有对错之分，关键看是否合适。就像自营和平台哪个模式更好？答案是都很好，所以亚马逊可以有三方入住，阿里也可以有自建仓嘛。实际上，CQRS就…博文来自： 我的新书《代码精进之路：从码农到工匠》应用架构之道：分离业务逻辑和技术细节阅读数 814
架构什么是架构？关于架构这个概念很难给出一个明确的定义，也没有一个标准的定义。硬是要给一个概述，我认为架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。架构始于建筑，是因为人类发展（原始人自给…博文来自： 我的新书《代码精进之路：从码农到工匠》IT转型之路（一） 迷茫、困惑阅读数 3105
从数通领域转行到IT领域，已经9个月了，该简单总结一下，一时不知道从哪里说起，先说说工作内容方面，以前做交换机、路由器的驱动开发，现在突然不做嵌入式的开发，心里有点发慌，在IT行业，我就是一个新兵，说…博文来自： 喜欢编程的小兵架构师变形记：讲述Java码农到年薪100万架构师之路阅读数 76
最近有不少朋友问我怎样才能成为年薪百万的架构师，我听到他这样问，首先想到的是什么样的人才可以称之为架构师，然后我给他总结了他需要攻克的3个难点：1.接触不到一线实战架构设计，尤其是有一定的技术深度和难…博文来自： weixin_34062329的博客架构师论文阅读数 2614
如何写论文用10分钟在草稿纸上写出思维导图，例如下面是分布式缓存系统设计的导图。如何提高系统架构师写作水平：http://www.cnblogs.com/muhongxing/archive/2010…博文来自： 我的新书《代码精进之路：从码农到工匠》代码精进之路.rar 06-10 本资源转载自网络，如有侵权，请联系上传者或csdn删除 如果你认为程序员的工作就是写代码，那就大错特错了！事实上，编程只占程序设计工作的10%，而且是相对简单的工作。本书以8个虚构的故事为主线，邀你探 下载代码精进之路(总结)1-3节阅读数 281
博文来自： xushuanglu_csdn的博客分布式数据库阅读数 862
1.分布式数据库领域CAP理论Consistency(一致性),数据一致更新，所有数据变动都是同步的Availability(可用性),好的响应性能Partitiontolerance(分区容错性)可…博文来自： 我的新书《代码精进之路：从码农到工匠》代码之外的功夫：程序员精进之路
