福大軟工 · 最終做業 - 軟件工程實踐總結（我的）

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

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

答：對比目前所學所練所得，達到我對課程目標和期待的有：在本學期的軟工實踐，在小組中擔任開發組的成員，因此對於coding能力確定有所提高，因此計算機的專業技能、專業能力有必定的提高，回顧我對這門課程的指望，當初想經過這門課程接觸一些新的開發工具，學習一些新的東西，這些仍是達到了個人預期。另外本門課程更側重於軟件工程的學習，經過一學期的實踐，也提高了本身對於這方面的理解，除了協做能力的提高外，本學期在要求之下，規範的按照軟件工程的理念開發了咱們小組的項目。也算是一次成功的項目經歷。對於軟件產品開發的流程有更深的理解。這些都是計算機專業能力和就業競爭力的加強。可是多多少少也存在一些不足之處。在本學期的軟件工程實踐中，雖然說軟件開發中的規範性學習到了不少，但本身在開發軟件的過程當中，bug不斷，在解決這些bug時花費了大量時間，從這方面也看出了對於軟件測試的缺漏。以及一些軟件功能的砍去對於技術風險的分析不到位。本身做爲開發組成員對於開發過程當中成員之間交流也存在欠缺。

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

• 統計一下，你在這門軟件工程實踐中，完成了多少行的代碼；
• 軟工實踐的各次做業分別花了多少時間？（作一個列表）
• 哪一次做業讓你印象最深入？爲何？
• 累計花了多少個小時在軟工實踐上？平均每週花多少個小時？同時貼出開篇博客「你打算平均每週拿出多少個小時用在這門課上」的回答
• 學習和使用的新軟件；
• 學習和使用的新工具；
• 學習和掌握的新語言、新平臺；
• 學習和掌握的新方法；
• 其餘方面的提高。

答：

• 這門軟件工程實踐中共完成了大約四千多行的代碼

做業	時間 /分鐘
第一次做業 - 準備之——自我介紹	5
第一次做業	240
第二次做業 - 我的項目	1200
第三次做業 - 結對項目1	500
第四次做業 - 團隊展現	10
第五次做業 - 結對做業2	3150
第七次做業 - 需求分析報告	160
第八次做業 - 課堂實戰 - 項目UML設計	600
團隊現場編程實戰（抽獎系統）	600
Alpha 衝刺	3000
第十次做業 - 項目測評	380
第十一次做業 - Alpha 過後諸葛亮	330
BETA 版衝刺前準備	10
Beta 衝刺	680
第十二次做業 - Beta答辯總結	400
最終做業 - 軟件工程實踐總結	200

• 第二次結對做業讓我印象最深入,在第一次結對做業原型設計後，第二次結對做業實現了第一次立下的大部分flag，第二次結對做業的時間充足，和隊友下了不少的功夫，從分工到代碼規範的制定，實現工具、數據結構的抉擇，到測試樣例的編寫，都是在大量討論下的結果，是本學期軟工實踐首次很是規範地完成一個項目，雖然是一個小項目，可是完成的時候成就感仍是很知足的。
• 大約累計花了一百九十小時在軟工上，平均每週應該有十四個小時

• 第一次做業的回答：

  答：對於本門課程，首先這必定是一門實踐性很強的課程，須要付出不少的努力，個人期待是從這門課程的學習以後，本身的專業技能素養能有較大的提高。平均每週拿出十幾個小時來用在這門課程上。博客A[1]的做者說到學長給的建議，「把天天把要作的事情分紅ABCD四類：A-緊迫且重要；B-重要不緊迫；C-緊迫不重要；D-不重要不緊迫。」，我贊同他的觀點，這挺適合於強迫症，可是我有困惑，這樣方案的實行真的利於堅持嗎？在我實踐中，我仍是以爲最適合本身的方法必定要本身不斷調整才行。我相信本身的目標必定會實現的。

