專案
內容這個作業屬於哪個課程
班級部落格
這個作業的要求在**
作業要求
我在這個課程的目標是
系統地提公升軟體工程能力
這個作業在哪個具體方面幫助我實現目標
回顧與總結學到的軟體工程知識
提問部落格鏈結
1、關於第一章中的「軟體的非連續性」
經過一學期的軟工，我認識到這種「軟體的非連續性」其實是指因為軟體是乙個離散的系統，當系統邏輯變得複雜時，輸入上的微小變化可能會導致其經過不同分支，產生截然不同的結果，這種情況下，測試就變得尤為繁重和困難，需要保證每乙個邏輯分支都能被覆蓋，才能保證軟體的可靠性，因此這種"非連續性"較大的影響了軟體的開發成本。解決這個問題的乙個重要方面便是在設計階段合理的拆分和解耦合，將複雜邏輯拆成互不相關的簡單邏輯，分而治之。
2.第二章---單元測試應覆蓋所有的**路徑
我的觀點同之前一樣，還是認為不需要保證單元測試覆蓋所有的**路徑，理由跟之前一樣：
當乙個專案非常龐大的時，對**所有路徑的100%測試覆蓋需要編寫的測試**量可能比**本身還大，測試工作量非常大；而其中的很多很多簡單的**，這種情況下我覺得不必為其編寫測試**。如何平衡測試效率和測試覆蓋率是測試人員需要磨練的東西
3.第三章---軟體工程師思維誤區之過早泛化
我當時提的問題是有些專案擴充套件性不足、有些專案存在過早泛化問題，那麼專案擴充套件性的度如何把握？
這個問題現在想想其實要求兩點：
1.設計階段就要對專案的架構、api等了解足夠清晰。回顧我們軟工開發的遊戲《原始碼召喚》，我們發現乙個問題：因為我們團隊剛開始都是unity小白，對很多遊戲功能的實現都不了解，是後來邊學邊用的。因此回看我們設計階段的技術規格文件，其實它非常簡陋，此外不同人員負責遊戲的不同模組，他們之間的對接主要是彼此商量出來的結果，並沒有在設計階段就很好地定義這些介面。設計階段的介面定義模糊會導致專案的擴充套件性充滿了未知。
2.認清你的預期
即給你的專案定個目標，預期能發展到什麼程度，朝著那個目標去設計擴充套件性。
4.第四章-----關於結對程式設計的如何落地
我的觀點同之前一樣：
在我看來，結對程式設計的複審可以以乙個函式為單位，這裡說的「任何一段**」不必細化到每一行**，在複審時對方只需要對這個函式的功能做一定的單元測試+了解這個函式的實現思路即可。在開發前設計好各個函式的輸入輸出以及邊界情況等，就像oo課程裡的jml一樣;同時通過**規範檢查等機制來限制每個函式的大小、行數，這樣在對方複審時檢查工作會容易進行得多，有利於結對程式設計的落地
5.第九章---高效的團隊討論
之前我對「高效的團隊討論」提出了自己想到的乙個問題
有些會議存在這樣乙個問題：議題過於龐雜，有些議題無關乎一些與會者當下正在做的或者是相關的工作和領域，被強行湊進乙個會，這時的會議的討論與與會者其實是無關的，也浪費了與會者的時間。需求階段
明確需求，保證調研的需求得是真需求，否則做好產品，再發現沒人使用，那麼整個專案的努力都會付之東流。
設計階段
設計要定義好整個專案的架構給出明確的介面，定義好可重用的部分。在我們的開發的遊戲中，這一點在遊戲開發中尤為重要，因為各關卡的遊戲場景裡可重用的部分較多，定義好哪些元件可以重用，就把它做成乙個prefab，後期修改這一元件會非常方便。
實現階段
實現階段我感受最深的是每日例會的作用，它幫助了我了解專案的整體開發進度，也起到了監督的作用，敦促了我不摸魚，努力幹活，同時每日例會也能反饋自己開發中遇到的問題，尋求技術幫助。
測試階段
重視測試，頻繁測試，全面測試。測試是保證產品可靠性和穩定性的重要手段,需要我們付出較多時間和精力。同時別將測試工作堆到開發完成後再統一做，否則測試工作將十分緊張。
發布階段
注意給發布留出緩衝期，提前確定好發布平台，發布條件等，例如遊戲的發布是否需要提供版號，這項要求在小公尺、華為應用商店就是必需的，在其他一些平台就沒有硬性要求。提前確定發布在哪，能否發布，如何發布等環節非常重要，否則發布之時就會麻煩不斷。
維護階段
注意收集反饋，彙總問題和bug，形成文件。
結對程式設計
主要是明確分工，同時保持良好的溝通。明確分工，兩人併發程式設計，提高效率，**審查也多了一雙眼睛；但同樣為了讓別人能看懂你的**，又需要你像jml那樣定義好各函式的輸入輸出、功能，增加了許多任務作量，溝通不暢也會帶來很多交流成本，有利有弊吧。
團隊專案
此前我從未在乙個多人團隊中開發乙個專案，這次的團隊專案對我來說確實是一次有意義的經歷與實踐。從需求調研到設計到開發、測試再到發布、維護，我們團隊7個人都為了同乙個目標而努力，遇到問題可以互相請教和溝通，這種氛圍、這段經歷讓我覺得開發並不孤獨。此外，隨著專案的一點點推進，產品也越來越完善，成就感也是很強的。總而言之，這學期的軟工實踐非常充實，豐富了我的團隊開發經驗，我學到了很多。
提問回顧與個人總結
首先我在整個團隊負責的是pm的工作，儘管有負責過開發的工作，但是我想更多地以乙個pm的角度來看待問題。通過一定的軟體流程，在預計的時間內發布 足夠好 的軟體。現在我打算從三個方面來徹底考慮這個問題。從開發者的角度來看，好的軟體是完成了其承諾的所有功能，修復了測試發現的所有bug。從測試者的角度來看，...
提問回顧與個人總結
專案 內容這次作業屬於哪個課程 軟體工程 這次作業的要求在哪 提問回顧與個人總結 答 我原來對這個問題理解也不是特別深，但是經過這次軟體工程小組一起開發的過程後，我理解到了這個 風格的統一是非常重要的，乙個團隊要想完成乙份好的 每個人都不可以太過彰顯自己的個性！答 其實經歷了結對程式設計之後，我還是...
提問回顧與個人總結
提問部落格 設計規範問題 函式最好有單一的出口，為了達到這一目的，可以使用goto。只要有助於程式邏輯的清晰體現，什麼方法都可以使用，包括goto.結對程式設計問題 他們併排坐在一台電腦前，面對同乙個顯示器，使用同乙個鍵盤，同乙個滑鼠一起工作。他們一起分析，一起設計，一起寫測試樣例，一起編碼，一起做...