我的閱讀做業 --軟件工程M1/M2總結

軟件工程M1/M2總結

---

 

寫在前面的話：

　　這學期的軟件工程伴着考期的展開逐漸落下帷幕，回顧這學期的軟件工程，我感受個人熱情在一次又一次的失落中逐步消耗殆盡，每一個人對於這門課的體驗都會有所不一樣吧，能夠肯定的是軟件工程的方法論很是重要，於實踐中的應用也很是重要。可是這是否就天然而然的衍生出咱們對於這門課程發自心裏的承認呢？我認爲這個問題還值得繼續探討。

進入正題：

　　這學期開始時進行了第一次的閱讀做業，經過對於《構建之法》的快速閱讀，我提出了對於軟件工程方法論的5個問題。

　　這學期的軟件工程課程臨近尾聲，回頭來看這些問題都有了一個較爲深入的認識。

 

　　問題1.第四章談到了兩人合做，在這個過程當中假若結對的兩我的能力是相近的，如何達到高效的開發，若是兩我的的能力是互補的，又如何達到高效的開發？

　　這學期的結對編程主要存在於兩個場景。一個是在結對編程做業中實現一個四則運算的程序，這一做業帶有強制性的要求咱們經過結對編程來實現；另一個是在團隊項目中，因爲M2階段各類大做業紛至沓來，包括編譯課設，數據庫課設，C2，Android等，軟工項目實際開發的時間相較於M1階段要少不少，爲了提升總體的開發效率而採用的自主的結對編程方法，即經過結對編程達到快速，高效的交流開發目的，從而防止由於交流問題而引入新的bug。

　　在經過一學期的結對編程實踐後，我對於這一問題有了本身的認識，即不論兩我的的能力是相近仍是互補，在結對編程的實踐中深刻的交流相當重要，此外，假若兩我的能力相近，能夠由兩我的共同承擔核心功能的實現，而若是兩我的的能力互補，則應當把功能切分爲儘量相互獨立的子模塊，每一個人來實現本身較爲擅長的模塊，對於一樣不擅長的模塊實現則由學習效率高的同窗爲主導，經過兩我的之間的溝通來協做完成。

 

　　問題2.在第六章敏捷開發中，我認爲軟件設計的可擴展性對於敏捷開發至關重要，而軟件的可擴展性應當從那些方面來考慮？即如何作到在需求不斷變化的狀況下，仍不至於不停地推倒重來？

　　在這一學期的實踐中，對於軟件的可擴展性有了一個進一步的認識，在我看來，在軟件開發以前對於用戶需求的詳細分析相當重要，在這一階段需求分析要儘量的詳細和完善，要從用戶的角度出發而非開發者的角度，考慮用戶需求可能的變化，要儘量的爲以後的設計留有餘地。

　　軟件框架構建的好壞每每取決於架構師的水平，對於已經歸入考慮的基礎功能則予以着重考慮，對於在構建階段已經被用戶拋棄的需求則須要進行深刻探討，假若不存在繼續實現的必要性，則將其從基本功能中刪去，對於在構建過程當中用戶提出的新功能則進行重要性判斷，通常若是需求分析作的足夠充分的話，這樣的新增需求每每不是核心功能，而是附加功能，對於這些功能的實現亦歸入框架搭建中考慮的範疇。

 

　　問題3.在第十二章談到了用戶體驗，有時候確實存在用戶體驗和產品質量不可兼具的問題，如何抉擇？

　　經過這一個學期的實踐，我認爲若是將產品的開發分紅多個迭代週期的話，那麼，咱們能夠考慮先在M1階段實現產品的基本功能，即知足產品發佈的最小要求，即保證產品的質量，而對於用戶體驗的優化能夠放到M2來作，固然，在M1階段若是不進行相應用戶體驗的優化，那麼至少應當爲M2階段進行優化提供必要的接口，保證在產品的總體架構上不會出現兼容性的問題。

 

　　問題4.在軟件的開發過程當中是否時時須要具有有防護性編程的意識，這樣可能使問題複雜化，或者僅須要按照設計規格來實現相應功能？

　　這個問題在實踐中主要依靠契約式編程思想來實現，防護性編程思想當然重要，可是有時候並無必要時時對於參數合理性進行驗證，不然會產生異常冗餘的代碼以及很是尷尬的編程體驗。

　　然而不進行驗證並不意味着會出錯，在使用契約時編程思想時候，全部軟件構建的參與者都會遵照相關抽象設計，即在函數的調用過程當中事先知足函數的前置條件以及後置條件的約束，在知足這些條件的狀況下才認爲軟件的執行知足不變性，即軟件的正確性纔能有形式化的保證，才能經過形式化的手段來驗證軟件的正確性。

 

