在學習這麼多之後，軟體工程給我的印象是：使用者需求的框架+樸實**的填充。
那麼在寫軟體的時候一定要用傻瓜式的**了麼？顯然不是，高階演算法能極大地減少時間複雜度與空間複雜度，只是放在大型工程裡，需要注意資料與其他模組的關聯性。現在我們先討論什麼是「好軟體」。一般情況下我們認為沒有bug的軟體就是乙個好軟體，但顯然乙個沒有任何bug的軟體極難，甚至是不可能寫出來，那麼退而求其次，我們可以從多個方面去評估軟體，書中列出了4個方面：使用者滿意度，可靠性，軟體流程質量，可維護性。由於我們是按使用者的需求去設計，因此有很多地方需要開發人員和使用者去溝通協商，因此，我認為：好軟體=技術+溝通。
軟體工程專案通常是乙個開發團隊去做，但不可因此忽略個人技術，這裡就提到了乙個重要的流程：單元測試。我對自己寫的**從來都是寫完乙個功能，隨便寫幾個樣例扔上去簡單測試一下，至少書中那樣詳細的單元測試流程，我沒有做到。但不可否認，這樣的測試十分重要。悶頭寫完所有**，測試最終結果時報錯，當你回顧所有**時你會感到非常頭疼，倒不如一步一腳印慢慢走。此外，在開發專案上，還有乙個回歸測試，這個在我的理解看來，大概就是更新軟體後出了bug，倒退到原來沒出bug的情況。最後在流程上的重點，注釋是關鍵，毫不誇張地說，現在讓我去看之前寫過的，沒有注釋的專案，若非時間短還有些印象，我要看懂也有些麻煩。注釋是寫給別人看的，盡量寫得簡練一些。
怎樣成為乙個合格軟體工程師，基礎的技術功底一定要過硬，在通過閱讀書籍和老師傳授的經驗之後，軟體工程師要有一定的思想基礎，我們是工程師，要講究分析設計，而不是單純的「碼農」。先談談技術功底，衡量技術總歸需要專案來看，乙個軟體開發的工作量和質量的衡量標準有4點：專案/任務大小；花費時間；質量如何；是否按時交付。分攤在個人身上的話，最直觀的也就是完成時間了。以前我一直覺得，只要在最短時間內完成，就是最好的，但顯然我考慮得少了，首先你要保證缺陷不要太多，「re-work」的時間是記入完成時間內的，同時「re-work」過多也從側面上反應了開發者的技術不嚴謹，還有就是時間的測量方式，之前提到過軟體上講究穩定性，乙個程式設計師是否有穩定且紮實的技術功底，要根據他完成工程時的時間方差來看。是的，除了直觀的時間結果之外，還要通過方差來看看這個程式設計師是否「穩重」。
構建之法 讀書筆記二
現在這本書已經讀了有三分之二了，看到這，我大概了解了關於個人技能提公升和團隊協作的知識。關於個人的成長，肯定是在不斷地實踐，不斷地出差錯，不斷地改進 解決問題 總結經驗中體現的，然後成為自己的知識，這就是提公升。而在軟體工程上也一樣，提公升不僅僅是在技術的提公升，更是在知識的積累，軟體設計思想的積累...
《構建之法》讀書筆記二
繼上次之後，讀了 本書的7到12章 下面主要寫一下書中覺得重要的東西。msf基本原則。1.推動資訊共享與溝通。2.為共同的遠景而工作。3.充分授權和信任。4.各司其職，對專案共同負責。5.交付增量的價值。6.保持敏捷，預期和適應變化。7.投資質量。8.學習所有的經驗。9.與顧客合作。對軟體的需求，也...
構建之法讀書筆記二
4.1 規範 包括 風格規範和 設計規範 4.2 風格規範 風格原則 簡明 易讀 無二異性 縮排 4個空格，而不是tab 行寬 限定為100字元 括號斷行與空白的 行 分行命名 匈牙利命名法 下劃線 分隔變數名字中的作用域標註和變數語義 大小寫 pascal形式和camel形式 注釋4.3 設計規範...