工程師應該花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做做有品質的交付,未來才不會疲於奔命。

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

Leave a Reply

avatar
  Subscribe  
Notify of