《程式設計師的職業素養之程式碼整潔之道》成為專業人士必讀

此處悼念1986年1月28日挑戰者號太空梭事故中喪生的七名優秀的宇航員

接下來大家帶著以下問題去閱讀此書《程式設計師的職業素養之程式碼整潔之道》 也可以閱讀此文章 本人儘可能將書中精華總結於此文章中

• 什麼是專業人士
• 軟體專業人事如何行事
• 軟體專業人士如何處理衝突,應對很緊的工期,如何和不講道理裡的管理人員打交道
• 軟體專業人士何時應該說"不" 怎麼說
• 軟體專業人士如何應對壓力

一 專業主義

1.1 專業主義

專業主義的精髓就在於將公司利益視同個人利益.也就是意味著擔當責任

1.2 擔當責任

1.3 首先不行損害之事

• 1.3.1 不要破壞軟體功能 所謂專業人士就是能對自己的犯下的錯誤負責的人,哪怕那些錯誤實際上在所難免,失誤率永遠不可能為零 但是你有責任讓他無線接近於零 簡單的做到以下幾點:
  • 儘可能的讓 QA 找不出問題
  • 要確信程式碼正常執行
  • 自動化 QA
• 1.3.2 不要破壞結構 成熟的專業開發人員知道 聰明的人不會為了釋出新功能而破壞結構 ,結構良好的程式碼更靈活, 以犧牲結構為代價,得不償失, 將來必回追悔莫及 所有軟體專案根本指導原則是:軟體要易於修改

1.4 職業道德

你應該計劃每週工作60個小時, 前40個小時是給僱主的,後20個小時是給自己的, 在這剩餘的20個小時裡 ,你應該多看書, 練習, 學習, 或者做其他能提升職業能力的事情

• 1.4.1 瞭解你的領域
• 1.4.2 堅持學習 軟體行業的飛速改變 意味著軟體開發人員必須堅持廣泛學習才不至於落伍 : 時刻記住不寫程式碼的架構師必然遭殃,他們很快會發現自己跟不上時代了,不學習新語言的程式設計師同樣會遭殃,他們只能眼睜睜的額看著軟體業一路發展,把自己拋在後邊,學不會新規矩和新技術的開發人員更可憐他們只能在日漸淪落的時候看著身邊人越來越優秀
• 1.4.3 練習 業精於勤荒於嬉
• 1.4.4 合作 學習的第二個最佳方式就是與他人合作
• 1.4.5 輔導 俗話說教學相長想迅速牢固的掌握某些事實和觀念 最好的辦法就是與你負責的人交流這些內容
• 1.4.6 瞭解業務領域 每開發一個新領域專案的時候 就要了解自己開發的解決方案所對應的業務領域 如果你編寫財務系統 你就應該對財務領域有了解,如果你編寫旅遊應用程式 那麼你需要去了解旅遊業
• 1.4.7 與僱主/客戶保持一致
• 1.4.8 謙遜

二 說 "不"

能就是能 不能就是不能 不要說"試試看" ----尤達

專業人士應該懂得說"不" 事實上 優秀的經理人對於敢於說"不"的人總是求賢弱渴 因為只有敢於說 "不" 的人 才能真正做成一些事情

2.1 對抗角色

你的經理要求你在明天之前完成登入頁面 這就是他在追求和捍衛的一個目標 那是進他的職責.如果你明知第二天之前不可能完成登入頁面 嘴上卻說"好的 我會試試的" 那麼你就是失責了 這時候 盡職的文藝選擇是說"不 . 這不可能"

2.2 高風險時刻

越是關鍵時刻 "不"字就越有價值 這一點應該不證自明 當公司存亡成敗皆繫於此時 你必須盡己所能 把最好的資訊傳遞給你的經理 這往往意味著要說"不"

2.3 要有團隊精神

有團隊精神的人會頻繁與大家交流 會關心隊友 會竭力做到盡職盡責

