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

軟件工程實踐總結

1、回望第一次做業中對軟件工程實踐的想象

1.對比開篇博客你對課程目標和期待，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，爲何？

• 開篇博客的期待(第一次博客連接)

• 但願能經過這門課程鍛鍊本身的項目開發能力，幫助本身較爲熟練地掌握一些開發工具以及思惟。
• 每週平均拿出六個小時左右吧，以後能夠根據實際狀況調整。

• 達到期待的部分

  通過了此次軟工實踐本身的項目開發經歷能夠算是從無到有了（若是不考慮以前的數據庫實踐），學習了python的相關語法知識以及運用，接觸了相應的IDE——pycharm。同時跟着組內的幾位大佬進行學習也提升了本身的編程思惟，學習了一些編碼過程當中debug以及優化的小技巧。

  至於每週的學習時間簡直是徹底超出期待啊，這門課有着和它2學分徹底不對等的學習時間，固然也許是我本身太菜了。

• 存在不足的部分

  其實整個產品的開發仍是靠着組內的幾位大佬，本身有能力參與編碼的部分仍是較爲有限的，這方面來講仍是比較惋惜吧，也辛苦組內的各位大佬不嫌棄我這樣的小菜鳥。

2.總結這門課程的實踐總結和給你帶來的提高

• 軟件工程中完成的代碼數

  • 總代碼數

    第N周	累計代碼（行）
    15	1380

    參考我的的學習進度條能夠了解到總共的代碼行數是1380

  • 最終可用代碼數
    
    這裏使用了張揚在羣裏提供的代碼統計工具，能夠獲得最終可用的代碼約有543行

• 軟件工程各次做業的用時

  做業	投入時間（小時）
  第一次做業 - 準備	12
  第二次做業 - 我的項目	21
  第三次做業 - 結對項目1	22
  第四次做業 - 團隊展現	2
  第五次做業 - 結對做業2	41
  第六次做業 - 團隊選題報告	2
  第七次做業 - 需求分析報告	20
  第八次做業（課堂實戰）- 項目UML設計（團隊）	6
  Alpha 衝刺（包括總結和答辯）	60
  團隊現場編程實戰（抽獎系統）	6
  第十次做業 - 項目測評（團隊）	10
  Beta 衝刺（包括計劃和總結以及答辯）	12
  總計	214

  以上統計是結合學習進度條和其餘博客進行統計的，可能有一些偏差，時間太長真的回憶不清楚了

• 印象深入的一次做業

  必須是Alpha衝刺了，如今回憶起來仍是以爲蕩氣迴腸。組內的小夥伴們在Alpha衝刺的時候經常一塊兒約在活動室進行集體編程，咱們一塊兒踩坑一塊兒爬出坑，互相幫助解決編碼過程當中遇到的各類問題，這是之前歷來沒有過的經歷，給我留下了很是深的印象。一羣夥伴爲了共同的目標一塊兒熬夜一塊兒編碼是很是有趣的，這是極其珍貴的經歷。

• 累計花了多少小時，平均每週多少，貼出開篇博客打算平均每週拿出多少小時用在這門課上的回答

  根據學習進度條來看累計花了351個小時，平均下來每週花了21小時，具體的表格能夠參考以前博客的學習進度條。

  開篇博客的估計以下：

  • 每週平均拿出六個小時左右吧，以後能夠根據實際狀況調整。

  如今只能說仍是太年輕，以前根本想不到這門課須要話這麼多時間。

• 學習和使用的新軟件
  • PyCharm
  • Qt Designer
  • 墨刀
  • TeamViewer

• 學習和使用的新工具

  • 墨刀
  • TeamViewer
  • Qt Designer
  • 圖牀
  • islide
  • Leangoo
  • ProcessOn

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

  • python

• 學習和掌握的新方法

  • vs自帶的性能分析測試
  • 調用高大上的庫（人生苦短我選python）
  • debug時在關鍵位輸出臨時變量
  • 風騷的調試功能（其實還不是很會）

• 其餘方面的提高

  學會了和團隊成員進行溝通，提升了團隊協做能力。提升了抗挫能力......

2、屬於本身的人月神話

• 解決問題的方法要靈活變通

  這方面在第二次結對做業真的是吃了很多虧，當時本身用結構體鏈表來構建字典樹保存詞組和單詞。其實在編碼的過程當中就感受到這樣比較麻煩並且容易出錯，可是由於我的習慣沒有改變方法繼續死磕下去。結果最後代碼運行出現問題，並且反覆找了好久都找不出問題到底出在哪裏。一直到最後時間來不及了才改用map來解決問題，結果出乎意料的順利...

