iT邦幫忙

2021 iThome 鐵人賽

DAY 4
2
Mobile Development

我的怨念齊天高 之「為什麼我的專案死掉了!」系列 第 4

懂很多的工程師最恐怖

有些比較大型、而且有規劃要進行客製銷售的專案,它在程式工程上有幾個階段,首先是「確立技術可行性」,然後是「提出核心模組」,接著就是開始組成工程團隊開始「應用模組陸續完成大型專案」。

既然有工程團隊,自然不只一個工程師...領頭的工程師自然是跟隨著專案團隊從「確立技術可行性」到「提出核心模組」步驟的那一位。
這樣的工程師往往經過人資精挑細選,具有「最資深」「做過最多東西」「懂很多平台技術/工具技巧」的特質。
專案前兩個步驟在他手中會進行的似乎非常順利,看著用核心模組做出來的雛形,專案領導者(和大老闆們)會開始構思著(幻想著)專案步上軌道後美好的畫面.......

然後專案(工程品質)就垮了。

怎麼垮的?
對不懂技術的人來說,他們可能永遠看不懂這個問題的全貌,就冒然下結論「一定是後續擴增的團隊成員資格不符、能力不佳」。然後他們的解決方案可能是拉著那位核心工程師(可能加個薪、給個頭銜跟大辦公桌)要求這人一肩扛下重組工程團隊的任務.......

然後專案(工程品質)就死了。

(有些時候,「為了拯救專案而做的事情,才是真正害死專案的癥結。」有機會再深入討論。)

事實上,這位工程師往往就是問題的癥結。
因為這位工程師根本不懂「怎麼用平行的心態去跟別人合作」。
講直白一點,「他在一開始用自己設計的核心模組做出雛形,但不表示這套核心模組可以交給其他工程師去進行其他專案。」

為什麼?
因為「設計核心模組」其實是門很抽象的、非技術性的學問,(就跟「如何讓專案具有可維護性」一樣,)但這位工程師正好只懂技術、正好只懂完成自己眼前看到的問題,給他越多權限、或越明確的認知「別人要跟隨你的腳步做事」,他針對問題所完成的解決方案就越不可用。

聽起來有點不可思議,可能同時違反了大家的經驗與直覺。
用個直接的例子來說明吧......

這位工程師有天寫了個函數A,為的是完成某項工程。


functionA(var a){
.......
}

但過了幾天幾個禮拜後,可能是工程內容改變,所以需要擴增函數A的內容,或是大家發現Bug,所以要進行修改並釋出新的函數。
不管怎樣,這其實都是很常見的事情。
結果大家會看到這位工程師針對函數A進行了以下的修改。


functionA(var a, var b){
........(完全沒有針對當「b」無傳入時設計該做什麼事情,就是真的只負責「擴充功能」「修正Bug」)
}

…………

沒翻桌的人大概都不懂技術或不懂如何團隊合作編寫程式。

函數A可能已經釋出在多個專案裡使用了,而且每個專案都不只使用一次。
(我經歷過最慘的例子是「每次點擊任何功能」都會呼叫到這個函數A。)
忽然改寫函數A的結構與使用方式,等於要專案工程師把已經完成的功能都修改過,甚至連已經通過測試的功能也要將測試結果作廢。

有點經驗或認知的工程師會將函數A這樣進行修改........


functionA1(var a, var b){
........
}

functionA(var a){
var b = ....(初始化)
functionA1(a, b);
}

工程師會另外釋出新版的函數A1,然後在函數A中呼叫函數A1,避免使用到函數A的地方都要進行大規模改寫。

修改核心模組時不去想辦法避免專案工程師要進行大規模改寫,專案工程師往往就要自我毀滅式的加班。
如果連續發生這種事情,專案工程師的體力就會開始往下掉、工程品質與效率也會跟著往下掉,而且是惡性循環的幅度。

(這是很多Android專案垮掉的原因。因為Google的Android工程師們顯然不懂這個道理。)

順便一提。
這技巧看起來很簡單,但真的很多工程師都不會。
而且是那些越積極吸收新技術、技術年會場場跑、各種新穎工具都能快速上手的工程師,往往不具備這些技巧。

很諷刺的是:他們很多是知道這個問題存在的。
只是因為沒人在針對這些技巧舉辦年會,各種技術平台或工具平台往往也只專注在「SDK說明」或「工具使用技術說明」,所以這些工程師可能年資十年,但從不涉獵這方面的技巧....
(可能也遭遇過不只一次,但他們選擇跟其他人一樣把責任歸咎給其他工程師,或是認為「這世界上一定有可以完美解決這個問題的工具」,然後轉頭去跳近無窮無盡的工具One Piece中...)

「喔!不就是彼德原理的活生生例子嘛~」不懂什麼是彼德原理?保重。


上一篇
我們註定成不了海賊王
下一篇
請學著打造點零件吧!
系列文
我的怨念齊天高 之「為什麼我的專案死掉了!」20

尚未有邦友留言

立即登入留言