軟件工程基礎 完結撒花

一點說明

這篇博客是軟件工程基礎（羅傑、任建）的最後一次課程博客做業。

項目	內容
這個做業屬於哪一個課程	軟件工程基礎（羅傑，任建）
這個做業的要求在哪裏	做業要求的連接
我在這個課程的目標是	提高對軟件工程的宏觀和微觀的全面認識，並加以實踐
課程在哪些方面幫助了我	方方面面，下文中將詳細分析與回顧
團隊項目的網址（歡迎訪問）	http://ddlkiller.top

1、提問回顧

問題1. 我的開發流程（PSP）中關於測試環節的設計是否合理？

在以前的提問中，個人觀點是「不該將測試環節安排在具體設計、具體編碼和代碼複審以後，而是應該在代碼設計與編碼過程當中同步進行測試」。

​ 通過了一學期」軟件工程「的實際體驗，我認識到以前的觀點是片面的。測試，我認爲能夠分爲兩步——自測和他測。「自測」是指團隊內部的測試，既包括編碼人員對本身代碼的簡單功能驗證，也包括團隊內的測試人員進行的單元測試、壓力測試等等。充分的自測每每能夠從技術層面儘量多的減小BUG，可是產品終究是要面向用戶的，因此「他測「也是必不可少的。「他測」是團隊外部的測試，產品用戶在實際使用中發現BUG（如操做邏輯不符合直覺、功能缺失或冗餘後，經過反饋渠道對開發團隊進行反饋，開發者經過必定的分析手段從收集到的全部反饋中提煉出有價值的問題，進而能夠肯定下一步改進的方向及措施，這也是一個測試的過程，也是提升產品力的一個關鍵措施。

​ 那麼回到以前的問題，測試環節到底放在哪裏更加合適呢？我以爲應該「有零有整」。一方面，將測試環節融入到具體編碼與代碼複審中。具體的作法是，咱們能夠借鑑契約式編程的思想，在項目正式進行編碼開發以前，不只對項目工程的總體邏輯進行設計，還要經過相似JML的格式，對工程中的每一個類、類中的每一個方法進行一個功能和結構上的詳細規範，造成一個個的規範文件。在這些規範文件上進行開發，既方便編碼人員的自我測試，也方便單元測試集的構建，將測試輕量化，從而能夠與編程環節良好的結合。另外一方面，要在具體編碼與代碼複審後進行獨立的測試環節，即對代碼實現的系統性的測試，包括「自測」和「他測」。「當局者迷，旁觀者清」，獨立的測試環節主要是細節的糾錯和完善，也是相當重要的。

問題3. 如何更好地管理」人件「？

本書的 11.6 節引伸的博客提到，

「如何在軟件工程這門課上模擬出相似真實軟件開發的環境，仍是須要‘大智慧’的人去發現」。

​ 反思整個 DDLKiller 開發過程當中咱們團隊的狀態以及狀態的變化，我認爲咱們經過必定的規則規約，作到了將 「你們約束在必定的權力和利益的關係之中」，從而「各個角色可以各司其職、各盡其能」。歸納下來主要有如下幾點經驗。

​ 一是作好任務細化。這一點看似日常實則關鍵，咱們團隊發現的一個行之有效的方法是制定詳細的任務清單，團隊中的每一個人都像是一個 賞金獵人，完成分配的任務就像是「打怪升級」。若是在規劃時將任務儘量的細化、明確化，就能夠減輕開發人員的負擔，也使得開發人員更加有積極主動性，從而輕鬆愉悅也更加高效地進行開發工做。

​ 二是用好「胡蘿蔔」與「大棒」。我還未接觸過真正的商業中的「軟件工程」，不知道將軟件開發放在商業環境中會有什麼其餘的規律。可是根據本學期軟工課程的體驗，我認識到營造出一種積極奮進、每一個人的內外壓力均衡的團隊氛圍是相當重要的，而合理地平衡「胡蘿蔔」與「大棒」就是其關鍵一環。例如，在Alpha階段，課程組制定了「強制轉會」的規則，不過關就淘汰（畢竟通常狀況下，誰也不想放手本身從無到有參與開發的軟件），這就有一絲人人自危的味道了，這就是「大棒」。而若是積極表現，既能收穫貢獻分又可以從一而終地完善做品，這就是「胡蘿蔔」。固然，企業中的「胡蘿蔔」更甜，「大棒」打在身上也更痛，可是這種辯證統一的關係應是一致的。

​ 三是保持恰當的距離。因爲疫情的不可抗力，本學期全部工做都只能轉移到線上，我我的認爲這反而有助於開發工做（僅指本課程的開發任務）的高效進行，由於團隊成員之間得以擁有一種比較合適的距離——一方面，依託Gitee等工具，咱們得以實現線上開發0距離，而線上便捷的實時交流、說開就開的騰訊會議等也讓你們的交流0距離；另外一方面，只要下了線，你們又是天各一方（∞ 距離），因此相對來講你們有了更大的自由度，來更加自如地安排本身的時間。換個說法，就是每一個成員對於其餘成員或PM來講，都是一個 「黑箱」 ，他只須要在指定時間交付上任務便可，中間的實現過程是不受監控的、徹底自由的。這必定程度上也避免了不少不必的衝突和摩擦，讓開發工做得以和諧地推動。

