人的腦子真是奇妙的東西。雖然大家都知道過度工程（over-engineering）不好，在實際的工程中卻經常不由自主的出現過度工程。我自己也犯過好多次這種錯誤，所以覺得有必要分析一下，過度工程出現的信號和兆頭，這樣可以在初期的時候就及時發現并且避免。 過度工程即將出現的一個重要信號，就是當你過度的思考“將來”，考慮一些還沒有發生的事情，還沒有出現的需求。比如，“如果我們將來有了上百萬行代碼，有了幾千號人，這樣的工具就支持不了了”，“將來我可能需要這個功能，所以我現在就把代碼寫來放在那里”，“將來很多人要擴充這片代碼，所以現在我們就讓它變得可重用”…… 這就是為什么很多軟件項目如此復雜。實際上沒做多少事情，卻為了所謂的“將來”，加入了很多不必要的復雜性。眼前的問題還沒解決呢，就被“將來”給拖垮了。人們都不喜歡目光短淺的人，然而在現實的工程中，有時候你就是得看近一點，把手頭的問題先搞定了，再談以后擴展的問題。 另外一種過度工程的來源，是過度的關心“代碼重用”。很多人“可用”的代碼還沒寫出來呢，就在關心“重用”。為了讓代碼可以重用，最后被自己搞出來的各種框架捆住手腳，最后連可用的代碼就沒寫好。如果可用的代碼都寫不好，又何談重用呢？很多一開頭就考慮太多重用的工程，到后來被人完全拋棄，沒人用了，因為別人發現這些代碼太難懂了，自己從頭開始寫一個，反而省好多事。 過度地關心“測試”，也會引起過度工程。有些人為了測試，把本來很簡單的代碼改成“方便測試”的形式，結果引入很多復雜性，以至于本來一下就能寫對的代碼，最后復雜不堪，出現很多bug。 世界上有兩種“沒有bug”的代碼。一種是“沒有明顯的bug的代碼”，另一種是“明顯沒有bug的代碼”。第一種情況，由于代碼復雜不堪，加上很多測試，各種coverage，貌似測試都通過了，所以就認為代碼是正確的。第二種情況，由于代碼簡單直接，就算沒寫很多測試，你一眼看去就知道它不可能有bug。你喜歡哪一種“沒有bug”的代碼呢？ 根據這些，我總結出來的防止過度工程的原則如下： 1. 先把眼前的問題解決掉，解決好，再考慮將來的擴展問題。 2. 先寫出可用的代碼，反復推敲，再考慮是否需要重用的問題。 3. 先寫出可用，簡單，明顯沒有bug的代碼，再考慮測試的問題。