軟件工程-提問回顧與個人總結

項目	內容
本作業屬於北航軟件工程課程	2020春季計算機學院軟件工程（羅傑 任建）
本作業的要求請點擊鏈接查看	提問回顧與個人總結
我在這個課程的目標	提高自身的代碼能力、學習團隊協作開發的過程
本作業幫助我實現目標的具體方面	總結課程收獲

在學期開始的時候，我針對軟件工程的方法提出了一些問題，提出問題的鏈接為：

軟件工程個人博客作業

已經能夠解答的問題

問題一

教材的1.1章節客觀地描述了軟件工程中包括的各種內容：

1.1 軟件=程序+軟件工程

上面這些和軟件開發活動（構建管理、源代碼管理、軟件設計、軟件測試、項目管理）相關的內容，是軟件工程的核心部分。廣義上的軟件工程也包括用戶體驗、用戶界面設計（User Interface Design）等。所以，一個推論是：軟件 = 程序 + 軟件工程，一個擴展的推論是：軟件企業 = 軟件 + 商業模式當然，軟件企業還需要各方面的支持工作，例如人員的招聘、績效評估、升遷、淘汰等人力資源方面的工作。弄清楚這些概念，是進行所有與程序、軟件、企業等相關的討論的基礎。回到本節開頭的疑惑，答案就很清楚了，程序（算法、數據結構）是基本功，但是在算法和數據結構之上，軟件工程決定了軟件的質量；商業模式決定了一個軟件企業的成敗。軟件從業人員和軟件企業的道德操守會極大地影響軟件用戶的利益。

很顯然，以上這些環節都是必不可少的，它們的技術難度有高有低，在實際的軟件應用開發中薪資也有高有低。那么這些環節之間，哪個能對軟件最終呈現的效果產生最大的影響？在學校中同學們都將學好程序技術作為第一目標，那是否在技術的基礎上對軟件工程掌握得越好就能開發出更好的軟件？技術人員的重要性（地位）是否高於其他環節的工作人員？

• 解答：

  在這次的團隊項目中，我認為能“對軟件最終呈現效果產生最大影響”的其實是軟件設計的階段，即這一軟件希望實現怎樣的功能。軟件功能的設計和UI的設計結束后，軟件所能達到的水准高度其實已經被確定。如果在立項設計階段僅僅是設計出了平庸、大眾化、已經被人重復了許多次的功能（比如很多學校的軟件工程課都只是在做各種管理系統），那么無論技術人員的水平有多高，都是做不出優秀的軟件的。在設計階段，技術人員當然非常重要，可以是由技術人員來提出設計，在對軟件功能進行設計時必然要考慮到這些功能是當前技術人員的水平、當前的計划時間內能夠實現的，而不是天馬行空地畫餅。也只有高水平的技術人員、設計人員才能准確發現用戶痛點、設計出簡潔有效的軟件功能。

  “在技術的基礎上對軟件工程掌握得越好就能開發出更好的軟件”這一點肯定是正確的，但是我認為軟件工程的各種方法，對軟件效果影響的優先度是不同的，在不同條件下的使用方法也是不同的。在最理想的情況下，軟件開發時間充分、團隊成員技術水平成熟並對項目十分了解，那就可以完整地實踐構建管理、源代碼管理、軟件設計、軟件測試、項目管理這一系列流程。但是，比如在團隊項目的alpha階段，團隊成員對所需技術並不熟悉、需要學習成本，因此開發時間並不充足。所以一切活動以“完成功能”為第一目標，在項目管理等方面存在不規范的地方。而在團隊項目的beta，時間充足、技術成熟，就有精力去完成規范的項目管理，還做了一些重構代碼的工作。但是，由於團隊規模並不大（6人）、模塊划分清晰，不規范的代碼管理並沒有影響到軟件的最終效果。可以說，當時間緊急、團隊規模不大，可以以盡快交付為最高優先度。而當團隊規模較大、對軟件的穩定性要求高的時候，就必須要考慮嚴謹的源代碼管理、項目管理、項目測試等部分。

  在我們本次的團隊項目中，因為項目工作量較大，所有團隊成員都擔任了開發人員和測試人員，因此無法完全區分“技術人員”和“其他人員”。但是可以得出明確的結論：技術之外的其他因素極其重要。如果沒有一個優秀的pm，我們這個存在一定難度且工作量較大的項目甚至在alpha階段按時交付都比較困難；如果沒有一個熟悉項目、擅長的展示的團隊成員，那么別人就無法得知我們項目的優勢。優秀的技術人員誠然重要，但是一個優秀的pm更能充分地發揮出團隊的潛能、保證項目的進度，而有一個優秀的“推銷員”對軟件推廣就更重要了。

