Re: [討論] 同一個程式碼段落超過一人以上在修改
※ 引述《ManGo1012 (ManGo)》之銘言:
: 如題,好奇想問一下
: 基本上在有正常版控的條件下
: 這種情況是不是根本不該發生?
: 尤其是開發周期尚未結束,沒有要交接
: 每個人負責的部分
: 最小單位應該直接用檔案切開
: 一個檔案只會有一個人在維護、push code
不一定,可能合理可能很 suck
要看規模、工作流程、有沒有人控場、默契
自己的經驗是分工做得好的地方通常會定義 ownership
「這塊 code 是拎北/拎母的,要改要先問」
積極的 owner 會對 code 要長成怎樣有明確的想法並前進
消極(但合格)的 owner 會讓 code...好好活著不要被亂改
甚至有時候不是明文規定,而是「啊,他對這段 code 最熟」
然後就自然演化成「他是 XX 系統扛壩子」
owner 的權限怎麼貫徹就到處都不一樣了
有的是如同你說的,只有特定人可以改某個檔案/repo
有的是同事可以亂發 PR / MR,但是只有 owner 可以 merge
這種就常常在解衝突,有時候頻率跟吃太陽餅掉屑差不多
一但有不只一人改同一堆 code,就會開始有知識的邊界的問題
怎麼知道哪段 code 在幹嘛,有什麼眉角,跟什麼外部系統有互動
又是哪個客戶提這種雞掰需求所以看起來雖然很怪但是不能改
在沒有明確定義 owner 的地方,這種事情會變成吵架的火種
(有定義的地方大概就會走一個「我要告老師(owner)啦哼哼哼」的路線...)
所以有類似制度的地方很多會做 code review,除了看同事 code 寫得如何
也很大成分是確保同事間知道彼此在做什麼,不用很熟,依稀有印象就可以了
「幹,這段 code 這麼鬼」
「我想起來了,有看過 MR,客戶A有這個雞掰需求...靠北這 MR 你發的耶」
「...幹我自己寫的自己忘了」
另外是 MR / PR 看多之後同事彼此的 code 會越來越像
之後改彼此的 code 會容易一點,這需要時間磨合就是
(但還是常看到因為「你這 code 寫好爛」而吵架的
軟體工程裡面最 suck 的終究是人類這個要素....)
BTW,MR / PR 跟其他所有的同事互動一樣
會展現出誰是雞掰郎,誰是會把事情都整理好再交出去的好孩子
回過頭,你碰到的問題不是「很多人改同一段 code」
而是「ownership 不明確」
然後你就覺得「他國軍艦駛入我國領海,幹林老師」
只是也可能想像出各種讓「定義 owner」很麻煩的理由就是
事情只要扯到人跟業務就是各種 suck
而大部分的 code 是人為了業務寫的
suck \(^_^)/ suck \(^_^)/ suck
: 即使是超龐大Class
: 也應該儘量切成不同小Class
: 然後利用繼承、封裝、多型分工出去才對
切小的好處
- 對腦袋比較輕鬆,一次不用載入這麼多 code
- 權限設定比較容易
切小的壞處
- 想想 java 的 stacktrace 為什麼會這麼長一串
這也是程度問題就是...
一千行的 class 也許 suck 也許合理,要看狀況而定
一萬行的 class 基本上很 suck,不過能不能重構則是另一個問題(泣
另外對外面的人來說,這有點單一窗口 vs 跑好多窗口的差別
前提是介面設計合理不亂七八糟就是
--
起來,不願做光棍的人們,把女孩的清純築成我們新的長城
蘿莉控們到了最危險的時候。每個人被迫著發出最後的吼聲。
起來!起來!起來!
我們萬眾一心,往著女孩的裙底,前進!
往著女孩的裙底,前進!前進!前進!進!
--
他國軍艦駛入我國領海確實很符合我的感覺XD,所以我才
問說會有這種感覺是不是我太龜毛
對自己的 code 主張所有權通常是個好跡象 比較不會始亂終棄,也比較認同權力帶來的責任 不過你們公司該怎麼做比較順就不一定了 「誰管什麼東西」其實是個政治問題 - 某個 class / 檔案全部你管,你認同嗎?你同事跟主管認同嗎? - 怎麼決定是哪幾個 class / 檔案? - 其他人怎麼知道是哪幾個 class / 檔案? - 所有該放進去的邏輯都由你來改,不管案子是不是你的,願意嗎? - 或每次要改之前都先跟你說一聲? - 如果其他人送 MR,你不會因為自己忙就都放個兩天再來看嗎? - 怎麼執行?怎麼避免其他人 merge?(Gitlab / Github 都以 repo 切分) - 整個 repo 你管 - 你有辦法處理(或至少認識)整個 repo 的流通業務嗎? - 處理 MR 速度能跟上同事寫 code 的速度嗎? - 全部拆掉 - 要花多少人力多少時間 - 該拆成什麼形狀?誰決定?整合誰管?(對,又冒出個空 owner) - 如果業務在人之間流動,切的形狀要跟著改嗎? - 或者...其他? 最大的問題: - 能說服有決定權的人認同「解這題付出的成本,值得」嗎? - 能說服業務在客戶 / stakeholder / 大老闆面前幫你坦嗎? 軟體工程很大一部分其實是要處理人的問題 以人為主的問題其實就是政治問題 但寫 code 的人(包括我)又很都自覺討厭處理政治問題...
※ 編輯: GALINE (218.166.77.235 臺灣), 03/21/2023 13:35:38雖然說看得懂就好但我還是想吐槽suck不是形容詞…
推這篇
推,專業
推推
推推
stakeholder
感謝... Orz
※ 編輯: GALINE (114.27.210.82 臺灣), 03/22/2023 16:53:43推 很貼切XD
爆
Re: [爆卦] 國中科展天才呂同學,就是唐鳳2.0無誤!嗨我剛剛把影片看完了 簡單來說他這段演講在介紹他學習ML的過程 他會看model的架構並理解 然後自己寫出code放到開源的github上 還很貼心的付了github repo給大家爆
Re: [心得] 如果可以, 真的建議不要再去創業公司了看到這篇好幾天了,想想還是也來分享一點個人經驗 我自己在業界的資歷沒有很久,也不是本科出身。 從十幾年前玩 open source 專案,誤打誤撞一路寫 code 到現在, 後來去國立資工所洗了一下 XD 所以現在也號稱本科了 研究所畢業後進入稍有規模的新創,後來也待了大公司。27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言: : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司,我進去前已就有一個前端工程師,他從0建構了整個產品A 代表他能力不算差24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3417
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候15
Re: [請益] 如何有效率的看code ?如果你沒寫錯的話 一年多看幾萬行code真的不多 我也是轉職仔,原本在ic house寫C做韌體,一個人負責一個.c/.h檔。一年才進三行code。 轉職後寫C++整個team大約十多人,負責的那一層有兩千萬行code。然後第一年就進快一萬行code。 我原本不會C++的,所以什麼framework,modern C++,design pattern,multithreaded 之類的都沒學過要重學。6
Re: 不想唸碩士了,想去刷題想作一下補充,維護legacy code應該算是比較吃經驗跟工程技術: 1. 判別code smell 2. 了解原code的邏輯 (願意而且能夠讀懂別人的程式碼) 3. 還要能改得對 看這位大大應該是解題能力強、做大型專案的能力也強,把code寫對跟寫好對你