無暇的程式碼- 專業程式設計師

[hsiaofung]

問題

1. 如何回應需求?

   • Yes or No : 完成一項行動的時間。
   • 明確說明完成時間

2. 可能的主題?

   • 時間管理
   • 壓力
   • 預估專案進度
   • 協作(合作開發)

3. 什麼是軟體專業人士?

4. 軟體專業人士如何行事?

5. 軟體專業人士如何處理衝突? 應對緊湊的開發進度，如何和不切實際的管理人員打交道?

6. 軟體專業人士何時應該說"不"? 怎麼說?

7. 軟體專業人士如何應對壓力?

目錄:

• 專業主義
• 說不
• 說是
• 寫程式
• 測試驅動開發
• 練習
• 驗收測試
• 測試策略
• 時間管理
• 預估
• 壓力
• 協作
• 團隊與專案
• 輔導、學徒期與工藝典範

[hsiaofung]

專業主義:

如何定義專業程式設計師?

• 需要什麼樣的態度、原則與行動?
• 只能從你負責的地方得到榮譽與驕傲
• 專業主義: 意味著"擔當責任"，將公司利益視同個人利益。(以公司的利益做決策)
  • 不專業 = 不負責。
• 測試還未完成、自己不能按時交付產品。

專業 = 負責，不專業=不負責

我們該如何承擔責任?

• 要做的專業，就不能留下bug
• 專業人士就是能對自己所犯錯誤負責的人
• 道歉
• 你有責任讓失誤率接近0。
• 讓QA找不出任何問題。
• 把自己沒把握的程式碼發送給QA，這麼做本身就是不專業。
• 反思那些bug是如何逃過你的注意，並想辦法防止它再次出現。

如何知道程式碼能否正常工作呢?

• 測試!一遍遍地測，翻來覆去地測，使出渾身解數來測!
• 自動化測試，執行單元測試。盡可能多執行這些測試。
• 要用這些自動化"單元測試"去測多少程式碼? 全部，全部都要測。
• 100%的測試覆蓋率，每一行的程式都要測試。
• 想要知道你寫的程式碼是否可行，就一定要對它進行測試。
• 一開始就要設計"易於測試的程式碼"，最好是先寫測試，再寫程式碼。(TDD)
• 單元測試、驗收測試
• 做為開發人員你需要有個快速且可靠的機制，來判斷所寫的程式是否能正常工作，並且不會干擾系統的其他部分。至少，你的自動化測試要讓你知道，你的系統很有可能通過QA測試。
• 建立靈活可維護的結構 : 專業的軟體發展人員會牢記這些原則與模式，並在開發軟體時認真遵循。

如何知道你的軟體易於修改?

• 想要證明軟體易於修改 : 那就應該時常修改它!
• 如果發現這些修改並不如你預想的簡單，就應該改進設計，使後續的修改變得簡單一些。
• 該在何時做小修改? 隨時!
• 童子軍規則 : 對每個模組，每次check in 一次程式碼，就要讓它比上次check out 時，變得更為簡潔。每次讀程式碼，都別忘了進行些許改善。
• 讓軟體固定是危險的!，如果一直不重構程式碼，等到最後不得不重構時，你就會發現程式碼已經僵化了。
• 結論: 如果你有一套覆蓋了所有程式碼的自動化測試，如果那套測試可以隨時快速執行，那麼你根本不會害怕修改程式碼。怎樣才能證明你不害怕修改程式碼呢? 那就是，你一直改。

職業道德

• 一周40小時應該用來解決雇主的問題，而不是你自己的問題。
• 你應該計畫每周工作60小時，前40小時給雇主，後20小時給自己，看書、練習、學習、或做其他提升職業能力的事。
• 例如: 每天3小時，午飯看書，通勤聽播客，花90分鐘學一門新的語言。
• 在那20小時，應該做能夠激發、強化你熱情的事。那20小時應當充滿樂趣。

瞭解你的領域

• 各種觀點、實踐、技術、工具與術語在我們這個領域層出不窮。如果想成為一名專業開發者，你就必須對其中相當大的一部分有所瞭解，而且要不斷擴展"這一部分"的範圍，充實更多的知識。
• 至少必須精通的事
  • 設計模式 : GOF 24 種模式、POSA
  • 設計原則: SOLID、深刻理解元件設計原則
  • 方法: XP、Scrum、精益(Lean)、看板(Kanban)、瀑布、結構化分析及結構化設計。
  • 學科: 必須練習測試驅動開發TDD、物件導向設計OOD、結構化程式設計、持續整合(Continuous Integration)和結對程式設計(Pair Programming)
  • 工具: 如何使用UML圖、DFD圖、結構圖、Petri網路圖、狀態遷移圖表、流程圖和決策表。

堅持學習

• 軟體發展人員必須堅持廣泛學習財部至於落伍
• 不寫程式、不學新語言、學不會新原則和技術都將跟不上時代。
• 雇主為什麼要聘用不能與時俱進的開發人員?
• 讀書、看相關文章、關注部落格、參加技術大會、訪問用戶群、讀書會、學習小組。
• Java、Ruby、.NET.....

練習 : 軟體發展者該如何不斷的訓練自己?