• 2.3.1 試試看 允諾"嘗試" 就意味著你承認自己之前未盡全力 承認自己還有餘力可施 允諾嘗試意味著只要你在加把勁 還是可以達成目標的 而且這是一種表示你將再接再厲去實現的目標的承諾 因此只要你要允諾自己去嘗試 你其實就是在承諾你會確保成功 這樣 壓力就是你來抗了 如果你的嘗試 沒有達到預期的效果 那就表示你失敗了

三 說 "是"

3.1 承諾用語

做出承諾,要包含三個步驟

• 1 口頭上說自己將會去做
• 2 心裡認真對待做出的承諾
• 3 認真付諸行動

如果你能夠一直信守承諾 ,大家會以為你是一名嚴謹負責的開發人員 在我們這行中 也是最有價值的評價了

3.2 學會如何說 "是"

和學會說 不 同樣重要的是 要學會說 是

專業人員不需要對所有請求都回答"是" 不過 他們應該努力尋找創新的方法 儘可能做到有求必應 當專業人士給出肯定回答是 他們會使用正式的承諾 一確保各方能明白無誤的理解承諾的內容

四 編碼

4.1 做好準備

編碼是一項 頗具挑戰也十分累人的智力活動 相比其他型別的活動 編碼要求更加聚精會神 因為在編碼是你必須平衡互相牽制的多種因素 如果感到疲勞或者心煩意亂,千萬不要編碼 相反要找到一種方法來消除干擾 讓心緒平靜下來

• 4.1.1 凌晨三點寫出的程式碼 ?(驚呆了) 疲勞的時候 千萬不要寫程式碼 奉獻精神和職業精神更多意義上指要遵循紀律原則而非長時間工作的的工作狂 要確保自己已經將睡眠,健康和生活方式調整到最佳狀況,這樣才能做到在每天的8小時工作時間內全力以赴

4.2 流態區

這是程式設計師在編寫程式碼時會進入的一種意識高度專注 但思維視野卻會收攏到狹窄的狀態.在這種狀態下,他們會感到效率極高;在這種狀態中他們會感到"絕無錯誤" 因此他們一直苦苦追求進入這種狀態 並經常以能在那種狀態下 維持多久來衡量自我價值

4.3 阻塞

有的時候.就是死活寫不出程式碼.我自己就曾經遇到過,也看到其他人身上遇到過這種情況,幹坐在電腦前什麼也寫不出 這裡有個簡單的好的方法可以解決這個問題, 這個辦法屢試不爽,既簡單易行,有能夠幫助你寫出很多程式碼,那就是:找個搭檔結對程式設計

4.4 保持節奏

軟體開發是一場馬拉松,而不是短跑衝刺.你無法全程一直以最快的速度衝刺來贏得比賽,只有通過儲存體力和維持穩定節奏來取勝.

4.5 進度延遲

管理延遲的訣竅就是早期檢測和保持透明 要根據目標定期衡量進度,使用三個考慮到多種因素的期限:樂觀預估,標稱預估,悲觀預估

• 4.5.1 期望 如果專案要在十天後發版 而你的常規預估是15天,你是絕對不可能完成任務的,所以不要對十天內全部完成特性開發抱有期望!這種期望會殺死整個專案,期望會毀掉專案進度表,玷汙你的名聲,期望會把你拖進大麻煩中.

• 4.5.2 盲目衝刺 不要經受不住誘惑就盲目衝刺 其實衝刺是做不到的 你無法更快的寫完程式碼. 你無法更快的解決問題, 如果檢視這麼做 最終只會讓自己變得更慢. 同時只能製造出一頓混亂 讓其他人慢下來

• 4.5.3 加班加點 加班確實有用, 而且有時候很有必要,有時候 通過一天工作十個小時在加上週末 你確實能夠達成原本不可能的進度. 但這麼做的風險也很高. 在額外加班20%的工作時間內 你其實並無法完成20%的額外工作而且,如果連續兩三週都要加班工作 則加班的措施必敗無疑

• 4.5.4 交付失誤 在程式設計師所能表現的各種不專業中 最糟糕的是明知道還沒有完成任務 確宣稱已經完成 這時候這只是一個撒過頭的謊言,. 這就已經很糟糕了

