如同人生一樣，沒有頂層設計的代碼移植過程也是會增加許多原本沒必要的挫折。
最近一週在忙一件事情：將產品A上的F功能移植到產品B上。其中一個很麻煩的問題就是代碼中變量和常量單位的修改，因爲由於B不支持浮點型加速運算，它當中很多原本是浮點型的數據都擴大了100倍轉爲整型進行運算，而A中的F功能代碼還都是採用浮點型運算，因此需要將F功能的代碼中變量和常量的單位根據產品B的需求進行修改，以融合到B中。
剛開始接到這個任務時，覺得這還不簡單，就是把這些變量的單位修改一下嘛。於是沒有太多想就開始一點點兒修改了，這真的是一場噩夢的開始。首先忘了標記在哪兒進行了修改，結果都不知道哪些已經修改過了，哪兒還沒有修改。其次沒有在修改之前系統地分析單位的修改所涉及的全部變量和常量，導致修改完一個再去看哪一個還需要修改，嚴重降低修改的效率。最後，沒有系統地設計單位修改的方案和流程，爲了知道自己修改到了哪種程度、哪些變量還需要修改，只能在修改完一部分之後對整個工程進行編譯運行，而每次編譯都需要挺長時間，自然浪費了很多時間。
更甚的是，尤其是這種缺乏頂層設計的修改，很容易導致某一個變量忘記修改，程序運行過程中自然會出現bug，而這種bug是很難定位的，因爲你不確定到底是哪個部分的問題。恩，我就是在這個問題上栽了兩天時間！按照自己隨意的模式修改完之後，運行程序，感覺好像是運行良好，內心很激動。但是稍微改變下運行參數，裏面的bug就開始逐漸冒泡了。我就開始根據bug的現象，結合程序運行的原理，逐漸猜測定位bug可能出現的位置，然後在這些位置上打上斷點，逐步調試，最後終於發現了bug所在，原來是一個變量在其中一個公式中進行計算時的單位忘記了修改。解決上述bug的過程看似就上面幾句話，但是真的是反覆測試分析了兩天時間，可想而知我這兩天的心情是多麼地鬱悶和焦慮。
在我終於解決了bug的瞬間，除了感覺到心情的順暢，感受根深的是頂層設計的重要性！很多時候在接到一個任務時，我們好像覺得非常簡單，就忽略了去系統地思考這個問題：思考這個問題所會帶來的其他問題、思考解決這個問題的最佳方法和流程、思考要解決這個問題每一步因該具體怎麼做。結果看似很快地付諸了行動，結果卻需要更長的時間，而且絕大部分時間是浪費在解決一些原本可以通過實施前的思考所避免的問題上，且這是的心情也是很糟糕的。那麼何不在行動之前系統地思考一下這個問題怎麼解決最好呢？這就體現了頂層設計的重要性，不僅在人生中很重要，在解決一個小問題時也很重要。
- 明確各變量原來的單位，以及要修改爲的目標單位是什麼，它們之間的轉換關係是多少。
- 明確各變量修改所涉及的範圍，一般包括公式中的變量、大小關係比較、以及常量。
- 根據需要修改的變量的名稱，逐個標記出需要修改單位的變量的位置。
- 逐個完成所有涉及的變量及常量單位的修改，一定不能遺漏某個未修改的變量，否則找bug的時候會讓你懷疑人生。
制定出一個完善、考慮周全的整體方案之後，在根據方案去實施，反而可能是更加高效有保證的做法。