feat(tasc): add talk about system complex.

README.md

@@ -96,3 +96,4 @@
 * [热风-聊一聊架构](book/talk-about-architecture.md)
 * [热风-使用Javac's Release选项](book/javac-release-option.md)
 * [热风-谈一谈设计范式](book/talk-about-design-paradigm.md)
+* [热风-说一说系统复杂性](book/talk-about-system-complex.md)

SUMMARY.md

@@ -84,3 +84,4 @@
 * [热风-聊一聊架构](book/talk-about-architecture.md)
 * [热风-使用Javac's Release选项](book/javac-release-option.md)
 * [热风-谈一谈设计范式](book/talk-about-design-paradigm.md)
+* [热风-说一说系统复杂性](book/talk-about-system-complex.md)

book/talk-about-system-complex.md

@@ -0,0 +1,35 @@
+# 说一说系统复杂性
+
+       业务在不断的发展，支持它的系统也变得越来越复杂，尤其是软件技术公司更是如此。规模巨大的科技企业更是深受复杂性所累，一个看似很小的功能，却在众多系统中来回穿梭，修改一次就如同翻江倒海，耗费了大量的人力和物力。为了抵抗复杂性，人们就摩拳擦掌跃跃欲试，甚至有些人为此专门成立了公司来售卖方法论，什么面向对象技术、面向服务体系结构以及微服务架构层出不穷，它们无一不打着降低复杂度和提升效率的幌子，但是没有一个能够兑现承诺。
+
+       业务发展赚来银子，雇佣更多的开发人员，而他们却深陷系统的复杂性之中，效率无法让业务得到满足，这难道就是技术的锅吗？是开发人员拙劣的设计带来的吗？这不是一家技术公司面临的问题，而这个广泛的问题是不是代表着大多数开发人员水平都是拙劣的呢？答案：并不是。系统变复杂的源头还是业务，本质就是业务人员自己没有理顺逻辑关系，做东西没有考虑旧有的规则以及如何应对用户的真实需求，而这些混乱的业务思考在只认逻辑的技术系统中落地，结果就是不断增加的复杂度。开发人员的低效，就是在同业务带来的复杂性斗争，在同没有想清楚的业务做斗争，费力的编故事来圆业务的锅，在做代偿。
+
+       既然问题源头不在技术，那开发人员是不是可以躺平了？非也。业务不按逻辑性办事，不代表技术不讲工程性，在技术工作中如果能够关注和治理系统复杂性，是不是可以减少一些苦难呢？
+
+       虽然复杂性的起源来自业务，但是开发人员在设计和实现系统时仍然需要对复杂性进行关注和治理，同时好的开发人员也会发现业务中存在的冗余和矛盾，推动业务人员不能以成本视角观察技术，而需要改进业务，避免所有涉众都会为混乱的业务以及产品架构买单。
+
+## 复杂性是个必然
+
+       只要业务存活，系统的复杂性就成了必然，讽刺的是，只有不断增加的复杂性才代表活着。就拿简中互联网中的BAT三家来说，Alibaba的系统已经做的很具扩展性了，而当下ByteDance的系统越做越复杂，从体感上讲，后者要活的比前者滋润的多。
+
+       以[Spring框架](https://spring.io)为例，从发布初期`0.9.1`版本的一万多行代码，到`2.5`版本的七万多行代码，复杂度增加了不少，但是从另一个方面看，它的使用人群变得非常广泛。业务和产品的演化是预料之中的，也是值得期待的，但它一定会导致复杂性。
+
+       面对复杂性，首先要理解它存在的必然性，观察它产生的原因，要比立刻着手修复它要重要的多。就像治理水患一样，疏要比堵更为有效，找到产生复杂性的原因，理解产生的原因，再动手也不迟。
+
+## 必然会产生债务
+
+       如果所在的系统不会变的复杂，或者说不会持续给你带来治理复杂性的挑战，那就代表着业务已经停滞。发展中的业务，必然会带来系统上的复杂性，而这种必然也会同时带来债务。[Ward Cunningham](https://baike.baidu.com/item/沃德·坎宁安/6488429)提出了一个说法，叫：技术债，它用来描述为了满足进度或用户期望而作出的设计让步。Deadline项目大部分都不会取得既定的业务指标，而它们给系统造成的伤害以及复杂性的上升却需要几倍的人力去挽回。
+
+       既然是债，就需要还，如果不还，就有风险或者问题。技术债是标的在技术产出物上的债务，技术产出物一般包括了硬件、操作系统、软件环境和应用程序。其中前三点，尤其是第二和三点，会构成隐形的技术债，最后一点会形成一般意义上显性的技术债。
+
+       隐形的技术债会带来隐形的成本，比如：使用较低版本的Java或者低版本的中间件，带来的问题就是需要花费更多的计算成本，如果能够定时升级，就会使得硬件的利用率得到提升，同时避免一些安全风险。显性的技术债往往是在应用程序中引入的，比如：由于项目时间过紧导致存在风险或者不合理的设计，以及由于项目技术人员能力问题引入的风险设计，无法应对实际系统（当下或短期可见）需要的计算指标。
+
+       这些技术债会拖慢后续系统的开发效率，增大应用的维护成本，就算使用良好的文档记录也无济于事，需要在技术债出现时给予评级，保证能够在未来的时间加以修复。隐形的技术债对使用者是透明的，但显性的则不然，它们大都是在应用的需求设计阶段引入的，没有系统的实现能够跑在业务需求前面，所以如何能够减少技术债的引入是考量一个架构师是否能够全面思考的关键点，通过一定模式化、具备防御性的架构设计，能够在略微增加项目时间的情况下，做到少负债，使得后续能够偿还债务，毕竟，有些债务的偿还成本过高，甚至难以偿还。
+
+## 债务需要去偿还
+
+       如果不去管理和偿还债务，就会如同当下的经济一样，陷入通缩，这种螺旋式下坠会让人万劫不复。既然复杂性必然要来，那就要科学应对，既不做涸泽而渔的刺激性工作，也不要搞运动式竞赛，妄图不放弃现有利益分配和路径的前提下，通过奋力一击就能回到原有状态，这就是痴人说梦了。业务人员要审视自己负责的业务，哪些存在冗余，产品人员要整理自己负责的产品，哪些没有人用，所有人员都要参与其中，组织中没有一种角色天生就是成本。
+
+       将债务分门别类的登记和管理好，搞清楚债务的起因，看看能否在来源上加以控制。要解决开发人员的效率问题，就要视拖慢业务节奏的慢发展为常态，这是在给业务还债的周期，需要多方理解和配合。通过合理的流程设计，降低开发人员负载，给予开发人员时间能够将手工操作转变为系统操作，避免出现问题。虽然开发人员的需求吞吐下降了，但是系统的稳定性提升了，而且开发人员也会在这个阶段帮助业务找到很多问题。新需求的设计方案以及旧有系统的改进方案都需要准备好扩展性，清晰的API设计以及可能扩展的SPI预留，模块化设计，这些都可以帮助开发人员整理和归纳好技术资产，目的就是未来奔跑过程中不会出现绊脚的情况。归纳好，整理好，屋子不能乱，好架构师就是好物业。
+
+       债务偿还周期需要多方相互理解，这也是对组织的终极考验，顺风仗容易打，但是逆风局才是考验真本事和定力的时候，不成熟的组织将会在债务偿还周期中消亡。如果组织没能突破这个必然，也要想开些，万物的发展就是这样，突破必然的事物也会必然出现，正所谓：沉舟侧畔千帆过，病树前头万木春。