軟件工程實踐總結（我的）

時間 2019-12-10

標籤軟件工程實踐總結我的简体版

原文原文鏈接

痛並快樂着——軟件工程實踐總結（我的）

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

1）對比開篇博客你對課程目標和期待，「但願經過實踐鍛鍊，加強計算機專業的能力和就業競爭力」，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，爲何？

一學期走來，感受仍是學了不少東西的。從剛開始聽到打代碼就頭疼，到如今可以獨立地完成一些有挑戰性的我的做業，成就感仍是滿滿的。雖然到如今我仍是但願未來可以少寫代碼，但經過一學年的學習，我也知道，能少打代碼意味着已經有了必定的代碼基礎。並且從事這一行業，不可能不打代碼。所以，軟工實踐以來的苦逼和痛，或許會在未來成爲意想不到的助力。css

學到如今也有不少不足，好比當時但願能作出一個很耐看的界面，後面也只是草草了事。理想和現實的差距，每每體如今能力的不足和人的惰性身上，也但願之後可以精益求精，對任何事情都能交出完美的答卷。還有很不足的地方，就是到如今都沒能習慣使用github，以及代碼規範。html

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

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

做業序號	代碼量	備註
1	300	我的做業-詞頻統計
2	200	第二次結對做業
3	1500	Alpha衝刺階段
4	100	團隊做業-項目測評
5	300	團隊現場編程-抽獎系統
6	1000	Beta衝刺
總計	3400

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

做業名稱	耗時(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

三、哪一次做業讓你印象最深入？爲何？

應該是第一次我的做業吧。那是我第一次接觸到這麼龐大的代碼量，以及要學這麼多的的新東西，單元測試，github的使用等等。這些都讓我感受頭疼和不適應。並且不一樣於結隊做業，我要一我的完成整個做業，其中不乏我很是不擅長的部分。雖然最後得分不高，可是我從中也收穫了不少寶貴的經驗，算是痛並快樂着吧。前端

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

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

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

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

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

github：學了，可是並無習慣運用

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

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

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

用例圖：基於場景來考慮分析問題，更有助於咱們瞭解需求
思惟導圖：用思惟發散的理論，基本覆蓋了要作的全部任務集，用圖來表示清楚美觀

九、其餘方面的提高。

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

2、寫下屬於本身的人月神話——我的或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析

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

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

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

我但願他們能學會合理分配本身的時間。軟工實踐的確是一門能夠學到不少東西的課，可是同時也意味着佔據了不少課餘時間，若是不能妥善處理，那麼極可能一事無成。我也但願他們可以作到咱們這屆作不到的東西，可以作出真正能面向市場的軟件。python

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

我認爲能夠有中途換隊員的操做，可是不必強制。由於有的人可能並不能適應這種被迫換隊的操做，雖然在社會中可能會出現這樣的狀況，也的確有鍛鍊的效果。但假若由於這種緣由而完成不了軟工實踐（下學期他們仍是必修）的話，這就是一件很尷尬的事情了。git

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

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

（4）我的/結對/團隊做業應該控制在怎樣的規模？面試

軟工真是個神奇的存在。在作做業的過程渴望做業少點，但到了如今又以爲這些做業量是合理的，也的確可以鍛鍊人。但仍是但願可以儘可能給學生足夠的自主性，不要過度影響大學的其它精彩的組成部分。

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

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

4、分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了「創造」階段了麼？（參考《構建執法》第17章人、績效和職業道德）

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

5、怎樣證實你學會了軟件工程？

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，更是爲從此擴充功能打好基礎。這不只須要嚴格的代碼規範和註釋，也須要有效的配置管理，這方面咱們團隊作的仍是比較粗糙的。同時我也發現，如今百度翻譯作的真的不錯，翻譯出來的效果基本和原意差的不是不少。固然，對一個程序員來講，學會看英文論文也是必須的，這個還須要增強學習。