問題二

教材在3.1章節中這樣寫道：

3.1 個人能力的衡量與發展

在團隊工作中，穩定、一致的交付時間是衡量一個員工能力的重要方面。軟件項目的確需要創造性，需要一些意外，一些驚喜。但是，更多的是常規的、可重復的任務，軟件工程的奠基人之一瓦茨·漢弗雷總結說，軟件領域可以分為兩個方面：一方面是技藝創新的大爆發；而另一方面是堅 持不懈的工程工作，包括軟件的改善、維護和測試等，這一方面占了90%—95% 的比例。對於這些任務，一個成熟的軟件工程師應該能夠降低任務交付時間的標准方差。

結合以上內容，是否可以如此概括：工程師實現需求的效率和穩定性就是評價工程師能力的指標？

• 解答：

  在我們的團隊項目中，每個人都是開發者，每個人都可以對項目的設計提出觀點，因此體現出的能力並非是單純的工程能力。但我認為，如果要評價“工程師”的能力，就不再考慮“提出觀點”的能力，實現需求的效率和穩定性的確是首要的評價指標。

問題三

技能的反面是什么？教材在3.3章節中這樣寫道：

3.3 技能的反面

計算機人機交互領域的科學家比爾·巴克斯頓（BillBuxton）在1995年的一篇文章中提到了“The Op-posite of Skill”[注釋10]： Before reading on, think for a moment, and tell me what is the opposite of skill? I'll even give you a hint： I'm not looking for "unskilled". 巴克斯頓說技能的反面是“Problem Solving”—“解決問題”，

就我對文本的理解來說，作者認為“解決問題”指的是“解決低層次的問題”，如果一個人需要不斷去解決低層次的問題，那么這說明他對低層次的問題掌握並不熟練。只有一個人當將所有的低層次問題都不再當成問題，都變成自然而然的操作、都不再需要“解決”的過程，才能稱為是掌握了技能。

我的問題是：什么樣的問題能被稱為是“低層次”的問題？計算機技術飛速發展，新技術層出不窮，一個人不可能完整地掌握所有技術，不可能掌握所有新技術中的“基礎”部分。面對新技術，無論怎樣的“高手”都要經歷一個學習的過程。那么面對一個問題，如何找到它在書中講述的“問題的層次”中的位置。

• 解答：

  這個問題在我這次的團隊項目實踐中得到了一定的解答：即使新技術層出不窮，只要是同一領域的問題就一定會有根本的互通點。一個“高手”如果是在他專業領域內的“高手”，那么對於一些共通的問題就能夠輕松地理解。舉個例子，我在這次的項目中就遇到了一個關於“對象深層復制”的問題，這樣的問題在很多編程語言中都存在，但是我沒有考慮到它在JavaScript中也會出現，因此一開始完全沒有考慮到這一問題。究其原因，還是我對深層復制本身不熟悉，這是所有技術都可能存在的一個基礎問題。如果熟悉，那么在進行操作之前就一定會先考慮：在這個新語言中是否存在同樣的特性。

仍不明白的問題

有一些問題，譬如說關於工業界軟件工程情況的問題，在我們的團隊項目實踐中沒有得到解答。

問題一

教材在3.1章節中這樣寫道：

3.1 個人能力的衡量與發展

在團隊工作中，穩定、一致的交付時間是衡量一個員工能力的重要方面。軟件項目的確需要創造性，需要一些意外，一些驚喜。但是，更多的是常規的、可重復的任務，軟件工程的奠基人之一瓦茨·漢弗雷總結說，軟件領域可以分為兩個方面：一方面是技藝創新的大爆發；而另一方面是堅 持不懈的工程工作，包括軟件的改善、維護和測試等，這一方面占了90%—95% 的比例。對於這些任務，一個成熟的軟件工程師應該能夠降低任務交付時間的標准方差。

結合以上內容，是否可以如此概括：工程師實現需求的效率和穩定性就是評價工程師能力的指標？除此之外，我還想知道，這樣的評價指標在實際工業界中推廣和執行的程度如何？如何量化？

在項目實踐中學習到的知識點

