提問回顧與我的總結

提問回顧與我的總結

1、做業要求

咱們在學期開始的時候佈置了閱讀做業，要你們快速閱讀，同時提出本身的問題。
如今一個學期過去了，同窗們完成了一個結對項目，兩個階段的團隊項目，中間還經歷了轉會環節。
正所謂"實踐是認識的來源、目的、動力以及檢驗認識真理性的惟一標準"，在經歷了一個學期的學習和實踐後，請你們寫一個提問回顧與我的總結的博客。

項目	內容
這個做業屬於哪一個課程	博客園班級連接
這個做業的要求在哪裏	提問回顧與我的總結
我的博客做業	初窺軟件工程 2020BUAA軟件工程⋅我的博客做業
我在這個課程的目標是	得到成爲一名軟件工程師的能力
這個做業在哪一個具體方面幫助我實現目標	總結回顧

2、問題解答

問題1. 單元測試時如何有效拆分單元？輸入數據和輸出數據如何構造？

答：單元測試的粒度，依項目而定。例如在團隊項目中，咱們作的知識路書web應用，其前端的單元測試是以任務功能進行劃分的，輸入的數據即爲覆蓋該功能模塊所有邏輯的一組操做。對於結對編程項目，單元測試應該以函數或類爲單位，輸入輸出的數據即按照類的構造函數或函數的輸入參數進行。

問題2. 即便用了源代碼管理工具，也很容易忘記某個版本到底是幹什麼的，如何更好地經過message提示本身？

答：使用集成開發環境的git GUI工具，能夠更加方便地編輯message，甚至支持markdown語法。還能夠github平臺的pull request功能，可以更加清晰地寫清某次代碼遷入作的功能是什麼。團隊開發時，要商議好commit的message和Pull request的message格式規範，例如咱們的敏傑開發團隊規定的commit格式爲：姓名：功能1；功能2；...

問題3. 怎麼在源代碼管理工具中更優雅地改bug?

這個問題理論上可使用git rebase的方法進行，可是容易出錯，不是很安全。在咱們的團隊項目開發過程當中，直接使用順序commit式bug修復，因爲不多使用代碼回滾，維護的最新版代碼始終是當前功能最多、bug最少的版本。

問題4. 多人合做時，如何解決push衝突問題

不一樣開發者儘可能不要同時修改相同的文件，每一個Issue和Pull request的粒度儘量細就能夠更好地保證這一點。若是真的遇上了必需要修改相同文件的話，兩者須要一塊兒合併代碼，保證雙方的更改不出現衝突。在咱們團隊項目的實際開發過程當中，每一個人負責開發的部分幾乎少有文件重疊，固然也有少許狀況出現了代碼衝突的狀況，咱們是經過有衝突的開發者共同解決衝突的辦法處理的。

問題5. 如何解決開發基礎差的問題？軟工課上如何解決？

對於咱們的團隊項目知識路書的開發初期，只有hdl一名同窗擁有開發經驗，其它成員都是開發小白，可是咱們隊伍的成員都有很強的快速學習能力，咱們經歷了2年的編程訓練，已經有很好的編程功底，通過熟悉開發的成員一帶，很快就掌握了基本的開發技術，以後就是滾雪球式的技術積累了，在完成了alpha階段的開發任務後，咱們的開發技術就均可以知足咱們項目的需求了。

問題6. 初創公司如何找到技術創新與營銷經營的平衡點？

對於技術初創公司，技術當然重要，可是必定不能掉進惟技術論的怪圈，只顧技術，永遠在迭代產品、優化產品，而不去想推廣、想營銷。企業總歸是要以營利爲目的的，推廣、營銷能夠帶來更多的用戶，帶來更多的用戶反饋，使團隊更清楚產品的真正需求。同時推廣營利能夠招攬更多人才，有更多優秀且志同道合的人加入，一樣會進一步促進技術的發展。

問題7. 軟件工程有沒有什麼解決不了的問題？軟件工程的痛點在哪？

軟件工程解決不了的問題是現有的管理學理論沒法很好解決的問題，沒法抽象成統一的理論，這類問題的解決要因人而異、因事而異。不一樣的開發團隊、不一樣的開發產品都會有不一樣的解決方法，因此說管理學是一門藝術，軟件工程管理亦是如此，一個軟件工程項目的成敗、管理好壞，軟件工程理論當然重要，但產品經理、項目負責人的管理藝術每每更能決定產品的命運。因此，軟件工程的痛點也在於此，只有將軟件工程理論，和實踐、經驗深入結合、互相補充，才能早就一個優秀的產品經理，造成優質的團隊管理文化。

3、新的問題

1. 當團隊成員對價值觀念、產品方向有不一樣觀點時，應該如何解決觀念上的不一致？

在《人件》中介紹了有凝聚力團隊的概念，你們都秉持相同的價值觀念、產品觀念，團隊總體的力量將大於個體之和。可是當團隊成員對價值觀念、產品觀念有不一樣觀點時，應該如何解決觀念上的不一致、從新回到一個有凝聚力的團隊總體呢？

當觀點可調和時，採用討論分析等辦法能夠得出一個最優的解決方案，讓團隊中的全部成員承認。可是當觀點矛盾不可調和時，又該怎麼辦？獨裁？分裂？仍是...

2. 什麼時候放棄？

當一個產品的實現難度、投入資源、預期收益等與原定設想不符時，團隊會倍感沮喪，凝聚力和幹勁都會大打折扣。做爲項目負責人，有抉擇堅持仍是放棄的責任，在何種條件下能夠下定決心放棄？有沒有理論上的一種條件，達到這種條件就應該放棄，堅持就是浪費資源？

4、習得知識點

