一、請回望暑假時的第一次作業，你對於軟件工程課程的想象
1）對比開篇博客你對課程目標和期待，“希望通過實踐鍛煉，增強計算機專業的能力和就業競爭力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，為什么？
- 回顧第一次作業，那時候我很糾結的，因為實驗班的軟工實踐是必修課，然后自己學業任務和學生工作任務都很重，但是，我還是都報名了。以至那階段真的是忙到想吐血。對軟工的印象也一直下降，甚至還會吐槽說怎么又是寫文檔，太可怕了。
- 現在對軟工的印象，或者說反思吧，我自己得到了什么，好像不僅僅是學分這么簡單的事情，但是我又說不出所以然。代碼量因為自己的沒有參與編程，並沒有得到多大的訓練，立下的flag要看完《Java編程思想》也沒有實現，寒假有時間要把這個flag補回來。
- 我對軟件開發的過程有了具體的了解，不僅僅是實踐課，理論課也學到了很多。我在我們小組的任務是扮演PM的角色，以前我覺得項目領導者也不過如此，但是自己親身經歷才會發覺壓力很大，因為自己沒有任何經驗。這段經歷然我想起了大一那時候剛剛進來大學，沒有任何經驗，還去勇敢地競選班長，最后成功，並且把班級帶得不錯的歷史。哈哈哈哈哈哈
- 不足的話，就是我的代碼能力吧，還是很菜。
2）總結這門課程的實踐總結和給你帶來的提升，包括以下內容：
- 1、統計一下，你在這門軟件工程實踐中，完成了多少行的代碼；
- 上GitHub看了看：752行代碼
- 此次的軟工項目，我並沒有參與編程，除了個人和結隊還有那時候的課堂小開發（校友錄）這些我有參與編程之外，其他方面我的參與度並沒有那么高。
- 2、軟工實踐的各次作業分別花了多少時間？（做一個列表）
| 作業 | 時間（分鍾） |
|---|---|
| 第一次作業--准備篇 | 120 |
| 第二次作業——個人項目實戰 | 750 |
| 原型設計（結對第一次） | 350 |
| 結對第2次作業——WordCount進階需求 | 1025 |
| 團隊展示（團隊） | 300 |
| 項目選題報告（團隊） | 1800 |
| 項目需求分析（團隊） | 600 |
| 團隊作業,隨堂小測——校友錄 | 600 |
| 個人作業——軟件產品案例分析 | 300 |
| 合計 | 5845 |
alpha沖刺和beta沖刺不知道怎么統計，就不填進去了。雖然沒有參與代碼開發，但是其他方面的任務，我自認為還是不錯的。
- 3、哪一次作業讓你印象最深刻？為什么？
- 非要說印象最深刻的是什么的話，就是選題了，那時候確定了選題，然后以為選題報告，答辯什么都是隊長做的，然后那時候我通宵了兩個晚上，做選題報告和PPT。以至那時候第二天答辯差點暈倒（雖然沒人知道），后來修改報告和ppt是和隊友一起修改的。
- 第二深刻的是需求分析，這回的分析報告是大家平均分配的，然后到了前一天要整合的時候，有人因為不可逆原因，沒辦法寫好，提交的過於簡陋，然后自己又在那里熬夜修改，突發情況的處理真的很傷身體。
- 還有那次校友錄，我負責最后的整合，然后在最后那里我上傳自己的代碼的時候，一直失敗，一氣之下，-f強制push，結果把隊友的代碼全部弄丟了。很是懊悔。
- 4、累計花了多少個小時在軟工實踐上？平均每周花多少個小時？
- 認真去估算了一下，總共花費的時間141.4小時，按照課表是03-14周有課，大概每周是花費11.8個小時。
- 5、學習和使用的新軟件；
- 墨刀，eclipse（特別是那時候校友錄我整合代碼的時候，崩潰），VS。
- 6、學習和使用的新工具；
- Java語言，eclipse，GitHub
- 7、學習和掌握的新語言、新平台；
- Java
- 8、學習和掌握的新方法；
- VS的調試，單元測試，利用vs來進行性能分析，還有Java的自動補全我一直沒搞好。
- 9、其他方面的提升。
- 和別人的合作能力，以及照顧團隊人員的情緒吧。還有百度很有用，Google我還不是很清楚。
二、寫下屬於自己的人月神話——個人或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析
-
個人作業的經驗教訓
自己不懂的地方可以去百度，或者翻找博客，然后找到解決辦法，但是如果解決辦法沒用的話可以找同學尋找幫助，比較不會浪費時間，但是一定先自己嘗試解決問題。還有助教和老師其實也是一種很好的資源，但是我沒意識到。
實例：那是個人第一次的作業是統計單詞數。最坑的就是一開始理解錯了題意，寫錯了代碼。然后和同學交流后發現自己的錯誤后，再進行改正。后來因為自己代碼不熟練，一個多層嵌套循環自己判斷錯了，導致了自己代碼運行結果不對，就那一次是兩個同學幫我找到的bug，我們先是交流問題的思路，然后那次我學會了調試。 -
結對的經驗教訓
結對的作業就是代碼會分開，然后千萬要保證兩個人用的環境是否一樣，否者有可能會報錯...慘痛。 -
團隊的經驗教訓
- 團隊的話，最好是一開始就加入編程，這樣子既可以幫助整個團隊，后續也知道什么代碼表示什么，在哪個位置。我一開始沒有參與，再beta階段想參與，但是很難融入。
- 注釋很重要，就是因為沒有注釋的原因，所以很難融入項目的開發。
三、對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，你有什么想建議和告知的呢？對於后來人的期許。 特別地，特別地，下一屆要不要中途換隊員？
- 選題不要太自信，我們團隊就是選題工程量過大，然后有一些技術上的問題一直無法實現，比如地圖路線的縮略圖生成。
- 在自己選完這門課后，最好暑假就學習一些開發工具和語言，安卓Java之類的，會讓后面事半功倍。
- 一定要找一個能理解所有人的話的人來當隊長，不然有時候兩個人溝通會很費勁。
- 寫文檔的任務是很煩人，但是大家一起配合的話，就簡單多了。
- 要不要中途換隊員：我覺得是可以換，但是中間的緩沖時間可以多給一些，或者說想想可以發什么任務給團隊磨合一下。不然，真的很難幫到項目什么忙。（主要還是太菜了hhhhh）
四、分析一下自己所處的團隊。軟件工程實踐是大學里少有的認真的團隊協作經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過么，最后到達了“創造”階段了么？（參考《構建執法》第17章 人、績效和職業道德）
分為四個階段
- 萌芽階段
這是最開始剛剛組隊的時候，大家就一腔熱血，說着自己喜歡什么想要做什么。一起吃頓飯，交流很多，但是很多不是關於項目的交流。 - 磨合階段
在alpha階段就是我們團隊的磨合階段，那時候項目開始，大家很有精力，努力學習新的工具和語言。但是就是因為對工具的不熟悉，導致我們團隊在alpha沖刺的最后一天整合代碼的時候，只能手工熬夜整合。 - 規范階段
在beta階段應該可以說稍微有點規范階段的意思了，每個人的分工明確了，統一用協同這開發的模式，然后每天push和pull，到最后代碼注釋的添加。我們一直在路上。 - 創造階段
創造階段我們團隊目前還有一定的距離。
五、怎樣證明你學會了軟件工程？
1）研發出符合用戶需求的軟件
必須公開發布，有實際的用戶，一定的用戶量和持續使用量 （3 天后能保持10 - 100個用戶）；而不是: 做沒有用戶使用的軟件
2）通過一系列工具，流程，團隊合作，能夠在預計的時間內發布 “足夠好” 的軟件
有項目規划/需求/設計/實現/發布/維護，有定時的進度發布 ； 而不是: 通過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄
3）並且通過數據展現軟件是可以維護和繼續發展的。
而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料
請在隨筆中用數據證明上述內容或側重選擇之一。
- 側重第二點
- 我們的團隊通過GitHub編程，再alpha沖刺階段確實做得比較不好，是通過熬夜人工整合代碼，規划做的不好。以至GitHub提交記錄很亂，在beta階段我們進行了改進，這就是我們的進步。
- 我們有通過問卷調查，確定選題，需求分析，類圖的運用，alpha/beta沖刺等階段來完成我們的項目
- 有明確的分工（三人負責前端，二人負責后端，一人負責其他事務）
- 沒有臨時熬夜，是幾乎每天熬夜。
六*（選做）、閱讀軟件工程中關於代碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合自己的實際做一個閱讀筆記（例如，自己寫的代碼質量如何，是不是一個大泥球，如何衡量自己代碼的質量）？從以下參考論文中選擇一篇或若干篇：
參考論文文獻：
[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.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87
七、個性發揮，包括圖文、照片和創意等
嗯，談談自己的感想吧，作為隊長，自己的專業技術確實沒有處於領先地位，能給的幫助會比較少。但是我覺得我做得最好的一點就是，我們做到每天組織大家開會，大家談談自己的問題，然后他們在交流過程中對方相互不理解，我能作為“翻譯官”來解釋，幫助他們。然后我有認識隔壁K班的一個PM，他做得比我好的地方是他有參與軟件的編程，他屬於代碼能力比較強的一個人，那天我和他交流，他們團隊也有不負責編程的人員，但是他屬於那種哪里編程出問題，他就到哪里幫忙，哪里來不及了，就去打下手。我覺得他做得很不錯，對比一下，我可能就比較low了。