| 這個作業屬于哪個課程 | 2020春 W班 |
|---|---|
| 這個作業要求在哪裡 | <個人作業——軟體工程實踐總結&個人技術部落格> |
| 這個作業的目标 | 總結、回首 |
| 作業正文 | .... |
| 其他參考文獻 | ... |
一、回望
（1）對比開篇部落格你對課程目标和期待，“希望通過實踐鍛煉，增強軟體工程專業的能力和就業競争力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目标，哪些方面還存在哪些不足，為什麼？
當初我覺得軟體工程是一群有着共同目标的人共同努力奮鬥、合作互助做出讓使用者滿意的軟體。并希望通過此次軟體工程實踐的課程能讓自己從一個項目經驗為零的小白成長為一個團隊的主力。
現在課程已接近尾聲，回望此次課程，确實收獲頗豐。
此次課程，讓我真正學習到了，一個軟體的産生，不僅僅隻是之前我所認為的通過簡單需求分析加程式設計就能形成。而是要層層遞進，從需求調查、分析到系統分析，再到資料庫的設計等等，都是一環扣一環的。前期好的分析設計奠定了軟體的基石，有了穩固的地基，對于之後軟體的程式設計開發是至關重要的。
由于上半年的疫情，導緻學校無法開學，大家也隻能通過遠端協作來溝通合作。盡管如此，此次課程也是對我團隊合作與溝通能力提升最大的一次。通過遠端螢幕共享、語音等方式，我和我的隊員們也并不覺得有任何阻礙。唯一做的不足的地方是由于前期考慮的不夠周到，對于前後端接口部分的定義有部分偏差，直到beta實作階段才發現一些當初設計的漏洞。但當時我們團隊也采用建立一個接口共享雲文檔，後端人員寫完接口後把詳細的接口定義放上去，友善前端人員調用，也算是起到了較好的作用。總體來說還是經驗不足的原因，相信此次積累的經驗對之後的開發會有很大的幫助。
對于技術方面，此次項目我主要負責的部分是後端，在開發過程中我認識到了很多之前從未了解過的開發工具，熟練了使用各種測試工具，并且學習到了很多技術方面較為成熟的程式設計方法，對于git的使用也更加熟練。
還有一點不得不提，那就是寫部落格的能力。在這之前自己從來沒寫過什麼文章，基本上是聯考過後就沒寫過了。這次軟工實踐也讓我意識到，部落格是一個很好的方式來記錄自己的學習，記錄自己遇到的技術上的問題。不但日後自己可以看自己的曆史，還能分享給其他遇到相同問題的人，增進交流。
（2）你在第一次作業的個人履歷中制定的 這門課程結束後，你預期你将增長的能力、技術、技能；
當初我對于工程能力的預期是：提升團隊寫作能力與個人程式設計水準，這點毫無疑問已經到達了我的預期。對于技術的預期是：掌握一定的架構和技術，熟練運用一門程式設計語言。我認為這點也大體達到了。在此次項目中，我學習并熟練了Spring架構的使用，對于開發過程中遇到的各種bug，通過搜尋相關資料也算是更加熟練了對Java語言的使用。但是對于Spring架構的内部原理以及底層源碼的學習還不足，要達到通過面試的水準還遠遠不夠。
當初我指定的技術架構是大資料相關的學習，但隻能說計劃趕不上變化。由于這學期的課程多，作業多，再加上大資料相關的門檻更高，而Java相關的學習也是學習大資料方面技術的基礎。于是我也在開學不久後改變了學習的方向與計劃，決定先從掌握Java相關的技術架構開始。總體還是達到了我的預期值。
3）請總結這門課程的實踐總結和給你帶來的提升，包括以下内容：
- 統計一下，你在這門軟體工程實踐中，一共完成了多少行的代碼；
粗略統計接近1W行代碼
- 軟工實踐的各次作業分别花了多少時間？（做一個清單）
| 作業 | 時間（H） |
|---|---|
| 軟體工程實踐 - 寒假作業（1/2） | 6 |
| 軟體工程實踐 - 寒假作業（2/2）—— 疫情統計 | 36 |
| 結對第一次—某次疫情統計可視化（原型設計） | 24 |
| 團隊作業第一次——種子隊伍選拔和團隊展示 | 5 |
| 結對第二次作業——某次疫情統計可視化的實作 | 28 |
| 團隊作業第二次—團隊Github實戰訓練 | 8 |
| 團隊作業第三次—項目需求分析 | |
| 團隊作業第四次—項目系統設計與資料庫設計 | 9 |
| 個人作業——軟體評測 | |
| 團隊作業第五次——站立式會議+alpha沖刺 | 70 |
| 團隊作業第六次——beta沖刺+事後諸葛亮 | 50 |
| 個人作業——軟體工程實踐總結&個人技術部落格 |
- 哪一次作業讓你印象最深刻？為什麼？
印象最深的屬alpha沖刺。由于之前沒什麼合作開發經驗，當時對于技術也不夠熟練，程式設計過程中出現了各種問題。有些問題甚至是自己 本地環境的問題，同一個項目檔案在别人電腦上沒問題，卻偏偏在自己電腦上崩了。當時調bug調了特别久，心态接近崩潰，印象尤為深刻。
- 累計花了多少個小時在軟工實踐上？平均每周花多少個小時？
累計花了接近260小時，平均每周17小時。
- 學習和使用的新軟體；
Markdown:Typora
原型設計：墨刀，Axure
思維導圖：XMind
UML圖：StarUML
編譯器：IDEA、HBuilder
模拟器： MUMU模拟器
- 學習和使用的新工具；
團隊協作：git與github的使用
測試：Postman、JProfiler、JMeter
- 學習和掌握的新語言、新平台；
語言：Java，第二次寒假作業與團隊作業中大量使用，更了解了Java的集合、JVM等知識。
JS：第二次結對作業中使用。作為一名後端人員，也學習了很多JS的知識。
平台：部落格園、Github、以及安卓端。
- 學習和掌握的新方法；
原型設計：第一次了解并學習到了原型設計
單元測試： 在第二次寒假作業中第一次使用JUnit進行單元測試
接口測試：團隊作業中使用Postman進行接口的測試
壓力測試：團隊作業中使用JMeter進行接口的壓力測試
團隊協作與版本控制：使用Git與Github進行軟體版本慣例
- 工程能力的提升；
需求分析能力、類圖分析能力、系統設計能力、資料庫設計能力、代碼編寫與調試能力。
- 團隊合作上的提升；
團隊溝通與協作能力：使用語音通話與螢幕共享進行溝通調試
- 其他方面的提升；
個人品質：個人責任心、耐心與時間管理能力都有所提升
部落格：部落格寫作能力有所提升
二、團隊總結
軟體工程實踐是大學裡少有的認真的團隊協作經驗。《建構之法》上說團隊的發展有幾個階段，你的團隊都經曆過麼，最後到達了“創造”階段了麼？（參考《建構執法》第17章 人、績效和職業道德）
你在團隊中擔任了什麼角色？你是否完成了該角色的任務？現在你覺得你适合該角色嗎？
我在團隊中主要負責後端部分。我認為我大體完成了該角色的任務，也比較合适該角色。
1、 如果你是組員，你覺得你的組長分工安排是否合理？你對組長的選舉有什麼建議？
我覺得我們小組的組長分工安排大緻合理，但我認為後端人員有點過多（後端5人前端3人），導緻開發階段前端進度趕不上，後端進度過快。
對于組長的選舉，我認為應該由小組成員自行投票選出。隊長不僅要有較好的團隊管理與進度把控能力，也應該有較好的技術水準。
2、 你這學期經曆過換組嗎？你對換組有哪些看法？談談你在這個過程中的感受。
我沒有經曆過換組。我認為換組是有必要的，這是一個模拟今後工作的過程，今後工作過程中難免會遇到這樣的工作變動。現在的換組訓練是對之後最好的模拟。換組後需要以最快的速度學習新的技術棧，快速熟練新的業務，熟悉新的環境，是個不小的挑戰。
3、 分析一下自己所處的團隊。軟體工程實踐是大學裡少有的認真的團隊協作經驗。《建構之法》上說團隊的發展有幾個階段，你的團隊都經曆過麼，最後到達了“創造”階段了麼？（參考《建構之法》第17章 人、績效和職業道德）
我們團隊通過前幾次的組隊作業以及需求分析到達了萌芽階段，通過系統設計與資料庫設計到達了磨合階段，在最終的開發實作的沖刺中，大緻達到了規範階段，但并未達到創造階段這個高度。
三、人月神話
1、怎樣證明你學會了軟體工程？以下要求你們的團隊達到了哪幾個？請在随筆中用資料證明上述内容或側重選擇之一。
1）研發出符合使用者需求的軟體 必須公開釋出，有實際的使用者，一定的使用者量和持續使用量 （3 天後能保持10 - 100個使用者）；而不是: 做沒有使用者使用的軟體 （2）通過一系列工具，流程，團隊合作，能夠在預計的時間内釋出 “足夠好” 的軟體 有項目規劃/需求/設計/實作/釋出/維護，有定時的進度釋出 ； 而不是: 通過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲傳遞等方式糊弄 （3）并且通過資料展現軟體是可以維護和繼續發展的。 而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料
我們主要達到了第二、三兩點。
我們有細緻的時間安排與進度安排，有詳細記錄每日站會的會議記錄，并且每個人要在文檔中說明自己昨日進度與今日任務。
我們也有詳細的設計文檔與接口文檔，源代碼已上傳github，前後端各一個倉庫，可以維護和持續發展。
2、寫下屬于你自己的人月神話——個人或結對或團隊項目實踐中的經驗總結+執行個體/例證結合的分析，文字部分字數要求在100字以上，可以使用你自己喜歡的方式表達（如圖文結合、視訊）..
項目開發中對于任務進度的計劃不應該過于緊湊，計劃趕不上變化，過度緊湊的安排最終隻會被打亂。要留夠充足的時間，将任務盡可能地細化，再合理地配置設定到每一天中，防止某天的任務因為bug等原因而拖遲影響之後的進度。在本次beta沖刺中，我們團隊盡早地就開始了沖刺，但是在測試階段發現了很多的bug，是以實際上最後改Bug花了很長的時間，遠遠不止7天的沖刺。還好我們開始的早，才能夠留有足夠的時間，在ddl之前交出滿意的答複。
四、建議
對下一屆同學的建議，或者對于開學初的你，對于大一的你，對于開學初的我，你有什麼想建議和告知的呢？請寫下你對後來人的期許。
我希望之後的同學們能夠更加重視這門課程，也許你們确實在QQ空間或朋友圈看到各個學長學姐的瘋狂吐槽，但軟體工程實踐這門課絕對是對你們意義非凡的一門課程。它不同于你們其他課程的課内作業，它有着更加系統與成熟的體系，你們付出的越多，得到的回報也一定越多。
對于軟工實踐課程，你有哪些建議？
希望軟工專業這門課程能和計算機專業的一樣改到大三上學期！到了大三下學期，大家都面臨着重要的選擇，要考研的，要找工作就業的，都得着手開始準備。放到大三上學期，這樣對于準備找工作的同學來說也有更加豐富的項目經驗，有助于找工作；對于準備考研的同學來說也能夠全身心準備考研。據我所了解的情況，周邊大部分準備考研的，這段時間以來基本上都沒法複習，我相信大部分同學都是希望能調到大三上學期的。
對于助教工作，你有哪些建議？
希望助教能專門分享下自己的學習路線與經驗，像樂助教一樣多開直播分享，為樂主教點贊。
對于自己今後，你有哪些建言？
不忘初心，砥砺前行。希望以後的自己不後悔現在做的每個決定。
五、個人技術總結
個人技術部落格——Spring中Controller的傳參與傳回值處理
六、閱讀筆記
我所閱讀的文獻為第一篇：[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
有幸在谷歌找到了PDF檔案。
本文開篇提到了開源軟體相比于傳統“closed”軟體的優勢，開源有着更多的貢獻者與社群力量，有着迅速疊代與新特性增加快的特性，能夠有更加迅速的發展。但是，由于開源項目通常來說都是由最初的建立者直接上司，關于開源軟體的開發過程并沒有很好的定義。
Bollinger和他的同僚指出對于開源代碼而言，一個很重要的要求是“rigorously modular, self-contained and self explanatory”（嚴格子產品化、自包含與自解釋），這樣才允許遠端的其他人員進行開發。他還提到，在這種情況下，系統需求要更加精确，設計和需求文檔也要更加嚴格，代碼的品質也要相應提升，才能開發出較好的軟體。
至此聯想到此次軟工實踐中我們團隊的項目，确實存在因為前期的接口文檔與資料庫設計不完善不合理之處，導緻後期實際開發階段需要進行修改變動的情況。誠然，精确、高品質的文檔對于後期開發是至關重要的。
在作者的案例研究中，他們使用了Logiscope@（Telelogic,2000),這是一套全面的工具，能夠自動執行代碼度量和比較與使用者定義的程式設計标準。他們使用此軟體，檢查了在SUSE Linux6.0版本中發現的100各C程式的樣本。給出了不同的參數名額與可接受範圍，包括語句數、圈複雜度、最大級别、路徑數等十個名額。
Logiscope會為每個軟體元件和标準提出具體的建議，建議包括四個級别：ACCEPT(接受)、COMMENT(注釋)、INSPECT（檢查）、TEST REWRITE（測試重寫）。相關計算因子與範圍如下：
計算式如下：