• 需求

  從理論到實踐還是非常困難的，雖然說我們學習了NABCD這樣一個競爭性需求分析框架，但它只能幫助我們分析項目，不能幫我們提出項目。因為“做什么項目”關系到了我們這后半個學期為什么而努力，團隊成員們都不想輕率地決定，否決了許多不太好的提案。在長達約六七個小時的馬拉松會議后，終於決定做一個線上的WebIDE。這個過程非常勞累，但是從后期成果來看又是非常值得的，這個項目做到了獨特性和技術性共存。在這一階段，我學習到的就是需求分析極其極其重要，而且它的作用是后期各階段都無法彌補的。軟件工程中在這一階段無論投入多少精力都是值得的。

• 設計

  功能設計文檔和技術規格文檔非常重要。在項目alpha階段，對項目的全貌和使用的技術都不是很熟悉，在完成當下部分之后就不知道接下來該怎么做了。而技術規格文檔就可以作為一個指引。在完成項目的大部分內容后功能設計文檔就可以起到一個查漏補缺未實現功能的作用。與軟件測試時團隊成員發現的bug要及時記錄下來，供所有團隊成員查看使用一樣，是為了防止有漏網之魚，紙面記錄一定比腦子更可靠。

• 實現

  每日例會非常重要。每日例會可以鞭策團隊成員及時完成當天的任務，可以根據項目的實際完成情況，及時調整項目計划，還可以提高團隊的活躍度，調動團隊成員之間積極地進行交流，這些都能極大地提高工作效率。

• 測試

  我是前端開發人員，主要的測試方法則是把自己當成客戶實際使用。但這里出現了比較大的問題，問題產生的主要原因是沒有想到用戶在第一次使用軟件時的使用習慣，預設用戶知道各種功能按鈕的使用方法、預設不會出現非法行為。這一經驗讓我深刻地體會到，有時候完善已有功能的異常處理比實現一個新功能更為重要。

• 發布

  其實發布也是一個測試的過程，進行大規模的發布也就是進行了充分的測試。在alpha階段我們因為一直擔心服務器的負載能力，沒有努力進行充分的發布。而在beta階段我們調整了后端設計，進行了相對規模較大的發布，得到了許多好的反饋，有許多反饋來自我們之前完全想象不到的角度。

• 維護

  根據發布后得到的用戶反饋，進行bug修復和調整。其實在這一階段積累的經驗是：並沒有必要在收到反饋后第一時間去修復並重新上線，而是可以等待積累一段時間的反饋后，重新上線一個優化力度較大的版本。可能因為我們制作的是Web應用，重新上線非常便捷，如果制作的是需要下載的離線軟件那么這個問題可能會更加突出。

對課程的理解和心得

• 個人項目

  在個人項目中收獲最大的可能是知道了git的使用方法和標准commit信息的寫法以及單元測試的思想。在后期的團隊項目中我使用了vue框架，它有自己單元測試的框架，因此和之前學到的東西關聯不大。

• 結對項目

  在結對項目中，一個收獲是明白了溝通的重要性。在之前各種課程上的團隊作業中，其實並沒有太多“團隊協作”的成分，基本上都是把任務直接切割各自為陣。而這一次的軟件工程課上，在結對項目和團隊項目中則真正體會到了什么叫做“團隊協作”。要推進團隊協作，充分有效的溝通交流必不可少，每個團隊成員必須對自己的任務負責，並且受其他團隊成員的監督。另一個收獲就是努力寫出了規范“優美”的代碼。因為寫出的代碼不僅是給自己看的，更要讓其他的團隊成員理解。在結對項目中的這一習慣也影響到了團隊項目。

• 團隊項目

  這可能是我大學里印象最深的課程之一。如上文所述，這是我在學習過程中第一次參與到真正充分的“團隊協作”，體驗在一個時期內高效工作、做出一個有生命力的完整產品的過程。在需求分析、技術學習、項目管理等等方面的問題在上面已經談論了許多。總結一下就是：軟件開發技術並不是軟件工程的全部，許多軟件工程和敏捷開發的理論並不是紙上談兵，而是在實際的應用中都能發揮出巨大的作用。

  經過這次經歷，我也發現了我學習方法上的一些問題。我的表達能力、展示能力、組織能力並不好，但我覺得只要埋頭把技術學好就可以彌補不足。但是通過這次團隊項目，我發現表達能力就是技術能力的一部分，頭腦清晰、善於交流、善於質疑，這些都是技術能力強的人的共同特點。我不應該再把“我花了時間去學習”當作表達能力差的借口，只有正視缺點才能取得進步。