Re: [討論] 系統越開發越多，負責的東西越來越多
幾個很簡單的學術名詞就能說明，我相信大家也知道
耦合性 如果我改A模組，B模組就需要跟著改 (這還是B模組沒有牽連其他模組的情況下)
經驗法則告訴我們 改的模組越多，消耗的時間也越多
所以時間成本增加
正交性 如果一個錯誤設計的函數其副作用會影響到非預期的變數或狀態(非正交)
非正交的設計會導致bug甚至影響業務的正確性
生活化的例子：「如果你今天開熱水器，結果旁邊的維波爐也開了」
不會抓狂嗎？
所以時間成本增加(你要再請工程師花時間解bug甚至賠償客戶)
粒度 你是希望有一千個功能相似又微妙差異的工具，每次要選擇都要重新翻箱倒櫃
還是你是希望有十個零件可以組出一千種功能？
不一定有對錯，但從新人教育程度跟熟悉的速度，
認識十個零件肯定是比一千個工具之間的細微差異還簡單
粒度低可以降低時間成本
這些都是理論，我相信對沒有技術背景的人來說也不難懂
那數據呢？統計呢？
從ticket、commit的內容我們可以發現，一定是有某些模組、某些類別、某些函數經常
被更改，而這些程式碼才是最有價值的地方，因此程式碼的重要性、頻率是可以從執行
紀錄、commit等資訊來加以量化的
如果某個模組特別容易出bug，很有可能是其模組本身或是其使用的模組有問題
這時你才有機會說服管理階層建立測試及其重要性
管理階層重視的不是工程師寫程式舒不舒服，而是用戶有沒有受影響？能不能減少公司
的執行成本？
測試可以盡量避免工程師改壞功能，而只有保證不改壞程式碼，工程師才有可能說服
管理階層允許大幅改寫原始的程式碼
而如何證明code quality跟test可以降低執行成本？這需要有證明的材料，如果某個
模組的code quality很高，而該模組相關的開發與維護速度都比其他模組來得有效率，
那也許可以透過比較間接證明此觀點 (但有些政治因素比較重的辦公室，我不推薦你
去比較)
如果現在沒有"你認為"品質好的程式碼，你就只能不斷透過能力證明而且去創造
你要說服管理階層，只能從管理階層重視的價值著手
最後做個總結：
遇到code quality差的公司建議直接跳槽
--
https://i.imgur.com/1VlaBnp.png
--
我反而 建議 遇到錢少的 在跳過 即可
講一大堆結論還不是不爽不要做XDD
你可以直接推文最後一行
推-簽名檔
推 總結
總結簡單明瞭
講得好
感謝分享 覺得這些是光靠自己下班精進很難有機會提升
到的能力
推最後一行
知識文
推這篇量化方式，看來有測試真的是很重要的一環
推總結
其實 $$跟code quality沒正相關 選錢多的即可
$$多 大便也能變香
2023都要結束了 還有沒test的公司喔 工程師心臟很大耶
沒有test的公司100年之後還是會有。
沒有test的公司，比你想像中多得非常多
推
想到面試問測試，一堆答自己測，甚至啥工程師要能保證
正確性這種幹話的，沒QA就乖乖承擔風險好嗎...
沒時間寫測試至少發PR主管review一下還比較保險，至於
那種想推code就能推的 老實說多到爆，光一堆接案公司根
本沒在管這塊的，更不用說傳產
下次把最後一行移到第一行可讀性會更高
2023都要結束了，一條龍工程師比你想的還多...
從談需求、架設備開VM或開雲端，設計資料庫寫程式
到測試、佈署，然後客服，一條龍工程師!
推總結
推推，真的是這樣XDDD
連客服都要兼的工程師真的是讓人無比欽佩 XDDD
作為客戶的窗口，那不是產品應用工程師的常態嘛
現實是公司沒給你測試人員
犯錯出包自己扛，做不出來也你扛
還是當舔狗比實作苦做的出路好
粒度是支語
https://www.ithome.com.tw/article/49179
https://dlcenter.gotop.com.tw/PDFSample/A532.pdf
台灣出版社現在翻粒度、清華大學資訊工程系的博士研究生也用粒度 你是沒讀過書還是支語腦？哪種？
你就是測試人員！
一條龍啊
喔這個想法正面我喜歡
推總結
推結論XD
專有名詞用英文比較好。如果沒有看你解釋的話，相信
大部分的人應該也不知道粒度是什麼？
粒度可能還不到常識等級的詞，但不會是什麼大部分人都
不知道的詞，尤其是這行
在這個版講粒度還好吧
依 CNS 標準，應該是精細度? https://reurl.cc/8N73E4
在國家教育研究院樂辭網查 確實大多數都是翻粒度
我國中時讀軟體工程的書就寫粒度了，真不知道某些支語警察是不是沒念過什麼書
真是中文跟專業能力一樣好
推~~~~直白易懂~~
推這篇，也非常同意27樓
看錢做事啊，沒錢沒人力搞啥模組oop
oop太趕時間弄出來的只是垃圾
去做台電台水準時下班不是很爽嗎？
46
首Po在公司待了好幾年，開發的系統越來越多。每個開發時都要搞懂一些新的業務邏輯，上線後 還要後續維護，有問題還要幫忙解決。 但我常常在想，人力沒變，但我身上的loading卻越來越重，現在的我比三年前的我多負責 了一堆系統問題，這樣是合理的嗎？ 大家的公司都是這樣的嗎？31
合理啊，進來這麼久了 對於程式碼和領域的掌握度，一定比幾年前的自己好上許多吧 一樣的工作量以前要做兩個禮拜，現在可能三天就做完了 當然要能做更多的事情 不然公司為什麼要給你更多薪水?21
(恕刪) : 問題是身為資深成員的你，可否提出數據說明工程宅們整天在吵的code quality到底跟業 : 務的關係在哪 : 是不是做同樣規模的feature要花的時間越來越多 : 是不是release後常常出問題要修17
微服務似乎可以改善一點這方面的問題 系統開發有點像是公司還很小的時侯 當你公司還很小的時侯 某個職員要當客服 又要兼倉管 又要兼銷售 所以這個職員可以拿到各種不同的數據
91
Re: [討論] 對岸的軟體工程師分享一下現在中國公司工作的狀況好了， 程式碼 build 都沒過，是絕對不能回家的，你會害很多人被扣錢。 首先程式碼 commit到分支前，都要設定好jenkins 使用 git push 程式碼到 repository 的分支時， 會觸發CICD流程，大致會執行以下流程:39
[討論] chatGPT會取代軟體工程師嗎?chatGPT會取代軟體工程師嗎? 我覺得這是個很有趣的問題，但其實沒有很精確。 如果要我講的話，我會說: 會，但會取代很基本的碼農，但是資深的軟體工程師絕對無法 取代。 這怎麼說呢? chatGPT是可以幫你寫程式碼沒錯，但前提是你要問對問題啊。 我目前是個有點年資的軟韌體工程師，我往往要解決的是一個"系統性"的問題，而24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題，來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。 3. 重構是一種相對安全的工具型開發方法論， 但仍然有不少風險跟誘惑。8
Re: [請益] 如何當軟體QA??之前寫的軟體測試幾個層級，提供參考。 最入門的狀況，Intern/工讀生通常只會碰到這 A. 依照Test Case進行測試。回報Issue,重現步驟 B. 有能力建置測試環境到可以部屬待測軟體。 測試的軟性觀念，這邊開始才真的進入測試的領域。![Re: [請益] 如何當軟體QA??](https://www.talentbooster.net/gleeceez/TB_MetaFB2_1200x650.jpg "Re: [請益] 如何當軟體QA??")
7
Re: [閒聊] 寫程式真的這麼邪門嗎？呃 講這個其實蠻尷尬的 因為綠乖乖是最省錢的解（？）XD 一般來說要提升程式碼品質 一些軟體工程的東西要確實執行6
Re: [新聞] 爭取路權 重機團體聲請釋憲盼合法行駛國想從另一個角度來說明一下在這部分不贊成的可能性。 我們先來假設整個交通系統 是一個電路系統，國道、省道和一般道路等都是一種模組， 但由於電力不穩(駕駛行為)和架構問題，像是道路(線路)設計及執行(法規、罰則及執法)效 率等，
![Re: [討論] 國泰出這包不太行吧](https://avatars.githubusercontent.com/u/8318854?v=4?s=400 "Re: [討論] 國泰出這包不太行吧")