軟件工程--提問回顧與總結

項目	內容
這個做業屬於哪一個課程	2019春季計算機學院軟件工程(羅傑)
這個做業的要求在哪裏	做業要求

一、之前提問題的博客

軟件工程第一次閱讀

二、對本身曾經提出的問題進行解答和分析

• 問題1：關於如何權衡高層次的科研和工程基礎。

  我認爲二者是能夠兼顧的，以前因爲基礎知識的欠缺，作不少學術方面的工做都很吃力，如今通過兩個學年的學習，計算機方面的綜合素質也獲得了鍛鍊。在接觸實驗室的過程當中，發現不少領域都須要從頭開始學起，特別也須要學習一些基礎的數學知識，有些在本科也是涉及不到的，的確如書中所說，要把底層的問題解決後再去解決高層次的問題。在學有餘力的時候應當多去實驗室接觸科研，也能提早知道本身適合哪方面的研究。

• 問題2：對結對編程的質疑，是否真的能提升編程效率？

  通過本身的實際操做，結對編程是能夠提升效率的。在團隊項目中，我和另外一個隊友寫後端，因爲咱們兩我的剛開始接觸ruby這門語言，在實際操做中很是不熟練，咱們採起告終對編程的方式，兩我的的思惟能力都提升了不少，能及時發現對方的錯誤，或者在某個方面提出更好的實現方法。雖然最後寫出來的代碼被大佬否認了。即便是不多時間量的結對編程，也能從對方身上學習到一些提升編程效率的方法。

  在閱讀相關論文"Case study: using pair programming in development of a complex module."後，論文提出告終對編程須要知足的條件：

  一、結對成員必須在一些編程觀念上達成一致

  二、結對成員之間必須保持良好的交流，願意相互合做

  三、結對成員技術知識必須具備可比性。若是一個經驗豐富的成員和一個沒有經驗的成員一塊兒工做，他們能夠創建良好的指導關係，但他們不一樣的經驗水平不利於有成效的結對編程。

• 問題3：關於敏捷流程中的Backlog如何制定和評估？

  在咱們的團隊項目中，Backlog的制定和評估由PM來完成，咱們在產品的三個階段都制定了詳細的須要完成的功能需求。alpha階段，咱們遵循mvp原則，咱們alpha版本的目標即是以較高的質量實現最核心的社團展現相關功能。儘管alpha版本的功能與某些組相比略顯簡單，可是咱們功能的完成度更高，從結果來看，咱們的作法是正確的。Gamma階段咱們仍有不少能夠實現的功能（以前版本功能的拓展，社聯但願咱們支持的功能，社團管理人員但願咱們支持的功能，通常用戶但願咱們支持的功能），咱們最終綜合實現成本、收益分析、後續維護問題以及用戶需求調研進行了篩選決定了gamma階段實現的功能。鍛鍊了軟工的需求分析能力。

• 問題4：在創新中爲何一些先行者會最後在競爭中被淘汰呢？

  一件產品是否能在競爭中贏得勝利實際上是有諸多方面的緣由的。先行者可以搶佔必定的先機，但若是後續的運營跟不上，極可能被後來者趕超。

  咱們的小程序也借鑑了以前南京大學的社團小程序，發現他們學校也有兩個這樣的小程序，而那個先行者運營的並無很好，最終被取代了，後來的社團小程序和學校官方進行合做，用戶活躍度明顯高出不少。有效的競爭策略加上公司資源的合理配置和使用可以加強一個公司的競爭力。

