前言
代码写了很多年，是“砖工”，还是“专家“，对代码的认知是一个绝对的分水岭。
代码最重要的是什么
是让人看的惬意，改的轻松。即：可维护性高。
注意：是让人。 再注意：人。
软件理论一大堆，什么 6 个原则，29 种设计模式，高内聚低耦合，DDD，各种架构，还有各种规范（比如代码不超过 50 行）等，无非就是为了解决这个问题。
代码写出来，是给人看的。
关于代码复用
代码复用和软件架构设计的好不好没啥相关性。
代码复用是结果，不是目的。 说“可以通过代码复用来减少代码行数，提升可维护性”的人，都是外行。
能不能复用，要分开看。算法类的可以复用，因为输入和输出都是明确的。业务类代码，要评估业务流程在多长的时间内具有相同的性质，如果在短时间内就会出现逻辑上的分叉，那么就不应该复用。即使内部实现逻辑完全一样，也不能，只不过是恰好相同罢了。就像双胞胎虽然像，但不是一个人。
关于框架复用
核心业务代码中，如果要引用其他的轮子，一定要加上防腐层。 否则，便如附骨之蛆，想去掉，那可就难上加难了。
注意： 是核心业务代码。
为什么那么多企业不敢升级 Java 版本，还不是因为依赖某框架的太深，太多？本末倒置。 浪费了多少人的青春，去研究那个狗屁框架？看起来光鲜亮丽，是苦是甜只有维护的时候才知道。
想减少造轮子是对的，但是不要把腿砍了安在轮子上，尤其是自己控制不住的轮子。
曾经的一个函数50行
曾记得，有一些公司的规范上写一个函数不能超过 50 行。考虑过为啥不？ 各位自己悟吧。
关于 Golang 的设计思路
Golang 有两个特性是非常优秀的。一个是协程的原生支持，一个就是Context&Error。
协程的支持，减少了资源的占用，这对企业来说降低的都是成本，都是钱。
Context&Error 的设计，恰恰是降低了维护成本，提升了可观测性的优秀设计。
这二者，真心是契合当今企业发展的超优秀的工程化语言。
