軟件工程終期總結

前言

一個學期，兩輪迭代的軟工、數據庫課程設計、編譯課程設計，還有一些有的沒有的小項目。彷佛這四個月的時間徹底付諸於開發了。天天工做小時數是兩位數，總計上萬行的代碼量，這一個有一個數字無一不在幫助咱們提升這本身的編程水平和開發能力。
或許是時候作一個總結了，總結一下一個學期下來的收穫，也會爲一下這一段時間以來的艱辛與快樂。

兩階段開發總結

通過一個學期的努力，咱們的項目完成了M1和M2兩個開發階段，發佈了alpha和beta兩個版本，其中alpha版本實現了主要功能，二在beta版本的開發過程當中，因爲須要多組間合做，所以咱們對上一個版本進行了重構。從環境搭建，到新技術的學習，再到代碼實現，進而測試、發佈，咱們經歷了重重困難才最終發佈出來這個網站。
與其說是總結，不如說我更想談一談在開發階段出現的想法。
首先讓我印象最深入的是M2的重構。在M2階段，咱們爲了和客戶端組公用後端，咱們把本來的使用跳轉的網站改形成了單頁應用，其中引入了ReactJS。又一次引入新的框架，這顯然讓咱們感受到有點吃不消。新的框架採用了數據單向流動的思想，造成了本身獨有的一套體系，直接限制了jQuery的使用，致使大量的代碼須要修改才能使用。爲此咱們討論了好久。可是通過一段時間的努力，咱們的代碼成功遷移，新的框架順利部署，這讓咱們的信心大增。
讓我印象最深的第二點在時間的分配。在M2開發階段，咱們同時要完成軟工開發、數據庫課設開發、編譯課設的後期編碼工做。幾個大型工程同步開發，已經不知足系統的可調度性，那麼要怎麼作？刷夜！一週刷夜兩天三天已經成爲了一種常態，天天3點前想睡更是天方夜譚。天天的時間幾等分，分別作不一樣的事情，堅定不浪費其中的每一點時間。通過很長一段時間的努力，我如今終於能夠說，咱們撐過來了，咱們勝利了。這讓我想到了真是軟件開發中的發佈前幾天，若是此時真的沒有完成工做，或是測試未經過，那麼要怎麼作？
Scrum Meeting，這是咱們開發過程當中天天或每兩天都要進行的活動。每次Meeting事後，咱們都會彙總工做進度，實現開發過程當中人員的動態調配。這也多虧了咱們有一個全棧工程師才能實現這樣的調動。如今開發結束了，大概咱們也只剩下最後一次Scrum Meeting做爲慶功宴了吧。
經歷了兩輪迭代的開發，我對軟件工程中的不少觀點有了更深的印象，對不少問題也有了新的見解。

問題整理

曾經的問題

傳送門：戳我進入

1.軟件工程是一個在不斷髮展的方法學，隨着時間在不斷變化。那麼咱們如今學習的方法是否會被替代？若是會，緣由是什麼？

答：軟件工程中的方法確實是在不斷髮展的，可是這個發展並不意味着完全的推翻。咱們在作項目的過程當中，M1和M2階段進行了兩次重構，由於咱們發現就在咱們開發的過程當中，已經有新的設計思想產生。可是重構並不意味着咱們須要徹底推翻已有的成果，而是修改掉與新的思想不符合的部分。軟件工程亦是如此。新的思想產生勢必會對老的思想產生衝擊，可是二者存在的主要仍是共性，所以能夠說新的思想只是舊思想和方法的發展，並不會在很短期內完全顛覆。長遠上講，即便經過不少次思想和方法的演化，就得方法學消失的無影無蹤，可是這其中的發展也是值得學習的，更況且咱們不可能在如此長的一段時間以內徹底不進行開發。再者言之，不一樣的方法針對不一樣類型的問題，所以方法之間想要真正實現徹底的替代也是不現實的。

2.書中寫，團隊須要有明確的分工。可是對於咱們這樣的小團隊，甚至是更小的團隊，沒法作到平均的分工，是否還應該有按照職責的明確的分工？

答：分工是要有的，即便並不能作到均分。撇開集市模式不提，對於一個任務型項目，分工顯得尤其重要。咱們都知道責任分散效應，若是一個任務沒有明確指定完成者，那麼全部人都不會採起行動，致使的直接結果就是項目不能完成。所以爲了咱們能順利完成一個可靠的項目，分工是必須的。次之，分工有利於加快項目的完成進度，在咱們進行項目的過程當中就有體會。咱們的項目先後端均使用了較爲複雜的框架，框架的學習成本自己較高，若是不進行分工，每一個人都接觸全部的框架，那麼項目進度將一拖再拖，完成的日期就無法預期了。可是對於小團隊，我認爲分工不必定須要很是明確，能夠採用根據需求和實際開發進度調整的方式，動態調整，維護總體該法進度平衡。

3.既然短時間刺激和長期影響並統一，那麼在開發時怎樣衡量和評估軟件的前景？

軟件需求能夠分爲多個層次：新鮮感、基本功能需求、特殊功能需求。新鮮感是指一個軟件在發佈事後能夠吸引到的第一批用戶所須要的資本，是咱們能從表面上給別人留下的印象。基本功能需求是指基本全部使用用戶都會使用的功能，若是咱們連基本的功能需求都沒有，那麼必然不能留住用戶。特殊功能需求是指咱們有二別人沒有的功能，軟件須要靠知足特殊功能需求來從其餘同類產品中吸引用戶並留住用戶。一個咱們在軟件功能設計的時候也須要考慮這幾點。新鮮感主要依靠前端實現，須要前端有足夠的吸引力。基本功能能夠仿照其餘網站實現。特殊功能是咱們設計中着重考慮的部分，所以咱們加入了不少本身的設計。一個軟件的前景並不能很好估量，可是經過作到以上幾點至少能保證不會很快的被排擠出市場。