• 4.5.5 定義"完成" 可以通過建立一個確定定義 的''完成''標準來避免交付失誤 最好的方法就是讓業務分析師和測試人員建立一個自動化的驗收測試,只有完全通過這些驗收測試,開發任務才能算已經完成

4.6 幫助

程式設計絕非易事 程式設計很難 事實上 僅憑一己之力無法寫出優秀的程式碼.即使你的技能格外高超,也肯定能從另外一名程式設計師的思考與想法中獲益

4.7.1 幫助他人

因此互相幫助是每個程式設計師的職責所在,作為專業人士,要以能夠隨時幫助他人為榮

4.7.2 接受他人的幫助

如果有人向你伸出援手,要誠摯接受,心懷感激的接受幫助並誠意合作,不要死命的護住自己的地盤 拒絕別人的幫助

五 測試驅動開發(TDD)

5.1 TDD 的三項法則

• 1 在編好失敗單元測試之前,不要編寫任何產品程式碼
• 2 只要有一個單元測試失敗了,就不要在寫測試程式碼;否則無法通過編譯也是一種失敗
• 3 產品程式碼恰好能夠讓當前失敗的單元測試成功通過即可,不要多寫 遵循這三項法則的話,大概三十秒就要執行一次程式碼, 先寫好一個單元測試的一部分程式碼, 很快,你會發現還缺少一些類或函式, 所以單元測試無法編譯.因此必須編寫產品程式碼,讓這些測試能夠編譯成功. 產品程式碼夠用即可,然後再哎回頭接著寫單元測試

5.2 TDD 的優勢

• 5.2.1 保證程式碼的確定性
• 5.2.2 降低缺陷注入率
• 5.2.3 勇氣 這是 TDD 強大之處, 擁有一套值得信賴的測試,便可完全打消對修改程式碼的全部恐懼, 當看見糟糕的程式碼是,就可以放手整理, 程式碼會變的具有可塑性,你可以放心打磨出簡單滿意的結果
• 5.2.4 文件 單元測試即是文件, 他們描述了系統設計的最底層設計細節,他們清晰正確,以讀者能夠理解的語言寫成, 並且形式規整可以執行, 他們是最好的底層文件. *5.2.5 專業人士的選擇 本節可以歸結一句話, TDD 是專業人士的選擇.他是一項能夠提升程式碼確定性,給程式設計師鼓勵,降低程式碼缺陷率,優化文件和設計的原則.對 TDD 的各項嘗試表明,不使用 TDD 就說明你可能還不夠專業

5.3 TDD 的侷限

儘管 TDD 有諸多優點,遵循這三個法則並不能擔保一定會帶來上述好處, 及時做到了測試先行, 仍有可能寫出糟糕的程式碼.如果遵循某項法則會弊大於利,專業的開發人員就當然不會選用它

六 練習

專業人士都需要通過專門訓練提升自己的技能 此節主要講的就是要不斷地練習 就像彈鋼琴一樣, 要想自如彈奏,樂手需要反覆的彈奏音節,各種練習曲,重複的節奏,直到爛熟於心.要相信10000小時定律

七 驗收測試(溝通的重要性)

專業開發人員既要做好開發,也要做好溝通

7.1 需求的溝通

PM 和 RD 之間最常見的溝通就是關於需求了的 PM 描述他們認為自己需要的東西, RD 按照自己理解的業務放表達的需求來開發, 至少理論上是這樣的,但是在現實裡 關於需求的溝通是極其困難的,其中會出現各種問題

• 7.1.1 過早的精細化 PM 和 RD 都容易陷入一個陷阱, 即過早進行精細化,
  • 1 不確定原則, 任何一個需求總是不確定 來回改變
  • 2 預估焦慮 評估可以額而且必須基於不那麼精確地需求,這些評估只是評估而已
• 7.1.2 遲來的模糊性 專業的 RD 也包括 PM 必須確認,需求中沒有任何不確定因素

7.2 驗收測試

