在中国特色社会主义「五位一体」的总布局中，生态文明建设是非常重要但却又极其容易被人们忽略的一部分。
改革开放以来，我国坚持以经济建设为中心，推动经济快速发展起来。但是有一些地方、一些领域没有处理好经济发展同生态环境保护的关系，以无节制消耗资源、破坏环境为代价换取经济发展，导致能源资源浪费、生态环境问题越来越突出。
对于一个创业公司，初期通常都会不约而同地以「经济建设为中心」，如此一来就总会有一些地方对经济发展和生态环境保护的平衡关系把握不够好。随着公司发展的规模越来越大，这些技术债带来的问题就会越来越突出。
1. 系统工程思路的脏治理
我们要认识到，山水林田湖是一个生命共同体，人的命脉在田，田的命脉在水，水的命脉在山，山的命脉在土，土的命脉在树。用途管制和生态修复必须遵循自然规律，如果种树的只管种树、治水的只管治水、护田的单纯护田，很容易顾此失彼，最终造成生态的系统性破坏。由一个部门负责领土范围内所有国土空间用途管制职责，对山水林田湖进行统一保护、统一修复是十分必要的。
经济的发展、社会的进步、人类文明的延续始终都伴随着一些副产物。「让自己所在的领域保持干净」看起来并没有问题，甚至相当美好。但是如果每个人都只是在为自己所在的领域干净而「努力」，那这份「努力」可能反而会带来更严重的破坏。因为「脏东西」并不会凭空消失，你的所谓「努力」只会将它转嫁到了自己看不见的领域而已。
「脏东西」的存在是很难完全避免的，总要有领域来消化它。我们应该让最适合的领域来消化它，这才是可持续发展。比如城市垃圾的治理，最初填埋法就是在用一个很不合适的领域来处理「脏东西」，随之而来的「垃圾围城」、「地下水污染」等问题在大家看不见的领域逐渐滋生起来。后来的焚烧发电等做法虽然污染也不小，但是比起百害而无一利的填埋已经算是在用一个比较合适的领域来处理了。
在软件架构中同样也存在很多无法抹去的脏逻辑，我们同样也应该找一个合适的领域来处理这些脏逻辑。
我们在推动 API 治理时就曾遇到过这样的问题。背景是希望通过一个通用的适配层来取代掉原来基于 php 和 Java 开发的 API 层，因为这一层占据了大量开发资源，希望把这一层的开发资源释放出来投入到更有意义的地方。但是这一层本身就是一个垃圾场，它们处理的往往都是最脏的逻辑，比如把数据拼成前端需要的结构又或者直连 DB 补充查询一些底层服务没有提供的数据。想要取代掉这一层就相当于把一个「垃圾场」给消灭，那么「垃圾」要怎么处理呢？
只能下沉到底层服务或前置到客户端。
可是客户端和底层服务的开发人员当然都不想自己负责的领域变脏。如果还只是以自己所在的领域来看问题，就会发展成两端的开发人员互相推脱这些脏逻辑的归属，造成更严重的后果。所以「由一个部门负责领土范围内所有国土空间用途管制职责，对山水林田湖进行统一保护、统一修复是十分必要的」。
2. 环境与生产力
2.1. 避免先污染后治理
当项目达到一定体量之后，如果开发人员还是抱着「先污染后治理」的态度来工作，最终总体工作量反而会增加，造成生产力浪费。这一点在环境库兹涅茨曲线上可以很直观地看出。
因为「治理」并不是一件轻松的事，无论是 API 治理、SOA 治理还是账户体系治理等，但凡升级到「治理」的层面，执行起来都是非常痛苦的。
举例：TODO
本来这一段在写的时候就想举例说明，但是一直想不到合适的例子，于是打了个 TODO。后来翻回来才意识到 TODO 本身就是一个挺不错的例子。
大部分时候代码里一旦写了 TODO 后来就不会去动了。不动的原因可能并不是因为懒，而是因为代码已经处于一个稳定版本，一旦实现了这个 TODO 可能反而冒出一系列问题。大家都不想去碰已经稳定了的代码，这也就是为何推动「治理」这件事非常困难的原因。
虽然通过一些行政手段可以强行推动，但如果执行的人没有明白这件事本身的价值，执行起来就会出现很多疏漏，甚至产生反效果。所以才有我这样的人来写这种试图给读者注入奇怪价值观的文章。
2.2. 如果不从现在起把这项工作紧紧抓起来，将来会付出更大的代价
也许有人会觉得，如果是因为「治理」的成本高，放任不治理不就行了吗？软件项目和生态环境不是完全对等的，生态环境是我们永远无法放弃的东西，而软件项目本身就有一个生命周期。只要确保在软件项目的生命周期内不捅出什么大篓子不就行了吗？
这种想法正是导致祖国经济快速发展时「一些地方、一些领域」没有处理好经济发展同生态环境保护关系的原因。一个公司甚至一个国家一定不是只有一个项目在进行，如果每个局部都认为自己是可舍弃的，那么我们还能剩下什么？
退一步说吧。项目往往很难预估生命周期，下一刻可能莫名其妙就变成网红，也可能怎么努力都吸引不来用户。如果一个项目希望在自己的生命周期内不捅出什么大篓子，那就只有从现在起把这项工作紧紧抓起来，否则将来可能付出更大的代价。
3. 领域驱动
在项目开发过程中，项目管理通常都只关心「项目进度」和「Bug 数量」等这些看得见摸得着的指标，而对于代码可读性、可维护性、可扩展性，以及周边的文档等这些可能不会直接影响业务的东西完全不上心甚至不会去思考的。
其实这也不能怪项目经理，从技术角度去看这些问题确实太复杂了。根本问题还是缺少一套科学的考核考评体系。如果有一个非常明确的维度可以判断一个项目的技术健康程度，并且加入到项目评估中。那么就和开发前评估工作量一样，我们同样可以评估一个功能需求的开发对项目健康程度的影响，然后把这个影响计如开发成本中。
比如开发 a 功能需要 n 天的工作量，但是除此之外还需要 m 天才能将其产生的硬编码、冗余逻辑等清理完毕，把文档之类的东西补全，把监控完善，把项目恢复到之前的健康状态。那么这个项目虽然 n 天可以开发完毕，但成本是需要 n + m 天。
这么评估的意义是什么呢？在实际开发过程中，一个功能应该归属于哪个系统是件模棱两可的事，在哪儿都能做。如果我们只算开发工作量会出现什么结果？算上项目健康恢复的成本再想想呢？聪明的你结合前面垃圾处理的例子一定能猜到我要表达什么吧？把功能放在自己最适合的领域做，总成本才是最低的。
最后
也许有人看到最后依然不知道我整篇在说什么？又为什么要说这些？其实这是一篇伪装成一般文章的读后感。但是如果我的标题写成「读《绿水青山就是金山银山》有感」恐怕就没人会点进来了。
书是个很神奇的东西，读书的心态不同，能够读出来的东西也就不同。所有的道理都有着共通之处，跨领域的理论碰撞与交融也是一股推动人类进步的力量。
