痛并快樂著——軟件工程實踐總結（個人）

一、請回望暑假時的第一次作業，你對于軟件工程課程的想象

1）對比開篇博客你對課程目標和期待，“希望通過實踐鍛煉，增強計算機專業的能力和就業競爭力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，為什么？

一學期走來，感覺還是學了很多東西的。從剛開始聽到打代碼就頭疼，到現在能夠獨立地完成一些有挑戰性的個人作業，成就感還是滿滿的。雖然到現在我還是希望將來能夠少寫代碼，但通過一學年的學習，我也知道，能少打代碼意味著已經有了一定的代碼基礎。而且從事這一行業，不可能不打代碼。因此，軟工實踐以來的苦逼和痛，或許會在將來成為意想不到的助力。

學到現在也有很多不足，比如當時希望能做出一個很耐看的界面，后面也只是草草了事。理想和現實的差距，往往體現在能力的不足和人的惰性身上，也希望以后能夠精益求精，對任何事情都能交出完美的答卷。還有很不足的地方，就是到現在都沒能習慣使用github，以及代碼規范。

2）總結這門課程的實踐總結和給你帶來的提升，包括以下內容：

1、統計一下，你在這門軟件工程實踐中，完成了多少行的代碼；

作業序號代碼量備注

1	300	個人作業-詞頻統計
2	200	第二次結對作業
3	1500	Alpha沖刺階段
4	100	團隊作業-項目測評
5	300	團隊現場編程-抽獎系統
6	1000	Beta沖刺
總計	3400

2、軟工實踐的各次作業分別花了多少時間？（做一個列表）

作業名稱耗時(h)做了啥

軟工實踐第一次作業	2	學了makedown格式，看看博客，寫寫博客
個人作業-詞頻統計	20.5	學習單元測試等新知識，復習c++，問同學，
第三次作業-結對作業（原型設計）	8	學習并使用Axure RP 8
第四次作業 - 團隊展示	1	交博客，增加個人部分
第五次作業 - 結對作業2	16	用python爬數據，實現一些附加功能
第六次作業 - 團隊答辯	0.5	交博客，增加個人部分
項目UML設計	5	學習ProcessOn、UML設計，繪制用例圖
需求分析報告	10	用墨刀設計原型
Alpha 沖刺	80	原型的重新設計，前端界面的設計，AR技術的研究，拍攝數據集，標數據集，做PPT，研究特效，詳見各次沖刺學習進度條，寫博客
團隊現場編程實戰（抽獎系統）	7	python學習和熟悉，聊天記錄的分析和挖掘
項目測評（團隊）	6	上臺答辯，做ppt，采訪和測試部分工作
Beta 沖刺	10	對前端界面進行優化，標數據集，拍數據集，參與PPT的制作
個人總結	4	寫博客
總計	190

3、哪一次作業讓你印象最深刻？為什么？

應該是第一次個人作業吧。那是我第一次接觸到這么龐大的代碼量，以及要學這么多的的新東西，單元測試，github的使用等等。這些都讓我感覺頭疼和不適應。而且不同于結隊作業，我要一個人完成整個作業，其中不乏我非常不擅長的部分。雖然最后得分不高，但是我從中也收獲了很多寶貴的經驗，算是痛并快樂著吧。

4、累計花了多少個小時在軟工實踐上？平均每周花多少個小時？

• 如果算上站立會議時間和課程答辯時間的話，大概在210小時吧
• 軟工從開學第一周到十七周基本結束，共17周，平均210/17=12.3個小時

5、學習和使用的新軟件；

• visual studio 2017 ：開發c++控制臺程序，第一次個人作業使用
• Android studio 3.0.0 ：andoid開發基本工具，用來做界面
• Axure RP 8：原型設計
• Sublime Text 3：使用python爬網站數據
• PowerPoint：做ppt
• Typora：群里老哥推薦，用來makedown的工具

6、學習和使用的新工具；

• github：學了，但是并沒有習慣運用

7、學習和掌握的新語言、新平臺；

• java：從0開始，還好可以向身邊同學學習
• python：爬爬數據，畫畫圖，需要什么功能學什么
• github：download代碼，用來學習
• Process On：一個在線畫流程圖/uml圖等的平臺，在需求分析階段尤其好用