• 學習和使用的新軟件：Android Studio、墨刀原型開發工具、Qt、eclipse等
• 學習使用的新工具：阿里巴巴矢量圖標庫、福步取色器、Snipaste、process on等
• 學習和掌握的新語言、新平臺：java 、python
• 學習和掌握的新方法:NABCD競爭性需求分析框架、SWOT框架分析、原型開發、軟件測試策略等

• 其餘方面的提高:coding能力，文檔撰寫能力，軟件需求分析、軟件測試等等方面的能力

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

答：

我的做業：

• 此次軟工我的做業的項目是寫一個詞頻統計，本身在寫的過程當中bug不斷，每每調試的時間是寫完代碼的好幾倍，思路構思不清晰急於快速完成致使了這樣的結果，因此我的做業是對於我的實戰能力的一個測試，能發現本身的不少不足，在動手敲代碼以前，先完成好總體的框架構思，再動手。ps：寫個詞頻統計仍是頗有用的

團隊項目：

• 溝通賽過一我的盲幹，有時候一個下午解決不了的問題，請教一下隊友幾分鐘就解決了，對於安卓自定義相機拍照卡頓的問題，在隊友的幫助下很快就解決了（固然不建議不斷地請教隊友，仍是要注重本身的思考）
• 合理的分工能發揮每一個人的最大能力，因此在剛剛定分工的時候應思考是否真的適合本身，或者本身想學哪些方面。例如：此次軟工實踐本身主動選擇了開發的工做，也學到不少，鍛鍊到不少。
• 文檔的重要性。此次軟工實踐，咱們團隊剛開始沒用很重視這些，尤爲是到後面的開發，不少都要去翻閱前面的文檔。

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

1. 你有什麼想建議、告知和期許想要告訴他們呢？
2. 特別地，特別地，下一屆要不要中途換隊員（強制的、完全的從一隊換到另外一隊）？假設依舊是一個90+人數的大班
3. 身在一個格外大的班級，競爭強勁，你認爲一個組的人數應當在多少比較合適？
4. 我的/結對/團隊做業應該控制在怎樣的規模？
5. 這學期下來，你最感謝的人是誰？有什麼話想要對TA說呢？

答：（對於下一屆的建議）

• 在軟工開始的招募階段，選擇本身感興趣或者有涉及本身想學習的方面的隊伍。但願大家都能度過一個愉快充實的軟工實踐。（這也是很總要的一個項目經歷）
• 不要中途換隊員，我以爲本身付出就要堅持下去，對於全部人都同樣，畢竟之後出去工做，也不是事事都能順心，每一個項目都按照本身的期許推動，因此要堅持，堅持下去必定有收穫的，作好本身應該作的事。
• 人數不能過多，也不能太少，太少的話每一個人的工做量太大，若是人太多的話，相應的也增長了溝通的成本（時間資源）
• 我的做業最好能在小一點的規模又不失實用性。，團隊做業最好不要弄太大規模，量力而行，牛不要吹太大了。
• 本學期軟工最該感謝柯逍老師，在這麼屢次實踐中給咱們組提了不少實用的建議和不足之處。

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

答：

• 萌芽階段：團隊剛剛確立，隊員之間還須要磨合，各自的職責基本肯定，對其餘成員的長處還有不少不了解的。溝通交流肯定主題。有些倉促。
  
• 磨合階段：溝通逐漸增長，對彼此有了更多瞭解，溝通交流更多了。
• 規範階段：確立了編碼規範（有了良好統一的編碼規範以後的合做仍是比較順暢的）
• 創造階段：目標明確，爲之努力，創造出真正像樣的產品，（雖然和理想仍是有很大的差距的），可是你們好像仍是很知足的。

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

1. 研發出符合用戶需求的軟件必須公開發布，有實際的用戶，必定的用戶量和持續使用量 （3 天后能保持10 - 100個用戶）；而不是: 作沒有用戶使用的軟件
2. 經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」的軟件有項目規劃/需求/設計/實現/發佈/維護，有定時的進度發佈 ； 而不是: 經過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄
3. 而且經過數據展示軟件是能夠維護和繼續發展的。而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料
4. 對着這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，本身若是去企業面試 ，這些常見的問題是否都能回答，並在此總結。

