如何判斷一個工程師程式碼是否寫得好?「主責檔案」的奇特方法。

更新 發佈閱讀 6 分鐘

「這個報表頁面點進去整個空白,孝宇,這個bug目前狀況處理的怎樣。」

早會一開始,客服夥伴先照例報告昨天的 bug 追蹤狀況。這種時候大家通常只是靜靜聽著,等待指派的負責人回報處理方式。

「應該是欄位格式問題,我昨天有補一段 callback,現在功能應該沒問題了。」孝宇回報bug處理進度與方法。

話才剛講完,查得主管便插話進來:「是哪支檔案?ACC(主責)是誰?」

孝宇停了一下:「痾... 是 `ReportParser.ts`這隻檔案,ACC是Ken。」

查得點點頭,沒再追問,像什麼都沒發生一樣轉頭繼續進行會議流程。

對沒參與專案細節的人來說,這段對話看似平常,但團隊裡的工程師都知道——副總那句「是哪支檔案?」其實從來不是單純想了解技術細節。

AI模擬情境:開會討論

AI模擬情境:開會討論

他不需要打開什麼表格,也不會當場說些什麼,但大家心裡都明白,他在默默記著:這個檔案的ACC是誰,誰的名字跟這段出問題的功能綁在一起。

一段短短的回答、一個名字,可能就成了他衡量一個人工作表現的依據。那不是什麼明講的 KPI,但它確實存在。

Bug 是誰修的、是誰動了誰的檔案、這段錯誤「應該」是誰要管,查得從來不說破,卻會在你領到績效獎金和年終的時候就知道了。 甚至查得還很喜歡拿作為威脅的手段,可以參閱臺灣職場的績效威脅:法律漏洞與自保之道了解更多如果遇到查得這種主管該怎麼辦。

ACC 主責管理

查得對「工程師程式碼是否寫得好」有一套自豪的管理哲學。他設計出 ACC(主責)制度,將專案內的檔案“盡量”依據功能模組分配給特定工程師,再搭配 SonarQube 報表,根據 bug 數、重複率等指標來「量化」每個人寫程式的表現。

這樣的設計可以在 Excel 得到漂亮的報表裡,誰負責了哪些檔案這些檔案的程式品質如何,在他最愛的Excel裡面一目瞭然,但忽略了一個本質問題:軟體開發是高度協作的行為,並不合適以單檔責任制度去管理。

功能常常會跨越多個檔案、甚至多個模組。產品的維護與迭代也經過了多個人的邏輯。Bug 的產生通常是系統性的錯誤,而非單一檔案或模組所造成的結果。在這種情況下,用「這是誰主責的檔案」來判斷誰該負責,只會讓真正該處理的問題被模糊掉。而且找出是誰出錯「找戰犯」這種行為只會讓團隊的士氣下降。

造成什麼樣的問題

這種制度雖然看似量化了每個工程師寫程式的程度指標,但也會帶來很多問題。甚至會讓整個團隊文化變糟,引響士氣

  • 檔案分配的是否公平?

因為不是每個檔案都會經常在修改或是比較有多的bug,有些模組的檔案本來使用率就比較低,各個檔案的複雜度也不一定一樣。這樣分配一定會有不公平的現象。

  • Bug出現的時候要找主責還是...?

通常bug出現應該是會找比較熟悉模組或是最近修改檔案的人處理,但必較熟悉該模組的人不一定就是ACC負責人,這樣到底要找ACC主責還是找比較熟悉的工程師呢?

  • 後端程式主責分配

後端的程式碼通常會有一個檔案包含很多不一樣的服務功能,程式碼行數可能會多達數千行。加上專案已經很舊了,這樣要怎麼分配主責?

有沒有更好的做法?

如果真心希望提升團隊的技術能力與合作,管理的目標不應該是一昧的只看SonarQube上面跑出來的數據指標。只會看報表數據但不管實際情況,這就是管理階層常常陷入的迷思。

假設管理者的目的真的是想知道團隊的表現好不好,那其實有很多更務實、更能看出「工程實力」的方式,而不是把責任硬將每個人分配到檔案上面、或是用 SonarQube 的報表去當績效分數。

以下是比較好的管理方法:

1. 用功能模組或業務邏輯來分工,而不是單檔責任

模組的邏輯往往比單檔案更具意義。與其把每一支檔案應歸給人,不如根據系統架構與業務邏輯分配 domain owner,讓工程師能深入理解整體設計,並對模組品質負責。

2. 關心在「解決問題的過程」,而不是哪一支檔案有問題

「是哪支檔案出問題?ACC是誰啊?」,這種找戰犯的行為對於產品維護迭代完全沒有幫助。更重要的是看團隊遇到 bug 或技術問題時,是怎麼討論、怎麼找解法、怎麼把系統恢復正常的。 這些過程才真正反映一個工程師的實力與態度。

3. 使用工具輔助討論,而不是主導評價

SonarQube 是個好工具,但它的指標應用來輔助大家發現問題、改善產品品質,不應該拿來評分評量每個人的產出的品質。畢竟程式檔案並不一定從頭都是這個人寫出來的。如果以這樣算在這個人身上是不是太不公平。

4. 建立公開透明的評分機制,而不是看報表打分數

