【我的博客做業Week7】軟件工程團隊項目一輪迭代感想與反思

(發佈晚緣由：發到團隊博客了

1、關於銀彈

在佛瑞德·布魯克斯於1986年發佈的《沒有銀彈：軟件工程的本質性與附屬性工做》這篇軟件工程的經典論文中，做者向咱們講述了軟件工程沒有銀彈這樣的理論。銀彈，指的是強有力的武器。用做者的觀點來講，就是：

「軟件工程中不存在銀彈——沒有任何一項技術或方法可以使軟件工程的生產力在十年內提升十倍」

軟件創做包括本質性工做和附屬性工做。本質工做指的是軟件構建、軟件從抽象性問題發展出解決方案。附屬工做指將解決方案實現到電腦上所遇到的困難。

文章中說，附屬性工做將會隨着工具的改善而逐漸淡化，並舉例說明從彙編到高級語言，附屬性工做難度的下降使軟件開發效率大大提升。我認爲這一點很正確，附屬性工做會隨着軟件行業總體的進步逐漸下降。近年來開源流行，許多先進技術的開源，框架的開源，都給咱們軟件開發提供了很是現成的工具。經過工具的幫助，咱們對於軟件的想法能夠很快實現。就像這一次開發中，後端使用了rails，前端使用了semanticUI，這些框架的使用，使咱們專一於核心代碼的實現。軟件設計中重複的工做（如HTTP請求、web server服務器的開發等）則交給「工具」來完成

而本質性工做的複雜性則難以消減、淡化，並始終制約軟件開發效率，使得軟件開發沒有「銀彈」。這些本質性的工做包含複雜性、一致性、可變性和不可見性。通俗地講，這些複雜性的難度表如今以下幾點：

1.軟件功能的增長，會致使軟件在複雜性處理上付出的設計成本幾何級增加。

2.軟件工程歷來不是一我的的工程，有時也不是一個開發團隊的工程，這裏面接口、文檔、以及設計的一致性直接影響開發效率、溝通成本的高低、大小。因此一致性必不可少，而軟件各模塊一致性的設計是至關複雜困難的。

3.軟件的首要功能是服務用戶，所以常常會須要持續變動，保證軟件的可擴展性也是軟件設計中的本質工做之一。

軟件工程沒有銀彈，但卻有各類增長軟件開發效率的方法。這一點我在開發團隊中深有體會。

首先，咱們在先後端開發前，先制定了API文檔。API文檔規定了後端提供的數據接口，調用方法以及返回值說明。使用JSON做爲API傳輸數據的主要格式。這樣作的好處有兩個：其一，將先後端開發的耦合性降到最低，先後端只須要對照API文檔開發便可，目標明確，而又互無干擾。其二，使用API做爲後端接口，爲未來的軟件擴展性騰出很大空間，由於後端提供API後，開發手機APP將能夠直接使用，無需調整後端架構。

其次，咱們使用了很是正確的技術棧，後端使用nginx+rails+mysql/sqlite，前端使用JS+SemanticUI，這直接是咱們的先後端開發效率直線提高。rails的使用，讓後端開發過程當中幾乎沒有遇到太大困難，並且rails自己的MVC框架再次將責任細化到模型、控制、視圖。前端JS+SemanticUI的架構，將前端工做拆分爲JS和web界面兩部分。這樣的技術棧選取，最大限度地將前端、後端的任務細化、消除耦合與相互干擾，使得在團隊協做的前提下，我的開發效率獲得有效提升。

最後，在開發以外，留有一手PM負責總體架構，考慮項目各模塊開發設計，技術選取以及可能遇到的技術難題並提早尋找解決方案，保證項目開發不由於技術問題停滯。此外，PM爲項目進展提供催動與監督，從技術上又提供指導，技巧上提供好的高效率的開發工具（如Fiddler），最終實現項目的平穩推動並完成發佈。這也是咱們對付「軟件工程」的一枚「小銀彈」 O(∩_∩)O

 

2、大泥球

大泥球指的是由混亂的代碼、一次性的代碼、修修補補的代碼盲目組合在一塊兒而造成的隨意化的雜亂的結構化系統，每每會致使不少錯誤和缺陷。

我認爲產生「大泥球」的主要緣由是代碼管控不嚴以及團隊規範未樹立。項目規劃不正確，致使遇到麻煩後亂了鍋，又對代碼管控不嚴，最終致使項目中代碼混亂而臃腫。若要預防大泥球，須要提早就對項目代碼結構有比較明確的規劃和預期，並提早指定應對大部分問題的規則，遇到意料以外的問題時應慎重對待、遵照團隊代碼規則，不要容許混亂的代碼進入代碼體系中。

面對大泥球，咱們時常會有「推翻重寫」的衝動，大泥球會帶給後來人太多痛苦，咱們寫軟件必定要避免「大泥球」！

咱們的項目由於是剛剛通過一輪迭代，一切從零作起，因此暫時沒有遇到「大泥球」的困擾。可是我以爲咱們的前端代碼可能會成爲「大泥球」，由於前端工做太細碎，又沒有規範，各我的都在向前端提供代碼而沒有統一的代碼規範以及應對前端各類開發問題的解決方案。如今看前端代碼，可謂是「補丁套補丁」，我以爲這隻能歸因於隊員們沒有開發經驗不足，實際上若是咱們對前端足夠了解，咱們會制定好一套前端代碼的規程。咱們會在二輪迭代中作好這一點，也有可能對以前的前端代碼進行重構整頓。

 

3、大教堂&集市

大教堂，是軟件開發的一種模式，指的是源代碼在軟件發行後公開，但由一個團隊管控。

集市，是另外一種軟件開發模式，指源代碼公開後，能夠供任何人開發提交代碼。

大教堂模式的優勢在於，代碼由固定的若干人負責，代碼質量比較有保證。缺點在於，軟件總沒法獲得充分的測試，可能會有bug，除錯時間大大增長。

集市模式的優勢在於，全部人均可以參與到軟件開發中，軟件中的bug能夠獲得更多人的檢視而被查出更正。

A Generation Lost in the Bazaar告訴咱們，集市開發模式的弊端是被一羣人更改後的代碼很難看，不簡約。

咱們的項目目前屬於大教堂模式，代碼僅由咱們的開發團隊控制。開發團隊內部也同樣，後端代碼由後端開發成員控制，前端代碼由前端開發同窗控制。

 

4、瀑布模型

瀑布模型是軟甲開發的一種模型，指的是將軟件開發分爲若干個流程，例如將軟件生命週期分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，並規定它們自頂向下，互相銜接，固定次序。如同瀑布流水，逐級向下，最終活的產品。

這樣的模型要求每一個階段都達到「無後效性」，即保證每一個階段開發的完備性。

在我看來，瀑布模型過於「笨重」，不適合於軟件的短時間開發。不過從長期來看，瀑布模型開發很平穩，有利於打持久戰。

5、敏捷開發

敏捷開發是一種面臨迅速變化的需求快速開發的能力。敏捷不僅僅是快，更是短週期改進、調整的意思。敏捷開發在形式上有product backlog、sprint backlog、sprint、scrum meeting、burning down等開發技巧。

咱們小組的軟件工程是敏捷開發的模式，將經歷集中在可執行的程序上，隨時考慮模擬用戶行爲、用戶體驗，對項目提出新的需求與改動，天天進行scrum meeting，彙報總結，發表報告。此外，敏捷開發最重要的是「溝通」，這一點咱們作的最到位，小組成員常常會坐在一塊兒交流，先後端交流、前端後端內部交流，實現了不少的「約定」，大大解決了互相之間的依賴與影響。

 

6、軟件工程的方法到底有多少用處

軟件工程的方法，在我理解來，就是一套方法、規則以及經驗。咱們閱讀的兩篇文章，告訴咱們軟件開發方法對軟件開發產生的影響、典型軟件項目每每沒有規律以及可預測環境。項目成功的惟一目標是：經過軟工開發達到項目開發的預期目標了嗎？很難知道是什麼因素致使了項目的成功或失敗。

我以爲軟件工程的方法，一方面，能夠給咱們提供不少經驗指導，使咱們少走彎路，開發效率獲得提升，另外一方面，告訴咱們應對各類開發問題的方法與心態，解決問題的方法論，開發團隊組織的方式等。這些在我看來是很是重要的，沒有軟工的方法，軟件開發過程可能會很痛苦，並且頗有可能由於採起不恰當的軟工方法致使軟工項目失敗。