軟體工程學習後問題解答

標籤：補丁   got   思考   單元測試   需求   識別   北京地鐵   大小   迴圈   

一、在學期初我曾通過閱讀教材發現了五個問題，現在我來對這些問題一一解答

1、問題：教材第二章講在進行軟體技術模組設計時，要越細越好，但是我在進行物件導向程式設計時，總是無法將某些模組分離開，導致某些方法程式碼數過多，請問有沒有更加具體一點的設計方法樣板。

　　解答：這個問題老師也曾回複過我解決方案就是在設計的時候不妨也進行一些單元測試，這樣有助於設計的展開，經過一個學期的學習與思考，我發現其實會發生這個問題主要是因為我編寫代碼的經驗不足和思考問題不夠全面導致，在個人項目和雙人組隊項目中我們的任務都是編寫北京地鐵的搜尋路線工程，在剛開始的個人項目中，由於我在設計的時候完全沒有經驗，因此在實現代碼的時候總是會出現一些在設計過程中沒有考慮過的情況發生，比如說機場線的單向地鐵，2號線的環形地鐵會導致搜尋死迴圈，和四惠到四惠東的一段路上有兩段地鐵等等，考慮上這些因素後，使得My Code變得和設計上有很大出入，有些地方甚至不得不改變設計，增添很多方法。但是在第二次雙人項目中，由於有了上次的實現經驗，我們在設計階段就考慮到了北京地鐵這些特殊的情況，並分別採用了更加明確的方法用來解決問題，而不是臨時“打補丁”，從而使代碼的設計更規範。

2、問題：教材第二章在講解使用程式碼分析工具時，注重講解了程式碼分析工具的好處，而忽略了程式碼分析工具的額具體使用方法，我個人在使用過程中，發現不是很清楚很多參數的意思，請問能否提供一些具體的使用教程。

　　解答：在實際進行單元測試的時候，在單人項目和雙人項目進行單元測試的時候，由於需要測試C#代碼，我發現我使用的vs2015社區版不能夠進行單元測試，要想使用vs的內建的測試載入器只能使用vs2015專業版或者更老的vs版本，因此最終我使用的是vs2013社區版，測試方法見http://www.cnblogs.com/codeinet/p/4647394.html

3、問題：教材第四章講goto語句在有助於理清代碼邏輯的情況下，可以使用，但我在學習C語言時聽說goto語句盡量不要使用，那會極大地增加代碼調試難度，請問如何解釋這一矛盾。

　　解答：這個問題我可能在編譯技術那門課上找到了答案，編譯器的實現過程中有一條就是首先講原始碼翻譯成中間代碼，再將中間代碼翻譯成彙編。我們所採用的中間代碼即是四元式，我所使用的四元式中有一條指令為 j，即為無條件條狀指令，與C語言中的goto類似，編譯技術中很常見的一種來源程式情況即為翻譯while語句，每個while語句在翻譯成四元式後結尾均會有一條j指令，用於跳轉到迴圈開始，從C語言這種進階程式語言轉化為同語義，但不同形式的四元式的時候，產生的j語句能夠協助我們更好的理清楚四元式的結構，協助我們快速定位四元式中與while等語義的語句的位置，因此，我得出如下結論，在C語言這樣的進階程式語言中goto語句確實會打破模組封閉性，增加調試代碼難度，但是當goto這類無跳躍陳述式用於理論上的程式碼分析（更加接近四元式這類低級語言）時候，更加有利於代碼的定位和識別理解，因此兩者不矛盾。

4、問題：教材第九章講了PM的重要性，PM是負責做開發與測試之外的事情，而在實際完成這門課的項目工程的時候，請問是不是在我們的團隊中並不需要PM這一角色？