看報表產出的指標,就真的可以代表這個員工的寫程式的功力好壞嗎?更何況你確定你設計的報表真的代表這個工程師嗎?加上各項評分指標並未公開,這樣和黑箱作業有什麼不一樣?


本文所表達的觀點與立場僅代表作者個人意見,與任何公司、組織、團體或其他人物無關。文中的內容純屬作者根據個人經驗、觀察及研究所提出的見解,並不代表任何外部機構的立場。若有任何不當之處,請以理性與包容的態度對待,並且尊重多元的觀點。



留言
avatar-img
留言分享你的想法!
avatar-img
Tom的沙龍
11會員
47內容數
我是一個從科技業轉職的軟體工程師
你可能也想看
Thumbnail
透過蝦皮分潤計畫,輕鬆賺取零用金!本文分享5-6月實測心得,包含數據流程、實際收入、平臺優點及注意事項,並推薦高分潤商品,教你如何運用空閒時間創造被動收入。
Thumbnail
透過蝦皮分潤計畫,輕鬆賺取零用金!本文分享5-6月實測心得,包含數據流程、實際收入、平臺優點及注意事項,並推薦高分潤商品,教你如何運用空閒時間創造被動收入。
Thumbnail
單身的人有些會養寵物,而我養植物。畢竟寵物離世會傷心,植物沒養好再接再厲就好了~(笑)
Thumbnail
單身的人有些會養寵物,而我養植物。畢竟寵物離世會傷心,植物沒養好再接再厲就好了~(笑)
Thumbnail
不知你有沒有過這種經驗?衛生紙只剩最後一包、洗衣精倒不出來,或電池突然沒電。這次一次補貨,從電池、衛生紙到洗衣精,還順便分享使用心得。更棒的是,搭配蝦皮分潤計畫,愛用品不僅自己用得安心,分享給朋友還能賺回饋。立即使用推薦碼 X5Q344E,輕鬆上手,隨時隨地賺取分潤!
Thumbnail
不知你有沒有過這種經驗?衛生紙只剩最後一包、洗衣精倒不出來,或電池突然沒電。這次一次補貨,從電池、衛生紙到洗衣精,還順便分享使用心得。更棒的是,搭配蝦皮分潤計畫,愛用品不僅自己用得安心,分享給朋友還能賺回饋。立即使用推薦碼 X5Q344E,輕鬆上手,隨時隨地賺取分潤!
Thumbnail
身為一個典型的社畜,上班時間被會議、進度、KPI 塞得滿滿,下班後只想要找一個能夠安靜喘口氣的小角落。對我來說,畫畫就是那個屬於自己的小樹洞。無論是胡亂塗鴉,還是慢慢描繪喜歡的插畫人物,那個專注在筆觸和色彩的過程,就像在幫心靈按摩一樣,讓緊繃的神經慢慢鬆開。
Thumbnail
身為一個典型的社畜,上班時間被會議、進度、KPI 塞得滿滿,下班後只想要找一個能夠安靜喘口氣的小角落。對我來說,畫畫就是那個屬於自己的小樹洞。無論是胡亂塗鴉,還是慢慢描繪喜歡的插畫人物,那個專注在筆觸和色彩的過程,就像在幫心靈按摩一樣,讓緊繃的神經慢慢鬆開。
Thumbnail
這篇文章探討了工程師在如何有效提升自己,強調不僅僅是多coding,而是要對程式碼有更深層的理解。隨著職涯發展,工程師需要從單純的技術執行者轉變為團隊領導者,具備解決複雜問題和與他人有效溝通的能力。
Thumbnail
這篇文章探討了工程師在如何有效提升自己,強調不僅僅是多coding,而是要對程式碼有更深層的理解。隨著職涯發展,工程師需要從單純的技術執行者轉變為團隊領導者,具備解決複雜問題和與他人有效溝通的能力。
Thumbnail
以前我在新創公司當PM(產品經理)的時候,如果提出做一個新功能的需求,常被工程師挑戰是否真有必要做...
Thumbnail
以前我在新創公司當PM(產品經理)的時候,如果提出做一個新功能的需求,常被工程師挑戰是否真有必要做...
Thumbnail
這篇文章著重於解釋軟體專案管理中的戰略意義和專案特性評估,並提出了四個不同像限的專案特性。
Thumbnail
這篇文章著重於解釋軟體專案管理中的戰略意義和專案特性評估,並提出了四個不同像限的專案特性。
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。
Thumbnail
軟體開發專案管理的失敗原因複雜多樣,但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步,需對軟體開發專案的特徵進行評估,選擇合適的軟體開發生命週期和專案管理方法。
Thumbnail
軟體開發專案管理的失敗原因複雜多樣,但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步,需對軟體開發專案的特徵進行評估,選擇合適的軟體開發生命週期和專案管理方法。
Thumbnail
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力,以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性,並強調從工程師升遷為專案經理並非易事,需要不斷學習與努力。
Thumbnail
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力,以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性,並強調從工程師升遷為專案經理並非易事,需要不斷學習與努力。
Thumbnail
這篇文章探討了在專案開發中遇到的時間壓力和執行困難,以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
Thumbnail
這篇文章探討了在專案開發中遇到的時間壓力和執行困難,以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News