爲何新來的技術很難接手維護一個系統

爲何開發功能變得愈來愈慢?

 

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

 

 

咱們讓項目變得可維護性有不少。對公司，對接手的技術，都是有利而無害的。

 

本身作的成果無法讓下一任銜接。就像官員上任，任期滿了後。這個燙手的山芋丟給下一任去解決。我這一任期內，維護穩定不出事情就能夠。

 

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

 

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

 

 

我發現很是像系統同樣：只要保證我在這公司幹這段時間內，系統是穩定的，能夠繼續加功能完成上面的任務便可。至於定時炸彈何時爆發，只要不在我任期內爆發就能夠了。

因而我在任期內，明明知道這裏是一個坑，都懶得去作代碼優化，作重構了。幹嗎要浪費本身時間作這種事情。

 

 

 

爲何招聘經驗豐富的技術投入和產出很值得。避免了不少坑，留給之後的技術債務。

 

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

 

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

 

 

 

 

命名是可維護性的第一步，代碼的功底卻是其次，由於每一個人的技術經驗不同。用拼音命名帶來接手人員的閱讀成本。好比用拼音命名變量或者程序文件zhuantipt實際上是拼音的縮寫，看不懂在幹嗎咱們第一眼看不出這個要表達的意思，維護一個系統只能靠看代碼來溝通了好的命名，就是減小誤解、減小溝通好比，之前有code，後來有app跳轉到網頁時也有一個code，可是是app_code命名上沒有區分開，形成了一些溝通障礙。開源組件amqp擴展，一個函數原來用的命名是：AMQPConnection::setTimeout():設置超時時間？讀仍是寫，仍是鏈接超時時間？後來他們就改成了：AMQPConnection::setReadTimeout() ，好的命名看到就知道，噢，這是設置讀的超時時間哪怕是剛畢業的技術，沒啥經驗。這種風格也是很容易學的。這樣他寫的代碼，就可讓別人好接手維護。