從“野路子”到“正規軍”的軟體開發之路
大家好，我是寶玉。我的專欄 《軟體工程之美》 剛剛上線，很開心看到了很多同學對軟體工程的理解和期待。
有同學說是從自學程式設計出身的，碰到過很多的問題，和很多人一樣，我也是野路子出身的，2000 年自學 Asp 程式設計，大學期間兼職給別人做了不少網站。但那時候拿到一個專案，上手就是寫程式碼，沒有對需求進行梳理分析，也沒有設計，直接就是想到哪寫到哪。
這種邊寫邊改的模式看起來開發速度很快，但是後面遇到了不少問題。比如說因為沒有分析需求，所以做出來的東西不是客戶想要的結果，就得要多次返工重寫，浪費不少時間；寫之前也沒有設計，邏輯都混在一起。 最誇張的一個程式碼檔案有上萬行程式碼，最大的函式有一千多行的邏輯。 可以想像維護這樣一個專案是多麼的痛苦！ 因為很多邏輯也沒有抽象 ，都是重複的，修改的時候得一個個查詢替換，一不小心漏了就出 bug 了。
有一件事我一直沒好意思提起，就是大二暑假還給別人山寨過一個“金領辦公系統”，如果你搜索一下“金領辦公系統 asp 原始碼”估計還能找到下載，可以看看我當年作為一個野路子程式設計師是什麼水平了，各種拼音 + 英文混合的命名、義大利麵條式程式碼、重複程式碼到處複製……
幸運的是，我大三轉到了軟體工程專業，重新學習了軟體工程、資料結構、面向物件這些基礎課程，畢業也順利的成為一個程式設計師。
經過專業學習後，對我後面成長還是幫助很大的，這個幫助主要體現在兩個方面。
第一個，就是學習新技術的時候，很快能領悟和融會貫通。比如說我學過瀑布模型，後來去看微軟的 MSF，去看敏捷開發，就能根據以前的理論基礎，去看它們共通的地方、不一樣的地方、各自的優缺點，這樣很快就能掌握。
第二個呢就是做事的時候，會更有章法，有理論指導。寫程式前會先注意對需求進行梳理，搞清楚產品經理想要的是什麼，這樣就不用有太多的反覆。寫程式碼之前我會先做設計，思考有哪些共同的模組， 應該怎麼抽象。
後來到飛信的時候，因為表現出色，我開始有機會去管專案。
我還記得第一次作為專案經理去管一個小專案，我一時之間還真有點懵，不知道該怎麼做。好在學過軟體工程，尤其對瀑布模型、軟體生命週期特別熟悉，於是就嘗試著按照生命週期模型，先把專案拆分成幾個階段，然後在每個階段裡面，按照模組再去細分，再去制定專案計劃。
幸運的是，我還找到了當初的專案計劃表，分享給大家看看。
在制定計劃的過程中，也幫助我做了一個很重要的轉變，那就是不再是像以前只盯著一個小模組，不是再只想著技術實現，而是站在專案的整體去思考。
這個專案後來按照我當時制定的計劃進展的很順利。如果之前沒有軟體工程的這些理論基礎，也許我後來還會轉型做管理，但是一定沒有當時那麼順利，要多走很多彎路。
所以我其實一直在微博上、微信上，很多地方都說過，軟體工程是大學裡最重要的一門課程。
我希望 《軟體工程之美》 專欄能幫大家重新理解軟體工程，從苦鑽技術不得法變得行有章法。