微軟最具價值技術專家：我的 16 年軟體開發經驗總結

摘要： 大家好，我是寶玉。有同學說是從自學程式設計出身的，碰到過很多的問題， 走了很多彎路，日常搬磚，增刪改查，非常困惑沒有自信。 這讓我想起了自己的經歷，和很多人一樣，我也是“野路子”出身的，2000 年自學 Asp 程式設計，大學期間兼職給別人做了不少網站。但那時候拿到一...

以前沒多大的感覺，並且這種邊寫邊改的模式看起來開發速度很快，但是後面遇到了不少問題。

比如說因為沒有分析需求，所以做出來的東西不是客戶想要的結果，就得要多次返工重寫，浪費不少時間；寫之前也沒有設計，邏輯都混在一起；難得接手一個複雜的、大的功能模組開發，也不知道如何拆解分工協作；以為功能上線就完事了，沒想到還要寫測試程式碼進行功能測試；還有些日常的小工具像原始碼管理、Bug 跟蹤等等，竟然都要用。

最誇張的是有一個程式碼檔案有上萬行程式碼，最大的函式有一千多行的邏輯。可以想像，維護這樣一個專案是多麼的痛苦！因為很多業務邏輯沒有抽象，都是重複的，修改的時候得一個個查詢替換，一不小心漏了就出 bug 了。

有一件事我一直沒好意思提起，就是大二暑假還給別人山寨過一個“金領辦公系統”，如果你搜索一下“金領辦公系統 Asp 原始碼”估計還能找到下載，可以看看我當年作為一個“野路子”程式設計師是什麼水平了，各種拼音 + 英文混合的命名、義大利麵條式程式碼、重複程式碼到處複製……

比較幸運的是，我大三轉到了軟體工程專業，重新學習了軟體工程、資料結構、面向物件這些基礎課程，畢業也順利的成為一個程式設計師。

這句話對我影響很大。我真的開始在日常生活中， 把每一件事都當做一個工程專案來推進。

2010 年在上海的時候，我機緣巧合參加了一個關於產品設計與使用者體驗的線下活動，我可能是與會人員中，為數不多的 非專業產品設計 的同學。在活動中組織者安排了一個遊戲環節，每 5 個或 6 個人分成一個小組，來設計一個給老年人使用的手機，限時 30 分鐘，完成後，每組選一個人上臺花 5 分鐘展示作品，最後投票選出做得最好的一組。

我的第一反應就是把它當作一個專案，於是快速地擬定了如下計劃。

• 0~10 分鐘（分析）：頭腦風暴，收集想法。
• 11~15 分鐘（設計）：根據頭腦風暴結果，確定最終設計。
• 16~25 分鐘（開發）：將想法畫在紙上。
• 26~30 分鐘（釋出）：完善結果，準備展示。

這個計劃小組成員都很認可，於是我們嚴格按照這個計劃進行手機的設計。同時我觀察了一下其他組的情況，大家都在熱火朝天地討論各種想法，似乎沒有意識到時間其實是有限的。輪到演示的時候，我們組毫無爭議地拿到了第一，因為我們不僅準備充分，而且設計的手機功能完整，而其他很多組甚至還沒來得及把想法完整地畫下來。

經過軟體工程的專業學習後，對我後面成長還是幫助很大的，這個幫助主要體現在兩個方面。

第一個，就是學習新技術的時候，很快能領悟和融會貫通。比如說我學過瀑布模型，後來去看微軟的 MSF，去看敏捷開發，就能根據以前的理論基礎，去看它們共通的地方、不一樣的地方、各自的優缺點，這樣很快就能掌握。

第二個，就是做事的時候，會更有章法，有理論指導。寫程式前會先注意對需求進行梳理，搞清楚產品經理想要的是什麼，這樣就不用有太多的反覆。寫程式碼之前我會先做設計，思考有哪些共同的模組，業務邏輯應該怎麼抽象。

後來到飛信的時候，因為表現出色，我開始有機會去管專案。

我還記得第一次作為專案經理去管一個小專案，我一時之間還真有點懵，不知道該怎麼做。好在學過軟體工程，尤其對瀑布模型、軟體生命週期特別熟悉，於是就嘗試著按照生命週期模型，先把專案拆分成幾個階段，然後在每個階段裡面，按照模組再去細分，再去制定專案計劃。

在制定計劃的過程中，也幫助我做了一個很重要的轉變，面對問題我會參考軟體生命週期和瀑布模型，把一件事情分成幾個階段： 分析、設計、實施、測試、完成，然後制定相應的計劃。

這種方法不僅非常有效，讓我的做事效率大幅提高，而且讓我在看待事情上，能夠更全面地、站在更高的角度去思考。

這個專案後來按照我當時制定的計劃進展的很順利。如果之前沒有軟體工程的這些理論基礎，也許我後來還會轉型做管理，但是一定沒有當時那麼順利，要多走很多彎路。

所以我其實一直在微博上、微信上，很多地方都說過，軟體工程是大學裡最重要的一門課程。我 希望 《軟體工程之美》 專欄能幫大家重新理解軟體工程，從苦鑽技術不得法變得行有章法。