• 7.2.1 "完成"的定義 身為專業開發人員, 我們經常面對的不確定因素之一就是"完成"的各種說法,開發人員說他已經完成任務了,太想表達什麼意思呢,是指開發人員已經有足夠的信心吧這項功能部署到生產系統,還是他可以準備 QA 程式,或者他已經寫完了程式碼並且跑通了,但還沒有真正測試過
• 7.2.2 溝通 驗收測試的目的是溝通澄清,精確化. 開發方,業務方,測試方對驗收測試達成共識,大家都能明白系統的行為將會是怎樣 各方都應該記錄這種準確的共識, 在專業開發人員看來, 與業務方,測試方協同工作,確保大家都明白要做的是什麼,是自己的責任
• 7.2.3 自動化 專業程式設計師會避免手動測試,相比手動測試來說,自動化測試成本非常低, 讓人手工執行測試指令碼不划算.專業的開發人員認為 實現驗收測試的自動化是自己的責任
• 7.2.4 額外工作 寫這些測試並不是什麼額外的工作,這些測試是為了確定系統的各項指標符合要求,. 確定細節指標的目的,是為了確定系統的指標,只有確定這些系統的指標,我們程式設計師才能確知完成, 只有確認這些指標, 業務方才能確認他們花錢開發的系統確實滿足了需求,只有確認這些指標, 才可以真正做到自動化測試, 所以不要把這些測試看做額外的工作,而應當看成節省時間和金錢的辦法.
• 7.2.5 驗收測試什麼時候寫,有誰來寫 在理想狀態下, PM和 QA 會協作編寫 這些測試, 程式設計師來檢查測試之間是否有衝突或矛盾. 但實際上 業務方通常沒有時間 或者有時間也難以達到所需要的細緻程度 所以他們通常會把測試交給業務分析員,QA 甚至是開發人員.如果只能有開發人員來寫測試,應當確保測試 的程式設計師與開發測試功能的程式設計師不是同一個人
• 7.2.6 開發人員的角色 開發人員有責任吧驗收測試與系統聯絡起來,然後讓這些測試通過
• 7.2.7 測試的協商與被動推進 身為專業開發人員, 與編寫測試的人協商並改進測試是你的責任.決不能被動接受測試
• 7.2.8 驗收測試和單元測試 單元測試是程式設計師寫給程式設計師的 他是正式的設計文件,描述了底層結構及程式碼的行為, 關心單元測試的結果是程式設計師而不是業務人員 驗收測試是業務方寫給業務方的 他們是正式的需求文件 描述了業務放認為 系統應該如何執行.關心驗收測試結果的是業務方和程式設計師

7.3 結論

要解決開發方和業務方的問題,我所知道的唯一的解決辦法就是編寫出無可挑剔的需求文件

八 測試策略

每個專業的開發團隊都需要一套好的測試策略

8.1 QA 應該找不到任何錯誤

我們努力的目標應該是讓 QA 應該找不到任何錯誤

8.2 自動化測試金字塔

擁有一套單元測試和驗收測試的 同事 還需要更高層次的測試,這樣 QA 才找不出任何錯誤 如下圖

• 8.2.1 單元測試 在金字塔底部就是單元測試,這些單元測試作為持續整合的一部分來執行,用以確保程式設計師的程式碼意圖沒有遭到破壞
• 8.2.2 元件測試 元件測試是驗收測試的一種 他們針對系統的各個元件而編寫的 元件的測試差不多可以覆蓋系統的一半
• 8.2.3 整合測試 整合測試只對那些元件很多的大型系統才有意義,整合測試一般有系統架構師或主設計師編寫
• 8.2.4 系統測試 這個測試是針對整個完畢的系統進行的自動化測試,是最終的整合測試,這個測試中 ,應該包含吞吐率測試和效能測試
• 8.2.5 人工探索式測試 這些測試的意圖 是要在驗證預期行為的時候,探索系統預期之外的行為.為了達到這個目的,需要人類智慧的介入,需要人類的創新能力

九 時間管理

八小時其實非常短暫, 只有480分鐘 28800秒,身為專業開發人員,你肯定希望能在這短暫的時間裡儘可能高效的工作,取得儘可能多的成果

