PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 寫程式的追求？

看板Soft_Job (軟體人)作者 (PCMan)時間3周前 (2025/05/15 15:53), 編輯推噓81(81推 0噓 43→)
留言124則, 84人參與, 1周前最新討論串16/19 (看更多)
※ 引述《del680202 (HANA)》之銘言： : ※ 引述《neo5277 (I am an agent of chaos)》之銘言： : : 純粹對工作上來說 : : 好抽換，好接手(易閱讀)，好維護(包含升級，測試 : 好接手，易閱讀… : 我想到一個故事 看到你的故事，讓我想起好多當年犯過的錯誤 : 幾年前有個同事，號稱國中時期就開始接案寫代碼 : clean code,DDD滾瓜爛熟,對coding極度潔癖 : 印象比較深的是入職時說了句：我看到不規範的代碼會非常生氣 我年輕的時候也這樣，但做久了慢慢可以理解凡事都是 trade-off 寫得很漂亮，卻沒商業價值的 code，根本沒人在用， 對比寫得很亂，卻實際有大量使用者的 code，很難說哪個是比較好的。 剛進業界第一份工作，很認真的幫每個 function 寫滿註解跟 API doc， 努力遵循各種 best practice，幾個月後專案取消了，這 code 從來沒上 production 對比那些可怕的 legacy code，每天都好好的運行著賺錢的服務。 後來開始懂得要考量 business 的需求，有時候犧牲一點品質，搶占先機是必要之惡 : 上工第一案子，設計一個工具網站，拆了七個GitHub repo 這我當年剛學 git/github 也做過，把個巨大專案拆了十幾個 repo， 原先要解決的問題是，希望每個元件可以降低耦合，容易獨立使用，分開 deploy。 隨著時間，逐漸發現各個元件需要共用的東西越來越多，互相 dependency 逐漸變多 這時候各個元件之間需要正確的版本，才能互相搭配，管理起來卻成了噩夢 有些直接 include 就能用的東西，拆在兩個 repo 掛 submodule 變得很難維護 build rules / makefile 也因此複雜了起來，最後有點後悔一開始把他們拆開。 體驗過就能理解為何很多大公司最後走向 monorepo 架構，全公司專案都在一個 repo 其中一個經典案例就是 google，幾乎全公司所有 code 在一個巨無霸 repo 內。 不同程式互相引用，就少有版本管理問題，開發的複雜度降低很多。 : Micro services, grpc當年流行的工具全套了一輪 : 說是將低耦合，高內聚做到極致 剛進業界的時候，我也是剛學了 microservice，很開心地把手上系統全拆了 拆分得很乾淨，每個服務都可以分開擴展，一開始還覺得這是 best practice 後來學到血淚教訓。因為業務的改變，需求大幅度改變了。原先的拆分並不合適 反而讓開發、測試、跟部署變得複雜，印證了 "monolith first" 的建議! 在早期需求還不明朗的時候，全部塞在一起，其實不是壞事，延遲到真正出現擴展需求 再來拆分，會比過早拆分要好。這跟不要 premature optimization 感覺很像。 就跟一開始學 OOP 都狂寫 interface，後來才發現根本沒有其他 implementation 白白多了一堆無謂的繼承，最後又發現需要不同的行為，於是換了 interface 本來定義的抽象化不但沒用到，還因為要保持相容，造成日後擴充的阻礙。 後來就學到 "concrete first"，不要起手式就急著開 abstract interface， 可以延後到真的有需要再來做，有時候反而會更合適。 做久了慢慢對這些東西有不同的感受，best practice 通常要放在特定情境下才是 best 如果很清楚自己做了什麼 trade-off，違反它們不見得是錯誤的。 : 其中一個repo 甚至只放了一個utils : 後來來了另一個人接手 : 改個功能要先看懂七個repo之間關聯，跟找大秘寶似的 : 在review code階段，還埋個彩蛋，發現了隱藏的第八個repo : 新來的同事說改不動了，就算加個menu都很麻煩 : 心一橫，提案該網站功能也不複雜，全部打掉重做 : 就自己埋頭花了兩週重做了那個網站加遷移 兩個禮拜是不是沒算到寫 test 跟重作 QA 的時間 XD 寫 code 相對快，大部分開發時間本就都花在其他地方 這種大霹靂式的重寫，通常是很危險的 XD : 工程師追求的很簡單，(自己）好閱讀，（自己）好維護就行了 : ----- : Sent from JPTT on my iPhone -- Sent from PCMan on PCMan's PC -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 73.70.25.48 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1747295625.A.D41.html
→
05/15 16:29, 3周前 , 1F
簡單一句話: 不要過早完美化。技術服務業務，隨服務演進
05/15 16:29, 1F
推
05/15 16:39, 3周前 , 2F
PCMAN大神
05/15 16:39, 2F
推
05/15 16:44, 3周前 , 3F
只能推
05/15 16:44, 3F
推
05/15 16:54, 3周前 , 4F
on demand做 而refactor的時候需要test避免你改錯
05/15 16:54, 4F
→
05/15 16:55, 3周前 , 5F
That's why unit tests are important
05/15 16:55, 5F
推
05/15 17:03, 3周前 , 6F
確實
05/15 17:03, 6F
推
05/15 17:30, 3周前 , 7F
感謝大大分享
05/15 17:30, 7F
→
05/15 17:41, 3周前 , 8F
寫不寫的漂亮與市場反應是兩件事情 這與公司經營和高
05/15 17:41, 8F
→
05/15 17:42, 3周前 , 9F
層思想才有關係 寫的好不代表一定花時間
05/15 17:42, 9F
→
05/15 17:44, 3周前 , 10F
但為了不讓資本囂張 我讚同有時可以這麼做
05/15 17:44, 10F
→
05/15 17:46, 3周前 , 11F
我認為 一個專案的基礎架構 開發藍圖 工時 要能準確估算跟
05/15 17:46, 11F
→
05/15 17:46, 3周前 , 12F
執行真的都需要高度經驗
05/15 17:46, 12F
→
05/15 17:47, 3周前 , 13F
工作而言 重要的事是怎麼在日期限制內交出及格的作品
05/15 17:47, 13F
→
05/15 17:47, 3周前 , 14F
什麼要取捨 什麼一定要做到
05/15 17:47, 14F
→
05/15 17:47, 3周前 , 15F
有時也不一定是資本囂張 是高層囂張
05/15 17:47, 15F
推
05/15 18:38, 3周前 , 16F
推這篇，句句是實務
05/15 18:38, 16F
推
05/15 18:57, 3周前 , 17F
至少你走過來了，辛苦了
05/15 18:57, 17F
推
05/15 19:19, 3周前 , 18F
推大神
05/15 19:19, 18F
推
05/15 20:28, 3周前 , 19F
上古神獸推推
05/15 20:28, 19F
推
05/15 20:51, 3周前 , 20F
推，雖然層級有差但魯蛇做久了感想完全一樣
05/15 20:51, 20F
推
05/15 20:56, 3周前 , 21F
感謝分享 看完覺得茅塞頓開
05/15 20:56, 21F
推
05/15 21:09, 3周前 , 22F
最近也有這種感覺，會開始要求自己做到best practice
05/15 21:09, 22F
→
05/15 21:09, 3周前 , 23F
，但老實說這是必經之路吧，經歷過凡事都要求完美的路
05/15 21:09, 23F
→
05/15 21:09, 3周前 , 24F
，才會知道哪些可以放棄不用
05/15 21:09, 24F
推
05/15 21:55, 3周前 , 25F
大神推推 都是血和淚的教訓
05/15 21:55, 25F
推
05/15 22:08, 3周前 , 26F
推
05/15 22:08, 26F
推
05/15 22:17, 3周前 , 27F
best 根本就不存在，完全是商業手法的誤導，欺騙初
05/15 22:17, 27F
→
05/15 22:17, 3周前 , 28F
學者以為只要看到 best 學就對，自己就會變成 best
05/15 22:17, 28F
→
05/15 22:18, 3周前 , 29F
這個世界只有 suitable practice ，最合適的，沒有
05/15 22:18, 29F
→
05/15 22:18, 3周前 , 30F
最好的
05/15 22:18, 30F
推
05/15 22:20, 3周前 , 31F
很多都這樣 一開始能動最重要，真的有閒穩定下來後才是
05/15 22:20, 31F
→
05/15 22:20, 3周前 , 32F
重構的部分
05/15 22:20, 32F
推
05/15 22:22, 3周前 , 33F
interface真的是說到點了，可能補習班教吧 一堆人都照著
05/15 22:22, 33F
→
05/15 22:22, 3周前 , 34F
一個service都做一個interface然後就只有自己實作
05/15 22:22, 34F
推
05/15 22:41, 3周前 , 35F
神獸來了快拜一下~~~
05/15 22:41, 35F
→
05/15 22:42, 3周前 , 36F
interface 還是看語言跟框架用啊
05/15 22:42, 36F
推
05/15 23:20, 3周前 , 37F
推這篇，這幾年工作下來的經驗也是如此，尤其碰到專案需求
05/15 23:20, 37F
→
05/15 23:20, 3周前 , 38F
變動快速的時候，這篇的經驗會更實用
05/15 23:20, 38F
推
05/15 23:56, 3周前 , 39F
interface 跟 DDD 就是互相成就
05/15 23:56, 39F
還有 45 則推文
推
05/16 22:48, 3周前 , 85F
推大神
05/16 22:48, 85F
推
05/16 23:09, 3周前 , 86F
Google用內部工具Blaze直接否決高耦合 才能不吵架
05/16 23:09, 86F
→
05/17 00:11, 3周前 , 87F
那基本上就算是長官或資深說你要怎麼做 你就得怎麼做XD
05/17 00:11, 87F
推
05/17 01:14, 3周前 , 88F
深有同感
05/17 01:14, 88F
推
05/17 02:25, 2周前 , 89F
推神獸
05/17 02:25, 89F
推
05/17 02:56, 2周前 , 90F
推
05/17 02:56, 90F
推
05/17 07:12, 2周前 , 91F
oop重點寫介面做啥？會寫的直接上手
05/17 07:12, 91F
推
05/17 13:23, 2周前 , 92F
看需求吧 有場景是要把code喂給編譯器看那就另當別論
05/17 13:23, 92F
推
05/17 16:33, 2周前 , 93F
推
05/17 16:33, 93F
推
05/17 19:04, 2周前 , 94F
該怎麼切沒有個聖杯，但核心就是要為爽跟快
05/17 19:04, 94F
→
05/17 19:04, 2周前 , 95F
爽 = 好維護好追問題，快 = 開發不會相依性一堆綁手腳
05/17 19:04, 95F
→
05/17 19:08, 2周前 , 96F
蝦拆但是會往反方向前進的，就是吵 = =
05/17 19:08, 96F
推
05/17 21:18, 2周前 , 97F
推
05/17 21:18, 97F
推
05/17 22:28, 2周前 , 98F
有時候寫interface是怕把依賴方向搞爛 有建議嗎
05/17 22:28, 98F
推
05/18 01:30, 2周前 , 99F
大神推推
05/18 01:30, 99F
推
05/18 08:27, 2周前 , 100F
推推
05/18 08:27, 100F
推
05/18 12:10, 2周前 , 101F
好猛
05/18 12:10, 101F
推
05/18 17:32, 2周前 , 102F
推
05/18 17:32, 102F
推
05/18 20:48, 2周前 , 103F
謝 strlen，gino0717，TaiwanUp，shortoneal
05/18 20:48, 103F
→
05/18 20:48, 2周前 , 104F
4位大大提供的方向
05/18 20:48, 104F
推
05/19 00:09, 2周前 , 105F
謝謝大大分享！講的超清楚
05/19 00:09, 105F
推
05/19 10:39, 2周前 , 106F
朝聖
05/19 10:39, 106F
推
05/19 12:47, 2周前 , 107F
推
05/19 12:47, 107F
推
05/19 22:46, 2周前 , 108F
推
05/19 22:46, 108F
推
05/20 00:55, 2周前 , 109F
推
05/20 00:55, 109F
→
05/20 09:18, 2周前 , 110F
謝分享
05/20 09:18, 110F
推
05/20 17:33, 2周前 , 111F
推，這些真的是慢慢工作才會理解到的
05/20 17:33, 111F
推
05/20 19:25, 2周前 , 112F
推
05/20 19:25, 112F
推
05/20 19:42, 2周前 , 113F
推
05/20 19:42, 113F
推
05/20 22:41, 2周前 , 114F
感謝分享
05/20 22:41, 114F
推
05/21 08:34, 2周前 , 115F
按需求服務 還有漸進式的抽出共用
05/21 08:34, 115F
推
05/21 11:00, 2周前 , 116F
但c#要mock的話不是一定要interface嗎？ 不測試的話的確
05/21 11:00, 116F
→
05/21 11:00, 2周前 , 117F
是不用interface啦
05/21 11:00, 117F
推
05/22 01:58, 2周前 , 118F
熱愛嘗試當下流行的新工具新理論的工程師，常常也是團隊主
05/22 01:58, 118F
→
05/22 01:58, 2周前 , 119F
力，很難找到理由阻止他們嘗試新事物
05/22 01:58, 119F
推
05/22 12:29, 2周前 , 120F
推
05/22 12:29, 120F
推
05/27 18:01, 1周前 , 121F
好奇Google 那樣要怎麼管理不同套件之間的相依性？ 如
05/27 18:01, 121F
→
05/27 18:01, 1周前 , 122F
果都要保持所有test全過的話 幾乎不太可能推新功能？
05/27 18:01, 122F
推
05/27 23:12, 1周前 , 123F
推 這如人月神話所說，軟體之中「沒有銀彈」
05/27 23:12, 123F
推
05/29 00:00, 1周前 , 124F
專業
05/29 00:00, 124F
‣ 更多 HZYSoft 的文章
文章代碼(AID): #1e9Ps9r1 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 16 之 19 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共19篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 HZYSoft 的文章
文章代碼(AID): #1e9Ps9r1 (Soft_Job)