• 熟能生巧。真正的專業人士往往勤學苦幹，以求得自身技能的純熟精煉。
• 只完成日常工作並不足以被稱之為練習，練習指的是在日常工作之餘專門練習技能，以期自我提升。
• 重複做一些簡單的練習 : 不是要找出解決方法，而是訓練手指和大腦。
• 時間可安排在正式投入工作之前。
• 可用重複練習培養某種專門的技能: 比如使手指習慣點擊快速鍵，或習慣使用某些重構技法。

協作

• 學習的第二個最佳方法是與他人合作
• 專業軟體開發人員往往會更努力嘗試與他人一起寫程式、一起練習、一起設計、一起計畫，這樣可以從彼此身上學到很多東西。

輔導

• 教學相長 : 想迅速牢固地掌握某些事實和觀念，最好的方法就是和"由你負責"的人交流這些內容。傳道授業的同時，導師也會從中受益。
• 讓新人融入團隊的最好辦法是和他們坐在一起，向他們傳授工作的要訣。
• 專業人士會視輔導新人為己任，他們不會放任未經輔導的新手胡打亂撞。

瞭解業務領域

• 每位專業軟體開發人員都有義務瞭解自己開發的解決方案所對應的業務領域。
• 你未必要成為該領域的專家，但你仍需要勤勉，付出相當的努力來認識業務領域。
• 開始一個新領域的專案時，應當閱讀一兩本有關該領域的書籍，要以該領域的基礎架構與基本知識進行客戶和使用者訪談
• 還應當花時間和業內專家進行交流，瞭解他們的原則與價值觀。
• 最不專業的做法是，只簡單地按照規格說明來撰寫程式碼，但卻對於那些業務為什麼需要做那樣的規格定義不求甚解。
• 專業的是，你應該對該領域有所瞭解，能辨別、質疑規格說明書中的錯誤。

與雇主/客戶保持一致

• 雇主的問題就是你的問題，你必須弄明白這些問題，並尋求最佳解決方案
• 每次開發系統，都應該"站在雇主的角度"來思考，確保開發的功能可以真正滿足雇主的需求。
• 專業人士應該盡力避免"雇主"，"開發人員"之分。

謙遜

• 勇於承擔有把握的風險，專業人士不是膽小鬼。
• 不因別人犯錯就貶低、嘲諷對方。也不因自己犯錯就看不起自己。笑笑即可。莫聽穿林打葉聲，何妨吟嘯且徐行。

[hsiaofung]

說不

• 該在何時以及該怎樣說"不"

寫出好程式，有可能嗎? 堅守專業主義的精神，有可能嗎?

• 是的。但你要學會如何說"不"。

如何學會說不?

[hsiaofung]

說是

• 承諾包含3個步驟
  • 口頭上說自己將會去做。
  • 心理認真對待自己所做出的承諾。
  • 真的付諸行動去做。

如何辨識缺乏承諾?

• 話中有以下這些詞
  • 需要/應當
  • 希望/但願
  • 讓我們而不讓我

如何識別真正的承諾?

• 識別真正的承諾要訣在，要去搜尋與下相似的語句:
  • 我將在.....之前.......(例如 : 我將在星期二之前完成這個任務)
  • 你對自己將會做某事做了清晰的事實陳述，而且還明確說明了完成期限。
  • 關鍵: 談的是你自己、會去做的一項行動、會做到。
  • 第一步驟: 承諾、第二步驟: 言必信，行必果。

若我的成功需要某某人去做某某事?

• 你只能承諾自己能完全掌控的事。
• 如果最終目標依賴他人，那麼你就應該採取些具體行動已接近最終目標。

不太確定是否能完成?

• 弄清楚"目標能否達成"這件事，便是你可以採取的努力行動之一。

因為無能為力? + 例如: 你承諾要解決某個你認為可以解決的bug，但隨後發現解決起來要遠比自己預期的棘手

• 有些事可能事先沒預料到。
• 如果你無法兌現承諾，那麼最重要的就是"儘早向你的承諾對象發出預警，越快越好，越早越好。"
• 發出預警訊號。這樣一來，專案小組還可以做些研究，決定是否採取一些行動來達成目標。

學習如何說是

• 試試代表兩種可能 : 仍有餘力可施，或可能做得到，也可能做不到。
• 回歸測試 : 當程式進行修改後，檢查修該之前能正常執行的功能是否仍舊能夠無誤地執行。
• 身為專業人員不能放棄底線 : 寫測試、重構、回歸測試。
• 身為專業開發人員，有責任根據標準來規範自身的工作。程式碼必須經過測試，程式碼必須有相對應的測試程式碼。要確保程式碼清晰整潔，而且必須確保沒有影響到系統的其他部分。

[hsiaofung]

寫程式

疲勞的時候寫程式

• 專業的精神應該是"遵循紀律原則"而非成為"長時間的工作狂"。
• 要確保自己已經將睡眠、健康、和生活方式調整到最佳狀況，這樣才能做到在每天的8小時工作時間內全力以赴。

焦慮的時候寫程式

• 這時候不該寫程式，應該先解除焦慮情緒。
• 先花1個小時解除焦慮。
• 專業開發人員善於合理分配個人時間，以確保工作期間的時間段中盡可能富有成效。
• 在家中就應該專門安排時間解決焦慮，這樣就不會把焦慮情緒帶進辦公室。

