之前聽公司某高管說過的，做項目計劃，有時候就像一個近視眼往一個遠處的山頂進發。你對你大概怎麼登山，方向如何，大概需要多久，最開始有個粗略的估算。然而隨著你前行，你能看得清的視野就逐漸推進。你會不斷髮現你之前沒有看到的沼澤、峭壁，甚至攔路虎。所以，有一個大方向不夠，你還應該有一個隨著需要新問題不斷合理調整路線，調整進度的策略。一成不變地試著只按照開始的路線的方案前進，很難行得通。
很多時候，項目也是。你會在後面發現，某個產品特性沒有考慮進去；某個基礎設施的功能塊還不存在；某個你以為可以用的工具原來不能完全適合你的需求…… 那這個時候，大家只能坐下來討論，如何進行調整。
而對於設計弊端的改進，其實很多時候有個度。比如你發現一個系統某個設計，原先是很好的，但是因為新加入的一個產品需求，突然變得不能支持這個需求。這時候或者做一些小改動，但可能會成為系統長久的一個隱患，也即 tech debt；或者考慮進新需求，重拿一套看似更完美的設計方案。
從道理上講，tech debt 是每個工程師都極力試圖避免的東西。但是重新設計新方案，真的就一定更好麼？
首先，取決於項目已經進行到哪個階段，重新設計可能意味著大量的代碼要重寫重構，很多相關的子系統設計要重新做相應改動。很多時候可能引起項目的延期。
此外，你當然可以說寧願延一個月，搞一個更理想的系統更可取。但是事實是，另一個方案只是設計階段，你是不是能保證沿著新方案做到一半的時候，不會發現其實新方案也有它的弊端呢。還有的時候，雖然說老方案在新特性上確實不那麼好用，但是這個新特性會不會不是一個核心需求，否則也不會在一開始完全沒有被考慮。即使是真的新增的核心需求，是不是能經得起各種用戶測試反饋，而長久地留下來？或者說其實只有很少的時候、很特殊的用戶才會用到？
當然，這也不是說，所有的時候，我們都有足夠的理由不對設計進行大的改動。如果設計的弊端就好像一棟房子的地基對其安全性可用性造成影響時，無論如何，也必須重新考慮。
那麼，怎樣才能盡最大可能的避免項目中大的設計改動呢？
一是初期設計的時候，就像近視眼登山，雖然你對遠處只能看到一個輪廓，但也要儘可能的去使用所有的工具，比如望遠鏡和地圖，去幫助你設計一個更可靠的路線和進度方案。設計也是，儘可能和產品充分溝通，確保你瞭解所有現有和未來幾年內可能的場景。儘可能瞭解你需要使用的已有系統和工具，以及正在開發的系統和工具，確保你想要的相關性能都能得到滿足。
二是設計在大的框架和細節上的平衡。確保大的框架可以以不變應萬變，這個上面花的功夫越多，後面進退兩難的窘境就會越少。而一些小的細節，如果能保證是可以把改動相對獨立化（decouple），而不會有牽一髮而動全身的耦合，哪怕後期要改，也不是什麼大問題。
和所有有經驗、有決定權的人在大框架上反覆溝通，確認再確認。而不是等到工程進行到一半被質疑為什麼這樣的設計決定沒有讓該知道的人知道。哪些是可以自己掌握的細節，視情況而定。
三是儘可能的將可驗收部分分塊，也就是一年的工程，每個季度可以完整交付哪一塊。而不是說，所有的部分都是正在進行，只有年底一個驗收階段，分期定交付目標可以把一些大問題控制在一個相對有限的範圍內。
四是任何一個系統，隨著產品、用戶數的進化，都不會是完美的，都持續會有新的可改進空間。知道自己主要要解決的問題是什麼，並且時刻謹記。因為有時候在為了某一個原因改設計的時候，可能你無意讓另一個之前解決的問題，變成新的痛點。
最後，項目是死的，人是活的。有的時候，同一個問題，換個人來負責，來做，可能就有完全不同的抉擇。儘可能制定一些指導規則，確保大家都同意，這樣，即使因為人員變動產生分歧，也不會引起太多不必要的爭論。
大改動傷筋動骨，要盡力避免。小改動幾乎是無可避免，坦然面對就行了。而小改動，雖然說不可避免，且危害不算太大。但有時候，因為各種產品、參與者的關係，也可能會發生 “改回來又改回去” 的情況。
閱讀更多 程序員的日常那些事 的文章