4.爲提高用戶的第一印象，不少軟件選擇減小開啓界面的複雜度，可是這樣會掩蓋不少軟件的功能和特色。對於這一矛盾應如何抉擇？

暫未解決。咱們致力於經過顯而易見的方式讓用戶能夠發現咱們的功能，雖然不在主頁面上顯示，可是從主頁面找到任何功能的操做都不會很是複雜。

5.敏捷開發中，儘早持續交付是一個基本原則，而十五章又講須要漸進發布，這兩者應該分別用於什麼場景？

儘早交付和按部就班並無矛盾。儘早交付只是意味着交付一個可使用的版本，而漸進交付意味着不斷添加功能。就像Windows10的更新方式，每次添加額外的功能而不是直接發佈新版本。這種方式能夠實現儘量早的給用戶他們指望的功能，用戶也必定會根據先用功能決定是否繼續進行項目，這是一個相互促進的過程。

6.若是開發過程當中，用戶的需求出現了較大變化，應選擇重構代碼，仍是在現有基礎上修改？

暫未解決。咱們沒有改動需求，只進行過兩次重構，其中第二次是需求出現了較少變化。可是每次重構的工做量都不小。若是是需求發生較大變更，恐怕會不得不重構，是否能承擔這樣的風險就不得而知了。

7.書中對績效的評定方式闡述的很含糊，沒有給出一個能夠量化的方式。在現實中績效是如何考察的？

對於績效的評定，沒有一個肯定的方法，不一樣類型的團隊能夠採用不一樣的方法。咱們曾選用時間工做量綜合量化加獎懲機制的方法。這種方法在開發過程當中雖然起到了必定的激勵做用，可是必然是不公平的。績效的存在自己就是爲了鼓勵成員高效高質量完成工做，所以只要能達到這個目的，任何方式都是能夠的。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~請叫我分割線~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

產生的新問題

1.當開發不能正常完成時，咱們應採起什麼樣的措施？
2.在多組合做進行開發時，若是已經設計好接口，某一方發現須要額外的數據或須要調整接口設計，是否應當聯繫其餘組進行修改？
3.在工做量難以預估的時候應怎樣設計開發計劃和進行人員分配？

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~我也叫分割線~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

軟件工程收穫體會

軟件工程是一門實踐性課程，在課程的實踐過程當中，我體會到了不少僅僅經過上課所得不到的東西。我還將其中的一些思想帶入到數據庫課設和編譯課設的編碼過程，發現確實對編碼效率和質量有很大提升。如下是我感覺最爲深入的幾點：

1.結對編程

結對編程是我在這個學期體會最深的東西。在數據庫課設開發的過程當中，體會尤其明顯。結對編程的核心思想在於一我的寫代碼，一我的指到思想，同時指正代碼中出現的失誤或錯誤。在一我的編程時，因爲手誤致使的錯誤頻發，這類錯誤難於調試，老是出如今很是隱蔽的位置，在debug的過程當中老是會花費大量的時間。在結對編程的模式下，因爲引入了一個一直在關注屏幕而不是鍵盤的人，這類錯誤的出現機率明顯下降。除此之外，結對編程還有利於發現邏輯上設計的失誤，有利於一遍寫出高質量的代碼。

2.架構和設計的重要性

編碼速度和質量會對一個軟件最終成型的效果產生較大影響，可是這個影響遠遠不及前期的架構選擇和設計。咱們在M1階段使用了Semantic UI + Django的架構，在第二階段爲了實現單頁應用又引入了React JS。這一套架構的選擇直接爲咱們省去了不少基礎性功能實現的編碼時間。
軟件結構的設計也是十分重要的。在咱們的開發過程當中，最重要的就是數據的傳遞。咱們擁有大量的數據，這些數據要在多組之間共享。所以咱們須要制定好接口，肯定哪些數據在前端處理，哪些數據在後端處理。M1階段咱們沒有清楚地劃分界限，在M2階段就不得不進行重構，從新定義接口規範，修改先後端的中間件和數據處理模塊。

3.軟件開發的六個階段中的知識點

軟件開發分爲六個階段，需求/設計/實現/測試/發佈/維護。

• 分析：結構化需求分析和麪向對象需求分析，兩者相互輔助，共同決定一個軟件的設計功能需求。
  
• 設計階段：軟件結構設計、數據格式設計、接口設計共同決定了軟件的流程，在每一個流程中還要設計各個過程從而真正實現一個軟件。設計是要遵循高內聚、低耦合的設計思想。
  
• 實現階段：能夠採用結對編程的形式提升編程效率。每一處代碼須要有單元模塊測試，遷入時須要進行復審。
  
• 測試階段：主要測試模塊間的耦合關係。能夠選用人工測試的方法，也可使用腳本測試。背刺軟件從新編譯後，都須要進行迴歸測試來保證沒有破壞更改前的功能。測試能夠選擇白盒測試、灰盒測試或黑盒測試，可是須要儘可能保證覆蓋代碼段中的每一條語句。
  
• 發佈階段：軟件正式上線。此後須要不斷收集用戶反饋的信息，維護軟件功能，修復bug。
  
• 維護階段：維護階段持續時間最長，維護的成本很高。因此在實現階段就須要考慮到可維護性，不能滾泥球！