流態區

• 流態區不一定好，只能敲出更多的程式碼。
• 在練習時進入流態區是OK的。
• 使用結對程式設計可以防止進入流態區。

音樂

• 聽音樂無法讓人寫好程式碼。

中斷

• 結對的夥伴可以幫你回復中斷前的狀態。
• TDD的失敗測試就是你被中斷後回去處理的任務。
• 被中斷，禮貌地表現出樂於助人的態度才是專業的態度。
• 停下手邊的工作，禮貌地幫助那些碰到困難的人。

阻塞

• 睡眠、焦慮、恐懼和沮喪會導致阻塞。什麼程式也寫不出來。
• 可以去做各式各樣的事，以便你不必死盯著螢幕，乾坐在那裏。
• 或是找一個搭檔結對設計。

創意輸入

• 創意激發創意
• 看科幻小說

除錯

• 使用TDD降低除錯時間。
• 衡量你是否為一名專業人士的一個重要項目，便是看你是否能降低除錯時間。絕對的零除錯時間。
• 製造出許多bug的軟體開發人員也不專業。

保持節奏

• 你無法全程一直以最快速衝刺來贏得比賽，只有透過保存體力和維持穩定節奏來取勝。
• 專業的程式設計師 : 會仔細保存好自己的精力和創造力。
• 應該知道何時該離開一會兒 : 回家，問題可能豁然開朗。
• 當你碰到困難而受阻，當你感到疲倦時，就離開一會。
• 回家的路上
• 洗澡
• 讓大腦脫離問題，休息一下，反而可以解決問題。

進度延遲

• 不要到最後一天才告訴人家你無法完成工作。
• 要根據目標定期衡量進度。
• 使用三個期限: 樂觀預估、常規預估、悲觀預估。並每天修正這些數字。

期望 : 如果會錯過最終期限，該怎麼辦?

• 不要輕易鬆口讓步。不要讓其他任何人抱有期望。

盲目衝刺 : 如果經理要求你盡力趕上最後截止期限，該怎麼辦?

• 堅持維持住你的預估，縮減範圍，不要經受不住誘惑盲目衝刺。

要求超時加班，該怎麼辦?

• 如果兩三個禮拜都需要加班，表示時間一定不夠。
• 如果加班還是來不及完成?

交付失敗

• 明知沒完成任務，卻宣告完成。
• 降低完成的定義。
• 定義"完成" : 透過建立一個確切定義的完成標準來避免交付失敗。最好的方法是讓業務分析師和測試人員建立一個自動化的驗收測試。只有完全通過這些驗收測試，開發任務才能算完成。
• 利害相關者和業務人員應該也能輕鬆理解這些測試，並且要經常執行這些測試。

幫助

• 互相幫助是每位程式設計師的職責所在。將自己封閉在OA隔間或辦公室裡與世隔絕，有悖於專業精神。
• 作為專業人士，你要以能隨時幫助別人為榮。
• 要清楚團隊夥伴的狀態。如果有人看起來遇到了麻煩，就應該向他提供幫助。
• 給他人提供幫助並非說明你比別人聰明很多，而是因為你帶來一個新的視角，對於解決問題起了顯著的催化作用。
• 所以不要羞於啟齒因為沒辦法真正解決問題，有時提供對方另一種想法、視角也有助於解決問題。
• 要好好的幫助他人，不要讓人家覺得你是隨隨便便的。好像是應付似的。
  • 比如: 等到對方說OK，再見。可以了....等等的話。
  • 問題真正解決了
  • 問題沒解決，但可以給對方新的想法。
  • 一起解決問題，例如: 坐下來一起解bug，坐下來一起寫程式、寫測試，坐下來一起解決問題。

接受他人幫助

• 如果有人向你伸出援手，要誠摯地接受，心懷感激地接受幫助並誠意合作。
• 不要死命護住自己的地盤拒絕別人的幫助。
• 如同要以"樂於助人"為榮一樣，也要以"樂於接受別人的幫助"為榮。
• 專業的職業精神: 如果幫助垂手可得，卻讓自己一個人杵在那哩，是很不專業的表現。

輔導

• 輔導缺乏經驗的程式設計師是那些經驗豐富的程式設計師的專業職責。
• 向資深導師尋求輔導，也是年輕程式設計師的"專業職責"。

[hsiaofung]

測試驅動開發

• 先寫測試的程式設計方式。
• 如果所有的程式碼是否能夠正常工作都不確定，那還算什麼專業人士?
• 如果每次修改程式碼後沒有測試? 如何能夠知道所有程式碼可以正常工作?
• 如果缺乏極高覆蓋率的自動化單元測試，如何能做到每次修改程式碼後都對程式碼進行測試?
• 如果不採用TDD，如何能夠獲得極高覆蓋率的自動化單元測試?

TDD的三大法則

• 如果將TDD作為行業的一項紀律，那麼每天要寫上幾十個測試，每週要寫上成千上百個測試，每年寫上成千上萬個測試
• 任何時刻，程式碼有任何修改，都必須執行手頭的所有測試。
• 如果單元測試全部通過，差不多就可以確信新的修改沒有破壞任何東西。(足以交付)
• 完整建置、單元測試、驗收測試。
• 降低缺陷率。

