軟體工程實踐總結

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

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

創新能力：這一項能力其實是我在課前沒有考慮到的。從個人、結對程式設計作業，到現場程式設計、團隊作業，想出了許多的點子。發現自己還是蠻享受頭腦風暴的過程。從個人和結對的創新點構想，到現場程式設計的新技術應用、團隊展示的idea，再到智能分析的資料處理架構，都是頭腦風暴的産物。把已有知識加工成新的東西，再把它實作，其實是這門課裡最讓我興奮的地方。

文檔能力：在團隊作業中，作為文檔、部落格的負責人，和隊友們撰寫的選題報告達到了五十多頁，需求報告達到了八十多頁，并且獲得了柯老師的認可，兩次登上了觀光車。可以說，文檔能力又上了一個台階。

程式設計能力：雖然完成了幾次程式設計作業，也完成了團隊作業了一個功能，但是感覺程式設計能力還是不太夠。

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

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

完成了以下的程式設計任務

任務	代碼數
個人作業詞頻統計	340
結對程式設計爬蟲代碼	260
團隊作業智能分析	1500
總計	2100

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

作業名	時間(min)
第一次作業	400
	1400
結對作業	2310
團隊第一次作業	240
結對作業二	2800
團隊選題報告	1800
課堂實戰	600
需求報告	1355
現場程式設計	1020
ALPHA	700
福大助手項目測評	420
BETA
	14545

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

結對程式設計的作業讓我印象最深刻。這次作業，為了解決一個bug，我見到淩晨五點半的福大，然後兩個半小時以後我又去上課了。淩晨四點的時候，正巧遇到了問題，打算給助教留個言，沒想到雨勤學姐一個秒回。并不是為了趕ddl而熬夜，而是代碼正好有了的進展，進着進着就

進到了四點多，吐槽這門課的同時，也不免感歎，有時候還是有點意思的。

4、累計花了多少個小時在軟工實踐上？平均每周花多少個小時？同時貼出開篇部落格“你打算平均每周拿出多少個小時用在這門課上”的回答

累計花了 14545分鐘，243個小時，相當于不吃不喝做了10天，平均每周808分鐘，13.5個小時。

真是觸目驚心啊。

當初的回答

我覺得很難用一個具體的時間來說要花多少時間在這門課上，就像說：我要花10個小時在這門課，或者說花30個小時在這門課，有一種空頭支票的感覺。在不知道每次作業量大小的情況下，10個小時可能多了，30個小時也可能少了。隻能說，我願意把這門課的優先級盡量往前提，在上面花費我的時間和精力。

我用總時間除以18周，算出是13.5小個小時。平均每周這個尺度其實不太科學，因為有時候每周的工作量會非常大，總之，工作量還是很大的。

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

• 墨刀
• Eclipce
• StarUML
• ProcessOn
• Python

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

• Visual Studio中的性能分析、代碼覆寫率、單元測試

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

• 更加熟悉 C++
• 更加熟悉 Python
• 使用了vs中的性能分析、代碼覆寫率的功能，發現十分強大

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

• 單元測試
• 代碼覆寫率
• 代碼性能分析
• Python爬蟲知識
• 将新技術應用于實踐
• 有更好的行動力

9、其他方面的提升。

• 個人方面，在文檔、設計、展示方面的能力得到鍛煉
• 提升了處理大量并行事件的能力。
• 學會了熬夜肝事情，不把事情做完不罷休（希望未來可以保留後半句，減少前半句的的發生）
• 将新技術結合進軟體産品，做出優化改進。

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

• 時間的安排對我來說是一個永遠都需要提升的能力————特别是從理論上可排程的時間已經小于總任務所需時間的時候。
• 無論個人還是團隊項目，總是想做得又快又好，雖然快字目前，但每次還是一不小心變成了好字當頭，雖當下喜不自勝，但在事情過後，站在其他堆積如山的事情面前，總是不免心生悔意。
• 熬了這麼多晚，掉了那麼多頭發，更光亮的頭總是對時間安排多了一些更多的了解。
• 熬夜會猝死，但是早起比較不會，也就有了早上5點多起來做軟工的經曆。
• 又快又好，在鄰近deadline之前完成，可以保證快，但不能保證好，而且有時候快也未必能保證。又好又快，在ddl前多天完成，可以保證好，很多情況下，做得也不慢，也留給自己更多疊代和修改的時間。
• 鄰近deadline完成任務是一種突發事件，容易打亂整體的時間安排，而提早多天，便于時間的安排，事實上，也能在合理的安排下做到省時。在一個提前多天的完成任務的團隊中，我深深感到提前完成的優勢。

三、對下一屆實踐的建議，或者對于開學初的你，對于大一的你，對于開學初的我，對于同期的TA們，對于後來的學弟學妹：

1）你有什麼想建議、告知和期許想要告訴他們呢？

不要低估軟工實踐的作業量，軟工實踐的作業量有下限，但是無上限。可能會花費大量的時間，但這取決于對這門課的定位。如果定位在績點上，這兩學分的課對績點的投入産出比實在太小，不值得投入太多的時間去做這門課。但這門課可能是唯一一門如此非傳統的課程，如果認真對待，它會極大占用你的時間，但也同時逼會你如何處理大量并行的事情；它會讓你長期脫離舒适區，但也從各個角度磨練你的能力。