• 問題5：關於沉沒成本，如何砍掉功能？

  在Gamma階段咱們的團隊項目有一個爬取公衆號連接的功能沒有作出來，這個功能以前問過從前的開發人員也發現實現的難度很大，並且通過咱們的討論後，發現該功能也並非那麼必要，可讓社團負責人本身上傳連接。

  這個功能實際上在前兩個階段都一直在摸索，但沒有找到合適的解決方法，能夠說在這件事情上花了一些沉沒成本，但若是咱們一直守着沉沒成本不放，只會給繼續增長投入的成本而沒有任何收益。因此在砍掉新功能的時候要考慮沉沒成本，也不能過度迷戀沉沒成本。

  從決策的角度看，以往發生的費用只是形成當前狀態的某個因素，當前決策所要考慮的是將來可能發生的費用及所帶來的收益，而不考慮以往發生的費用。

  人們在決定是否去作一件事情的時候，不只是看這件事對本身有沒有好處，並且也看過去是否是已經在這件事情上有過投入。可是這些不可回收的支出其實對將來的效益並無改善。

• 新的問題：

  關於團隊中的角色轉換和轉會，究竟有沒有這方面的須要呢？咱們團隊進行了角色的轉換，但你們都須要花費很長的時間進行新知識的學習，是否是下降了效率呢？

三、團隊項目項學到的「知識點」

需求

需求分析是開發人員通過深刻細緻的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化爲完整的需求定義，從而肯定系統必須作什麼的過程。

咱們在每一個階段都會進行用戶需求的調研，發放問卷等，開組會進行詳細的需求分析，每一個組員表達本身的見解，而且由PM撰寫需求分析文檔。

在後續階段也進行了需求文檔的維護和更新，使得團隊成員對需求的理解更加深刻。

設計

咱們團隊由PM進行了產品的原型設計，把設計稿交給前端進行詳細的設計。把ui設計和前端進行了分離，設計出來的產品也更加美觀。

實現

學習了ruby on rails的開發框架，學會使用orm模型框架的後臺。

同時也參與了一些前端的工做，在接口設計部分向大佬學習了不少經驗，注意一些接口的命名規範等。咱們廣泛使用的是RESTful的接口命名規範，方便先後端進行通訊。

測試

在ruby on rails中，我學會了單元測試的一些框架，並用此找出了代碼中的不少bug。也在ruby mine ide中學會使用了代碼覆蓋率的插件。同時我也對服務器進行了壓力測試，使用了ab測試工具。

發佈

因爲微信小程序是騰訊的平臺，有諸多方面的限制，咱們實現一些小程序的功能，例如跳轉到公衆號的連接，主動推送微信消息給用戶，就須要認證成爲企業小程序，還有審覈等問題須要花費不少時間，這些都須要提早進行規劃。

維護

軟件維護是軟件生存週期的最後一個階段，是在軟件交付使用後，爲了改正錯誤或知足新的須要而修改軟件的過程。軟件維護工做的目標是：不斷地、持續地改進、擴充、完善軟件系統，以提升系統運行效率，並儘可能延長系統的使用壽命，爲用戶創造更大的價值。

咱們在發佈以後也及時收集用戶的反饋，發現了一些bug並及時修復。

四、心得體會

經過軟件工程這門課，我有機會接觸一個項目的完整開發，也速成了一門新的語言。

在alpha和beta階段中，我負責的是後端的開發工做，咱們組有一位有開發經驗的同窗。在一開始我和另外一位同窗沒有ruby的開發經驗，還處於學習階段。在隨後的開發工做中，咱們三個也一直在磨合，因爲本身的開發經驗不足，致使不少地方的代碼寫的很醜，不符合規範，也沒有使用最好的實現方法，被大佬指正出來並進行改正。有時候問題沒有及時反饋，會致使後面大規模的返工，下降了開發效率。在這個過程當中也明白了團隊合做的重要性，團隊成員要如何在項目中分工等。

在gamma階段中，我開始學習前端的開發，實現了兩個頁面的製做，獲取formid等功能，對先後端的交互也有了更深一步的瞭解。

在這門課真的收穫了不少，而且遇到了一羣靠譜的隊友和特別負責的PM芬姐，在這裏也感謝個人隊友們和老師助教，但願軟工愈來愈好。