專業程式設計師怎麼容忍程式碼持續劣化?

• TDD : 讓程式設計師有勇氣整理程式碼。

專業程式設計師提供什麼樣的文件?

• TDD : 單元測試就是文件。它們描述了系統的最底層設計細節。它們清晰準確，以讀者能夠理解的語言寫成，並且形式規整可以執行。它們是最好的底層文件。

什麼才是好的設計

• 基於測試先行的需要，會迫使你去思考什麼才是好的設計。
• 如果不先寫測試，就有可能出現各個函式耦合在一起，最終變成無法測試的一大團問題。如果後面再寫測試，你也許能夠測試整個大塊的輸入和輸出，但是很難測試單個函式。

那個專業人士不想採用能夠促使他們做出"更好的設計"的工具呢?

TDD是專業人士的選擇。

• 它是一項能夠提升程式碼確定性、給程式設計師鼓勵、降低程式碼缺陷、強化文件和設計原則。TDD的各項優點表明一件事，不使用TDD就說明你可能還不夠專業。

TDD 的侷限

• 遵循這三大法則並不能擔保一定會帶來上述好處。
• 如果遵循某項法則會弊大於利，專業的開發人員當然就不會選用它。

[hsiaofung]

練習 : 程式設計師如何提升專業技能

• 專業人士都需要練習。他們這麼做是因為他們關心"自己能做到怎樣的最好結果"。更重要的是他們用自己的時間練習 因為他們知道保持自己的技能不落伍是"自己的責任"，而不是雇主的責任。
• 練習一系列的問題和解決方法，一而再，再而三的練習直到熟練為止。
• 練習者不是在解決問題，而是練習解決這個問題所需的動作和決策。
• 逐步練習以達純熟。
• 找一套Kata來練習: TDD、CI
• 通用的問題，解決方案之間的聯繫，遇到問題可以馬上解決

程式設計柔道場

• 為開放原始碼貢獻程式碼。
• Kata、自由練習、wasa

[hsiaofung]

驗收測試

• 專業開發人員既要做好開發，也要做好溝通。
• 若輸入是垃圾，輸出也會是垃圾。
• 專業程式設計師會重視與團隊及業務部門的溝通，確保這種溝通準確、流暢。

需求的溝通 : 客戶怎麼發現他們想要的東西?

• 他們對功能的設想，其實經不起在電腦前真刀真槍的考驗。
• 過早精細化
• 東西畫在紙上與真正做出來是不一樣。
• 觀察者效應或不確定原則 : 每次你向業務展示新功能，他們就獲得比之前更多的訊息，這些新訊息反過來又影響他們對於整個系統的看法。
• 專業開發人員知道，預估可以而且必須基於"那不怎麼精確的需求"，這些預估只是預估而已。為了強調這一點，專業開發人員通常會在預估中使用誤差棒，這樣業務就能理解不確定性。
• 專業的開發人員(也包括業務方)必須確認，需求中沒有任何不確定因素。

驗收測試 : 解決需求的不確定因素

• 這裡定義為 : 業務方與開發方合作編寫的測試，其目的在於確定需求已經完成了。
• 需求完成的定義 :
• 專業開發人員的完成定義: 即完成就是完成，完成意味著所有的程式碼都寫完了，所有的測試都通過了，QA和需求方已經認可。如此，才叫完成。

如何達到完成，必且保持開發過程中每次Iteration的速度呢?

• 應該編寫整套的自動化測試，他們全部通過，就意味著滿足了所有的要求。如果對功能的驗收測試全部通過，就算真正完成。
• 專業開發人員會根據自動化的驗收測試來定義需求。他們與業務方和QA一起工作，確保自動化測試能夠真正完整地覆蓋所需的各項指標。

溝通

• 驗收測試的目的是溝通、澄清及精確化。開發方、業務方、測試方對驗收測試達成共識。
• 大家都明白系統的行為將會是怎樣。各方都應當努力達成這種清晰準確的共識。
• 從專業人員的眼光來看 : 與業務方、測試方協同工作，確保大家都明白要做的是什麼，是自己的責任。

自動化

• 驗收測試總是自動化，驗收測試不應當手工進行，原因很簡單要考慮成本
• 專業的開發人員認為，實現驗收測試自動化是自己的責任。

額外的工作

• 寫這些測試是為了確定系統的各項指標符合要求。
• 只有確定這些細節指標，程式設計師才能確知完成。
• 只有確定這些細節指標，業務方才能確認它們花錢開發的系統確實滿足了需求。
• 只有確認這些指標，才可以真正做到自動化測試。
• 這些測試可以避免你的開發誤入歧途，也可以幫你確認自己是否已經完工。

驗收測試什麼時候寫，又該由誰來寫

