自我參加工作已經有幾年了，接手過的項目也不少，包括安卓端和web前端的，在做這些項目的過程中，相當一部分的項目到最後都出現了一個現象：代碼越寫越亂，維護性越來越差。究其原因，我認爲有如下幾點：
1.程序員自身能力
出現問題，首先得從自己身上找原因，這是我的第一想法。
我們知道，一個項目基本不可能是完全由一個人開發的，這其中就涉及到協作開發，而且IT行業的跳槽還是比較頻繁的，這就導致了一個項目可能經手的人很多，然而不同程序員的個人水平參差不一，很容易就出現寫的代碼差異很大，特別是如果每個人都不按照某一個大概的規則來寫代碼，各做各的，閉門造車，就會出現各種“垃圾”代碼，長久以往，而又不去改變，就會導致項目維護性變差，最終甚至只能重構項目。
這是我認爲最大的原因，解決這個問題除了程序員需要不斷提升自身能力之外，擁有一個項目核心人物和一份完善的項目說明文檔是很有必要的，核心人物必須對這項目充分了解，起到帶頭指導作用，一份完善的文檔可以讓開發者更加直觀明瞭的熟悉項目。我在做一個項目一段時間後，都會爲這個項目寫上一份說明文檔，描述項目的情況，項目的結構，以及標明做這個項目的一些注意事項，然後在以後的開發過程中不斷完善這份文檔，讓參與這個項目的人能方便快捷地瞭解這個項目。
2.項目架構不合理
這裏說的架構不僅僅是指某一端的架構，包括整個項目所涉及的後臺，前端等，很多時候，項目的基礎架構很大程度決定了項目以後代碼的結構，如果項目在初期架構不合理，不夠健壯，容錯性差，本該後臺解決的事卻讓前端來做，一個流程邏輯七繞八繞，這就會導致以後代碼越寫越亂，出現各種拆東牆補西牆、代碼冗餘問題。
這就涉及到在設計系統時必須統籌各方資源，合理規劃項目內容。但有時候項目架構即使足夠合理，也不一定能解決問題，這是我接下來說的第三點比較大的影響因素。
3.不斷變更的需求
我們經常調侃產品經理和碼農是天生的仇人，這其實也是有一部分原因的，產品經理的需求設計決定了碼農應該怎麼去寫代碼，如果一個項目的需求經常變更，產品經理沒有很好地去控制，交給開發人員手上就很容易導致項目的代碼越寫越亂，特別是需求不合理的時候（特別是有些時候爲了迎合客戶而去做一些看上去跟之前設計完全相悖的需求），這就容易導致原有代碼沒辦法重用，不得不又在原有基礎上“添油加醋”，從而出現一大堆冗餘垃圾代碼。
這個有辦法解決嗎？在我遇到的情況來看，只能跟產品多溝通適當調整部分功能，但大部分情況都是因爲時間問題沒辦法調整，然後就不得不在原有基礎上“添油加醋”，不得不說這是一件很無奈的事，而且這種項目一般到一定時間段都很大可能要進行一次重構，欠下的技術債務，總是要償還的，否則長此以往，只能是惡性循環直至搞垮這個項目。當然重構並不是壞事，只是爲了改善現有代碼結構，方便開發，但重構無疑會花費很多人力、時間，這需要在項目不緊急的時候來進行。