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

看板Soft_Job (軟體人)作者 (PCMan)時間5小時前 (2025/05/15 15:53), 編輯推噓11(11010)
留言21則, 14人參與, 23分鐘前最新討論串16/16 (看更多)
※ 引述《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, 4小時前 , 1F
簡單一句話: 不要過早完美化。技術服務業務,隨服務演進
05/15 16:29, 1F

05/15 16:39, 4小時前 , 2F
PCMAN大神
05/15 16:39, 2F

05/15 16:44, 4小時前 , 3F
只能推
05/15 16:44, 3F

05/15 16:54, 4小時前 , 4F
on demand做 而refactor的時候需要test避免你改錯
05/15 16:54, 4F

05/15 16:55, 4小時前 , 5F
That's why unit tests are important
05/15 16:55, 5F

05/15 17:03, 4小時前 , 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, 2小時前 , 16F
推這篇,句句是實務
05/15 18:38, 16F

05/15 18:57, 2小時前 , 17F
至少你走過來了,辛苦了
05/15 18:57, 17F

05/15 19:19, 2小時前 , 18F
推大神
05/15 19:19, 18F

05/15 20:28, 51分鐘前 , 19F
上古神獸推推
05/15 20:28, 19F

05/15 20:51, 28分鐘前 , 20F
推,雖然層級有差但魯蛇做久了感想完全一樣
05/15 20:51, 20F

05/15 20:56, 23分鐘前 , 21F
感謝分享 看完覺得茅塞頓開
05/15 20:56, 21F
文章代碼(AID): #1e9Ps9r1 (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1e9Ps9r1 (Soft_Job)