06從小工到專家6

1、編寫規範是一項重要的職責，但問題是很多人可能會陷在這裡，不斷地增加規範項。我們可以做這樣乙個嘗試，寫乙份簡單的描述，告訴別人怎樣繫鞋帶。

這可能是乙份並不能幫助他人的描述，因為對有些事情「做」勝於「描述」。因為無意識的行為更快，考慮規範反而會拖慢進度。

2、對待開發文件也一樣，不要編寫過於詳細的規範。因為很可能開發者在思考某個問題時會想到兩種不同方案，經過簡單對比，選擇乙個更優的那個。但面對嚴格的規範文件，一步步思考，這更可能束縛開發者的發揮。

1、設計文件裡的圓圈和箭頭用來解釋他們指代的作用，但這還有可能是推翻我們原先設定的證據。感覺這個是承接上一節的內容，不要被以前的假設和設計所限制，留有一定的彈性空間。

2、我們相信，盲目地採用任何技術，而不把他們放進你的開發實踐和能力的語境中，這樣的處理日後可能會讓你後悔。

3、不要迷信工具以及各種方法學，注重實效的程式設計師會批判地看待他們，並從中提取精華，融合成每個月都在變得更好的一套工作習慣。

1、書籍的前幾章講了幾條如何成為注重實效的開發者的建議，當然他們也對團隊有所幫助，如果個體都是注重實效的，那他對整體起的作用更大。

2、不要留破窗戶：作為整體的團隊更不應該容忍**質量的問題，不規範的不在乎質量的團隊，很有可能把那些注重實效的開發者帶偏。

3、煮青蛙：整體中的個人更難覺察到作為團隊所存在的問題，可以指定乙個「檢測員」，讓他去檢查團隊整體進度，依賴項的準備情況，各個環節的配合等內容。

4、交流：傑出的專案團隊往往有著截然不同的個性，更能與其他團隊進行配合。有乙個簡單的幫助團隊凝聚力的方法：創立團隊品牌，以品牌代指整個團隊。

5、不要重複你自己（dry）：由於個人理解程度的不同或者新成員的加入，團隊總會面臨重複的內容，適當的指派一名管理員，讓他專門維護這些資料，所有對此有疑問的人都不必自我尋找，只要去找管理員就行了。

6、正交性：對於較大的團隊，更應該通過功能進行組織劃分，而不是工作職務。比如開發多個專案，會有多名開發，多名測試，多名設計，他們之間更應該按照具體專案進行劃分，乙個專案的開發，測試和設計為乙個小團體。

7、自動化：確保一致性和準確的一種很好的方式是使團隊所做的每件事情都能自動化，如果還沒有做到那就嘗試去做。

8、知道如何停止繪畫：團隊是由個體組成的，給每個成員足夠的空間，並支援他們，而不是一直給他們具化各種需求。

1、文明通過增加我們不加思索就能完成的重要操作的數目而取得進步。— 阿爾弗雷德·諾思·懷特海

2、我們應該在盡可能多的場景下使用自動化，因為人工流程及不能保證一致性也無法保證重複性。

3、在一些特定場景下我們可以選擇適當的工具進行自動化處理：

1、注重實效的程式設計師會受到找到自己 bug 的驅使，以免以後經受由別人找到我們 bug 帶來的羞恥。

2、早測試，常測試，自動化測試。要通過全部測試，編碼才算完成。

3、測試主要圍繞三個方面進行：測試什麼、怎樣測試、何時測試。

4、測試什麼。測試型別有以下這些：

5、怎樣測試。主要介紹有哪些測試方法：

6、何時進行測試。盡早測試，而且測試應該是自動完成的，我們在提交**時就應該保證測試已經全部通過。

1、**要跟文件緊密結合，我們要認真對待注釋及文件，他們不是可有可無的東西。

2、我們喜歡看到簡單的模組級頭注釋，關於重要資料和型別宣告的注釋，以及給每個類和每個方法所加的簡要頭注釋，用於描述函式的用法和任何不明了的事情。

3、應當使用特定的格式進行注釋，通常對應語言或者 ide 有推薦的注釋格式。

4、可執行文件，即使按照特定格式進行注釋，然後利用工具提取注釋內容並生成文件。例如 j**adoc

5、有時文件撰寫者和開發並不是同一人，但他們應當接受同樣的原則，特別是 dry，正交性，以及自動化原則等。

ios也有乙個文件生成工具：jazzy，支援 oc 和 swift，它可以根據標準的注釋生成文件。

1、某個專案團隊奇蹟般的完成了乙個非常複雜的專案，但卻遭到使用者抵制，原因是該引用沒有幫助系統。所以考慮現實，專案的成功是由它在多大程度上滿足了使用者的期望來衡量的。

2、要與客戶之間多交流期望，了解他們的需求，而不是一味沉溺在技術的世界裡。

3、適當製造驚喜，會有些通用性的技巧能讓專案獲得更好的體驗。比如：

1、注重實效的程式設計師不會逃避責任，相反，我們樂於接受挑戰，樂於使我們的業務知識廣為人知。

2、過去時代的手藝人為能在他們的作品上簽名而自豪，你也應該如此。sign your work.

3、kent beck 在極限程式設計(xp)裡的建議是採用公共的**所有權，其還要求了結對程式設計，以防匿名的危險。所有權的好處是能為優秀的開發帶來自豪感，並且當人們在一段**上看到你的名字時，會將其認為質量的保證。