　　解答：這個問題可能是我問的最沒有技術含量的問題了，當初我對軟體工程的理解太過狹隘，以為不過是一個領導帶領一幫程式員寫代碼，但經過一學期的學習，我發現PM所需要做的事一點也不比我們少，他要及時瞭解每個團隊成員的項目進度，編程過程中遇到的問題，以及這會對整個開發項目進度的影響，並即時動態做出調整，以保障項目在規定時間完成，還要不斷向老師彙報工作進度，擷取老師意見，和其他團隊溝通擷取需求，並規劃這些事情對項目工作進度的影響。這些工作雖然繁瑣，但對於整個項目至關重要，正是由於有PM的存在，我們這些開發人員才能安心，全心投入到工程裡。所以PM不可缺少。

5、問題：教材第十二章將使用者介面的重要性，那麼在時間和精力有限的情況下，我們是應該捨棄一些擴充功能的開發而投入更多給介面還是著重去開發一些擴充的功能？

　　解答：一個良好的使用者介面會給予使用者極佳的使用者體驗，但更加炫酷的功能也是使用者所期望的。但當時間不足以讓兩者均為最佳時，我們需要考慮這樣一個問題，一些擴充的功能勢必會引起介面的改動，這些改動可能是龐大的，甚至全新的介面，因此，在實現某些特定功能的時候，要考慮到介面團隊能否在規定時間內完成這些需求上的改動，如若不能完成，則應放棄這一擴充功能的實現，否則即可考慮實現。

二、在學習完這學期的軟體工程後，我又有了一些新的問題

1、在Team 專案中，我充當的是後端代碼的編寫，這其中涉及到使用其他團隊成員的方法，在調用之後，我需要進行測試以保證使用無誤，有時發現問題後我還需要進行調試，對發現的問題進行定位，那麼我在整個團隊中的定位從一個代碼整合者變為了調試者，於是有時我會對自己在整個團隊中的定位有些困惑，請問我如何在團隊中定義自己的角色？

2、在團隊合作中，衝突是不可避免的，每個人對問題的理解有所不同但都有自己獨到之處，我在團隊中一般發生衝突的時候都會選擇妥協，但在實施別人的計劃之後有時還是覺得自己的想法可能會更加有效，此時應該怎麼辦？

三、軟體工程中我所學到的知識點

1、需求

“客戶永遠是第一位的”：在需求方法，我深刻的感受到這一至理名言，一旦客戶提出的需求有所改動，我們就需要更新甚至改變我們的開發進度，時時刻刻以滿足客戶的需求為準。

2、設計

“設計先於動手”：一個項目在沒有完全理清楚結構之前直接動手是致命的，整個項目的實際情況和預期的出入，計劃的調整甚至更改，可能直接導致整個項目在預期時間內完成不了。

3、實現

“減少或替換新技術的使用”：一項新技術的使用勢必會導致從未解決過的問題的發生，這個問題可能導致整個工程進度的延期，在我們的項目中使用了java調用C#的技術，這項交叉編譯的技術在我們當初設計的時候覺得根本不是痛點，可就是這樣一個不起眼的小問題，將我們的進度拖慢了2周時間，直接導致很多我們想要實現的功能沒有實現。

4、測試

“完備的測試很關鍵”：一個團隊中如果有一個人的代碼有問題，則會影響到整個團隊的工程發生問題，如果以整個工程為單位進行代碼調試，任務量巨大而且效率極低，故每更新一個模組，每修改一行代碼就應該進行完整的測試，這樣發現問題後定位問題將會容易許多，不要覺得“我改這行代碼沒有問題”，你是這樣理解這段代碼的，但是其他人可能有不同的理解，從而有不同的使用方法，因此改動無論大小都應進行完備的測試。

5、發布

“注意發布版和實驗版的不同”：發布版本首先要經曆實驗版本的測試，並且發布版的代碼應該更加簡潔，運行更加穩定，其運行過程中不應輸出調試資訊，代碼中注釋掉的代碼也應該去除。

6、維護

“維護是一種責任”：所謂維護是指代碼在發布穩定運行後依舊有人去定期關注其運行情況，保證無誤，如若存在問題，及時糾正。維護是一個團隊的責任，保障自己的程式能夠正常運行，是對使用者的負責任，也是自身的義務，責無旁貸。

軟體工程學習後問題解答