8、學習和掌握的新方法；

• 用例圖：基于場景來考慮分析問題，更有助于我們了解需求
• 思維導圖：用思維發散的理論，基本覆蓋了要做的所有任務集，用圖來表示清楚美觀

9、其他方面的提升。

• 除了技術硬能力方面，和同學的團隊合作也提高了我的團隊協作能力和交際能力；
• 每次在deadline前肝博客提高了我的熬夜能力；
• 答辯和博客提高了我的溝通能力和瞎編能力；
• 碰到不會的部分提高了我的學習能力和抗打擊能力......
• 學習這門課真是好處多多，學弟學妹們一定要選柯老師（劃重點！）

二、寫下屬于自己的人月神話——個人或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析

• 第一次個人作業的時候，只有痛苦，沒有快樂。那種直到deadline，卻始終交不出東西的感覺，是很難受的。現在想來，失敗的原因除了代碼經驗過少之外，對軟工不夠重視（其實很重視了，但是沒想到還不夠重視）是更主要的原因。沒有付出足夠的努力和時間，自然不能保證得到滿意的結果。
• 結對作業的完成還是比較流暢的。因為我c打的不好，所以主體功能還是由隊友完成的。我負責用爬蟲爬數據，也學到了一些有用的技能。比較可惜的是最后程序似乎有點小bug，得分點并沒有全部得滿，還是有點可惜的。
• 團隊作業過程中真的學到了很多，算是把軟件工程理論課所學到的東西幾乎都能付諸實踐。不止是技術上的，還有答辯能力和團隊協作能力。因此，假如你經得起軟工實踐的挑戰的話，還是能從中受益頗多的。

三、對下一屆實踐的建議，或者對于開學初的你，對于大一的你，對于開學初的我，你有什么想建議和告知的呢？對于后來人的期許。 特別地，特別地，下一屆要不要中途換隊員？

（1）對下一屆學弟學妹們（和開學初的我）的建議和告知：**

我希望他們能學會合理分配自己的時間。軟工實踐的確是一門可以學到很多東西的課，但是同時也意味著占據了很多課余時間，如果不能妥善處理，那么很可能一事無成。我也希望他們能夠做到我們這屆做不到的東西，能夠做出真正能面向市場的軟件。

（2）特別地，特別地，下一屆要不要中途換隊員（強制的、徹底的從一隊換到另一隊）？ 假設依舊是一個90+人數的大班

我認為可以有中途換隊員的操作，但是沒必要強制。因為有的人可能并不能適應這種被迫換隊的操作，雖然在社會中可能會出現這樣的情況，也的確有鍛煉的效果。但倘若因為這種原因而完成不了軟工實踐（下學期他們還是必修）的話，這就是一件很尷尬的事情了。

（3）身在一個格外大的班級，競爭強勁，你認為一個組的人數應當在多少比較合適？

8-10人吧，我覺得按這學期的人數劃分就很合理了。真的想完成一個比較完善的軟件，4-5人是遠遠不夠的。

（4）個人/結對/團隊作業應該控制在怎樣的規模？

軟工真是個神奇的存在。在做作業的過程渴望作業少點，但到了現在又覺得這些作業量是合理的，也的確能夠鍛煉人。但還是希望能夠盡量給學生足夠的自主性，不要過分影響大學的其它精彩的組成部分。

（5）這學期下來，你最感謝的人是誰？有什么話想要對TA說呢？

喜源同學，我的結隊隊友和團隊隊友。到了計算機以來，很多實踐基本都是和他組隊，而且說實話，他帶我飛的次數會比我帶他要多很多。最想對他說一句由衷的謝謝。還有說過請他吃飯的事情一定會兌現諾言的。

四、分析一下自己所處的團隊。軟件工程實踐是大學里少有的認真的團隊協作經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過么，最后到達了“創造”階段了么？（參考《構建執法》第17章 人、績效和職業道德）

