談「生態文明建設」

在中國特色社會主義「五位一體」的總布局中，生態文明建設是非常重要但卻又極其容易被人們忽略的一部分。

改革開放以來，我國堅持以經濟建設為中心，推動經濟快速發展起來。但是有一些地方、一些領域沒有處理好經濟發展同生態環境保護的關係，以無節制消耗資源、破壞環境為代價換取經濟發展，導致能源資源浪費、生態環境問題越來越突出。

對於一個創業公司，初期通常都會不約而同地以「經濟建設為中心」，如此一來就總會有一些地方對經濟發展和生態環境保護的平衡關係把握不夠好。隨著公司發展的規模越來越大，這些技術債帶來的問題就會越來越突出。

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 天。

這麼評估的意義是什麼呢？在實際開發過程中，一個功能應該歸屬於哪個系統是件模稜兩可的事，在哪兒都能做。如果我們只算開發工作量會出現什麼結果？算上項目健康恢復的成本再想想呢？聰明的你結合前面垃圾處理的例子一定能猜到我要表達什麼吧？把功能放在自己最適合的領域做，總成本才是最低的。

最後

也許有人看到最後依然不知道我整篇在說什麼？又為什麼要說這些？其實這是一篇偽裝成一般文章的讀後感。但是如果我的標題寫成「讀《綠水青山就是金山銀山》有感」恐怕就沒人會點進來了。

書是個很神奇的東西，讀書的心態不同，能夠讀出來的東西也就不同。所有的道理都有著共通之處，跨領域的理論碰撞與交融也是一股推動人類進步的力量。