軟體工程課所思所想 &&《移山之道》讀後感

　　軟體工程課我的觀念轉變

　　之前瞭解到鄒欣老師教過的軟體工程課都是大四或研究生的課，我還曾抱怨過。

　　我曾想過大三的代碼量還不夠很好地學習軟體工程，而且以我的理解這門課是將一定數量的程式員很好地融合進同一個工程的學習，類似於“介面的構建”。而現在連類內部的方法（個人對程式設計語言的掌握）都沒搞清楚，我們的資料庫等專業課還正在學，要很好地在工程中合作必然阻礙重重。

　　有一段時間我一直都是這個想法。

　　其實自第一天學C開始，我就一直聽到人們在說像learn by doing這類的話，我還是像對待數學物理那樣去學編程必然是行不通的。在無數bug中慢慢提高，這是目前為止我學編程最真切的感受。

　　關於軟體工程課，客觀的說應該是在漫長的編程學習過程中一門鞏固提高並具啟發作用的專業課。我們不能只局限於一個問題的演算法實現和最有效率的資料結構的使用，真正能讓自己的這一段代碼很好地融合進整個大工程，才能真正起到它的作用。所以說個人的修鍊自然是需要堅持進行的，而學會真正在工程中與他人合作，更是必不可少的能力（我曾在@我的微博上聽說Microsoft的一個牛人David Cutler先生經常一個人高效率寫大工程，表示我可不是“作業系統天神”）。

　　《移山之道》

　　在這篇部落格裡我就不班門弄斧地說一些技術上的1234條什麼的了，我就唯寫一些感悟類的東西。《移山之道》是鄒欣老師寫的一本有關VSTS開發的書，不是嚴苛的工具書，就像是一篇篇部落格的合集。我讀後感覺很像是現在本科三年級的我和同學們做編程開發的例子。都是有一定的編程基礎，但是對於如何做工程僅僅是一知半解，像書裡寫的我們的第一個Team 專案是“第一個孩子，照書養”，各種小心翼翼，想要完全消除warning並盡量做到在正確前提下速度最快。

　　然而這是很難實現的。一是我們自身對編程的理解與掌握還有限，再者只要工程稍大點，想要面面俱到就是很難的了。代碼的複雜程度絕對不是線性增加的！這點相信能得到廣大群眾痛心疾首的支援。一旦成千上萬行的程式在眼前展開，尤其是其中好多方法還是照著書第一次用的，調試起來真心有如2012來臨。然而之前都是自己一個人死死盯著螢幕找BUG，或許一天一夜之後被偶然經過的某人一句不經意的話語點醒，那可真是忽如一夜春風來~現在結對程式設計能夠很好地解決這個問題，至少不用等一天一夜那麼久了。

　　在《移山之道》的結尾，我和參加了Stone項目的阿超、果凍等人一樣也做了總結。其實在前進時不必遺憾，若成功了，叫做精彩；就算結果是糟糕的，也稱作經曆。果凍說“發布才是硬道理”，其實這不僅僅是指拿出一個完成的作品，發布了的RTM軟體（其實自Alpha起就已經是了）就要像自己傾注心血的藝術品，我們不滿足基本實現了預想的功能。我們要在這個領域內做到極致。正如文無第一武無第二，IT也是贏者通吃的。行業巨頭天下皆知，要問第二好的是誰？或許已經倒在前進的道路上了。談到軟體實現的功能與使用者需求之間的關係，我想引用@程式員鄒欣老師的微博裡提到過的一條：

　　 最符合實際的要求 > 使用者的要求 > 使用者表達出來的要求 > 軟體團隊理解的要求 > 具體開發人員的理解 > 在當前各種約束條件下的實現 > 給使用者用。　　　　 結束語  　　上邊的這個反饋多走幾遍，才能夠讓軟體真正經得起考驗。我想我現在編程式也應該這樣子要求自己。編程可不僅僅是把一個數學問題用代碼實現那麼簡單，真正的軟體在解決實際問題時有無數的障礙在等著你。使用者並不會像程式開發人員那樣子去想，怎麼樣能讓軟體的使用者體驗友好、易於操作，這不僅僅是單純的技術問題了，綜合多方面因素。軟體說到底是一個工具，不想鎚頭剪刀等實實在在觸摸得到，千百年來人類在不斷完善改進工具來使生活更加美好。軟體實現的就是工具的功能，讓人們的生活為之改變。我們不會做很應手的木器鐵器，但我們能從這無數的“0”與“1”裡創造一個新的世界。（文via 全瘋男）