幾個星期前，我閱讀過一篇文章，一位老師教導自己的學生要積極地去閱讀文學文獻，其中，我很欣賞他的一句話：“Just think of liturature as if you're reading a long text-message”。引申到這裡，對比後才發現自己在現實生活中真的很少在課後花時間來細看自己的專業書籍，說來慚愧，這種情況出現的頻率最多的就是在學期末備戰考試了。因為這次的作業，我似乎告訴自己這是一個非常“恰當”的理由去讓自己提前去完成未完的“任務”。閱讀一本書，就要認真，要對得起自己，還要對得起作者。這次閱讀鄒欣老師著作的《現代軟體工程——構造之法 》的第一到第五章，我在課堂上用了3節課的時間，在課下用了一個半小時，受益匪淺！
-
第一章（概論）1-19
這一章主要是把“軟體工程”這四個字剖析了。從一開始的介紹，就讓我們瞭解到 軟體=程式+軟體工程，程式=資料結構+演算法 。
軟體工程是把系統的、有效的、可量化的方法應用到軟體的開發、運營和維護上的過程。一個複雜的軟體不但要有合理的軟體架構、軟體設計與實現，還要有各種檔案和資料來描述各個程式檔案之間的依賴關係、編譯引數等等。“軟體工程”是一個大專案，裡面有很多的概念需要我們理解：原始碼管理（配置管理）、質量保障、軟體測試、需求分析、程式理解、軟體維護（服務運營）、軟體生命週期、專案管理、使用者體驗等等。
“軟體工程”的概念是在1968年第一次被提出來的，為了更好的瞭解它的歷史及影響，我們拿軟體業和航空業來做對比，可以得出好多相似的地方：
軟體它是屬於邏輯產品，生產的團隊很大，雖然維護比較複雜且易退化，但是它不會磨損老化。在1.2.5節中，談到了什麼是好的軟體？同時，我也很疑惑，因為Bug的多少可以直接衡量一個軟體的開發效率、使用者滿意度、可靠性和可維護性，那麼是不是軟體沒有Bug就是好軟體呢？我覺得不然，因為有實際用處的同時又是完美的軟體，在這個世界上是不存在的。就算微軟很自豪的window8系統也會有偶爾出現藍屏的現象，但是這並不會直接影響到微軟公司的能力，也不會直接影響到window8系統的可用性，因為你的RP是由你的程式質量決定的，所以我個人覺得軟體不存在完美，總會有顧客的客觀或主觀因素而感到不滿意，我們不能迎合所有的市場需求，最重要的還是考核市場的主流需求而不斷完善自己跟團隊研發的作品。
-
第二章（個人技術和流程）20-41
這一章主要是介紹 PSP（Personal Software Process），也就是指個人軟體開發的流程，主要由單元測試和效能分析工具組成。
單元測試可以準確、快速地保證程式程式基本模組的正確性，建立單元測試函式的主要步驟是：設定資料、使用被測試型別的功能、比較實際結果和預期的結果。在2.1.2節中談到了怎樣才算一個好的單元測試，經總結後應該是：單元測試應該在最低的功能/引數上驗證程式的正確性；單元測試必須由最熟悉程式碼的人（程式的作者）來寫；單元測試過後，機器狀態保持不變；單元測試要快（一個測試的執行時間是幾秒鐘，而不是幾分鐘）；單元測試應該產生可重複、一致的結果；單元測試的執行/通過/失敗不依賴於別的測試，可以人為構造資料以保持單元測試的獨立性；單元測試應該覆蓋所有程式碼路徑；單元測試應該整合到自動測試的框架中；單元測試必須和產品程式碼一起儲存和維護。
效能分析主要有抽樣和程式碼注入這兩種分析方法。抽樣方法不需要改動程式，執行較快，可以很快找到瓶頸，但是不能得出精確的資料，也不能準確表示程式碼中的呼叫關係樹。而程式碼注入可以使程式的各個資料都可以被精確地測量，但執行的時間會大大加長，還會產生很大的資料檔案，同時也增加了資料分析的時間，這會影響程式的執行情況。如果我們不經分析就盲目優化分析，也許會事倍功半，所以我們要根據實際情況來選擇適合自己程式的分析方法。
在2.3節中，對比了大學四年級的學生和工作三年的軟體工程師的個人專案耗時，表中可以明顯的發現在需求分析和測試這兩組資料上，工程師會比大四的學生用時多，而在具體編碼上大四學生是比工程師花費的時間多。那這樣是不是就一定說明大四的學生比軟體工程師弱？我覺得不然，軟體工程師是比大四學生多讀了3年書，多工作了3年，兩類人所處的環境跟所經歷的東西不同，所以兩個人任務完成的質量要求也就不一樣，我覺得，按照目前來說，大四學生在對軟體工程運用的熟悉程度上或許還不及工程師，但只要經過刻苦的鍛鍊，醜小鴨也會變成漂亮的天鵝的！
-
第三章（軟體工程師的成長）40-54
這一章主要講述了軟體工程師中，高階工程師為何會比剛入職的工程師優秀。
初級軟體工程師要讓自己成長並強大起來，就需要做到：積累軟體開發的相關知識，提升技術能力（如對具體技術的掌握，動手能力）；積累問題領域的知識和經驗；對通用的軟體設計思想和軟體工程思想的理解深入；提升職業技能（區別與技術技能）；有實際成果。高階軟體工程師，對於我們現在的水平來說，是不是就觸不可及了呢？其實不然，我們現在還年輕，還有很多時間去學習、去實踐，在通往高階軟體工程師的路途上，我們可以考相關的證書來獲取理論上的技能，然後去各相關的單位上實習來獲取經驗，最後通過自主研究或團隊開發來進行實踐，進而開發大腦智力和提升自己的動手能力。
同時，我們要時刻對自己進行自我評估。絕大部分的軟體工程師都不是技術天才，很多都是後天形成的，我們要多對自己的能力進行評估並作出及時的改進，然後通過不斷的學習，把那些低層次的問題都解決了，變成不用經大腦的自動操作，然後才有時間和腦力來解決較高層次的問題。
-
第四章（兩人合作）56-82
這一章主要講述了兩人合作的不同階段和影響他人的技巧。
軟體都是在相互合作中完成的，翅膀只剩一邊是飛翔不起來的，儘管很努力的飛到半空，也不夠雙翅滑翔的輕鬆自如，所以合作真的很重要。在合作中，只有互相交流、交換思想，才會發現自己的優勢和不足之處在哪裡。有了同伴的監督，可以讓自己不敢偷懶，讓自己更認真的去檢視和更正程式的不足，有了一個方向和目標，讓大家更有追求。
在4.4節中，強調了程式碼複審的重要性。那我們應該以怎樣的情況和環境下進行復審呢？程式碼複審有自我複審、同伴複審和團隊複審，在軟體工程中最基本的複審手段就是同伴複審。複審者是要通過發現問題來確保軟體質量的，我們做程式碼複審的目的是為了減少錯誤的發生，而不是找一個人來對著自己點頭，所以，找到一個適合自己的同伴來一起工作是很重要的，讓兩個人在駕駛員和領航員的角色中互換，進而提高雙方的能力水平。兩個人能夠成功的脫穎而出就能夠在合作的階段從萌芽到磨合，進而到規範，不成功的合作伙伴如果不能體諒對方，或許就會輸在磨合階段，因此，換位思考在這裡起著至關重要的作用。
兩個人的合作即為結對子合作，結對程式設計其實對結對的我們都會有很多好處：在開發層次，結對程式設計能提供更好的設計質量和程式碼質量，兩個人合作解決問題的能力更強；對開發人員自身來說，結對工作能帶來更多的信心，高質量的產出能帶來更高的滿足感；在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，分享知識，能更好地應對人員流動。
總之，兩隻手能抬，兩條腿能跑，兩個人才能交流合作。
-
第五章（團隊和流程）83-99
這一章主要介紹的是團隊精神
那是不是說只要能組合在一起的就是組成了一個團隊了呢？其實不然，軟體團隊有各種形式，適用於不同的人員和需求。適合自己的團隊才能共贏！
一個好的團隊流程能把衝突的積極方面（各自盡力把自己的工作做好，說服別人）釋放出來，而避免消極方面（因為衝突而產生的消極、牴觸情緒等）。我們不能因為說有了團隊的隊友就放鬆對自己的要求，因為每一個人的工作質量會直接影響到最終軟體的質量，當所有的個人高質量工作加起來才可以達到一個優秀的團隊高質量工作專案。
軟體團隊的模式有好多種：主治醫師模式、明星模式、社群模式、業餘劇團模式、祕密團隊模式、特工團隊模式、交響樂團模式、爵士樂模式、功能團隊模式和官僚模式。每一個團隊不能夠衝著利益最高的而自創模式或亂串模式，適合自己團隊和專案要求的才是最重要的。那麼怎樣加強與別人的合作呢？在一個組織之中，很多時候，合作的成員不是我們能夠選擇得了的，所以很可能出現組內成員各方面能力參差不齊的情況，如果作為一個領導者，此時就需要很好的凝聚能力，能夠把大多陣列員各方面的特性凝聚起來，同時也要求領導者要有很好地與不同的人相處與溝通的能力。如果領導者在開始時沒有以身作則做好各方面的工作，就會產生許多不良的後果。
所以，學會與他人合作，發揮團隊精神在具體生活中的運用，可以使我們收到事半功倍的效果，可以使我們的工作更加良好地向前發展。
