軟工實踐個人小結（未完成）
請回望暑假時的第一次作業，你對於軟體工程課程的想象
對比開篇部落格你對課程目標和期待，“希望通過實踐鍛鍊，增強計算機專業的能力和就業競爭力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，為什麼？
總結這門課程的實踐總結和給你帶來的提升，包括以下內容：
統計一下，你在這門軟體工程實踐中，完成了多少行的程式碼；
估算的話，在個人專案和結對專案中花了約2000餘行（含註釋），在團隊專案中約7000餘行，其中後端Java約2800行，SQL語句約700行，前端JS約3500行，wxml約800行，其餘的雜項約500行，總計約10000行。（含註釋）（用個人專案統計，不含空行 ps：第二次作業）
軟工實踐的各次作業分別花了多少時間？（做一個列表）
待填入
哪一次作業讓你印象最深刻？為什麼？
應該是第二次作業，即個人專案之詞頻統計，在這次作業學到了很多，也踩了許多坑，雖然程式碼不難，但是開發規範卻學到了很多，包括程式碼規範，面向物件，單元測試等等，可以說，第一次作業做得是最艱辛的，因為所有的都不會。
累計花了多少個小時在軟工實踐上？平均每週花多少個小時？同時貼出開篇部落格“你打算平均每週拿出多少個小時用在這門課上”的回答
有些時間沒有具體的統計，但總的來說300以上小時還是有的,平均一週15-20h吧，在後期alpha和beta爆肝的時候，一個星期可以到40h。
學習和使用的新軟體；
VS2017；微信開發者工具 ；Eclipse；Mysql
學習和使用的新工具；
markdown；processon；GitHub；
學習和掌握的新語言、新平臺；
Java;wxml;wxss;JS;
學習和掌握的新方法；
學習使用spring boot框架；學會UML圖和思維導圖；
web端服務：證書，伺服器，域名配置等；- 其他方面的提升。
- 對deadline有了更明確的認識。
寫下屬於自己的人月神話——個人或結對或團隊專案實踐中的經驗總結+例項/例證結合的分析
對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，對於同期的TA們，對於後來的學弟學妹：
你有什麼想建議、告知和期許想要告訴他們呢？
1.如果可以的話，做團隊專案前要考慮清楚以下幾點
- 誰能做什麼
- 誰做不了什麼
- 誰願意做什麼
- 誰不願意做什麼
特別地，特別地，下一屆要不要中途換隊員（強制的、徹底的從一隊換到另一隊）？假設依舊是一個90+人數的大班
不要。首先以UML的現場實踐為例，雖然部分被調到其他組的人完成的也較還不錯，但畢竟外組人員不瞭解轉入組的情況，會導致效率很低，體驗較差。儘管看起來很新奇。
身在一個格外大的班級，競爭強勁，你認為一個組的人數應當在多少比較合適？
個人覺得5-6人是比較合適的人數，其中三個後端，兩個前端，一個PM兼職美工等，人多了難以協同，並增加交流與任務分工分配的成本。
- 個人/結對/團隊作業應該控制在怎樣的規模？
- 個人：20h
- 結對：
- 團隊：
這學期下來，你最感謝的人是誰？有什麼話想要對TA說呢？
分析一下自己所處的團隊。軟體工程實踐是大學裡少有的認真的團隊協作經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了“創造”階段了麼？（參考《構建執法》第17章 人、績效和職業道德）
怎樣證明你學會了軟體工程？
- 1）研發出符合使用者需求的軟體
必須公開發布，有實際的使用者，一定的使用者量和持續使用量 （3 天后能保持10 - 100個使用者）；而不是: 做沒有使用者使用的軟體 - 2）通過一系列工具，流程，團隊合作，能夠在預計的時間內釋出 “足夠好” 的軟體
有專案規劃/需求/設計/實現/釋出/維護，有定時的進度釋出 ； 而不是: 通過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄
- 3）並且通過資料展現軟體是可以維護和繼續發展的。
而不是 找不到原始碼，程式碼無文件，程式碼不能編譯，沒有task/bug 等專案的發展資料
- 4）對著這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，自己如果去企業面試，這些常見的問題是否都能回答，並在此總結。
請在隨筆中用資料證明上述內容或側重選擇之一。
（選做）、閱讀軟體工程中關於程式碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合自己的實際做一個閱讀筆記（例如，自己寫的程式碼質量如何，是不是一個大泥球，如何衡量自己程式碼的質量）？從以下參考論文中選擇一篇或若干篇：
參考論文文獻：
[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