最後一次做業——總結

總結

格式描述：

這個做業屬於哪一個課程	https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign
這個做業要求在哪裏	http://www.javashuo.com/article/p-ymzlhdjh-et.html
團隊名稱	楊榮模傑和他的佶祥虎
這個做業的目標	課程總結
Github地址	Github

隊員列表：

學號	姓名
201731103226	翟仕佶
201731062517	曾中傑
201731062424	楊模
201731062632	鄧高虎
201731062624	張祥
201731062224	陳遠楊
201731062420	胡思榮

第一次博客

對於第一次問題的解答

問題一：我在第三章55頁看了職業發展—考級之路這一段，有個問題「這些證書真的有企業承認麼？行業承認度怎麼樣？」，我查了一些招聘要求，發現行業對這些證書不太承認的樣子，個人困惑是「如今去考這些證真的有必要麼？他們的承認度不過高的樣子。」

答：其實還好，這半學期我也去了解過一些招聘的文章，也發現了不少HR仍是會對證書感興趣的，可是也不是很高，有證的必要性也不是那麼的高，可是也能夠做爲一個亮點，其次的話，有證也至關於對本身職業的一種承認吧！

問題二：個人困惑是「是否是咱們之後工做時寫代碼時只須要寫上徹底的註釋，而不用向上兼容代碼的使用者呢？」

答：經過這學期的團隊項目，我發現，關鍵的註釋是必要的，這樣會節省你和下一個來接手你代碼的人的大量時間，而對於使用者的話，你只須要保證本身的代碼不出錯，且告訴使用者如何合理的去使用這些東西便可。

問題三：「既然敏捷開發在國內受到文化差別的影響，甚至已經丟棄了敏捷開發所帶來的優勢，爲何這麼多互聯網公司仍是在樂此不疲的採用敏捷開發呢？」

答：在團隊項目的開發中，其實咱們也碰見了一樣的問題，隊員之間因爲陌生，以致於在每日站立會議的時候沒法給出合理的建議，也沒法合理的說出缺點，都過於委婉了，可是咱們也在其中收到了不少好處，敏捷開發的確能幫咱們開發出咱們想要的產品。這可能就是國內互聯網公司採用這種開發的緣由吧，畢竟花取少許時間就能獲取足夠的成果，這種開發模式又有哪一個老闆不喜歡呢？

問題四：身爲程序員如何明白的表達這個需求作不了之類的觀點？項目經理又如何讓一堆技術人員明白他的要求呢？又何以服衆呢？

答：這個仍是得說說，咱們組得項目組長其實也不太能理解其餘人的代碼，可是組長很是樂於聽取他人意見，並給出合理的對策，使得咱們在需求分析和需求確認階段的每一個需求都有專門的人去負責，故我認爲i，只要組長足夠服衆，就算他不是技術人員，也不礙事的。

問題五： 對於一個大型的，擁有足夠多用戶的軟件產品來講，這個軟件可能遇到的狀況，也是」荒誕「的。由於一個軟件開發者（團隊），永遠沒法在測試中窮盡他們設計的軟件會被怎樣的使用，和遇到什麼樣的情況。，可是，我仍是想問，是否存在一種標準去量化這些測試的有效度呢？

答：通過此次團隊項目，我認爲這種東西是沒法去度量的，由於咱們沒法知道咱們得系統到底有多少bug，因此沒法用數學去度量它，在咱們項目開發的過程當中，咱們每次都認爲此次的BUG徹底修復，可是老是有其餘新奇的BUG被其餘組測試出來。

是否產生了新的問題？

• 軟件工程的人如何快速的掌握寫文檔的技巧？

• 繁多複雜的文檔會不會佔用太多的編碼時間？

回顧

其實，經過這門課的學習，讓我掌握了不少軟件工程得過程方法這些，也明白了軟件工程爲何要叫軟件工程。瞭解到原來程序員也不僅僅的只是去負責編碼，在項目開始階段有着比編碼更重要的東西，明白了團隊間協做的重要性，掌握了墨刀等原型工具，知道在編碼以前如何向客戶展現他們所需求的東西。理解用戶需求，遠遠要比編碼重要得多。這些東西，都在課程中源源不斷的反覆練習着。

體會

學了兩年的軟件工程，直到這學期才知道咱們學的是什麼，爲何要去學，在學習的過程當中，的確由於做業出奇的多而各類抱怨老師，卻不知只有讓咱們本身去經歷一下才能讓咱們對軟件工程有更深入更全面的理解。其次呢，這門課讓我認識了不少人，不少志同道合的人，本身也掌握了不少和原來不同的技術，惟一一點的遺憾就是，此次的課程彷佛也沒有提升本身的編碼能力，不過編碼自己就不是這門課的重點，沒有鍛鍊到也在情理之中。