通過了一學期的軟件工程的學習, 我對於軟件的開發和協做流程有了新的認識, 所以寫下這篇博客來回顧一學期的學習。html
項目 | 內容 |
---|---|
這個做業屬於那個課程 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2020_LJ |
這個做業的要求在哪裏 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2020_LJ/homework/10822 |
我在這個課程的目標是 | 清晰職業發展規劃, 學習領先的軟件開發方法 |
這個做業在哪一個具體方面幫我實現目標 | 回顧了以前學到的知識點, 對將來有更清晰的認識。 |
做業正文 | 以下 |
迴歸測試前端
在之前的博客中, 迴歸測試問題 , 我曾問過這樣的問題python
我有一點疑問, 新的版本的軟件可能在新加的部分有缺陷, 也多是由於破壞了之前的功能, 或者是兩者連接起來出了問題, 而要檢測這樣的bug須要跑全部的測試, 這樣是否會有很大的時間成本開銷? 是否有好的方式可以把新增的代碼單獨測試? 以及用更通用的測試去驗證流程的正確性?mysql
以前不是很理解迴歸測試的做用, 通過了幾輪軟件工程的開發, 我對於迴歸測試的重要性有了新的理解。 在咱們的軟件開發中, 有一次後端由於添加了新的接口, 致使了老接口的權限出了問題, 花了很長時間才修復了bug, 從那以後, 咱們很注重迴歸測試的流程, 添加新功能的同時保證了舊功能的正確性。git
敏捷開發github
在之前的博客中, 敏捷開發, 我曾問過這樣的問題面試
請問在敏捷開發中, 什麼樣的設計模式和軟件架構可以適應敏捷開發的流程? 在招聘中, 如何判斷一個成員是否可以勝任敏捷開發的工做?算法
通過了一學期的軟件工程的學習和實習, 我對該問題有了更深刻的理解。 在實際的軟件工程中, 若是想要進行敏捷開發, 必定要注重軟件架構的設計, 不然每次開完stand up meeting, 新添加功能的時候會很困難。 在設計軟件的時候, 要把模塊的功能儘可能細化, 千萬不要把全部內容堆疊到一個函數內, 不然很難修改, 實現高內聚低耦合的架構更時候軟件開發。 在招聘中, 若是想要判斷一個成員是否可以勝任敏捷開發工做, 首先要確保該成員有紮實的數據結構和算法知識, 以後能夠採用漸進式的面試方式, 不斷添加功能看該成員可否在短期內設計好框架, 實現新功能。sql
在學習中, 我也產生了一些新的問題。數據庫
好比
需求
學習了NABCD分析, 在討論中尋找用戶的需求, 針對痛點設計軟件。
設計
設計主要分爲兩方面, 功能設計和技術規格設計。 功能設計須要繪製原型圖, 對整個軟件操做的流程有一個大概的認識, 列出軟件的交互邏輯。 技術規格須要對軟件使用的編程語言和編程框架進行約定, 指定可行的方案和優化方向。
實現
學習django後端開發, 經過python來實現一套Restful接口, 實現先後端分離的設計
測試
coverage自動化測試工具, 迴歸測試, 代碼覆蓋率。 在每次代碼提交複審前先進行迴歸測試
發佈
發佈的時候須要收集用戶的反饋, 進行推廣。
維護
根據用戶反饋修復bug, 指定下一階段的sprint目標, 維護mysql數據庫。
我的項目是實現一個交點求解的程序, 這個項目主要是讓人熟悉一些我的軟件的開發流程, 拿到任務後進行軟件的架構設計, 查資料思考算法, 最後實現, 測試, 性能分析, 用github提交。 總體來看, 這個項目並非很難, 可是讓新接觸軟件工程的同窗對我的流程有了基本的認識。
結對編程項目是頗有趣的體驗, 這個項目能讓人學會如何進項小範圍的, 兩我的的軟件開發合做, 爲以後的團隊項目搭好基礎。 這個項目用到了模塊的封裝, 編程動態庫, 以及使用MFC開發GUI, 兩我的一塊兒一我的當領航員, 一我的當駕駛員, 能夠互相找bug和代碼中的問題, 提高編程水平。 此次項目我我的的體會是, 雖然結對編程可以互相幫助, 可是這種開發方式是比較低效的, 一我的的工做兩我的同時作的成本很高, 在真實的軟件開發中不太實用。
團隊項目帶給個人是一次比較完整的軟件工程體驗, 從討論選題, 分析不一樣用戶的需求, 再到設計, 技術的選擇, django實現, 單元測試, 發佈, 維護, 一我的見從雛形到成熟的總體流程是比較完整的。 咱們採用了github來管理代碼, 用看板, issue, 燃盡圖的方式來控制進度, alpha階段主要的任務是把軟件搭起來, 可以使用, beta階段進行了一系列的優化。 我負責的部分是django rest後端api的開發, 須要給前端一套restful的api, 管理用戶的數據。 我以爲在團隊項目中, 團隊總體須要有一個完善的開發流程, 好比在stand up meeting討論要sprint的目標, 指定目標後把任務分給我的, 提issue, 而後各自寫各自的代碼, 提PR, 代碼複審, 測試, 關issue, 對接。 若是全部團隊擁有很高的軟件開發素質而且遵循這套流程的話, 那麼團隊的開發是很高效的。 團隊項目是須要多人合做來完成的, 所以團隊流程這件事情給我留下的印象比較深。最後, 總結下敏捷開發的方式, 這學期也在校外實習, 公司用的也是敏捷開發的流程, 和咱們的敏捷開發的流程仍是有些不一樣的, 公司的stand up meeting沒有那麼頻繁, 通常都是和本身組內的人進行溝通, 並且需求的文檔和寫代碼前的設計文檔是比較完備的, 所以也不須要太多的後續溝通。 同時, 我我的感受公司的CICD和代碼複審要比咱們我的的團隊成熟, 有更多年經驗的工程師來給個人代碼架構和性能提意見, 我以爲在開發中這一點是很重要的, 必定要有有經驗的人去帶, 要不很容易陷入低效代碼重複編寫的循環。