作者 bachelorwhc (積積陰陰德)標題 Re: [討論] 系統越開發越多，負責的東西越來越多時間 Sat Oct 28 17:16:31 2023
推 yangs0618: 推個 希望有機會聽到進一步分享how
On提出數據說服主管/管理層 開發是越來越耗時間10/28 07:58
→ panbanana: 要怎麼跟上頭說開發越來越久跟code quality有關10/28 08:18
幾個很簡單的學術名詞就能說明，我相信大家也知道
耦合性 如果我改A模組，B模組就需要跟著改 (這還是B模組沒有牽連其他模組的情況下)
經驗法則告訴我們 改的模組越多，消耗的時間也越多
所以時間成本增加
正交性 如果一個錯誤設計的函數其副作用會影響到非預期的變數或狀態(非正交)
非正交的設計會導致bug甚至影響業務的正確性
生活化的例子：「如果你今天開熱水器，結果旁邊的維波爐也開了」
不會抓狂嗎？
所以時間成本增加(你要再請工程師花時間解bug甚至賠償客戶)
粒度 你是希望有一千個功能相似又微妙差異的工具，每次要選擇都要重新翻箱倒櫃
還是你是希望有十個零件可以組出一千種功能？
不一定有對錯，但從新人教育程度跟熟悉的速度，
認識十個零件肯定是比一千個工具之間的細微差異還簡單
粒度低可以降低時間成本
這些都是理論，我相信對沒有技術背景的人來說也不難懂
那數據呢？統計呢？
從ticket、commit的內容我們可以發現，一定是有某些模組、某些類別、某些函數經常
被更改，而這些程式碼才是最有價值的地方，因此程式碼的重要性、頻率是可以從執行
紀錄、commit等資訊來加以量化的
如果某個模組特別容易出bug，很有可能是其模組本身或是其使用的模組有問題
這時你才有機會說服管理階層建立測試及其重要性
管理階層重視的不是工程師寫程式舒不舒服，而是用戶有沒有受影響？能不能減少公司
的執行成本？
測試可以盡量避免工程師改壞功能，而只有保證不改壞程式碼，工程師才有可能說服
管理階層允許大幅改寫原始的程式碼
而如何證明code quality跟test可以降低執行成本？這需要有證明的材料，如果某個
模組的code quality很高，而該模組相關的開發與維護速度都比其他模組來得有效率，
那也許可以透過比較間接證明此觀點 (但有些政治因素比較重的辦公室，我不推薦你
去比較)
如果現在沒有"你認為"品質好的程式碼，你就只能不斷透過能力證明而且去創造
你要說服管理階層，只能從管理階層重視的價值著手
最後做個總結：
遇到code quality差的公司建議直接跳槽
--
https://i.imgur.com/1VlaBnp.png
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.109.122 (臺灣)
※ 作者: bachelorwhc 2023-10-28 17:16:31
※ 文章代碼(AID): #1bFD5pGx (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1698484595.A.43B.html
※ 同主題文章:
Re: [討論] 系統越開發越多，負責的東西越來越多
10-28 17:16 bachelorwhc
推 aa08666: 我反而 建議 遇到錢少的 在跳過 即可1F 10/28 17:23
推 yangs0618: 感謝分享 覺得這些是光靠自己下班精進很難有機會提升到的能力8F 10/28 20:43
推 shieldsky: 推這篇量化方式，看來有測試真的是很重要的一環12F 10/28 21:27
推 vi000246: 其實 $$跟code quality沒正相關 選錢多的即可
$$多 大便也能變香14F 10/28 22:07
→ flash5408: 2023都要結束了 還有沒test的公司喔 工程師心臟很大耶16F 10/29 05:51
推 s06yji3: 沒有test的公司100年之後還是會有。18F 10/29 08:27
推 mathrew: 沒有test的公司，比你想像中多得非常多19F 10/29 10:07
→ abccbaandy: 想到面試問測試，一堆答自己測，甚至啥工程師要能保證正確性這種幹話的，沒QA就乖乖承擔風險好嗎...21F 10/29 13:42
→ Mrhonest: 沒時間寫測試至少發PR主管review一下還比較保險，至於那種想推code就能推的 老實說多到爆，光一堆接案公司根本沒在管這塊的，更不用說傳產23F 10/29 13:56
推 s860134: 下次把最後一行移到第一行可讀性會更高26F 10/29 16:55
推 kaitokid2: 2023都要結束了，一條龍工程師比你想的還多...
從談需求、架設備開VM或開雲端，設計資料庫寫程式
到測試、佈署，然後客服，一條龍工程師!27F 10/29 17:03
--