9.1 會議

關於會議 有兩條真理: (1) 會議是必需的 (2) 會議浪費了大量的時間

專業的開發人員同樣清楚會議的高昂成本, 他們同樣清楚自己的時間是寶貴的,他們同樣需要時間來寫程式碼,來處理日程表上的事物,所以 如果會議沒有現實且顯著 的成效,他們會主動拒絕

• 9.1.1 拒絕 受到邀請的會議沒有必要全部參加, 參加的會議太多,其實只能證明你不夠專業.你應該理智的使用時間,所以 必須要謹慎選擇, 應當參加那些會議, 禮貌拒絕那些會議 好的領導一定會主動維護你拒絕出席的決定,因為她和你一樣關心你的時間

• 9.1.2 離席 重要的是,你應該明白, 繼續待在會議室裡是浪費時間; 繼續參加對你沒有意義的會議是不專業的行為, 因為你有責任合理分配老闆給你的時間和金錢, 所以選擇一個合適的機會商量如何離席,並非不專業的做法

• 9.1.3 確定議程 和 目標 為了合理使用與會者的時間,會議應當有清晰的議程, 確定每個議程所花的時間以及確定的目標

• 9.1.4 立會 讓立會簡潔

• 9.1.5 迭代計劃會議 迭代計劃會議用來選擇在下一輪迭代中實現的開發任務, 在會議召開前必須完成兩項任務: 評估可選擇任務的開發時間, 確定這些任務的業務價值, 如果組織的足夠好, 驗收和元件測試也應當在會議召開前完成,或者至少要有概略方案

• 9.1.6 迭代回顧和 Demo 演示 此類會議用來讓業務方可以看到最新工作的成果的 DEmo 這類會議可能浪費很多時間, 所以不妨在最後一天下班前45分鐘召開, 花20分鐘來回顧, 花25分鐘來演示

• 9.1.7 爭論/反對 凡是不能再5分鐘內解決的 爭論, 都不能靠辯論來解決 因為爭論之所以話這麼長時間,就是因為各方都拿不出足夠有力的證據, 所以應當儘量控制爭論的時間

9.2 注意力點數

程式設計是需要持續投入精力和注意力的智力活動.注意力是稀缺的資源,它類似魔力點數,如果你用光了自己的注意力點數, 必須花一個小時或更多的時間做不需要注意力的事情,來補充他

• 9.2.1 睡眠 睡眠的重要性怎麼強調都不為過,專業的開發人員會安排好他們的睡眠, 保證清晨有飽滿的注意力點數去上班

• 9.2.2 咖啡因 毋庸置疑,對有些人來說,適量的咖啡因可以幫他們更有效的使用注意力點數

• 9.2.3 恢復 在你不集中注意力的時候,注意力點數可以慢慢恢復,漫長的一段長路,與朋友聊天, 看看窗外, 都有助於恢復注意力點數

• 9.2.4 肌肉注意力

肌肉注意力有助於改善心智注意力, 而且不僅僅是簡單的恢復, 我發現定期培訓肌肉和注意力,可以提升心智注意力的上限. 比如我自己 我就會經常的跑步鍛鍊身體

• 9.2.5 輸入與輸出 關於注意力, 我知道的另一個重點是平衡輸入與輸出, 程式設計是一項創造性勞動, 我發現如果能接觸到其他人的創造思維,我的創造力也最旺盛,

9.3 時間拆分和番茄工作法

其基本思想很簡單, 把廚房用的計時器(通常他們很想番茄) 設定到25分鐘, 倒數計時期間不要讓任何事情干擾你的工作

9.4 死衚衕

所有軟體開發者都要遇到死衚衕 比如你做了一個決定,選擇了走不通的技術道路.你對這個絕地個越是堅持,浪費的時間就越多, 專業人員不會執拗有不讓放棄也無法繞開的注意, 他們會保持開放的頭腦來聽取其他意見

9.5 泥潭

比死衚衕更糟的是泥潭,泥潭會減慢你的速度,專業開發人員對泥潭的恐懼遠遠大於死衚衕.他們會時刻留神顯露出來的泥潭, 然後運用各種努力,儘早儘快的脫身,