答：

這是咱們組的軟件產品：

咱們的產品有公佈公開，可是因爲資金的缺少（須要一個雲服務器），因此並無持續的用戶使用量。

• 
  
  

• • 有規範的文檔（軟件規格需求說明書）
• • 有項目的管理（Github倉庫）
• • 合理的分工合做
• • 有按期的進度發佈，和團隊之間的溝通交流
• • 雖然咱們有在deadline前熬夜，可是如柯老闆說的「deadline是第一輩子產力」，咱們的產品不是熬夜胡亂拼湊出來的，是在團隊充分溝通合做的前提下製做的。
• 源代碼
• 高正確率：深度學習店鋪識別算法結合咱們軟件的AR功能，是通過咱們大量測試的前提下的，正確率在（在數據庫內）無遮擋的狀況下能夠99%，人爲故意遮擋（遮擋40%一下）的狀況下準確率能夠達到90%。

• 基礎、進階、應用開發拓展、安全基礎、性能基礎。涵蓋了不少方面。對於一些問題本身感受仍是沒有問題的，可是真真的項目工做須要的優秀的開發人員，要具有的不只僅是coding能力，對於一些應用開發拓展、安全、性能等方面也要有充分的認識，在我看來，本身還有許多不能回答或者不能很好地回答，因此在接下來的時間還要好好地鍛鍊本身，朝着優秀開發人員的方向努力。工程的思惟是很重要的。嚴謹求實，增強本身的專業素養。理論知識，更全面的看問題。

6、（選作）、閱讀軟件工程中關於代碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合本身的實際作一個閱讀筆記（例如，本身寫的代碼質量如何，是否是一個大泥球，如何衡量本身代碼的質量）？從如下參考論文中選擇一篇或若干篇：

答：
一個優秀的開發人員的coding能力的衡量很大一部分取決於他的代碼質量。現代軟件工程中的一個著名猜測是外部質量特徵與內部質量特徵相關。源代碼的度量爲評估其質量提供了有用的信息，在必定程度上能夠預測外部系統質量特徵，如可維護性、可靠性、可擴展性和可移植性。

開源項目應該該努力提升代碼的可維護性

• 像柯老闆說的同樣，好的項目纔開源，因此開源項目對軟件代碼質量是很注重的。

• 開源軟件開發的缺點包括缺少完整的文檔或技術支持
• 開源軟件的代碼維護性會隨時間的惡化
• 代碼行數(LOC)能夠度量程序代碼的物理大小，不包括空行和註釋
• MI公式的係數：MI經過考慮代碼的大小、複雜性和自描述性來度量可維護性。MI可能會由於添加到現有源代碼中的新代碼(因爲錯誤修復或其餘糾正措施)而改變。然而，因爲MI是基於平均值的，它相對獨立於這些變化的絕對值，能夠用來比較不一樣大小的系統
• 將開源的可維護性度量與閉源軟件的可維護性度量進行比較，或者只是觀察這些度量的趨勢，並對代碼質量的改善或惡化進行推測。由於從許多不一樣的度量標準中得到關於可維護性的單一描述是很困難的。考慮代碼的大小、複雜性和自描述性來度量可維護性。
• 代碼質量須要監控和改進

• 提高自我：按期傳代碼到github上，在每一次項目開始前先建好項目倉庫，制定好代碼規範，保證高代碼質量的前提下進行開發，而不是一個大泥球。監控和改進本身的代碼質量，經過一系列的評價指標分析的本身代碼存在的質量問題，加強軟件的可維護性、可靠性、可擴展性和可移植性等等。

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

• 帥氣的摩爾紋解決：
  
• 9我的的夜個人心應該放在哪裏？
  

參考文獻：

[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