要说清楚代码的业务逻辑复杂度，首先就要理解剂几个关键概念。
第一就是模块化。一个软件，它是由若干个小功能组成的，而且这些小功能会大量的被重复使用，比如一起帮里到处都要“支付/收取帮帮币”：买卖帮帮币自然不用说了，酬谢好心人要支付帮帮币，发布/打赏文章要支付帮帮币……那么我们写代码的时候，自然就会想到把“支付/收取帮帮币”这一功能给封装起来，做成一个模块，在需要的时候直接调用这个模块就可以了，而不必把“支付/收取帮帮币”几十上百行代码不停的复制粘贴。这就是模块化，好处当然是显而易见的，但当模块越来越多的时候，问题就出现了，这就是：
耦合。指的就是各个模块之间的相互依存相互影响。仍然是上面的例子，一旦“支付/收取帮帮币”帮帮币这一模块出现改动，势必影响所有调用它的其他模块。哪怕是一个小型项目，就像现在的一起帮，这种模块就已经上千了。你就想象1000个点，点与点之间用线段相连，是不是很快就会形成一个密密麻麻的网？牵动网中的任意一点，就会经由改点，把震动传递到几乎整个网络？文艺点的说法，这就是“牵一发而动全身”？或者你可以想象成在搭积木，一层一层的叠上去建好了一座宫殿，然后现在要换下面一根柱子，是不是稍不留神就“哗啦”一下全垮掉了？
写到这里我就想到我做家装的时候，给公司做企业网站的那个小伙子，我认为我就是提了一个很小的改动，就吓得他尾款都不敢要了，直接闪人。当时不明白啊，现在终于明白了。
有人把写代码比作写文章（说明文/操作指南），从某些角度看，有一定的道理。但是，文章和代码有一个很大的区别：文章好改，代码不好改。很多行业外的人士，一个普遍的误区，把改代码看成是word文档里改几句话一样简单，“我特么就改这么一点点，你跟我瞎哔哔不行……”如果一定要在这方面，把文章和代码放在一起比，那文章应该是那种人物众多，无数明线暗线，情节百转千回，逻辑严丝合缝的现实主义巨著，这种文章不知道大家有没有了解过，就很容易“写崩”：人物的性格情节的发展、前后不搭，定型了还很难甚至没法改，一改就是一个疤。但是，文学作品我们读者对它有很高的容忍度，这里编得不像就不像，将就了；计算机不能将就的，错了就错了，跑不过就跑不过，零容忍！这就非常麻烦了。
长期以来，整个程序员群体都一直过分强调了算法复杂度，而忽视了业务逻辑复杂度。说到“数据结构和算法”就两眼冒光，各种高大上的感觉，虽然可能一辈子都用不到；说到业务逻辑，一脸鄙视，不就是增删改查么？烦都烦死了！确实很烦，我也正被烦着呢。
但是，当我转念一想：以后我自己的项目代码规模也可能不断扩张，要是维护成本也像现在手里的代码一样高，怎么办？于是赶紧静下心来仔细琢磨。所以，你看，同一个问题，是自己的还是别人的，考虑的方向马上就不一样了。别人的问题，下意识的想法是怎么躲开它，比如这类提问“如何避免写过多的业务逻辑代码？”；自己的问题，就只能想办法解决它，问题就变成了“如何写好业务代码？”
这一琢磨，就琢磨了好多年。过程我也不说了，具体的技术细节我也不讲了，这不是一篇技术论文，而且这里面的东西，别说一篇文章一本书都写不完，涉及到面向对象、设计模式、系统架构、项目管理方方面面的知识。我把面向对象和设计模式归入“微观”层面，而系统架构和项目管理归入“宏观”层面。就架构而言，我说说让我豁然开朗的最关键的几个点：
第一，认识到“架构是一种管理”。在此之前，我以为架构是一种的“技术”，和学C#学ASP.NET一样，学会了语法熟悉了相关类库就OK了，结果把《企业应用架构模式》这本书从头看到尾，就是各种架构模式的罗列而已，问题是我究竟该选哪一个呢？是，你把每一种架构的优劣也都罗列出来了，但我真的还是不知道该怎么选啊。
+++++++++++++++++
整整憋了两天，实在写不下去了，因为希望能让不是程序员的读者也能勉强理解，把我给写得啊……
跳过跳过，以后再写。
以下为草稿：
架构的本质是管理，管理的目标是降低代码复杂度”。“架构”是解决业务逻辑复杂度的。很多程序员把架构理解成一种的“技术”，如果你一定这么理解的话，请把它理解成一种“管理技术”。和学某种编程语言不一样，学会了语法熟悉了相关类库你就算是学会了。但架构没有学会这一说法，它本质上就是一个代码的组织
架构没有一定之规，没有可以现成套用的“模板”。
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
