工程師應該花70%的時間在溝通上

曾有一段時間覺得，寫程式是個需要腦力的工作，需要專注才能寫出有品質的程式。而如果要達到專案進度，每天最好需要有一段專注的時間，不該隨意被打擾。

工程師常常會覺得溝通頗浪費時間，我都沒時間寫Code了，還要去參加各種會議、討論計畫、demo進度，到底寫Code的時間還剩多少？工作一陣子之後，我的想法改變了。

好的軟體工程師在每日的工作中，70%的時間會花在溝通，而不是寫程式上。

也就是一天8個小時的工時，真正手放在鍵盤上打字的時間，可能不到3個小時。

寫出能動的程式碼不難

寫出能動的程式碼一點都不難，每一個同事都能完成工作的要求，連工作需求都沒辦法完成的人通常不會成為你同事。真正困難的事情往往在寫完程式的三個月之後，隨著需求異動，客戶要求增加更多新功能，接著事情開始變得一團糟。程式裡出現一大堆的if/else，過度複雜的繼承關係、各種壞味道充斥在程式裡。開發速度開始變得越來越慢，每增加一個新功能，都必須確保原本的功能不會壞掉。前人都在copy paste，重複的東西越來越多，工作開始成為一件痛苦的事情。

程式是需要維護的

如果程式寫好後，接下來不會有任何更動，那簡直太棒了，因為只要電腦看得懂，能夠跑起來可以了，少數的程式的確是這樣的，例如概念驗證的程式、一次性的檔案處理等等。可是大多數的程式不是這樣的。PO會要求加入新功能、可能會有bug需要修復，公司付我薪水，因為必須要有人去維護這些程式。必須有人去讀懂其中的邏輯，尋找修改的位置，並確保原本正常的功能依然正常。

工程師在面對這類的程式碼時，大多數的時間會花在「了解是麼運作的」，為什麼這裡要宣告這個變數、為什麼這兩段程式碼是重複的，為什麼那裡會有數十個if/else if。在開發者缺乏紀律的情況下，這種複雜性會如同生物演化般持續疊加上去。最後我們坐在電腦前花了一兩個小時讀前人的設計，罵了N句髒話，心想當初設計這一坨大便的人在想什麼，最終只修改了兩三行。

可維護的程式碼是溝通出來的

要怎麼寫出好維護的程式碼，這是個不容易回答的問題。但反過來問「什麼時候，程式碼會難以維護」就簡單許多。通常難以維護的程式會發生在

• 始作俑者已經不在公司，沒有人可以詢問設計的原因
• 明明是個簡單的情境，卻過度設計
• 不明究理的狀態、判斷式，不知道當時是基於何種情境寫的判斷
• 程式沒有即時重構，設計者也缺乏重構的能力，導致後面救不回來
• 接手的人選擇copy paste，因為這樣比較快，但接下來越來越多的copy paste，導致難以修改。

要怎麼在事前避免這些事情發生？

• 在開發時，程式必須有明確的情境和需求規格，並且透過撰寫測試確保程式的功能符合需求
• 不做過度設計，清楚了解需求後，開發者做「最剛好的設計」
• 出現重複、出現程式碼的壞味道時，及早重構（大多數的重構都太晚），而重構的前提是有測試做保護。

溝通清楚需求

工程師享受在電腦前面搭建東西的感覺，而不是和一個不懂自己專業的人打交道。

但溝通並不是在專案一開始確認規格，接下來就不問世事拼命寫Code。溝通是持續的過程，可能做到一半，發現有些當初沒想清楚的問題，隨時跟PO確認需求，看看畫面是不是他要的、問優先順序。朝錯誤的方向跑步，你跑得越快，反而離終點越遠。

有多少時候，你以為你已經做完了，最後卻發現不是PO要的？不確認清楚需求、不確認驗收條件，你怎麼知道「你完成了？」

如果完成的定義是模糊的，那麼接下來完成新功能需要花多少功也會是模糊的，估計會失準，團隊的承諾就會失去信用。原本說要for Demo就好，團隊說一個禮拜可以做完。下週PO說希望能直接上線，團隊估計再一週，結果做到一半才發現當時for Demo的版本有一堆細節沒有完成，浪費一整週的時間沒有產出，只因為當時想省掉溝通的時間。

並不是只有你一個人

團隊會和你一起維護這段程式。你們要寫新功能、修復Bug。如果不討論，只是拼命寫，那麼你們只是在「分工」，而不是在「協作」，就像蓋摩天大樓卻沒有一份共享的藍圖，每個人都在用自己想像的方式蓋一堆違章建築。

常見的情況是，Senior工程師知道Junior寫的不好，但又放任Junior工程師自生自滅。問一段程式碼的這樣設計的原因，寫的人說「這要解釋複雜，你自己去讀就會懂了」，於是讀的人得額外花更多時間了解他到底為什麼這樣寫。

既然都已經很複雜了，那為什麼不在撰寫時「向大家解釋設計的理由」，然後我們可以選擇「要用哪種方式」做呢？

自己一個人往前衝並不是快

工程師常常覺得「自己寫」比較快，原因不乏是

• 和同事一起Pair Programming很浪費時間，花了兩個人卻只有一個人的產出，甚至會更少
• 同事寫的程式碼品質不好，我自己寫比較好

但如果沒有跟同事討論需求、怎麼確保你寫的程式是符合需求、會不會不小心漏掉東西？

怎麼確保你的同事知道設計理念？你們有討論過有哪些選擇，哪一種選擇是目前代價相對小，而且又有彈性的設計？未來同事才有辦法基於你的設計繼續開發

你怎麼知道一段程式碼寫得好不好，未來方不方便維護？維護的不是只有你，還有你的同事們。

如果有一些Domain Knowledge只有你知道，你怎麼讓團隊中的其他人也獲得同樣的知識？

如果你是個Senior engineer，你怎麼讓Junior能夠成長與進步，好讓他未來能夠分擔你的工作？

溝通+技能才能帶來真正的快

和PO確認清楚需求、和團隊pair programming、討論設計的原因和取捨、討論有哪些作法，我們可以選擇怎麼做。撰寫測試，描述清楚需求，讓未來在重構時可以充滿信心的修改設計，同時測試也可以充當live document，在交接給其他人時更加清楚。讓團隊成員的技能一同成長，你們的生產力才會增加。

如果你把時間花在這些地方，那麼真正寫Code的時間當然會變少，可是你寫的每一行Code，都是符合需求的、做過討論、不多不少、恰恰好的設計。堅持在每個sprint做做有品質的交付，未來才不會疲於奔命。

這不容易，因為溝通已經花掉許多時間（但這些是必要的），剩下不多的時間內，你需要有能力撰寫測試、有能力做出好的設計、有能力重構、有能力在多個技術選擇中做出相對好，代價低的選擇，有能力善用工具避免重複枯燥的開發過程，而這就是厲害的工程師和平庸的工程師之間的差異。