[個人部落格作業Week7]軟體工程Team 專案感想與反思

標籤：

在閱讀了推薦閱讀的材料之後，我想了很多東西。最終還是決定，以Team 專案的經曆為主線，敘述我關於軟體工程的一些思考與體會。

 

鳳凰涅槃，浴火重生

如果要我來概況這幾周Team 專案的經曆的話，那麼句話是我所能想到的最貼切的一個表述。從最初的雄心壯志，到中間的困頓不堪，再到目前如重生一般的喜悅，我們整個團隊經曆了太多太多。

重造輪子

　　輪子，在軟體行業中經常指那些設計好的，用於處理常見功能的庫、架構或者可重用的代碼。而重造輪子則是說，在已經有可用的“輪子”的情況下，自己重新實現一個自己的“輪子”。有些人經常說，重造輪子是一種很傻的行為。已經有現成的代碼可以解決問題，可以工作，我們為什麼要重造輪子呢？也有人認為，重造輪子往往會引發一場進步。比如在已有的庫的設計無法滿足實際需求時，重造輪子則可能產生更為先進而高品質的輪子。因此重造輪子是值得鼓勵的。

　　在我們的項目開始之初，作為團隊中的架構師，我想了很久。我們擁有往屆留下的完整的代碼。稍微做些修補和部署的工作，那些代碼就可以實現很多功能。雖然介面很醜陋，部分功能也恐怕存在諸多問題，但畢竟是八千行代碼，幾年的課程積累下來的東西。採用它們，我們的工作能夠輕鬆很多。但這樣的輕鬆也存在問題：代碼遺留bug是肯定存在的，而且據測試的小夥伴說，問題還不小。上一屆留下來的文檔也提到，他們發現再上一級很多功能沒有實現，空有一些介面等等，調了很久。文檔不齊，原有開發人員又都不在項目中，採用的技術也相對老套。且這套代碼經曆過多年的開發，縫縫補補修修整整，就像閱讀材料中所說的大泥球，誰都很難說現在代碼的狀態是什麼樣子。在這樣的情況下，我們是否應當重造輪子，將其推翻重來？

　　雖然直到現在，我依舊無法衡量，當時的選擇正確與否。但經曆了重造輪子的過程之後，我對於造輪子有了更深的一些想法。造輪子最痛苦的一點在於：我們需要重新實現原有的功能，而無法依託於哪些東西。所以，造輪子的代價之高昂，是顯而易見的。現在看來，我們對於這一點的認識顯得過於稚嫩。憑著一股莫名地自信，我們就認為自己能用兩千行python能實現原有的8000行代碼的功能，現在回想起來，確實感覺有些太過自負了。但徹底的重寫也帶來了意料之外的好處，我們整個採用了時下較新的技術，以較低的成本實現了很多功能，整個架構無論是實現新功能，還是重新實現原有功能，都很容易。一些看上去很複雜的東西，通過使用現代化的架構就可以輕易解決。我們的系統目前大量地使用了分布式的技術，可以通過增加節點來提升效能。這一點是通過重構原有的代碼很難實現的。這些新鮮的技術也帶來了很多新鮮的設計和鮮活的動力。我們所採用的架構，都蘊含了很多現代化的設計思想。這些思想也透過這些架構，滲透到了我們的設計中。我們遵循它們所提供的一些設計原則，理解它們的很多設計理念，並試圖去應用這些設計哲學。在這個過程中，我認為我們整個項目的整體感覺要比原有項目好得多。團隊成員也都很有幹勁，每當實現了一個新的功能，或者採用了某些新鮮的東西，都會拍手高呼。由於是全新開始的項目，沒有遺留代碼的曆史負擔，我們可以盡情地使用我們所想用的工具，而不必在意曆史包袱。

　　總結起來，我認為，重造輪子的好處在於沒有曆史包袱、思路更為大膽開拓、可以給一些項目帶來革命性的變化。而採用原有系統，則可以“站得高，望得遠”。這二者的權衡，是一件需要更為細緻周到地去思考的事，輕易下一個結論，則會招惹意料之外的麻煩。正如我們目前的狀態，從最初選擇放棄舊有代碼，自己重造輪子，到現在，方才認識到，當初的決定影響到底有多麼深遠，需要考慮的問題又有多麼複雜。也許有些事，經曆過才會才知道深淺。如何權衡利弊，如何評估方案，也許下一次再做得時候，我們會成熟很多，並且謹慎很多。

團隊管理及開發方法

　　軟體工程沒有“銀彈”。我十分認同這一觀點。從之前的結對程式設計，到目前的敏捷開發。所有的方法都有它的應用範圍。比如結對程式設計對於結對雙方的性格、關係等等都有一定的要求。兩個人一見面就掐的那種，還是不結對效率來得高。而我們目前所採用的敏捷開發，對於任務的分解、分配，人員的協調，角色之間的關係，都有著很強的要求。而這對於一個團隊來說，不見得是很容易達到的。比如PM和程式員之間，就是位置很糾結的一組關係。按理來說，PM負責協調工作、項目宏觀方向、跟蹤進度等等，但如果程式員相對比較強勢，那麼PM的工作往往難以進行。PM把握不了項目的基本走向，而程式員們毫無組織地鬆散開發著。除了PM和程式員外，測試、UI等各個角色之間的關係，都可能成為整個項目的瓶頸。

