軟體工程部落格作業
softwareengineering
至此，軟工課即將結束，團隊專案也已經完成了m2階段，下面回顧這個學期軟工課的實踐經歷，對一些問題再次進行思考：
xubaonline:bugphobia團隊
這個時期，對於我們團隊來說可以用兩個詞來描述：passion 和 confusion。 passion是因為我們有著對團隊和專案的高度自信，有著對專案的美好憧憬，對新技術學習的好奇和激動…… confusion是因為這個時期的我們對不僅僅在每個模組的技術細節上都存在著很多無知，需要耗費大量的學習成本，更是因為在組內各個模組的對接、與其他小組的資料對接都存在著很多問題。這些問題導致專案出現了較長時間的阻塞，令我們很是困擾，但慶幸的是我們是乙個有責任感有激情的團隊，在後期我們及時採用組內結對程式設計的模式來協調模組間的拼接，同時實現快速敏捷開發。
在m1階段我主要負責的是後端，當時感覺比較深的是和前端的耦合程度太高。因為django採用的模板渲染機制，所以有時我需要先獲得前端開發人員完成的頁面來進行調整，如果前端此時還未開發完成，那麼我需要自己寫一些頁面。這就造成了模組之間的界限不是很清晰，不僅帶來了重複的工作，也帶來了由於模組間依賴而引起的等待阻塞。
同時在這個階段前期我們太過自由了，當時沒有pm來進行全域性的協調和管理，導致任務有些拖沓，不過也有一部分原因是因為技術學習成本，導致整個過程不夠「敏捷」。後來自從結對程式設計後，我作為後端功能組與前端開發人員以及資料組進行結對程式設計，整體的效率提高了很多，於是明白了來自團隊的激勵和約束在乙個團隊專案開發過程中來說是非常關鍵的。
這個時期，在開發中有很多的無奈，但是讓我們很有成就感。無奈是因為其他課程的壓力特別重，導致在專案上能夠投入的時間遠不能達到預期的標準，很多功能被迫轉變；但是成就感來自我們針對m1階段中存在的問題通過架構修改和團隊管理制定專門的方案進行解決，同時更是通過設計了一套完整的架構讓xuba專案的四個小組整合了起來，而我們組作為其中的核心起著至關重要的作用。
這個階段我是後端的總負責人，不僅僅將原來的後端**通過互動方式的修改轉變成能夠適應前後端介面，同時與另乙個小組進行組間的結對合作，將問答平台移植到了django的後端之中。同時為了滿足開發的介面能夠讓前端開發者正常順暢的呼叫，我們在開發後端的時候還專門進行了單元測試，其中單元測試分了兩層，首先第一層也就是最基礎的一層，我對資料庫的所有操作進行了測試；第二層，針對的是我們web的特點，對於所有http互動介面進行了測試。上面的兩層單元測試保證了能讓前端開發者安心的呼叫介面獲取資料，從而提公升效率。
從中可以很好的感受到，我們的團隊合作和管理有了很大的提公升，尤其是各個模組之間的解耦讓我們開發人員可以專心按照需求完成自己的工作，模組之間的依賴直接就下降了。
同時我們的任務審核機制能夠及時對任務完成情況進行監控，同時對目標進行調整，這也是為什麼我們m2階段中後期及時將目標轉為面向後期的開發人員，為此我們在後面的開發之中非常注重**的質量以及注釋的完整情況，同時也準備了大量的學習總結文件，讓下一屆的團隊能夠很輕鬆得入手我們的專案。
在m1/m2結束之後來看我們的經歷，確實有種別樣的感覺，有種「陽光總在風雨後」的舒暢，心裡確實挺開心的，雖然我們的專案beta階段沒能給使用者乙個完整的版本，但是我們組無疑是有最多體會的，無論在技術層面，還是組內組間協調合作方面，中間都碰到了很多其他組沒遇到的問題，正因為如此我們有更豐富的軟體工程開發體驗。最後，再次感謝老師們推行這樣的課程模式。
閱讀《構建之法》後的思考和疑問
我們使用的後端是django，我專門負責的後端，在m2階段我通過給所有資料庫操作以及http請求進行單元測試保證這兩個層次上的正確性。其中後端運用的就是django提供的unittest 框架，這給錯誤定位帶來了很大的幫助。在單元測試時，它自動對資料庫進行備份，然後在每個testcase中可以隨意得進行操作，但是在整個測試結束之後會恢復資料庫，對原有的資料庫一點都不會產生影響；而且每次只需要簡單的一行指令就行執行所有的測試，迅速就能進行單元測試和回歸測試，讓**可靠性有很大的提公升。總的來說，通過實踐的開發過程，我清楚得認識了單元測試的重要意義。
對於這個問題：這個問題顯然是需要在專案開發的過程中去體驗從最初設計到最後的這樣乙個過程，才能有所思慮和認識。這個問題我最初想問的是設計方面需要細化到什麼樣的程度，在開發過程中我認識到，設計方面需要充分考慮到很多細節的問題上面去，這樣才能讓專案能有很好的擴充套件和發展，同時這也是為了能夠讓開發過程中各個模組之間能夠更好得協調開發，從而讓專案能夠更好得依照預期的進度去推進。比如我們beta階段的重構就是因為在alpha階段初期設計時沒能夠預料到模組之間的耦合度會這麼高，並且最初沒有去想如何將xuba四個組聯合起來。如果當初的設計就能夠預料到這些問題，那麼會減少很多不必要的時間消耗，但是問題往往在於我們軟體工程經驗性比例比較大，所以我們只有見識過足夠多的架構之後才能在自己設計時有個巨集觀的把控。另一方面，具體細化的程度至少要完成各個模組之間的介面設計，然後的設計就可以留個各個模組的開發人員去保留創造力了。
對於這個問題：通過開發體驗我有了這樣幾點想說：解決問題的能力
溝通能力
責任感
精神層面
對於這個問題：我覺得可以有一下幾點的看法。好的團隊機制能夠使得更敏捷
任務劃分盡可能細化，並制定好優先順序
對於這個問題：我目前的感覺還不是特別深，但是有一點可以確定，在優化之前先得將專案的功能給完成了，所以不需要過分去擔心這種由於架構帶來的問題，只要在設計過程中盡量多考慮一些問題就行。曾經在《數學之美》一書中看到這麼乙個說法，往往人們最初為了解決某個核心的問題而設計出來的framework會具備很好的實踐運用效果，後期即使再怎麼優化都很難有什麼較大的改善。這些**和部落格都比較長，但是主題還都是比較清晰的。
軟體工程的複雜性和可變性確實是太大了，其中存在著很多的變數，尤其在時間的安排和管理方面很難和預期的一致，這個時候對我們的要求就很高了。我們有很多經驗性的方法可以嘗試，但是具體的效果如何還是需要具體得去結合實際的專案需求以及開發情況。
所以在軟體開發過程一定要有乙個很好的團隊管理機制，然後通過這個機制積極調動成員的參與和合作，同時還需要有溝通交流，及時反饋。時刻對照監督任務的完成情況，好讓預期的目標得以實現。
需求階段
正如上面所提到的，它是整個問題鏈的開端。所有需求分析顯得非常重要。首先需要對專案有個基本定位，然後對潛在的使用者進行需求調研分析問卷，並且對問卷的結果進行分析來確定功能的選擇及其開發的優先順序。
nabc分析，swot分析也都是為了通過需求來明確我們專案的核心目標和出發點的，對於後面的進一步開發起著非常重要的作用。
設計階段
在設計階段首先有乙個總體的架構設計，這個架構設計需要明確前端和後端使用的框架，以及之間如何進行連線的介面設計。然後需要對具體的前端設計兩個層次，第乙個層次是設計頁面的布局，然後根據頁面布局和跳轉得到功能上的需求設計，然後在根據這些功能上的設計需求來得到關於後端的具體設計規範。
實現階段
這裡講究的是任務的分派問題，在團隊管理方面會有很多激勵和監督機制，從而來保證任務的正常完成，專案進度的正常推進。同時也會需要制定一些**規範來保證**質量。具體實現階段的合作方式可以有結對程式設計。
測試階段
包括：效能測試
相容性測試
場景測試
發布階段
需要對功能進行全面的介紹，同時需要對針對各種環境進行說明，對發行版本存在的問題進行記錄。
維護階段
需要開放專門的反饋平台來接受使用者的反饋，同時要秉著負責人的態度，積極和使用者反饋並對反饋的問題進行補丁。
軟工課程總結
提公升總結 作業時間列表 作業名稱 耗時 h 任務軟工實踐第一次作業 2跟隨問題引導，反思自己，做出預期 個人作業 詞頻統計 15複習c 學習github使用 第三次作業 結對作業 原型設計 2接觸墨刀，嘗試原型設計 第四次作業 團隊展示 5設計團隊頭像，確定專案，開會討論並拍照 第五次作業 結對作...
高等軟工課程總結
回顧當初剛選這門課的時候，對於這門課持有的一些期望。1.能夠掌握良好的需求分析能力，能夠把握需求的要點。在這門課的學習過程中，我算是真正意義上完整參與了乙個產品的設計過程，雖然過程磕磕絆絆，不過在老師的教導之下，目光也似乎從區域性慢慢擴散到整體了，這一部分的收穫挺大。2.對需求抽象並設計系統的能力。...
高等軟工課程總結
對本課程的期望 1 提高團隊協作能力 2 提高文件編寫能力 3 規範軟體開發流程 開發過程 領域分析 領域分析即確定問題所屬領域。在課程的小組合作作業中,我和其他組員們一起寫了領域分析報告。其實,我們組寫了兩次領域分析報告,第一次由於沒有參照老師給出的模板,導致最終的領域分析報告和老師預期偏差較大,...