• 萌芽：團隊的起源源于隊友暑假打的一個比賽，既然比賽有一個成功的算法雛形，我們當然愿意參與其中。知道這個團隊的組成還是很開心的，因為很多都是以前聽說的學霸，自然而然地就以為可以在里面舒舒服服地被帶飛。可惜在軟工實踐中，這是不可能的，想要得到好成績，就要付出努力。
• 磨合：剛開始的團隊磨合還是會有一些小問題的。開始的幾次會議簡單確定了接下來的方向，在一次決定分工的群投票中，由于選擇的太晚。最后迫于無奈被分入的開發組。但想到大家基本都是0基礎，都得從頭開始學，也沒什么怨言。后來的合作基本流暢，當然也出現過因為貢獻度分配的問題而產生爭執的情況。我覺得這是很合理的，并不是一件壞事，理越辯越明，這會讓我們團隊合作更加緊密。
• 規范：這大概是我們團隊目前的現況吧。分工明確，責任和協作人清晰可查。組長的統籌也很合理，并且具有執行力。當然，在代碼上的規范還是遠遠不夠的。
• 創造：現在團隊還沒有到創造的階段。每個人做的基本都是自己的工作，很少有個人能夠在各個模塊都有一定貢獻，并提出創造性的想法。整個團隊雖然有創造力，但是遠遠稱不上一個創造階段的團隊，我們也沒有能力去執行我們的創造性想法。

五、怎樣證明你學會了軟件工程？

1）研發出符合用戶需求的軟件

我們團隊開發的產品是面向大學生使用的，現在暫未投入市場，但經過我們小組內部使用和前期投放的問卷調查，這一產品還是比較受市場歡迎的。

2）通過一系列工具，流程，團隊合作，能夠在預計的時間內發布 “足夠好” 的軟件

我們隊用燃盡圖等手段，定時查看每個隊員的“生產進度”。采用原型設計模型，擁有良好的團隊協作，足夠保證能在預計的時間內發布“足夠好”的軟件。

3）并且通過數據展現軟件是可以維護和繼續發展的。

我們團隊有足夠詳細的文檔說明和源碼，易于維護和繼續發展。
補充一下圖片：

4）對著這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，自己如果去企業面試，這些常見的問題是否都能回答，并在此總結。

大部分都不能回答，看來我的專業水平離一個程序員的標準還是遠遠不夠啊。

六*（選做）、閱讀軟件工程中關于代碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合自己的實際做一個閱讀筆記（例如，自己寫的代碼質量如何，是不是一個大泥球，如何衡量自己代碼的質量）？從以下參考論文中選擇一篇或若干篇：

論文名：Open source software development should strive for even greater code maintainability

引用：（百度翻譯后的）

隨著年齡的增長，預計OSS項目會有類似的行為是很有道理的：OSS方法將以與CSS相同的方式產生遺留系統。因此，OSS系統也需要適當的重新設計操作。換句話說，預防性維護可能是OSS支持者必須考慮的第三種維護類型。需要更多的實證分析來鞏固這項研究的發現。我們將繼續監控這些項目的質量，并將我們的分析擴展到其他OSS項目，這些項目預先發送了有趣的特性，并允許與CSS開發進行比較。但是，從OSS系統用戶感知質量的角度來整合OSS質量的結構視圖是非常重要的。

雖然簡單地瀏覽了一遍，但是并沒有很透徹地理解文章的意思。本文著力于oss與傳統css的比較，多次提到了可維護性的概念。軟件工程中也反復提到可維護性的概念。從可維護性的角度來看，不止是能更容易地發現bug，更是為今后擴充功能打好基礎。這不僅需要嚴格的代碼規范和注釋，也需要有效的配置管理，這方面我們團隊做的還是比較粗糙的。同時我也發現，現在百度翻譯做的真的不錯，翻譯出來的效果基本和原意差的不是很多。當然，對一個程序員來說，學會看英文論文也是必須的，這個還需要加強學習。

七、個性發揮，包括圖文、照片和創意等

團隊的第一次合影，希望我們團隊能保持初心，始終如一。

不知道說些啥，那就新年快樂（期望考試高分）吧>_<

轉載于:https://www.cnblogs.com/dldr/p/10197957.html

總結

以上是生活随笔為你收集整理的软件工程实践总结（个人）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。