• 如果只能由開發人員來寫測試，應當確保寫測試的程式設計師與開發被測試功能的程式設計師不是同一人。
• 業務分析員 : 測試正確路徑，以證明功能的業務價值。
• QA : 測試錯誤路徑、邊界條件、異常、例外情況。考慮哪些部分可能出問題。
• 遵循"推遲精細化"原則，所以驗收測試應該越晚越好，通常是功能實作完成的前幾天。
• 在敏捷專案中，只有在選定了下一輪sprint所需要的功能之後，才編寫測試。
• Iteration 開始的第一天，就應當準備好最初的幾項驗收測試。然後每天都應當完成一些驗收測試，到Iteration 的中間點，所有測試都應當準備完畢。
• 如果這時候還沒準備好所有的測試，就必須抽調一些開發人員來完成測試的撰寫工作。如果這種情況經常發生，這個團隊應當增加BA或QA人員。

測試的協商與被動推進

• 寫測試的人也是普通人，也可能會犯錯。
• 身為專業開發人員，"與撰寫測試的人協商並改進測試"是你的職責。絕不能被動接受測試，更不能對自己說: "哦，測試就是這麼要求的，我就得這麼做。
• 請記住，身為專業開人員，你的職責是協助團隊開發出最棒的軟體。也就是說，每個人都需要關心錯誤和疏忽，並協力予以改正。

驗收測試和單元測試

• 驗收測試不是單元測試。
• 單元測試是程式設計師寫給程式設計師的，它是正式的設計文件，描述了底層結構及程式碼的行為。關心單元測試結果的是程式設計師而不是業務人員。
• 驗收測試是業務方寫給業務方的(雖然可能最後是身為開發者的你來寫)。它們是正式的需求文件，描述了業務方認為系統應該如何運行。關心驗收測試結果的是業務方和程式設計師。
• 單元測試是深入系統內部進行，呼叫特定類別的方法。
• 驗收測試則是在系統外部，通常是在API或UI層級進行。兩者的執行路徑是截然不同。
• 這兩種測試並不重複的根本理由在於，它們的主要功能其實不是測試，測試只是它們的附屬職能。單元測試和驗收測試首重的是文件，然後才是測試。它們的主要目的是以文件如實描述系統的設計、結構、行為。事實上，它們雖然自動地驗證了設計、結構、行為是否達到了指定的規格，但是，它們的真正目的並不是測試上，而是在規格上。

圖形介面及其他複雜因素

