前言
這篇稍微紀錄一下這次讀本書第二篇的感想，剛好與實例有關。
Agenda
- 大泥球
- 幫助團隊更好地寫程式
前提
- 大泥球 (Big Ball of Mud, BBM): 當你的程式碼內有很多你看不到的相依性，跟很多重複的程式碼。每個層級沒有明確的撰寫方式。常常你修改東卻壞了西這類狀況發生的時候，你要注意你已進入BBM。
- 幫助團隊更好地寫程式: 改善程式碼，不會是一個人的事，所以該怎麼幫助他們，而不是更加的分裂他們，這裡會說到。而狗咬狗的所謂彼此競爭的做法並不適合在軟體工程團隊。
造成大泥球原因:
1. 未能準確了解客戶的所有需求:
但造成這個原因的是溝通，常常我們開會有種似懂非懂的感覺，但當下你不敢在反問了，因為大家都會等你，講者重複解釋他的分貝也拉高了，你看似一位剛畢業的新手，而不是主管，所以不會在會議上問的，這是埋下問題的開始。但你很害怕到底在講啥，所以你會反給他以個你認為的意思或是範例，以便凸顯”你好像懂了，是否是這樣請你回復的一個狀態”，不瞞你說講者要瑪不懂你在說啥，要瑪時間上緣故，他會打呼帶過。不顧造成這類問題的發生多半跟你們用的詞彙有關，有人說他們是Front-End團隊，別人說他們是前台團隊。見鬼了，是前台還是前端? 清楚明白而且有共識的詞彙可以大大降低彼此的誤會，縮短會議的時間，甚至激發出舉一反三的效果。
2. 開發時採用RAD (Rapid Application Development)方式:
這種方式的缺點是延展性差，但是開發速度快，適用於小專案，大型專案千萬別用，後續維護很辛苦的
3. 開發團隊跟業務人員之間的不準確估算:
由於兩批人馬是不同的單位，不同的背景，所以業務人員已為他們說的要”會員系統”，包含了會員註冊，登入等等這類的。開發人員也認為就是這樣吧!會員系統。試問，你們要SSO嗎?你們要OWIN嗎? FB登入? Google登入? 手機登入等同大小網站都登入? 需要轉登入嗎? 開發人員在做完第一階段的成果後，常常會被業務人員問說如果我要上續的其中一個功能，有嗎? 業務人員認為這都是屬於會員登入，開發人員會認為這是而外的需求，需要更多時間，這就是常見的不準確估算。建議在估算期間，竟可能把所有可能出現的不確定性都說出來，可以降低後續的安排跟規劃。
4. 缺乏測試:
測試有4種，本書講到三種: 單元測試Unit Testing，整合測試Integration Testing，驗收測試Accpetence Testing。不可否認這幾樣都做了你的程式碼會比較好，但是，你有時間嗎?試問老闆跟業務人員把這個也算進去了嗎? 還有開發人員真的會寫測試嗎? 他是RD還是QA? 劃分職責是很重要的，很多公司是沒有這樣規模的規劃的。那要code review嗎? 很多公司也沒這樣的規劃，雖然這個成本很低，老闆或是PM下命說要做，但開發團隊有沒有做你也不知道。在這點上我想建議的是如果公司有位Tech Leader是很重要的，就像run scrum一樣，建議你要有scrum Master，不然你會走偏。一樣的技術團隊建議要有技術主管，也可以是架構師，真的懂技術也知道在幹嘛的人。可以解決RD，維運或是QA技術上的問題，再次說明，不是出嘴的，因為任何底下的人做不出來，就是這位技術主管下去解，他必須要有實戰能力(經驗)。
5. 不明確項目所有權:
這件是很常發生在跟跨部門的合作上，常常以為機器歸Infra團隊管，程式上去，維運要監控，但，問題發生你不會知道是程式問題造成還是機器環境造成。第一時間該找誰? 火燒屁股該找誰? 最近流行的SRE救火團隊，但很多公司沒這團隊的，都是由該負責此業務的module團隊leader先出來。在抓出RD是誰? 錯誤訊息看不出就只能先退版，回復上一動。但，每次這樣搞，搞久了團隊會拆散的。一間每天到晚都戰戰兢兢的公司，技術團隊壓力太大了，會慢慢養成推卸責任的人員，慢慢養成以不碰麻煩事務的人員，慢慢養成想獨立獨自拆分出來的人員，legacy code慢慢的就沒人想碰。聊遠了，多半還有一個狀況是機器好了沒? 那該由誰去追，寫程式的需要機器，但生機器的Infra並不知道要怎樣的機器。如果我說PM/PO會是追機器的人，你相信嗎? 因為寫程式的人不適合去做跨部門接洽，甚至追機器。由上到下，由管理該Module案子的人來追會比較適合，那這邊會問機器後續管理呢? 再項目的所有權上，我認為PM/PO權責最大，由他主動最適合，或是指派有相對能力的人也行，但那會是誰，誰對目前案子最熟? 寫程式的? 寫測試的? SA嗎? SD嗎? Tech Leader嗎? 另外如果真要指定一位人員做這類事項請一定給他一個頭銜，畢竟跨部門，派個小弟去很難完事的，或是一定要資深人員才會比較適合。
6. 忽略危機狀態:
這裡講的是技術困難方面，建議是希望身為架構師身份的你，不去忽略或是帶過你覺得可能出現的任何問題。但我在想該公司沒有這類人物怎辦，RD發現問題他無法解，因為跨層級了，是架構等級的問題，他跟提需求的人說，他做不出來，在他有限的能力範圍內他也不知道該如何是好。但是謾罵或是貶低是往往發生的，多半是註記這個RD能力不夠。RD也不想被註記，所以經過一次後他不會再講，他會用他的方式帶過問題。但問題就被埋藏在程式碼中，當專案不斷成長，這問題就更加難以修正。但這是可以協調溝通的，也可以提早發現處裡的。由於Tech Leader無法得知每個項目細節實作的內容，但他可以透過底下的人反應，盡快導正，不論是程式碼問題，架構問題，或是需求問題(有些需求是矛盾的)。那為什麼說到Tech Leader，因為他夠大，一般阿貓阿狗的RD沒有說服力，所以往leader身上丟問題，讓他確認後，在反應會比較好。
結論
說到這裡，你不難發現，BBM的發生基本上天天來的，而且每家公司都有，完美的公司是不存在台灣的，但是我們努力往前，希望更好。最後建議，如果公司規模到能有一個技術部門，建議你要有一位技術長或是Tech Leader之類的人物，他們會是技術團隊的生命，他可以解決很多BBM上的問題，千萬別找只出嘴的。
幫助團隊更好地寫程式
-
這篇我想說的是之前面試有人問我，你會做code review，當時我很肯定我不做。我知道做code review是很好的，對品質有幫助，但是還要看是誰做才行。我曾經讓微軟內的高手幫我做code review雖然過程很打擊，不過事後修改後，代碼的乾淨度跟整體維護性都有大大的提升了。但過程是痛苦的，因為你會被打臉，甚至你會考慮考慮自己是不是不適合寫程式，不然就是質疑她說的真的對嗎?等等的，但，熬過再出發總是另一種層次的提升。有幾點我想說，就是不是每個人都適合做code review，所以當時有人問我的時候我很肯定地說我不幫同事做code review。以下是我認為最起碼要有這兩項才可以做:
1. 最好要有明顯的階級以上的人來做 2. 須明確提出錯誤以及更改後的優點 (要有數據) - 原因是因為我們需要團隊不是英雄
- 本書第二章紀載如何幫助團隊寫更好的程式碼，這邊我想介紹其中一段，”如何告訴別人他們的代碼很爛”，這段的title很吸引人，因為我們常常看到舊的程式碼，第一件事就是批評，但建議你千萬別這樣做，因為這樣會影響整個團隊士氣，當時寫code的人可能因為時間關係，可能因為熟悉度關係，可能程度關係，也可能這是別人告訴他應該這樣寫的，這樣說應該會被撻伐，但我想說的是，有時候不是RD可以決定該怎麼寫，因應團隊需要，時間跟環境需要，他寫出了符合當時他能做到的。如何帶領團隊成長，有時候就是從這裡開始，但切記在沒證據之前，千萬別亂下定論，批評一段程式碼。建議使用好奇的方式詢問，了解當時正真的動機，在提供你認為可以怎樣做會更好的程式碼。是會更好喔，別提有爭議性的，最好有大神加持那種，或是明確的數據加持。如果只是寫法不一樣，我建議別當英雄，因為團隊整體會比較重要，你多出來的一份看似好，但沒人懂得程式碼有時候是一種負擔。如果效能也沒大大提升，維護上也沒比較精簡，不如維持現狀唄!其馬整體一致性還保持著。
