為什麼開發功能變得越來越慢?

某天來一個技術，他跟老闆說：這個系統太臃腫了。很亂，我很難開展工作下去，至少很難按照我的經驗和設想來實施。如果想讓我順利幹下去，辦法就是對系統進行重構一次(重構程式碼,或者開發新的系統替代原來系統)。

我們讓專案變得可維護性有很多。對公司，對接手的技術，都是有利而無害的。

自己做的成果沒法讓下一任銜接。就像官員上任，任期滿了後。這個燙手的山芋丟給下一任去解決。我這一任期內，維護穩定不出事情就可以。

片面追求gdp指標，就好像片面追求功能的完成，不管功能完成的質量。外行也沒法評價功能完成的質量，他們只能說：這個功能達到我的預期了。就是質量好。

這就好比，gdp達到預期指標了。就是質量好。可是會忽略掉一些重要的東西。

我發現非常像系統一樣：只要保證我在這公司幹這段時間內，系統是穩定的，可以繼續加功能完成上面的任務即可。至於定時炸彈什麼時候爆發，只要不在我任期內爆發就可以了。

於是我在任期內，明明知道這裡是一個坑，都懶得去做程式碼優化，做重構了。幹嘛要浪費自己時間做這種事情。

為什麼招聘經驗豐富的技術投入和產出很值得。避免了很多坑，留給以後的技術債務。

我覺得，至少要招聘經驗豐富的技術作為領頭羊帶領下面的人，有一個正面的能量。

俗話說，上樑不正下樑歪，下面的人都是看領導是什麼水平的。領導是一個什麼樣技術思想，下面的人就能夠很好的施展開來。

命名是可維護性的第一步，程式碼的功底倒是其次，因為每個人的技術經驗不一樣。

用拼音命名帶來接手人員的閱讀成本。比如用拼音命名變數或者程式檔案

zhuanti
pt
其實是拼音的縮寫，看不懂在幹嘛

我們第一眼看不出這個要表達的意思，維護一個系統只能靠看程式碼來溝通了

好的命名，就是減少誤解、減少溝通


比如，以前有code，後來有app跳轉到網頁時也有一個code，但是是app_code

命名上沒有區分開，造成了一些溝通障礙。

開源元件amqp擴充套件，一個函式原來用的命名是：AMQPConnection::setTimeout():設定超時時間？讀還是寫，還是連線超時時間？

後來他們就改為了：AMQPConnection::setReadTimeout() ，好的命名看到就知道，噢，這是設定讀的超時時間


哪怕是剛畢業的技術，沒啥經驗。這種風格也是很容易學的。這樣他寫的程式碼，就可以讓別人好接手維護。