9.6 結論

專業的開發人員會用心管理自己的時間和注意力, 他們知道優先順序錯亂的誘惑, 他們也珍視自己的聲譽. 所以會抵制優先順序錯亂, 他們永遠有多種選擇,永遠敞開心扉聽取其他解決方案, 他們從來不會執拗於某個無法放棄的解決方案, 他們也時刻警惕著正在顯露的泥潭,一旦看清楚 就會避開.

10 預估

預估是軟體開發人員面對的最簡單也是最可怕的活動之一了,預估影響到的商業價值巨大關乎聲譽嗎預估是也業務人員和開發人員之間最重要的障礙, 橫亙在雙方之間的種種不信任幾乎都由他引發

10.1 什麼是預估

問題在於 不同的人對預估不同的看法.業務方覺得預估就是承諾, 開發方認為預估就是猜測, 兩者相差迥異

• 10.1.1 承諾 承諾是必須做到的 如果你承諾在哎某天做成某件事, 就必須按時完成, 即便他意味著你必須每天工作12個小時, 放棄週末的休假, 也不得不如此, 既然承諾了,就必須要實現

• 10.1.2 預估 預估是一種猜測, 預估無關聲譽,不幸的是,大多數軟體開發人員都很不擅長預估

• 10.1.3 暗示性承諾 專業開發人員能夠清楚地區分預估和承諾, 只有在確切知道可以完成的前提下, 他們才會給出承諾, 此外, 他們也會小心避免給出暗示性的承諾, 他們會盡可能清楚的說明預估的概率分佈, 這樣主管就可以作出合適的計劃了

10.2 PERT 計劃評審計劃

簡單的 PERT 計算說明了一種避免樂觀預估的合理方法, 不管嘗試加快進度的壓力有多大, 專業開發人員都應當謹慎的設定合理的預估值

10.3 結論

專業的開發人員懂得如何為業務人員提供可信的預估結果,以便做出計劃,如果做不到或者不確定能做到,專業開發人員不會給出承諾 一旦做出了承諾, 就會提供確定的數字, 按時兌現, 但是在大多數情況下, 他們都不會做這種承諾, 而是提供概率預估,來描述期望的完成時間及可能的變數

11 壓力

即使有巨大的壓力, 專業的開發人員也會冷靜果斷. 儘管壓力不斷增大, 他仍然會堅守所受的訓練和紀律, 他知道這些是他賴以戰勝有最後期限和承諾所帶來的壓力感的最好方法

11.1 避免壓力

在壓力下保持冷靜的最好方式,便是規避會導致壓力的處境, 規避的方式也許無法完全檢出壓力, 但是可以大大降低壓力並縮短高壓力期的時間

• 11.1.1 承諾 之前第十章已經說過,我們應該避免對沒有把握能夠完成的最後期限作出承諾 避免給自己帶來不可估量的後續問題
• 11.1.2 把持整潔 讓系統,程式碼和設計儘可能整潔, 就可以避免壓力, 這並非是說我們要花無窮無盡的時間去清理程式碼, 而只是說不要容忍混亂, 混亂會降低速度, 導致工期延誤, 承諾失信, 因此,要盡力保持輸出成果整潔乾淨
• 11.1.3 危機中的紀律 當困境臨降時, 也不要改變工作方式, 如果你遵守的紀律原則是工作的最佳方式, 那麼即使在深度危機中也要堅決秉承這些紀律原則

11.2 應對壓力

• 11.2.1 不要驚慌失措 正確對待壓力, 放鬆下來,對問題深思熟慮,努力尋找可以帶來最好結果的路徑, 然後沿著那條路徑一合理穩定的節奏前進

• 11.2.2 溝通 多多溝通,讓你的團隊和主管知道你正深陷困境之中, 告訴他們你所制定的走出困境的最佳計劃, 請求他們支援,避免產生驚恐,沒有東西比驚恐更令人憤怒和市區理性,驚恐會讓你的壓力增大十倍