• GUI通常是不斷變化的。
• GUI背後的功能卻不會因為效率和美觀的因素而變化。所以，在編寫GUI的驗收測試時，必須使用GUI背後相對穩定的抽象元素。
• 如果一個頁面有7個按鈕，應該根據有明確意義的ID來點擊，而不是根據座標、名稱。
• 要把GUI和業務邏輯分開 : 測試系統功能時，應當呼叫真實的API，而不是GUI。測試程式應當直接呼叫GUI使用的API。
• 透過GUI來進行測試非常容易出問題，除非你要測試的僅僅只有GUI，因為GUI很容易變化，所以針對GUI的測試很不穩定。
• 如果GUI的每一次變動之後，都會有成千上百個測試無法通過，那麼最好放棄這些測試，或者不要更動GUI。兩者都只是補救，根本的辦法還是透過呼叫GUI背後的API來測試業務邏輯。
• 最好把GUI和業務規則"去耦合"，在測試GUI本身，用Stub(測試替身" fake、mock)替代業務規則。
• 應當盡可能地減少GUI測試。GUI很容易變化，所以這類測試是不穩定的。GUI測試越多，維護它們的難度就越大。

持續整合

• 請務必確保在持續整合的系統中，單元測試和驗收測試每天都能執行好幾次。
• 整套持續整合系統應該由原始程式碼管理系統來觸發。只要有人提交程式碼，持續整合系統就會開始建置，並執行所有的測試，測試結果會用電子郵件發給團隊的每一個人。
• 立刻中止 : 保持CI測試時時都在執行是非常重要的，並且永遠不應該失敗，如果失敗了，團隊裡的每一個人都應該停下手裡的工作，看看如何才能讓測試通過。

[hsiaofung]

測試策略

• 應該要把QA找不到任何錯誤作為努力的目標。
• 對QA找到的每一個問題，開發團隊都應該高度重視、認真對待。應該反思為什麼會出現這種錯誤，並採取措施避免今後重犯。
• QA和開發人員應該緊密協作，攜手保障系統的品質。
• QA是需求規約定義者: QA的任務是和業務人員一起建立自動化驗收測試，以作為系統真正的需求規約文件。
• 再一遍又一遍的iteration中，他們可以從業務人員那裏收集需求，將之翻譯為"向開發人員描述系統行為的測試"。
• 通常，業務人員編寫針對正常路徑的測試，而由QA編寫針對極端情況、邊界條件和異常路徑的測試。
• QA是特性描述者 : 在這項任務中，QA不翻譯需求，而是鑑別系統的真實情況。

自動化測試金字塔

• 專業開發人員遵循TDD的要求來建立單元測試。
• 專業開發團隊使用驗收測試定義系統需求。使用持續整合保證品質穩定提升。
• 擁有一套單元測試和驗收測試的同時，還需要有更高層次的測試，這樣QA才找不出任何錯誤。
• 自動化測試金字塔 : 以圖形化方式展現專業開發組織中所需要的測試種類。

單元測試 :

• 在金字塔底部是單元測試，這些測試是由程式設計師使用系統開發時的同一種語言所編寫的，是供程式設計師自己使用。+
• 編寫這些測試的目的 : 是在最低層次上定義系統。
• 先寫測試，再寫產品程式碼。
• 這些單元測試將作為持續整合的一部分來執行，用以確保程式設計師的程式碼意圖沒有遭到破壞。
• 單元測試是可行的，而且可以做到接近100%的覆蓋率，通常來說這個數字應該保持在90%以上。
• 這裡說的是真實的覆蓋率，而不是那種雖然能通過，但並不關心執行結果的錯誤單元測試。

元件測試

• 元件測試是驗收測試的一種。

[hsiaofung]

時間管理

會議

• Iteration 計畫會議 : (下午)分派任務(任務目標、誰負責、需要多久時間)

• 立會 :

  • 開發前端
  • 後端
  • 文件 : 規格(一個人負責寫規格文件，開task)
  • 文件 : 技術文件
  • QA。(QA一個人負責，一旦有任務完成馬上測，一有錯誤或有新需求馬上提出並把task丟回去)

• Iteration 回顧和Demo 展示 : (上午)檢視上次衝刺會議決議要執行的任務的結果，檢討未完成的任務。

• 如何有效的發言:

  • 如果要發言問問自己為何要發言?

    • 遇到了問題，在會議上發言看看有沒有人可以提供不一樣的想法?
    • 提供另一個視角
    • 發現成員有誤(不要直接指出成員錯誤，而是可以提出一些問題，或是提出發生的情境)
    • 報告事實，幫助他人決策
    • 報告事實，讓他人評估
    • 報告事實或分析，給建議

  • 如果決定要發言了，那要講什麼內容?(事先準備內容或提問)

  • 有結構的議題，才能做有效的討論

  • 議題結構化 : 就是將議拆解成幾個部分，分清順序與前因後果，逐次討論，這樣才不會出現完全不同的架構，導致討論難以進行。

• 何時該保持沉默:

  • 如果想炫耀自己對這主題很懂。
  • 想提升團隊成員的能力。(例如: 主席一開始就講出想法、做法，底下的人察言觀色自然就不說了。要讓會議有小主席最好不要發表意見，要引導會議，例如: 覺得有誤，不要明白說出，可以問一些問題，或提出能發生的狀況情境，讓他們去討論，自然就能引導到正確方向。)
  • 如果你的發言是適合一對一。

爭論/反對

• 非專業行為中最糟糕的 : 有人會表現得非常被動。他們同意結束爭論，之後卻消極對待結果，拒絕為解決問題出一份力。他們會安慰自己說: "既然其他人想要這麼做，就這麼做吧"，這可能是非專業的行為中最糟糕的了，千萬千萬不要這樣做。如果你同意了，就必須拿出行動。

• 該如何拿出解決問題的資料? 實驗、模擬或建立模型。

• 但有時候，最好的辦法是拋硬幣來決定 : 如果問題解決了，這個選擇就是對的。如果遇到麻煩，可以退回來選擇另一條路。 明智的做法是，選定一個時間點或者設定一系列標準，來決定什麼時候該放棄。

• 要小心這類型的會議 : 他們的目的只是發洩情緒，或者讓大家選邊站。如果會議上只有一面之詞，就要避免參加。

• 如果爭論必須解決，就應當要求爭論各方在5分鐘內向大家表明問題。然後大家投票。這樣整個會議的時間不會超過15分鐘。

該怎麼發言?

何時發言?

發言什麼?

時間拆分和番茄工作法:

• 定時25分鐘，做雜事，休息5分鐘，再設定25分鐘，每完成4個番茄時段，就休息30分鐘。
• 25分鐘不要讓任何事情打擾你。之後處理雜事，休息5分鐘。再定時。

要避免的行為

• 優先順序錯亂 : 無論什麼原因，我們都可以找到辦法逃避真正的工作。你說服自己有些工作更緊急，所以轉而去處理，這種行為叫做優先順序錯亂。
• 提高某項任務的優先順序，之後就有藉口延後真正急迫的任務。
• 專業人員會評估每項任務的優先順序，排除個人的喜好和需要，按照真實的緊急程度來執行任務。
• 死胡同 : 比如你做了決定，選擇了一條走不通的技術道路。
• 專業開發人員不會執著於不放棄也無法繞開的idea。他們會保持開放的頭腦來聽取其他意見，所以即便走道盡頭，他們仍然有其他選擇。
• 要意識到走入死胡同，並且有足夠的勇氣走回頭路。

泥潭

• 泥潭 : 比死胡同更糟，泥潭會減緩你的速度，但不讓你徹底停下來。
• 某天你發現自已從一開始就做了錯誤的選擇，再需求變化的方向上，程式跟不上變化的腳步。
• 可以回頭修正設計，走回頭路絕對是最簡單的方法。
• 專業開發人員對於泥潭的恐懼遠遠大於死胡同。他們無時不刻留意著顯露出來的泥潭，然後運用各種努力，盡早盡快脫身。

結論

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

[hsiaofung]

預估

• 專業開發人員都應當謹慎地設定合理的預估值。

預估任務

• 這個任務涉及什麼?(必須知道做什麼，才知道如何做)

• 如何實現? ( 必須知道如何實現，才能估時間)

  • 而且實現的方法有可能是根據經驗或猜測，但真正做的時候可能會
    • 如預期順利做完。
    • 踩到雷。
      • 踩到雷又分兩種 : 做不下去的死胡同，和泥潭。
      • 死胡同 : 另外找實現的方法，重做。
      • 泥潭 : 要決定走下去還是放棄?(放棄，重新找路)

• 什麼因素會把它弄複雜?(小技巧: 找出可能會讓任務複雜的因素)

• 將大任務拆開成小任務來預估(小技巧: 將大任務變成小任務，小任務的時間好預估)

• 專業開發人員懂得如何為業務人員提供可信的預估結果，以便做出計畫。如果做不到，或者不確定能做到，專業開發人員不會給出承諾。

• 專業開發人員一旦做了承諾，就會提供確定的數字，按時兌現。但在大多數的情況下，他們都不會做出這種承諾，而是提供機率預估，來描述"期望的完成時間"及"可能的變數"。

• 對需要妥善對待的預估結果，專業開發人員會與團隊的其他人協商，以取得共識。

[hsiaofung]

壓力

• 即便有壓力，專業開發人員也會冷靜果斷。儘管壓力不斷增大，他仍會堅守所受的訓練和紀律，他知道這些是他賴以戰勝"由最後期限和承諾所帶來的壓力"的最好方法。
• 應當避免對沒有把握達成最後期限的工作做出承諾。不切實際的承諾會阻礙目標的實現，對公司和個人都沒好處。
• 專業開發人員總會千方百計幫助業務找到達成目標的方法。但並不一定要接受業務代為做出的承諾。
• 如果我們無法兌現業務所做出的承諾，那麼該由當時做出承諾的人來承擔責任。
• 業務總是期望能拿到這些承諾，因為他們想消除風險。我們要做的就是讓風險量化，並將它們陳述給業務方，這樣他們就能做好相對的準備。做不切實際的承諾會阻礙目標的實現，對公司和個人都沒好處。

保持整潔

• 要想快速前進以確保最後期限的方法，便是保持整潔。
• 專業開發人員不會為了快點前進而胡搞。
• 專業開發人員明白"快速但髒亂"是自相矛盾的說法。髒亂只會導致緩慢!
• 讓系統、程式碼和設計盡可能整潔，就可以避免壓力。
• 這並不是代表我們要花無窮無盡的時間清理程式碼，而只是意味著不要容忍混亂。混亂會降低速度，導致工期延誤，承諾失信。因此，要盡力保持輸出成果的整潔乾淨。

危機中的紀律

• 觀察自己在危機時刻中的反應，就可以了解自己的信念
• 如果在非危機時刻你會遵循TDD的紀律，但是在危機時刻你放棄這種做法，這就說明你並不真正相信TDD是有幫助的。
• 如果在危機時刻你會結對工作，但平時卻不結對，就說明你相信結對工作比不結對更有效率。
• 選擇那些"你在危機時刻依然會遵循的紀律原則"，並在所有工作中都遵守這些紀律。遵守這些紀律原則是避免陷入危機的最好途徑。

應對壓力

• 專案週期就是比任何人之前所預估的還要長?
• 原始設計有錯誤必須重做?
• 失去一名重要的團隊成員或客戶?
• 做出了一個無法兌現的承諾?
• 保持冷靜
• 讓團隊和主管知道你正深陷困境之中。走出困境的計畫?請求他們的支援與指引。
• 依靠你的紀律
• 尋求幫助: 結對，伸出援手結對工作，幫助他們走出困境。

結論

• 應對壓力的訣竅在於，能規避壓力時盡可能地規避，當無法規避時，則勇敢直接面對壓力
• 可以透過慎重承諾、遵循自己的紀律原則、保持整潔來規避壓力。
• 直接面對壓力時，則要保持冷靜，與別人多多溝通，堅守自己的原則紀律，並尋求他人的幫助。

[hsiaofung]

協做

• 對做的事情充滿熱情事好的，但是，最好把注意力集中在付我們薪水的老闆所追求的目標上。
• 專業開發人員的首要職責是滿足雇主的需求。
• 這意味著要和你的經理們、業務分析師、測試工程師和其他團隊成員進行良好的協做，深刻理解業務目標。
• 這並不是說你必須成為業務專家，而是說你要理解業務價值是什麼? 了解企業如何從你的工作中獲得回報。
• 專業開發人員最糟糕的表現是把自己封閉起來，只顧一頭將自己埋在技術堆裡，甚至連公司火燒眉毛、即將崩潰也不聞不問。 你的工作職責就是要讓業務免於陷入困頓，讓公司可以長久發展下去。
• 專業開發人員會時間花時間理解業務，他們會和使用者討論他們正在使用的軟體，會和銷售人員及市場人員討論所遭遇的問題，會和經理們溝通，明白團隊的短期目標和長期目標。簡而言之，他們會將注意力放在如何與業務同舟共濟之上。
• 專業開發人員不會阻止別人修改程式碼。他們不會在程式碼上建立所有權的藩籬，而是盡可能地互相合作。他們透過合作來達到學習的目地。
• 專業人士會採取結對工作。
• 專業人士之所以結對工作，因為這是分享知識的最佳途徑。
• 專業人士並不會僅憑一己之力從零開始建立知識，而是透過互相結對來學習系統的不同部分和業務。
• 專業人士明白儘管每位團隊成員都有自己的位置，但在緊要關頭時，每位團隊成員也要能夠接替其他人的位置。
• 專業人士結對工作，是因為結對是複查(review)程式碼最好的方式。
• 程式碼複查的方法很多，但大多數方法的效率都極低。最有效率且最具效果的程式碼複查方法，就是以互相協作的方式完成程式碼的撰寫。
• 專業人士會共同工作。

[hsiaofung]

團隊與專案

• 有凝聚力的團隊

  • 12人

  • 分析師 : 開發需求，為需求編寫自動化驗收測試，分析師關注在業務價值。分析師編寫成功路徑場景。

  • 測試員 : 為正確編寫自動化驗收測試，測試員關注在正確性。測試人員要關心那些可能出錯的地方，他們編寫的是失敗場景和邊界場景。

  • 專案經理 : 跟蹤專案的進度。確保成員理解專案時間表和優先順序。

  • 其中有一名成員可能會拿出部分時間充當團隊教練或Master角色，負責確保專案的進展，監督成員遵守紀律。他們擔負的職責是，如果團隊因為專案壓力太大選擇半途而廢，他們應當作為中流砥柱。

發酵期

• 6個月~1年 : 形成真正的團隊
• 形成團隊後不要拆散，只要把新專案分派給他們即可。
• 以專案形成團隊，團隊永遠都不可能形成凝聚力。每個人都只在專案中短期停留，只有一部分時間為專案工作，因此他們永遠學不會如何相互配合?
• 專業的開發組織會把專案分配給已形成凝聚力的團隊，而不會繞著專案來組建團隊。
• 一個具有凝聚力的團隊能夠同時承接多個專案，根據成員各自的意願、技能和能力來分配工作，而且會順利完成專案。

團隊要保持多快的速度?

• 團隊速度 : 在一定時間段內團隊能夠完成的工作量。
• 速度: 是每週工作速度的平均值。
• 可以將多個專案分配給一個具有凝聚力的團隊。例如: 每週50點，15,15,20，並且若是B專案到了緊要關頭，還可以分配100%的團隊精力到B專案上。

結論

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

[hsiaofung]

輔導、學徒期與工藝典範

• 如何提升到專業水準?
• 有哪些步驟?
• 需要達成哪些目標?
• 會遭遇那些挑戰?

大師

• 已經領導過許多重要軟體專案的程式設計師。
• 10年以上的從業經驗
• 曾在多個不同類型的系統、語言和作業系統上工作過。
• 懂得如何領導和協調多個團隊，他們是熟練的設計師和架構師。能夠游刃有餘地進行程式設計。
• 透過閱讀、研究、練習、實踐和教學來維持自身的技術水準。
• 公司會把專案在技術方面的主要職責交由大師來承擔。

熟練工

• 還處在受訓階段，不過已能勝任工作。
• 學習如何在團隊中卓越的工作和成為團隊的領導者。
• 對當下的技術十分了解，但是對其他系統缺乏經驗，他們一般只了解一種語言、一個系統、一種平台。
• 平均經驗5年
• 熟練工在大師或其他資深熟練工的督導下工作。很少會讓資歷尚淺的熟練工獨立工作。他們在嚴格的督導下進行工作。他們的程式碼會被人仔細地複查。
• 隨著經驗不斷累積，他們的自主能力也會不斷增長。對其直接介入指導的地方會變得越來越少，指導內容也會趨向那些微妙之處。最終，督導活動會轉以審查(同行評審)的方式進行。

學徒/實習生

• 熟練工擔任導師確保學徒下列事項:
  • 設計原則
  • 設計模式
  • 各種紀律
  • 固定的操作環節
  • TDD
  • 重構
  • 預估
  • 安排閱讀、練習和實踐任務。
  • 檢查學徒們的任務進展狀況
  • 學徒期至少持續一年
  • 期滿由熟練工推薦給大師。大師透過面談和水準審查，對學徒們進行考核檢驗。如果取得大師認可，學徒可晉升為熟練工。

現實情況

• 程式設計師的水準是否能夠提升和最終是否能夠得到職位晉升，全視乎程式設計師自己的表現。
• 現實缺乏技術方面的傳授、培訓、督導和審查。

工藝

• 工匠: 含有心智、技能和品質的意味。它會在人們心中喚起經驗豐富和堪當重任這樣的印象。
• 成熟工匠手腳俐落、從容淡定，他們能做出合情合理的預估並遵守承諾
• 工匠知道何時該說"不"，但他們更懂得如何承諾。成熟工匠是一名專業人士。
• 工藝的文化基因包含: 價值觀、原則、技術、態度和答案。
• 以身作則

[hsiaofung]

工具

• 持續建置 : Jenkins : 把它和原始碼控制系統對接起來。不管什麼時候，只要有人簽入程式碼，就要能自動進行建置，並把結果狀態報告給團隊。
• 提交程式碼之前必須執行自動建置腳本。
• selenium