問題4. 如何設計軟件使軟件擁有更多的受衆，甚至打造國民級軟件？

在以前的提問中，個人主要問題是」如何才能贏得 ‘沉默的大多數’ 「。

​ 這個問題如今於我來講依然無解。在咱們團隊項目的推廣中，其實也沒有很好的解決這一問題。其實 「沉默的大多數」 之因此沉默，我能想到的有如下幾種可能。一是他們已經習慣了「沉默」，他們產生反饋的閾值很高，只要這個產品的核心功能能夠較好運行，小的BUG不足以提供他們反饋的動力，你若強迫他們反饋，極大可能只能收到一個「好」或「很差」，也許你新加了一個功能、新補了一個BUG，他會感嘆「哇，比之前好用了」，可是僅此而已；二是軟件提供的反饋時機不對，從技術層面，我認爲運行出現BUG的時候當即彈出反饋渠道是最佳的選擇，可是若是考慮到須要收集多元化的用戶反饋信息，這個時機的選擇可能要具體問題具體分析了。

​ 正如王小波先生所說，「在一個喧囂的話語圈下面，始終有個沉默的大多數」。我認爲打造國民級軟件的重要一環，就是發掘「沉默的大多數」的需求。也許，他們不發聲，咱們也能「聽」到他們的聲音。答案，我尚未答案。

問題2. 如何恰當的使用goto語句 & 問題5. 科研與創新的關係

​ 問題2實屬無稽之談，而問題5還未有新的想法，故暫且不表。

2、新的問題

問題1. 如何在開發中如何準確劃分需求的等級？有沒有相關的工程理論或準則？

​ 換言之，如何給軟件的優化需求進行一個「輕重緩急」的優先級排序呢？好比，在團隊項目開發時，Beta階段，我對「添加新日程」這一操做進行了從新設計，以下圖。在新的版本中，我添加了 「回車快速建立」 功能，在詳細建立頁中增添了默認的快捷日期和時間，同時支持自動根據描述添加標題，並且整個的UI也進行了從新設計。

​ 這個優化目前看來彷佛沒有什麼很差，可是，其實在優化以前，我面臨着兩個選擇，一是圖中所展現的，另外一個則是 增長AI自動識別內容並自動添加日程的功能，即自動識別 時間、地點、參與者等關鍵詞並添加。因爲時間有限，我只能二選一，而實際發佈之後，我忽然意識到，其實被我pass的功能或許纔是 殺手功能。可是爲時晚矣……

問題2. 不一樣團隊成員對產品定位和發展方向理解不一樣，致使在具體功能設計中發生衝突，如何解決？

​ 咱們團隊採起的方法是 「擱置爭議，共同發展」 和 「誰提出誰解決」 ，即若是在某一個功能的增減上發生了衝突，優先選擇 「我全都要」，可是對於較難實現的需求，秉持「誰提出誰解決」的方案。這樣的作法的好處是，極大地避免了團隊內的衝突。可是，這種方法顯然不是萬全之策。從某種程度上來講，它並無解決問題，而是逃避了問題。那麼在實際的軟件工程中，應該如何處理這些衝突呢？

3、學到了！

4、心得體會

我的項目 —— 革命還沒有成功，同志仍需努力

​ 軟工的我的項目難度並不大，可是在實現過程當中，我仍是對本身的數學知識的遺忘和匱乏有了更深的認識。尤爲是，在思考程序優化時，徹底沒有頭緒，感受無處下手。後來觀摩了文瑄老哥的優化方法，看到他使用流水線等方法一層層地抽絲剝繭，最終得出解法，心裏實在敬佩。將來但願本身也能更進一步，認真學習數理知識，在思考和實踐中融會貫通。

結對項目 —— 凡事預則立不預則非

​ 第一次接觸結對項目，我以爲我沒有作得很好，可是在與結對夥伴一塊兒探索的過程當中，仍是收穫了不少。好比，高效溝通的祕訣在於溝通以前的準備，準備的越充分，溝通的效率越高，若是溝通前沒有作好準備，那麼溝通必定是低效的，甚至是徒勞的。咱們也再一次被生活毒打——因爲最初對鬆散耦合的實現要求沒有理解到位，咱們在完成與其餘組對接時重構了咱們的代碼。這也讓咱們明白了兩個道理，一是磨刀不誤砍柴工，二是凡事預則立不預則非。

團隊項目 —— 用衆人之力，則無不勝也

​ 本學期在團隊項目上的耗時最多，收穫也最大。體驗了軟件開發的全流程，也見識了強制轉會等生活的殘酷一面。收穫在上一部分已經分享了，下面說說個人一些體會。咱們團隊整個的工做氛圍是比較輕鬆的，你們原本就很熟，而後也都很上進，雖然到了後期你們都很忙，有一些懈怠，可是在軟件的攻堅期，你們相互鼓勵、相互幫助，各自發揮所學和所長，一塊兒克服困難，最終攢出一個發佈版來出來，真的是很是有成就感的！

​ 最後附上咱們團隊成員的簡介，很是開心可以和你們一塊兒完成 DDL Killer ，感謝每一位給予個人幫助，有機會再約一波深夜DEBUG局☺。