• 11.2.3 依靠你的紀律原則 當事情十分困難的時候,要堅信你的紀律原則,他們可以指引你度過高壓期

11.3 結論

應對的訣竅在於,能迴避壓力是儘可能迴避,當無法迴避是則勇敢直面壓力, 可以通過慎重承諾, 遵循自己的紀律原則,保持整潔等來回避壓力.直面壓力時, 則要保持冷靜, 與別人多多溝通, 堅守自己的原則和紀律 並尋求他人的幫助.

12 協作

大多數軟體都是由團隊開發出來的,當團隊成員能夠十分專業的互相協作時, 整個團隊是最為高效的, 單打獨鬥與遊離於團隊之外都是不專業的表現

12.1 程式設計師與人

我們並非是因為喜歡和其他人一起工作才選擇做程式設計師的, 我們都認為人人際關係難以應付而且毫無規律.程式設計用的機器則整潔,行為也可預見,如果可以一個人待在房間裡數個小數沉浸在一些真正有趣的問題上, 那將會是最開心的時光

• 12.1.1 程式設計師與僱主 專業的程式設計師的首要職責是滿足僱主的需求.這意味著要和你的經理們,業務分析師門,測試工程師門,和其他團隊成員很好的協作, 深刻理解業務目標, 這並不是說你必須要成為業務方面的老學究,而是說你需要理解手上正在編寫的程式碼的業務價值是什麼,瞭解僱你的企業將如何從你的工作中獲得回報

• 12.1.2 程式設計師與程式設計師 程式設計師之間很難密切合作,這就會帶來不小的問題

  • 程式碼個體所有 不正常的團隊最糟糕的情況是,每個程式設計師在自己的程式碼周邊築起一道高牆, 拒絕 讓其他程式設計師接觸到這些程式碼
  • 2 協作性的程式碼共有權
    專業的開發人員是不會阻止別人修改程式碼的, 他們不會再程式碼上構造所有權的藩籬,而是儘可能多的合作, 他們通過合作來達到學習的目的

12.2 結論

也許我們不是因為通過程式設計可以和人互相協作才選擇從事這項工作的, 但真不走運,程式設計就意味著與人協作.我們需要和業務人員一起工作,我們之間也需要互相合作. 如果我們真想終生能以程式設計度日,那麼一定要學會交流 ,和大家交流

13 團隊和專案

小專案該如何實施? 如何給程式設計師分派? 大專案有該如何實施?

13.1 只是簡單混合麼

讓一個程式設計師把一半的時間投入到專案 A 中,把其餘時間投入到專案 B 中,這並不可行,尤其是當這連個專案的專案經理不同,業務分析師不同,程式設計師不同,測試人員不同是,更不可行.這不是一個團隊,只是從榨汁機中榨出的混合物而已

• 13.1.1 有凝聚力的團隊

形成團隊是需要時間的,團隊成員需要先建立關係,他們需要學習如何互相協助,需要了解彼此的癖好,強項,弱項,最終才能凝聚成團隊, 有凝聚力的團隊確實有些神奇之處, 他們能夠一起創造奇蹟,他們互為知己,能夠替對方著想, 互相支援, 激勵對方拿出自己最好的表現,他們攻無不克

• 13.1.2 如何管理好有凝聚力的團隊 每個團隊都有自己的速度,團隊的速度,即是指在一定時間段內團隊能夠完成的工作量,有些團隊使用每週點數來衡量自己的速度,其中"點數"是一種關於複雜度的單位. 管理人員可以依據團隊的平均速度來合理分配每週工作的點數

13.2 結論

團隊比專案更難構建 .因此 組建穩健的團隊,讓團隊在一個又一個專案中整體移動共同工作是較好的做法, 並且 團隊也可以同時承接多個專案, 在組建團隊是, 要給予團隊充足的時間, 讓他們形成凝聚力, 一直共同工作,成為不斷交付專案的強大引擎

一週的零碎時間將此書讀完並整理出每節重要內容,書中更多的是結合公司中實際例子來說明每一個點的重要性,希望每個開發都能成為像 bob 大叔一樣厲害的人