提問回顧與個人總結

專案

內容這個作業屬於哪個課程

2020春季計算機學院軟體工程(羅傑任健)

(北京航空航天大學 - 計算機學院)

這個作業的要求在**

提問回顧與個人總結

我在這個課程的目標是

實現自己在軟體工程方面的個人素質的飛躍

個人提問部落格鏈結

buaa軟工第二次作業

關於增量程式設計，如何解決增量到一定程度後系統過於臃腫的問題？（第6章）

隨著軟體的開發，軟體的功能在通常情況下都是越來越豐富，但隨之而來的就是軟體的臃腫。由於在我所在的專案開發中，更多的是負責前端相關的工作，所以對我之前所問的，關於擁有複雜邏輯的後端開發基本沒有涉及，不過從同伴的**中還是可以窺知一二。在寫好乙個功能後，為了避免增量開發導致新增bug，要盡量避免修改這個功能的**，雖然這並不能保證新功能的開發不會觸發老功能**中潛在的bug，但至少不會因為隨意的改動而觸發新的bug。如果老功能必須進行**的改動才能跟上新版本呢？那就盡可能以新增**的方式進行改動，而不去改動現有的**。

關於開發與測試的對立（第7章）

實際開發的時候，感覺開發和測試並不是像某些課程一樣，處於乙個完全對立的狀態。畢竟在軟工課程上，開發人員和測試人員的利益都是一致的，最終目標都是交付乙個能夠正確執行的軟體。但如果在實際開發團隊中，將開發人員與測試人員放在乙個對立的位置（比如測試人員測試出bug後懲罰寫bug的開發人員或讓他加班修bug），就有可能導致開發和測試的矛盾，影響軟體工程的實施。

關於bug hell的設定（第11章）

這個問題倒是在開發中沒有遇到，我們也沒設定這樣的bug hell。主要的原因是，我們的程式規模較小，不太可能出現人均寫出大量bug的情況。並且在開發的時候，遇到的bug都是那種直接導致功能無法實現的bug，這種bug在發生時就會用最快的時間排除。

關於「小強大掃蕩」，如何確定bug的數目（第13章）

這個事情仔細想來的話，標準可以有很多種。不僅是從發現的問題或者修復的問題來劃分不同的bug，也可以根據bug的嚴重性進行劃分。像github的issue一樣，對每個bug劃分不同的size，可能是一種好方法。

關於軟體工程師的職業道德（第17章）

這件事情實施起來還真不好講。在開發的過程中，我們也曾經有過利用破解版外掛程式進行開發的計畫（雖然最後沒有實施）。今後做類似開發的時候，應當注意避免此類問題，不僅是道德層面，更要小心法律風險。

關於開發過程中人員的分工，是按前後端劃分（我們在\(\alpha\)階段的做法），還是按功能劃分（在\(\beta\)階段的做法）效率更高？個人感覺按前後端劃分更適合技術水平不太高的團隊（或起步階段），熟悉開發流程後就可以按功能進行人員劃分。不過是否還有其他更好的解法？

當團隊成員中溝通不是那麼便利的情況，如何保證開發進度仍然處於計畫之中？我們的做法是定期開會，匯報各自進度。有沒有其他的方法呢？

需求對需求的分析是軟體工程的開端。好的開始是成功的一半，在需求階段，需要投入一些精力，通過各種調查手段，結合團隊內部的分析，對使用者的需求下乙個明確的定義。在這一階段，應該盡可能重視現實的調查結果，而不能陷於開發者自己的美好想象中，否則就會出現產品和使用者需求不匹配的情況。

設計在設計階段，可以借助一些有效的設計工具，前端可以使用框架繪製工具，以現有**為模板也是一種可行的方法；後端則可以利用uml，modeling language等工具定義**結構和功能。

實現開發的過程中可以使用git issue，pull request等管理**，避免不同成員提交導致的**衝突。

測試發布

發布時，要注意重新檢測bug，因為伺服器配置可能不與本地相同，可能會出現相關問題。對這類問題進行排查時，則要結合本地執行結果進行對比，看看bug是不是因為在伺服器上部署而產生的。

維護發布後，要注意瀏覽訪問量等後端相關資料，並檢視使用者反饋，為維護做準備。

課程雖然占用時間很多，但總體上看，收穫和投入的時間是成正比的。希望這門課程中所積累的寶貴開發經驗，能夠成為今後工作學習的築路基石，

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

相關推薦