這篇部落格是軟體工程基礎（羅傑、任建）的最後一次課程部落格作業。專案
內容這個作業屬於哪個課程
軟體工程基礎（羅傑，任建）
這個作業的要求在**
作業要求的鏈結
我在這個課程的目標是
提公升對軟體工程的巨集觀和微觀的全面認識，並加以實踐
課程在哪些方面幫助了我
方方面面，下文中將詳細分析與回顧
問題1. 個人開發流程（psp）中關於測試環節的設計是否合理？
在之前的提問中，我的觀點是「不應將測試環節安排在具體設計、具體編碼和**複審之後，而是應該在**設計與編碼過程中同步進行測試」。 經過了一學期」軟體工程「的實際體驗，我認識到之前的觀點是片面的。測試，我認為可以分為兩步——自測和他測。「自測」是指團隊內部的測試，既包括編碼人員對自己**的簡單功能驗證，也包括團隊內的測試人員進行的單元測試、壓力測試等等。充分的自測往往可以從技術層面盡可能多的減少bug，但是產品終究是要面向使用者的，所以「他測「也是必不可少的。「他測」是團隊外部的測試，產品使用者在實際使用中發現bug（如操作邏輯不符合直覺、功能缺失或冗餘後，通過反饋渠道對開發團隊進行反饋，開發者通過一定的分析手段從收集到的所有反饋中提煉出有價值的問題，進而可以確定下一步改進的方向及措施，這也是乙個測試的過程，也是提高產品力的乙個關鍵措施。
那麼回到之前的問題，測試環節到底放在**更加合適呢？我覺得應該「有零有整」。一方面，將測試環節融入到具體編碼與**複審中。具體的做法是，我們可以借鑑契約式程式設計的思想，在專案正式進行編碼開發之前，不僅對專案工程的整體邏輯進行設計，還要通過類似jml的格式，對工程中的每個類、類中的每個方法進行乙個功能和結構上的詳細規範，形成乙個個的規範檔案。在這些規範檔案上進行開發，既方便編碼人員的自我測試，也方便單元測試集的構建，將測試輕量化，從而可以與程式設計環節良好的結合。另一方面，要在具體編碼與**複審後進行獨立的測試環節，即對**實現的系統性的測試，包括「自測」和「他測」。「當局者迷，旁觀者清」，獨立的測試環節主要是細節的糾錯和完善，也是至關重要的。
問題3. 如何更好地管理」人件「？
本書的 11.6 節引申的部落格提到，「如何在軟體工程這門課上模擬出類似真實軟體開發的環境，還是需要『大智慧型』的人去發現」。 反思整個 ddlkiller 開發過程中我們團隊的狀態以及狀態的變化，我認為我們通過一定的規則規約，做到了將 「大家約束在一定的權力和利益的關係之中」，從而「各個角色能夠各司其職、各盡其能」。概括下來主要有以下幾點經驗。
一是做好任務細化。這一點看似平常實則關鍵，我們團隊發現的乙個行之有效的方法是制定詳細的任務清單，團隊中的每個人都像是乙個賞金獵人，完成分配的任務就像是「打怪公升級」。如果在規劃時將任務盡可能的細化、明確化，就可以減輕開發人員的負擔，也使得開發人員更加有積極主動性，從而輕鬆愉悅也更加高效地進行開發工作。
二是用好「胡蘿蔔」與「大棒」。我還未接觸過真正的商業中的「軟體工程」，不知道將軟體開發放在商業環境中會有什麼其他的規律。但是根據本學期軟工課程的體驗，我認識到營造出一種積極奮進、每個人的內外壓力均衡的團隊氛圍是至關重要的，而合理地平衡「胡蘿蔔」與「大棒」就是其關鍵一環。例如，在alpha階段，課程組制定了「強制轉會」的規則，不過關就淘汰（畢竟一般情況下，誰也不想放手自己從無到有參與開發的軟體），這就有一絲人人自危的味道了，這就是「大棒」。而如果積極表現，既能收穫貢獻分又能夠從一而終地完善作品，這就是「胡蘿蔔」。當然，企業中的「胡蘿蔔」更甜，「大棒」打在身上也更痛，但是這種辯證統一的關係應是一致的。
問題4. 如何設計軟體使軟體擁有更多的受眾，甚至打造國民級軟體？
在之前的提問中，我的主要問題是」如何才能贏得 『沉默的大多數』 「。 這個問題現在於我來說依然無解。在我們團隊專案的推廣中，其實也沒有很好的解決這一問題。其實 「沉默的大多數」 之所以沉默，我能想到的有以下幾種可能。一是他們已經習慣了「沉默」，他們產生反饋的閾值很高，只要這個產品的核心功能可以較好執行，小的bug不足以提供他們反饋的動力，你若強迫他們反饋，極大可能只能收到乙個「好」或「不好」，也許你新加了乙個功能、新補了乙個bug，他會感嘆「哇，比以前好用了」，但是僅此而已；二是軟體提供的反饋時機不對，從技術層面，我認為執行出現bug的時候立即彈出反饋渠道是最佳的選擇，但是如果考慮到需要收集多元化的使用者反饋資訊，這個時機的選擇可能要具體問題具體分析了。
正如王小波先生所說，「在乙個喧囂的話語圈下面，始終有個沉默的大多數」。我認為打造國民級軟體的重要一環，就是發掘「沉默的大多數」的需求。也許，他們不發聲，我們也能「聽」到他們的聲音。答案，我還沒有答案。
問題2. 如何恰當的使用goto語句 & 問題5. 科研與創新的關係
問題2實屬無稽之談，而問題5還未有新的想法，故暫且不表。
問題1. 如何在開發中如何準確劃分需求的等級？有沒有相關的工程理論或準則？
換言之，如何給軟體的優化需求進行乙個「輕重緩急」的優先順序排序呢？比如，在團隊專案開發時，beta階段，我對「新增新日程」這一操作進行了重新設計，如下圖。在新的版本中，我新增了 「回車快速建立」 功能，在詳細建立頁中增添了預設的快捷日期和時間，同時支援自動根據描述新增標題，而且整個的ui也進行了重新設計。
問題2. 不同團隊成員對產品定位和發展方向理解不同，導致在具體功能設計中發生衝突，如何解決？
我們團隊採取的方法是「擱置爭議，共同發展」和「誰提出誰解決」，即如果在某乙個功能的增減上發生了衝突，優先選擇 「我全都要」，但是對於較難實現的需求，秉持「誰提出誰解決」的方案。這樣的做法的好處是，極大地避免了團隊內的衝突。但是，這種方法顯然不是萬全之策。從某種程度上來說，它並沒有解決問題，而是逃避了問題。那麼在實際的軟體工程中，應該如何處理這些衝突呢？
個人專案 —— 革命尚未成功，同志仍需努力
軟工的個人專案難度並不大，但是在實現過程中，我還是對自己的數學知識的遺忘和匱乏有了更深的認識。尤其是，在思考程式優化時，完全沒有頭緒，感覺無處下手。後來觀摩了文瑄老哥的優化方法，看到他使用流水線等方法一層層地抽絲剝繭，最終得出解法，內心實在敬佩。未來希望自己也能更進一步，認真學習數理知識，在思考和實踐中融會貫通。
結對專案 —— 凡事預則立不預則非
第一次接觸結對專案，我覺得我沒有做得很好，但是在與結對夥伴一起探索的過程中，還是收穫了很多。比如，高效溝通的秘訣在於溝通之前的準備，準備的越充分，溝通的效率越高，如果溝通前沒有做好準備，那麼溝通一定是低效的，甚至是徒勞的。我們也再一次被生活毒打——由於最初對鬆散耦合的實現要求沒有理解到位，我們在完成與其他組對接時重構了我們的**。這也讓我們明白了兩個道理，一是磨刀不誤砍柴工，二是凡事預則立不預則非。
團隊專案 —— 用眾人之力，則無不勝也
本學期在團隊專案上的耗時最多，收穫也最大。體驗了軟體開發的全流程，也見識了強制轉會等生活的殘酷一面。收穫在上一部分已經分享了，下面說說我的一些體會。我們團隊整個的工作氛圍是比較輕鬆的，大家本來就很熟，然後也都很上進，雖然到了後期大家都很忙，有一些懈怠，但是在軟體的攻堅期，大家相互鼓勵、相互幫助，各自發揮所學和所長，一起克服困難，最終攢出乙個發布版來出來，真的是非常有成就感的！
最後附上我們團隊成員的簡介，非常開心能夠和大家一起完成 ddl killer ，感謝每一位給予我的幫助，有機會再約一波深夜debug局☺。
完結撒花2020 12 14日記
今天把半澤直樹看完了，雖然昨天晚上就想看完，但是實在是太睏了，只看了一集就睡覺了。睡得很香，一覺睡到了十一點。起來趕忙洗漱，把堆積了一段時間的衣服送洗衣機了，拿了兩個快遞，又拿了外賣，繼續看劇了，嘻嘻。中途支付寶提示我樓下的衣服洗好了，我滿心歡喜的想下去曬結果到樓下一看，洗衣機顯示還有18分鐘才洗完...
軟體工程基礎
abc 軟體 測試的目的 d單元測試 單元測試是對軟體設計的最小單位 模組 程式單元 進行正確性檢驗的測試。單元測試的目的是發現各模組內部可能存在的各種錯誤。單元測試的依據是詳細設計說明書和源程式。主要針對5個基本特性 模組的介面測試 區域性資料結構測試 重要的執行路徑檢查 出錯處理測試 影響以上個...
軟體工程基礎
python語法簡單，採用縮排方式 四個空格 乙個tab鍵 以 開頭的語句是注釋 abs 177 177 大小寫敏感 zhangsan zhangsan zhangsan lisi lisi 水果 fruit 饅頭 streambread 比如 n表示換行,t表示製表符，字元 本身也要轉義，表示的字...