作業原文
對比開篇部落格你對課程目標和期待，「希望通過實踐鍛鍊，增強計算機專業的能力和就業競爭力」，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，為什麼？
在和他人合作編碼的方面得到了鍛鍊，不僅是在剛開始一對一的結對程式設計，後面的團隊作業也是。寫**不單單是考慮實現相應的功能，還要盡量讓**規範易讀，加上必要的注釋，不然別說別人，自己過段時間可能都看不懂，這是乙個值得注意和保持的好習慣。還有對團隊合作的工具，主要是 github ，又熟悉了些，確實很強大，但是自己還不能熟練地使用。
不足自我感覺還是自學的能力，上手比較慢，後來也只是能夠大致滿足團隊開發需要的程度，沒有很深入。
總結這門課程的實踐總結和給你帶來的提公升，包括以下內容：
作業所花時間
閱讀思考與期望
5h個人專案實戰之數獨
20h結對專案第一次作業
3h團隊第一次作業之團隊展示
1h結對專案第二次作業
15h團隊作業之選題報告
1h個人技術部落格（alpha）
5h團隊作業之需求規格說明書
1h團隊作業之採訪學長
1h團隊作業之系統設計
2h團隊作業之uml設計
2h團隊作業之同學錄
7h個人作業之華為軟體雲
3h團隊作業之 alpha 衝刺
50h團隊作業之 beta 衝刺
15h軟工實踐個人總結
3h還是同學錄的那次隨堂小測，算是軟工實踐的乙個縮影。一開始是大家一起討論確定需求，確定要使用的工具，再確定好分工，完成後，再把各自的模組整合起來。我們各自的模組感覺都完成得挺順利的，但是最後整合起來卻不盡如人意，大家一起找 bug 找了好久。各個模組的介面啊規範啥的，我們在編寫的時候有注意，希望整合的時候不要出什麼么蛾子。現在回想起來，這樣還不夠，感覺還需要乙個專門測試的人員。各個模組沒有經過充分地測試，只是簡單地跑出了乙個成功結果，整合起來還是很容易崩的。找 bug 也不清楚具體是哪個模組的錯，找起來也就更心塞。模組化，單元測試，**規範，這些積木還是細緻點好。
對下一屆實踐的建議，當然是一定要選實踐啦，真是很難得的課程，選了不後悔系列，和其他的大作業完全不一樣呢。軟工的理論課感覺像職業規劃，還是實踐課好玩。對於要不要換隊員，我沒有離開隊伍，也認識新加入的成員，就沒有什麼特別的感受。希望能不是強制要求換隊員，而是允許申**入其它隊伍這樣自願的形式。初衷是模擬以後工作的真實情況，可我覺得沒什麼必要非要堅持。
萌芽階段、磨合階段、規範階段、創造階段都經歷過吧，因為大家本來就是低頭不見抬頭見的同學，前面的萌芽和磨合階段都很快，規範階段再確定一下規範，就到創造階段了吧。
通過一系列工具，流程，團隊合作，能夠在預計的時間內發布 「足夠好」 的軟體
有專案規劃/需求/設計/實現/發布/維護，有定時的進度發布 ； 而不是: 通過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄
這些團隊的 alpha 衝刺 和 beta 衝刺 可以證明的
並且通過資料展現軟體是可以維護和繼續發展的。
而不是 找不到源**，**無文件，**不能編譯，沒有task/bug 等專案的發展資料
這些團隊的 github beidouqixing 可以證明
個人作業 軟工實踐總結
這個作業屬於哪個班級 班級鏈結 這個作業要求在 作業鏈結 作業正文 部落格鏈結 作業要求 軟工實踐個人總結 在實踐鍛鍊上不管是技術熟練度還是工具熟練度都得到了很大的提公升，而在就業競爭力上只有微乎其微的改變，沒有質的變化。因為我們團隊裡沒有人有與企業對接的開發經驗，大家都是從頭開始摸索，走了很多彎路...
軟工工程實踐總結作業 個人作業
當初 對實踐專案完成後學習到的能力的預期 能夠深入了解什麼是框架，鍛鍊自己的大局觀。能夠合理融洽的參與到團隊配合中去，鍛鍊在開發專案的時候，應該如何溝通才能使進度最快，質量最高。養成自己寫 的時候一定要寫注釋的習慣！鍛鍊自己寫文件的能力 文件表述能力，能夠讓大家都能明白的文件 先明白要幹什麼，再去寫...
軟工實踐個人總結
開篇部落格時我對課程的目標和期待比較美好，現實的所學所得與其相去甚遠。工作量和脫髮量遠超預期.對程式設計工具和程式語言的學習有較大的提高，但技術積澱還是差很多。我菜是因為我興趣缺缺和憊懶吧。大三是個轉折點，大二之前對於程式設計的實操都是針對一點的 玩具程式 語言和工具的掌握非常片面。而大三的軟工課第...