• 團隊交流要積極

  不能被動地等待PM下達任務或者等待和你結對的同窗來找你一塊兒打代碼。在參與到項目的過程當中必定要是積極的態度，被動接受任務對於本身和團隊都是很差的。在第二次結對做業中由於我和結對的同窗交流不夠致使最後實際的完成時間被壓縮了很多，而在團隊項目開發中其實團隊也存在由於過於依賴PM分配任務而出現的開發停擺。

• 多看多學多作

  你能夠菜，可是你必定不能所以不去嘗試。在團隊項目的開發中，我在開發經驗以及python的使用上都是一片空白，開發過程當中其餘的一些工具也都是以前從未接觸過的。爲了彌補這樣的自然缺陷我試着在學習文檔的同時跟着大佬觀摩編碼過程，同時請教問題，以後回到宿舍再模仿大佬的代碼和解決思路進行編碼，在這樣的過程當中我學到了許多新的知識。（在這裏很是感謝張揚大佬提供的幫助）。在看的過程當中學習到的東西要在腦中消化，以後付諸實踐。只有這樣看到和學到的東西才能真正化爲本身所掌握的。

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

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

• 在進行正式的開發以前必定要認真考慮開發中要使用的工具和語言，由於一旦開始開發以後不少東西就難以更改了，若是在開發過程當中更改工具或者平臺是很是痛苦的。
• 若是能夠的話不要選這個課？由於真的對菜鳥很是不友好。不過正經說的話這節課仍是可讓人學到不少東西的，不僅僅是開發產品的能力，還有演示、營銷、人際溝通等不少東西。
• 但願學弟學妹們能夠堅持下來吧。

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

• 換隊員進行少數幾回現場設計是能夠接受的，但若是指的是永久地強制更換到另外一隊，那麼我認爲是不合適的，這對於在有限時間內開發一個產品是不利的（雖然能夠幫助模擬真實工做場景中跳槽或者更換項目組的狀況）。

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

• 5個左右的話也許是不錯的人數安排，人數多的時候會面臨一些分工以及結果合併的困難。不如讓組多一些，百花齊放。

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

• 做業規模的話按照當前的規模其實仍是有點點偏大（參考2學分的話），不過整套流程走下來的話仍是對於理解軟件工程有很大幫助的。

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

• 張揚吧。在開發過程當中整個後端幾乎都是張揚在領頭。由於是第一次接觸產品開發還有python，因此在過程當中碰到了很多問題，可是每次問張揚他都很耐心地解答。

4、分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了「創造」階段了麼？

萌芽階段

經歷過，團隊剛剛組成的時候其實你們對於項目都有各自的想法。真正談下來以後發現你們對於最終開發產品的見解竟然是有出入的，如今想一想仍是挺有意思的。

磨合階段

經歷過，在這個階段裏面你們對於最終產品的定位產生了一些矛盾，這固然不是指隊員間的矛盾，指的是想法之間的不一樣，不過在組長還有其餘各位大佬的協調下最後都肯定了下來。

規範階段

經歷過，肯定了開發目標和定位以後你們就在組長的安排之下開展各項工做，總體流程仍是比較清晰有序的。

創造階段

不太肯定有沒有經歷過，就我的感覺的話團隊仍是比較依賴組長的分配，不可以作到書中說的自治，仍是不夠靈活。

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

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

咱們團隊開發出來的產品託管在github平臺上，可是暫時尚未打包成具體的產品，用戶量暫時也有點不理想。可是從產品功能上仍是具備至關完整性的，基本符合了需求分析時所提出的需求，只談功能使用的話能夠知足用戶的需求。
2.經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」 的軟件

咱們團隊使用leangoo平臺進行任務的發佈和進度統計，同時在github上託管代碼。在時間把控上面雖然仍是存在一點熬夜加班的問題，不過我以爲總體上已經很不錯了。最後開發出來的產品我的來講也以爲挺滿意的，雖然暫時還未打包不過已經具備完整的ui界面以及功能模塊，交互也還算友好。
3.經過數據展示軟件是能夠維護和繼續發展的

開發中的源碼有按照文件夾分類託管在github平臺上，對於維護性和發展性仍是有保障的。
4.對着檢查表 檢查本身若是去企業面試，這些常見的問題是否都能回答，並在此總結

對於不少技術上的問題可能會回答很差甚至是回答不上來，同時也感嘆本科期間能夠學到的東西太少了，並且就這樣量級的知識本身竟然沒能學的牢固，很是慚愧。在各方面的知識上本身還須要多加學習和實踐的。

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

參考論文文獻：

[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

最近考試真的特別多可能就暫時無法補上此處以及其餘地方缺省的東西了

7、個性發揮

下面這張圖仍是很是符合本身的狀態的。通過了軟工實踐的磨練不得不說本身仍是有了不小的提升，可是整體來講仍是沒有脫離小菜鳥的狀態。雖然如此，可是本身仍是會繼續努力的。