專案
內容這個作業屬於哪個課程
2020春季計算機學院軟體工程(羅傑 任健)
這個作業的要求在**
提問回顧與個人總結
這個作業在哪個具體方面幫助我實現目標
回顧了軟體工程及開發中的一些問題
其他參考文獻
《構建之法——現代軟體工程》
提問部落格
個人部落格作業
關於寫單元測試的人選
「**的作者最了解**的目的、特點和實現的侷限性」這句話沒錯，但根據我的經驗，**作者往往很難用自己對**的理解構造真實有效的測試用例。而且就算**作者對**進行了完備的測試，也只能保證**在作者設想的環境下完成作者計畫的功能，這不一定滿足其他情況對**的需求。我想這也是為什麼我們在物件導向程式設計中設立了「互測」這一環節。經過團隊開發的洗禮，我認為單元測試還是應該由作者本人完成。我經歷了轉會過程，先後待了兩個團隊，在前乙個團隊是測試的角色，後乙個團隊作為後端開發的角色。
在給別人的**寫單元測試時，通常是沒有方向的，只能寫寫正常狀態下的功能測試，而對於**的***沒有了解，很難對異常情況下的**進行測試；而給自己的**寫測試時就相對來說得心應手了，因為清楚自己的**的短板，在寫測試時知道要往哪方面去測。
關於如何保護創新
可以看到，在此時創新者僅僅是淪為了競爭者，當如書中所說，我們的創新被變成大路貨的時候，我們還剩下什麼競爭力呢。我現在認為或許保護創新這個想法不一定是好的，如果沒有後來者，就意味著壟斷，而壟斷往往固步自封，造成整個行業的停滯。而「保護自己的創新」最好的方法，可能是不斷地創新進步。又如書中所說，「大部分成功的創新者都不是先行者」，但先行者定義為這個領域乃至這個行業的第一人，是在更寬泛的意義上的創新，然而這種先行者往往被後來居上的產品打敗。作為最初的創新者，我們應該如何保護自己的創新？
關於創新的顧慮
不考慮中文玩家的 wiifm(what's in it for me)，我的疑惑是為什麼英文玩家在如此大的優勢前都沒有屈服。誠然，這與大眾習慣的已經形成分不開。但根據我的經驗，先入為主的規則往往只適用於先入者不劣於後來者的情況，比如國際標準單位制，因為沒有人喜歡改變。但在這種情況下，我想真正的問題在於如何對大眾講清楚，讓他們看見這個相對優勢。我仍存在這個疑惑，或者說是對原書觀點的懷疑。如果大家能真正認識後來者的優勢，考慮需要做出的改變，取代前者不是不可能的。
關於goto
這一點與我的經驗矛盾。從開始學習程式設計起，"goto"一直是禁術一般的存在，無論是老師同學還是論壇上都建議不要使用"goto"。在我自己的程式設計經驗裡，goto除了打亂我的**邏輯也並沒有為我帶來其他的好處。我仍然認為goto不是應該被無腦禁止的，在不造成**紊亂的情況下是可以合理使用的。但是書中的前提是「為了是函式有單一的出口」，我認為如果僅僅在這種情況下使用goto，應該不會造成**紊亂。但實際的效益還是要在實踐中證實。
關於敏捷開發
上文提到了敏捷方法的優勢，可以看到，其中「敏捷」指開發速度快，從而使整個開發過程有了字面意義上的「敏捷」。同時我們也可以發現，敏捷的優勢都是針對「使用者」而言的，體現在對於客戶需求的響應變化迅速。經過團隊開發、結對專案的洗禮，我大概理解了敏捷開發課程的作用。要經歷週期很短的開發階段，又面臨著實實在在的需求和技術棧，就必須具備較強的學習能力，及時更新自己的技術棧。這是敏捷開發課程教我的最重要的東西。我的疑惑是，敏捷開發對於學習這門課程的我們有什麼執行上的必要性。what's in it for us?
提問回顧與個人總結
首先我在整個團隊負責的是pm的工作，儘管有負責過開發的工作，但是我想更多地以乙個pm的角度來看待問題。通過一定的軟體流程，在預計的時間內發布 足夠好 的軟體。現在我打算從三個方面來徹底考慮這個問題。從開發者的角度來看，好的軟體是完成了其承諾的所有功能，修復了測試發現的所有bug。從測試者的角度來看，...
提問回顧與個人總結
專案 內容這次作業屬於哪個課程 軟體工程 這次作業的要求在哪 提問回顧與個人總結 答 我原來對這個問題理解也不是特別深，但是經過這次軟體工程小組一起開發的過程後，我理解到了這個 風格的統一是非常重要的，乙個團隊要想完成乙份好的 每個人都不可以太過彰顯自己的個性！答 其實經歷了結對程式設計之後，我還是...
提問回顧與個人總結
提問部落格 設計規範問題 函式最好有單一的出口，為了達到這一目的，可以使用goto。只要有助於程式邏輯的清晰體現，什麼方法都可以使用，包括goto.結對程式設計問題 他們併排坐在一台電腦前，面對同乙個顯示器，使用同乙個鍵盤，同乙個滑鼠一起工作。他們一起分析，一起設計，一起寫測試樣例，一起編碼，一起做...