《程序員的職業素養之代碼整潔之道》成爲專業人士必讀

此處悼念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 大叔同樣厲害的人