2）特别地，特别地，下一屆要不要中途換隊員（強制的、徹底的從一隊換到另一隊）？

假設依舊是一個90+人數的大班

可以鼓勵，但是沒必要強制。如果一個組經過較長時間的磨合，氛圍很好、幹勁很足，很有可能被強制換人打破。

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

十人左右。組數太多課上展示時間縮短不易控制品質。人數太少人均工作量太大難以完成，人數多則需要通過合理分工配置設定任務。實際上，即使是6-7人一組，也出現了隻有1-2人幾乎完成整個軟工的情況。問題的關鍵是要合理分工。

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

不過多地增加額外要求。附加要求要有，但是太多，太頻繁的出現，會大量擠占時間，導緻課程完成困難，也反作用于軟工。

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

四、分析一下自己所處的團隊。

軟體工程實踐是大學裡少有的認真的團隊協作經驗。《建構之法》上說團隊的發展有幾個階段，你的團隊都經曆過麼，最後到達了“創造”階段了麼？（參考《建構執法》第17章 人、績效和職業道德）

《建構之法》團隊發展階段

• 萌芽階段：就像小苗破土而出，柔弱但充滿希望。團隊成員剛剛接觸到團隊的宗旨，同時很有可能剛剛互相認識。團隊的目标沒有真正達成一緻，而成員則非常依賴于團隊上司的指導。
• 萌芽階段： 應該在讨論需求的時候，是處于萌芽階段，大家剛剛互相認識，但是還不确定要做什麼，是以就靠一次一次的會議推動。

• 磨合階段：就像一個人的青少年時期，充滿了對個人、同伴和團隊的疑惑和沖突。團隊無論大小都要克服困難，傳遞結果，大家不得不認真的面對問題，開展讨論了。這些沖突不一定都是技術問題也許是關于角色、職責、互相關系。甚至是各自性格、文化的沖突。不少人都想成為某個領域的“擁有者”（在軟體項目中，誰負責哪個方面，每個方面要怎麼做，等等）。同時也有一些人會以不同的方式進行挑戰。
• 磨合階段： 偶爾出現摩擦的情況也是存在的，原則就是對事不對人，大家都是明理人，也不會因為一些摩擦而不快。總之隻要是為了團隊，磨合都不是事。

• 規範階段：從磨合階段畢業進入到規範階段的團隊成員們就角色、職責定義和流程都取得了比較一緻的意見。這一時期團隊具有以下特點。

1. 團隊的工作流程和工作的方式得到大家的認可。成員之間互相更加了解，欣賞各自能力和經驗，工作中互相支援。
2. 上司主要扮演促成者和鼓勵者的角色，有能力的成員也分擔了一定的上司職責，并自然的獲得大家的尊重。
3. 随着項目的開展，一些成文的或不成文的規則逐漸建立起來了。
4. 作為一個整體，團隊要做什麼、不做什麼，都更加明确。團隊的信心更足，和其他團隊打交道更有底氣。

• 規範階段： 後期團隊慢慢規範，因為團隊内部氛圍很好，成員之間互相更加了解，一些成文的或不成文的規則逐漸建立起來，是以大家都更加明确，團隊的信心更足。雖然不敢說完全規範，但是某些方面還是達到了的。

• 創造階段：經曆以上三階段後團隊可以創造一些有意義的東西，并不是所有團隊都能到達這一階段。擁有以下特點：

1. 團隊知道為何而戰，并将注意力幾種到如何創造、實作目标上。
2. 高度自治，不再需要上司的時時教誨與介入。不同意見仍會出現，但成員都以一種積極的心态和方式解決。互相支援，互相依賴，并保持各自的靈活性。

• 創造階段：也許某時候偶爾能達到這個階段，偶爾能閃現出一些創新的點子，但是沒有辦法完全達到。

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

通過資料展現軟體是可以維護和繼續發展的。

而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料

軟體一定是可以也需要維護和繼續發展，就像軟工課本開頭寫到的硬體軟體的損耗模型，軟體的理想曲線是到後期損耗越來越少。而實際上，可能會出現劇烈的波動，需要有健全的SCM來做做好更新管理。以一項intel的大型開源軟體為例：

https://www.dpdk.org/

到18年為止，有很多的版本更新，已經維護和發展了很久。以下是更新疊代的版本。

并且有大量的文檔說明，詳細解釋。

并且在每個版本，都有詳細的更新說明

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

閱讀了

pen Source Software Development Should Strive for EVEN GREATER CODE MAINTAINABILITY

這篇論文是通過對六百萬行代碼的追蹤，記錄如何維護和不斷疊代開源的代碼。

對傳統不開源軟體和開源軟體進行了比較：

随着版本的不斷疊代，傳統的不開源軟體的MI會逐漸降低，并且低于開源軟體的MI

并且發現：

1. 開源軟體的品質有時要比不開源的品質要好
2. 後續版本的變化有時對軟體的影響很大，要通過一些工具來幫助代碼結構分析
3. 要對項目可能發生的問題做好預案，因為OSS也會老化，要做好一些預防性的維護。

其實對于我們的軟工項目也是如此，如果疊代到深入的階段，也必須要做好一些預防措施，做好軟體監控。如果有更多使用者使用了，更需要對一些可能遇到的問題，做好預案，防患于未然。

參考論文文獻：

[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