　　閱讀材料裡所說，“有人負責，才有品質”。經曆過一輪Team 專案的開發後，我非常認同這一觀點。而且，我認為，這裡的負責有兩層含義：一、有一個特定的人負責處理這件事。二、這個人有能力處理好這件事。第一層相對是顯而易見的，一個任務必須指派給某一個固定的人，否則，這個任務若是沒人認領，自然很難期盼它被良好地完成。就像一棵無人搭理的樹苗，雖然最後也能長起來，但是相比起被園林工人精心呵護的樹苗來說，其形態樣貌等都會有一些程度的差距。第二層則是經曆過Team 專案後，我所得出的一個理解。所謂負責，並不是說指派給某人，某人就能負責。這個人必須有能力負責才行。例如，你指派一個小學生去進行[完成高等數學習題]這樣一個任務。雖然指定了特定的人去負責處理，但是，顯而易見地是，被指派這根本沒能力對這件事負責。即使他最終做出來，做的不好再打回去一遍遍改，仍然很難改好。這也就是有能力負責的意義所在。

　　我們團隊所面臨的最慘痛的一次教訓也正是源於此。我們雖然按照要求，每天都開"每日立會"，有時遇到問題，幾個人也經常串宿舍討論，但卻沒有明確地指定負責人。於是，手裡有一波又一波鬆散的記錄、不正式的文字，卻一直未能整合到一起。專門負責維護的同學又是對於內容十分較真的人，品質不夠絕不會往出發。結果，每日立會相關的文檔就一直拖了下來，造成了很嚴重的後果。現在想來，如果當初能夠指定一個特定的人，有足夠能力的人來專門負責這件事，也許最後就不會出現這樣的局面。我們一直採用集市式的方式進行我們的Team 專案，大多數任務幾乎都是自己主動要來的。團隊內部的大部分人都很積極，任務也大多數都有明確的人來真正去負責。所以大體上十分順利。但是，集市式方式所面臨的問題，我們自然也不可避免的遇到了。而且，我們甚至沒能及時注意到這成為了一個問題。大教堂式的開發是設計好了一切，按部就班地完成開發。而集市式則更像一個鬧哄哄的集市，每個人選擇其自己感興趣的任務去進行。我們順利地採用集市式的模式完成了幾份高品質的作品。一個人初稿、一個人複審迭代更新、一個人再度審核排版等等，每個人都出於個人的責任、榮譽以及興趣等複雜情感，深入地參與到了整個過程中。雖然沒有非常明確的安排，但是大家都主動承擔了某一部分的任務。我們用集市搭建起了一座教堂。然而，這種搭建是有條件的，正如《大教堂與集市》的作者所總結得那樣：

1）項目首先必須是你自己感興趣的，但是最終能對其他人有用。

2）將使用者當作合作者。

3）儘快地和經常地做出改進，多聽取使用者的意見。

4）健壯的結構遠比精巧的設計來得重要。換句話說，結構是第一位的，功能是第二位的。

5）保持項目的簡單性。設計達到完美的時候，不是無法再增加東西了，而是無法再減少東西了。

之前的成功使得我們沒能認清楚上面所敘述的一些本質性的東西，從而導致了後面的問題。我認為其中最主要的是第一條：項目必須首先是你感興趣的，最終對其他人有用的。之前構築的一系列文檔，源自團隊中對於文字有執著追求的青年的努力，也源自團隊自身開發設計的需求，因此，大家參與得較為深入。特別是一些每個成員都能夠用到的文檔，比如設計文檔、需求分析等等。然而，我們沒有認識到‘每日立會‘的會議記錄的作用，因而也沒有人對其感興趣。大家都覺得，這個東西似乎沒那麼重要，沒有給予太多的重視。現在回想起來，我覺得這確實是違背了上面的第一條條件：項目必須首先是自己感興趣的。沒有人願意關注的東西，自然難以採用集市式的方式進行。於是，在這一次，集市沒有起到任何作用，我們一直所倚靠的集市式成了低品質的罪魁禍首。

在經曆了這樣許多之後，我認為，我們依舊需要堅持我們所一直依賴的集市式模式，它是我們成功的基石。但在此之上，我們必須另想辦法解決那些不適用於它的情景。在我看來，一個適合我們團隊情況的開發模式是這樣的：對於每一個任務或者需求，首先應當盡量採用集市式的思路去完成它。但同時，我們應當設定一個警戒時間。如果超過這個時間依舊沒有任何起色，那麼就說明集市模式已經不再適用於這個任務或需求了。我們應當綜合各方面意見，選定一個特定的，有足夠能力的且適合完成這個任務的人。讓他為此事負責，這樣才能產生足夠的品質。從而避免集市式模式失效後直接崩盤的慘痛結果。

結語

幾周的Team 專案開發，我們從高潮到低穀，再重新一步一步向上爬。跌宕起伏的過程，讓我們更充分地意識到了哪些是對的，又有哪些是存在問題的。我們團隊的前路依然艱險，但我認為，我們已經摸索到了正確的模式。在下一輪開發中，我們能夠應用這些經驗與感悟，小步快跑，達到更高的一個層次上。

 

[個人部落格作業Week7]軟體工程Team 專案感想與反思