老專案和人有一個能跑就行

 大多數開發者認為“老專案和人有一個能跑就行”，不願意對其做較大的改動。所以有個名詞叫zuchuan程式碼。我猜幾乎每家公司都會遇到這種情況吧。

 原因太多了，以下都是我結合各行各業吐槽列出（但不限於）

1.需求亂提：不合理的需求未萬惡之源，可能這個需求會導致特別複雜。12306的業務場景堪稱變態，造成這種是我國地域發展不均衡的，實在也改不了。但是也有不少公司的需求不亞於12306的複雜度，那就不應該了。按照這種需求寫的程式碼，想很清晰是不太可能了。

2.設計亂來：其實就是沒設計。今天建立個表，明天加個欄位。表是什麼含義不知道預留了，tab001  002.欄位也是預留欄位1，預留欄位2.。。。。。。你會發現一個有趣的現象就是幾乎從來沒人用預留欄位。因為不敢用。不知道自己會不會影響別人。所以預留了個寂寞。

3.開發亂寫：比如一個表50個欄位。如果是核心表，我會設計提供最小化原則，只提供幾個關鍵的，其他的來一個定製的，按需提供。確保最頻繁的操作一定最輕量化。但是現實中，我看到的一般都是最大化提供。提供出去一個全部的作為公共。即使其他場景用一個，也要取全部。更有甚者全部取到頁面上，然後是僅僅不顯示。這種消耗和傳輸都實實在在發生了。

4.運維不力：管控不了開發，然後擴充套件到架構層面引入中介軟體和異構資料庫。這本身有增加了開發難度和成本，給 zuchuan程式碼繼續加碼。

今年不是有文章說有云了，還要不要DBA。其實就以上幾個場景來說，1 2公有云是一點都解決不了，要DBA去解決。3 4 公有云最希望你發生，用的越多成本越高。DBA是可以去解決的。當然這裡的DBA已經到了最高的Architect的程度了。至於私有云就是1234幾乎都管不了。

一般來說CTO都不希望出故障，如果出了故障要先發現以及快速解決。在123的前提下，做到這點非常難。我個人愚見還是管好123，才能儘可能程度防患於未然。