Utensil按： 此文是我在renny的博客實習回來，說說心理話 的回覆，講了個人對文檔與團隊的一點粗淺理解。現在放到自己的博客裏來存個照。
文檔
關於文檔的重要性，我說一個自己的經歷：
之前爲某外國開源類庫寫一個實用工具，有兩個core developer
review，往來都是e-mail溝通，但基本上是一個人寫的，但在覈心功能實現之後，我由於時間原因不得不擱置下來，我最後就用Doxygen給軟件
寫了非常詳盡的文檔，說明了設計思路、可擴展的開發接口、存在的問題以及TODO等等。我擱置很久之後，那個對我工作了解的最少的core
developer輕鬆地接手了維護。
我這樣做是因爲我深知：
這個實用工具，如果沒有爲它的核心類寫份文檔，在我停止開發之後，最有可能的命運就是因爲維護問題而從類庫的util中消失，或者變成別人寫的新實現，而他們卻無從瞭解舊設計在產生過程中所遇到的實際問題以及相應的適應性改變，要提煉出一個更好的設計會更困難。
文檔是軟件生命的有機成分，能在作者離開後延續它生命，原有的經驗和代碼得以重用，或對新的設計有啓發。而光溜溜的源代碼，可能在環境變後都無法編譯了，可能時過境遷自己都理解不了了，又有誰來試圖理解和維護？曾經花在上面的心血，就此白費。
解耦的確是寫程序中非常重要的一環，但是內聚所代表的“把相關的內容儘可能集中，方便理解和維護”，在實際編程中更難做到。而文檔在這上面能有一定幫助。
寫作文檔的過程也是一次清理接口和重構的過程，因爲如果接口設計得不好，文檔寫起來就非常困難，非常冗長。可以以“好的代碼不需要註釋和文檔”的思想來指導編碼，不過不能因此而覺得文檔無用。
強調文檔重要性，不是個學院派的嘮叨，實踐中挺重要的，就像單元測試一樣，沒有，始終是個致命傷。
團隊
關於團隊的問題，的確是一個很令人頭疼的問題。
在學校裏，能者往往居組長，組長往往變苦力。這其實是團隊非常原始的形態，可惜這樣一種原始的形態仍然不斷在實際工作中重現、定型、死循環化。這種形態的另外一個變種是組長是甩手掌櫃/催命神，副組長做苦力。
和很多同學相比，我並不是一個有很好組織能力的人。但大學四年，一個很重要的收穫，就是在一次次做組長的團隊中，每一次和前一次相比，我都更從苦力狀態中掙脫出來，團隊也更從孤立單幹、陷於碎片的狀態中掙脫出來。
並
不至於變成了甩手掌櫃，我仍然把握住最爲核心，某些事情團隊中只有我才能做好的事情，我依然自己完成，但一次比一次剝離出去讓組員做的事情更多。到後來，
我手上不會再有勞動力密集型的工作，工作量也成了團隊中最少的，但我卻能更好地調動團隊，讓他們去做他們有積極性做的事情，而這些事情能爲我省不少心，同
時又充分發揮了他們的特長和能力，保證了進度和最終的質量。
早溝通，早讓他們參與其中，以及自己心中預先對不同難度的各種任務的分佈有個
基本的概念，有些人可以一直參與做個瞭解狀況的閒人，後期可做預備隊來解燃眉之急。如果有同學技術不行，我會製造給他一種項目需要他的力量的感覺，讓他緊
迫起來，不至於覺得自己什麼事都做不了，什麼責任都不用負，也就毫不關心。至少他會在項目期間試圖去學一些相關的基礎知識，如果瞭解項目，後期調用他，他
也能有相應的功能，呵呵。
而且遠在瞭解敏捷開發的結伴編程之前，我在宣傳部就用了結伴的管法。每一張海報，都由兩個人完成，其中一個指定
爲主要完成海報的人，因爲PS這個事情本來能合作的就有限。另外一個人其實對這張海報什麼都不用做，（往往有另外的任務在身），但會需要督促前者的進度，
在前者陷入審美困境的時候給他建議，閒下來也可以做前者的助手。如果進度和質量不過關，兩個人都要負責。
這個管法是從我自身的工作效率低
下的體驗中總結出來的，因爲我會把正事擱到最後一刻加班做，之前的設計醞釀階段和找資料階段往往因爲一點不知方向在何就停頓下來。因爲做海報，特別需要靈
感和方向感。一個人做的時候我往往感覺到需要另外一個人和自己一起才帶勁。所以在管團隊的時候，我就用了這個辦法，把這另外一個人制度化。
當然，這些措施也未必有效，說下自己心得，與博主分享，歡迎大家指正。