在團隊項目中，咱們在實踐中學到不少軟件工程的知識點，下面分類進行介紹。

1. 需求

需求分析是一個軟件工程項目的第一步，抓住一個好的需求每每是項目成功必要條件。咱們敏傑開發團隊，通過若干次會議的頭腦風暴，碰撞出了幾個有痛點的需求，當時的選擇有三：

• 基於深度學習的字體自動生成
• 醫學、化學在線實驗平臺
• 圖形化文獻管理工具

通過NABCD分析，咱們最終得出，圖形化文獻管理工具這個需求咱們團隊更能駕馭，咱們自己就是該項目的目標用戶，能夠更直接準確地分析出需求。因而咱們選擇了知識路書——圖形化文獻管理工具這個項目做爲咱們的開發目標。

2. 設計

經過撰寫技術規格說明書和功能規格說明書，咱們更加清晰地描述了整個項目的設計。在實際操做中，咱們在組會中共同繪製ER圖，成員一塊兒在一份ER圖上添枝、加葉、修改，最終共同碰撞出了一份完整、清晰的項目架構，團隊成員也都明確了項目的整體設計。在肯定了項目的整體設計後，咱們討論了實現上的設計，因爲目前web端應用的受衆廣、可移植性強、移植性好，咱們選擇了基於web平臺的實現設計，並進一步肯定了選擇的先後端框架、平臺、工具等，你們開始了前期的學習準備工做。

3. 實現

咱們首先根據項目特色進行人員分工，咱們的項目主打前端應用，後端主要提供CURD等api支持，因此前端共4名成員，後端2名，1人PM兼自由人，能夠根據開發進度補充至前端或後端。在開發過程當中，咱們採用增量式敏捷開發工做流，在alpha階段完成了最核心的功能，完成了一個最小可用版。在beta階段，持續重構與優化alpha階段的工做，並增量式添加新的功能。在開發中，相似每日構建原則(daily build)，咱們作到了實時構建(always build)，咱們保證每一次提交都必須可運行，在代碼互審時，不只僅要展現所改動的模塊是否工做正常，還應簡要回歸測試原有功能，保證產品時刻可運行。

在項目管理中，咱們學到了很是多的知識，在beta階段新成員進組時，咱們向其介紹了咱們團隊的整個項目工做流，讓其頗爲驚歎，這纔是軟件工程。關於咱們的項目管理能夠參考個人這篇博客使用Github進行軟工開發管理

4. 測試

因爲是敏捷開發，在測試中也採用敏捷開發的風格，咱們的實時構建(always build)原則能儘量保證前端在開發過程當中的持續測試，每位成員在開發本身功能的時候，均可以不經意地測試網頁其它部分的功能，一旦發現問題，當即寫入Issue。因爲開發過程當中已經針對功能進行了較多的單元測試，在實際測試階段咱們重點進行了場景測試，將用戶的使用流程分紅若干個工做場景，對軟件進行總體測試，保證用戶不會觸及最明顯的bug，另外還能夠以用戶的身份體驗產品，獲得新的改進需求。

對於後端，咱們採用了覆蓋率測試，使用成熟的測試框架，使測試覆蓋率達到90%以上，保證了後端api的穩定與精準。

5. 發佈

咱們在alpha階段的推廣出現了一些失誤，致使了推廣效果不佳。主要緣由是選錯了「目標用戶」，咱們的產品主要面向有科研需求的研究生、博士生、導師等，而在alpha階段，咱們重點向本科生進行推廣，致使咱們沒有達到預期用戶量。在beta階段，咱們根據目標用戶的使用特徵，定向地推廣給實驗室的研究生，讓他們在組會中嘗試使用咱們的軟件，得到了不錯的推廣效果。另外咱們還作了針對本科生科學方法論課程的殺手功能，能夠利用這個功能，讓同窗們更方便地完成該課程的要求，咱們在科學方法論課堂上展現了咱們的產品，也收穫了很多的用戶。因此，對於軟件工程，開發技術當然重要，推廣的技巧也必不可少，否則就只是寫程序，而不是寫軟件了。

6. 維護

對於維護，用戶的bug反饋十分重要，咱們在開發初期，就在頁面中加入了bug反饋入口，在兩個階段的開發中，已經收到了大量的反饋信息，其中不乏對於bug的反饋。

另外，成熟的文檔也必不可少，咱們分別針對前端、後端、用戶寫了三份詳細的文檔，保證了後續接手的開發人員和維護人員能夠快速上手。

5、心得體會

一學期的軟件工程課收穫滿滿。軟件工程課就應該在作中學、學中作。團隊項目中，我從一個開發小白的身份在alpha開發階段一點點摸爬滾打，從咱們的前PM大佬學到了不少開發技術、項目管理方法。進入beta階段後，我有幸接替原PM大佬的工做成爲PM，和團隊成員一塊兒不斷完善咱們的產品。PM的經歷讓我實踐了更多軟件工程領域的學問，我學會了如何與人溝通、如何分配任務、如何督促監管任務的執行、如何與團隊合做等等。看着咱們的產品從無到有再到基本健全、收到用戶的積極反饋，真的是一件無比享受且欣慰的過程。我會珍惜此次軟件開發經歷、珍惜一塊兒結對編程的小夥伴、珍惜在北航度過的軟件工程時光～

2020.6.14 補充：最近中國若干高校被封鎖了matlab軟件，引發了國內社會的不小爭議。我以爲相似Matlab這種重要的科研軟件，我國須要投入人力和資金進行研發，對於這類大致量軟件的開發，軟件工程理論的指導不可或缺，國內的各大高校計算機專業和軟件專業應該更加劇視軟件工程課程的質量，培養更多優秀的軟件工程技術人員。