　　問題5.在團隊合做中，成員之間須要良好的溝通來完成，有沒有什麼必要的溝通原則和技巧？

　　在博客的回覆中助教談到了「unconscious bias」，在查閱相關資料後我瞭解到：無心識偏見的產生是由咱們的環境和自身經驗所決定的。因爲咱們的思惟是在不斷地處理信息數據，而當咱們對問題的分析過程當中若是缺少相關的數據，那麼咱們無心識的偏見就填補了這一空白，從而影響了咱們相互之間的溝通效果。如今已經有愈來愈多的科學家研究無心識偏見和咱們如何防止它的負面影響對於咱們決策的危害。

　　在我看來，無心識偏見對於溝通的影響很是嚴重，在咱們進行溝通以及對於事物進行價值判斷的時候能夠經過對於相關領域作出相應的充分研究以後再作出判斷，而非憑藉着無心識偏見作出所謂「經驗上」的判斷。

 

軟件工程中概念的再認識：

　　經過這一學期的軟件工程理論的實踐，我對於其中一些概念有了更加深入的認識，主要包括有：

• No Silver Bullet：強調軟件工程自身的複雜性以及多變性致使軟件工程不一樣於摩爾定律所描述的硬件的增加速率那樣，使得咱們可以有肯定的可期待的通用的優化方法可以使軟件生產率獲得成倍的提升。

• Big Ball of Mud：強調代碼只是雜亂無章的堆砌，沒有進行結構化的設計，致使在開發的後期出現許多錯誤和缺陷，能夠採用以下方法避免大泥球：在軟件設計階段首先須要關注軟件的特性和功能，而後集中在架構和性能，使得軟件設計之初就避免產生問題或者方向的誤差。其次，在編寫軟件時要及時解決出現的小問題或者原型概念等等，這樣不會使得問題堆積致使後期的沒法修改。

• The Cathedral and the Bazaar：描述了兩種軟件開發模式，其中大教堂模式的軟件開發讓程式除錯的時間大幅增長，由於只有少數的開發者可參與修改工做。市集模式則相反。

• A Generation Lost in the Bazaar：描述了集市模式致使的一個悲哀的現實：成堆的權宜代碼被一羣盲目的根本不知IT架構爲什麼物的所謂IT「專業人士」永無休止地複製着，粘貼着。針對這一現象最有效的解決方式是：所謂質量，只有在某人對它負責時纔有意義，而這個「某人」只能是一我的，不能是幾我的——二重奏除外。個人理解是針對軟件的架構師必需要負責整個軟件的生命週期，由於，軟件的開發人員可能更迭，若是架構師不負責軟件的維護，那麼後續的開發人員對於軟件很難有一個良好的把控，只能不明因此地沿用前人的代碼，而沒法對於已通過時甚至錯誤的代碼作出適當的刪改，致使軟件的碎片化，以及文中指出的那樣對於早已過期的Fortan編譯器兼容性的檢測。

•  Waterfall Model：在《構建之法》第五章(P107)談到了瀑布模型，瀑布模型將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落，最終獲得軟件產品。瀑布模型的突出優勢是：可在迭代模型中應用瀑布模型。增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可運行的版本,同時增長更多的功能。每次迭代必須通過質量和集成測試。瀑布模型的突出缺點是：因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發風險，此外這樣的開發過程難以適應用戶需求的變化。

• Agile Methods：在團隊項目開發的過程當中用到的敏捷開發的思想主要有：採用迭代的方式來對於不可預見過程進行控制，採用SCRUM進行軟件開發的進度管理。把一個項目分紅若干個爲期兩週的迭代階段，每一階段爲一「衝」（sprint〕。天天有一個短會，這樣管理者能對項目有近距離的觀察與控制。

 

知識點回顧：

　　對於軟件工程項目實現過程當中的各個階段：需求、設計、實現、測試、發佈、維護，每一個階段都學到了不一樣的知識點，歸納以下：

• 需求：需求階段主要的知識點是需求分析的「NABCD」模型。
• 設計：設計階段主要的知識點是典型用戶和場景分析以及功能說明書和技術說明書的撰寫。
• 實現：實現階段主要的知識點是對於實現流程的把握 。
• 測試：測試階段主要的知識點是幾種測試方法，包括單元測試，迴歸測試，以及場景測試。
• 發佈：發佈階段主要的知識點是對於項目的回顧與反思（postmortem）。
• 維護：維護階段主要的知識點是接受用戶的反饋，並進行軟件的維護。