[討論] 同一個程式碼段落超過一人以上在修改
如題,好奇想問一下
基本上在有正常版控的條件下
這種情況是不是根本不該發生?
尤其是開發周期尚未結束,沒有要交接
每個人負責的部分
最小單位應該直接用檔案切開
一個檔案只會有一個人在維護、push code
即使是超龐大Class
也應該儘量切成不同小Class
然後利用繼承、封裝、多型分工出去才對
因為我常遇到為了rebase
需要一定程度搬動到別人的code
可能就是往前往後個幾行
或是在相同段落內插入幾行自己的
這種情況是否就代表分工不明確、模組化沒做好?
是否有甚麼情況是讓這件事可以被接受的
還是這種情況本來就家常便飯
單純我太龜毛而已XD
--
這就跟隕石開發一樣阿,不應該,但大家都習慣了
只要沒天兵直接蓋過去就好了
自己解conflict啊
如果我解完我的conflict之後,讓你寫的某個function多了幾行,就算功能不影響,但這件事不會怪怪的嗎
那些被你搬動的code就是比你早commit啊 那就是既有程式碼
了 三分鐘前才commit進去的code 跟上個月寫好commit進去
的code有什麼分別嗎
就很常見吧 誰晚進去 誰就rebase 測試寫好不要影響對方
你說的就是svn的概念,就是因為不好用才慢慢改成 git
你能想像為了改一個檔案等一個星期的痛苦嗎?
很正常吧 站會聊一聊不就解決了
那就代表那段邏輯還沒完善而已啊
為何會很常遇到呀,分工通常是每個人會開發不一樣 c
omponent ,還是剛好都一直碰到共用的地方?
目前算是模組化沒切好,所以灰色地帶太大了
猜拳決定誰處理衝突
單元測試覆蓋到就會安心點
理論上然樓主說的算對,但現實上,跟你合作的人,程式碼品
質就是無法預期.要是他又是你客戶公司的正職RD,那你能
怎樣? 跟你的客戶PM抱怨說你們家誰誰誰寫code很髒??
或是你自己開公司當最高的甲方
啊版控不就是要處理這件事的嗎?
丟給chatgpt請他優化就好
這不是很正常的事情嗎 版控某方面也是預防被蓋過去啊
不正常耶 代表每個人負責的功能是互相影響的
就沒切好,檔案改了又沒查,你UT不給他過不給merge就好
看起來怪怪的 這是大家都維護同一個branch的意思嗎?
如果不同branch 就是給衰小的人merge
本文中提到的rebase是指你們上到master很頻繁嗎?
開發專案照檔案切負責範圍???第一次聽到,長見識了
我的意思不是這樣XD
感覺你們該做的是切branch來最小化這個問題
衝突很常見啊,尤其團隊規模一大自然避不開
你要PR前本來就要rebase 跟是不是branch有啥關係
版本控制讓多人對同一段 code 貢獻變得可能,衝突時解
conflict 很正常,而往往問題不是在 conflict,而是在
有人 code 寫太爛
其實我問的就是多人對同一段code貢獻這件事,我總覺得怪怪的
會容易改到同一段code或同一個function是你們本身
架構上就有問題 沒做好solid吧
超正常啊,公司一個人只負責特定的程式碼,會滿危險的
,沒辦法互相 cover
vscode live share
你們的系統可能缺乏「架構」
正常 尤其有兩三個長期專案在跑時 常會影響其他人
其實這也是CICD的精神 一但commit就要做integration test
就算模組切的在細 都有可能遇到多人開發conflict的狀況
最小單位用檔案切開 除非你們真的湊巧 他加欄位你修功能
不過這是理想的情境 專案頻頻發生衝突這並不正常
確實做到單一職責 切開之後別人的code多髒都不關你事
我也這麼覺得
請切開
你自己不就有答案了 你有空幫忙切開封裝啊
怎麼切都還是會有可能衝突,尤其是不同bug卻改到相近的區塊
上面說什麼模組切的好就不會的都是唬爛你的,講誰都會講。
我覺得就算是理想情況,當然實際不一定能做到完美
一般情況不會一起寫同一個函式吧?
同時間不同人頻繁改同一個段落確實很奇怪 也許可以用unit
test確保執行成果符合預期
conflict無法完全避免喔
目前看大家的回覆確實應該要切開,當然理想跟實際執行還是有差 但至少切乾淨這個理念要有才對
※ 編輯: ManGo1012 (118.163.80.132 臺灣), 03/21/2023 12:28:31你想一下開放封閉原則你就會發現他不符合,但礙於
每個人現在都有新的功能要開發,我建議你們各自寫
一個擴充版本跟測試,以後找另一個人重構,除非你
們有一個大神直接重構成很好的樣子,不然一直改會
很痛苦
樓上 理想很豐滿 現實和骨感
是不想回家了的意思嗎?
慣老闆:浪費時間重構啥雞巴 能賺錢嗎
你動到別人可能在改的 code 時,就要有意識可能會 con
flict。先跟對方確認沒有相依,有的話就約定好一個順
序,看是誰要先誰要後
找一個人重構, 這種沒考績的屎缺誰要做
先寫測試 有測試保護再談重構 重構也不用特地請人寫
重構是在有寫測試保護的情境下 自己找時間或順手重構
一般不太可能知道這個code同時有誰在改吧......
如果跑敏捷 也可以在daily standup講一下自己今天要
處理的ticket做溝通啦…
樓上 多數的scrum master為了排除障礙
短期見效 就是派衰小的人去merge阿XD
他這個問題就有點像是工項拆解
或是程式架構
甚至到git branch的切割
其中的某一項或是某幾項有問題
乍看之下應該是無法在立會後短期奏效的issue
負責merge的人真的衰 所以我們是每週不同人輪流merge
版控又不能控需求還有工作分派和時程
組件分開再組裝稍微好點 不是一個一個ser
server 強迫別人寫稍好的程式
模組化
這跟元件,solid 哪有什麼關係,任務分配下去 共用到哪些
邏輯又不能控制
你確保封裝邊界不要更改,如要大改 要通知大家有相依的
先等你的發車在往下進行 如果有人比你急 你就晚點改
功能本來就一環串一環 怎麼切看話事人功力
力 我講的不是solid 是專案內kiss
統整的人再把它串起來功能就完成了
就像shell只是調用方的角色 前面說的衝突
的衝突多是一個人事情做太多會發生的
其實也就是叫別人寫lib 好處很多
相依於介面 改的人修內部邏輯 用的人DI介面 就不會衝突
27
[請益] 如何快速用java寫出卡牌對戰遊戲對java的物件導向概念始終感到很迷茫,有點難想像class之間怎麼傳那麼多層,要怎麼傳過去,更遑論設計遊戲流程,看別人的code能看懂,但自己寫不太出來。 然而期末小組專題期限將近,要設計web畫面的卡牌遊戲,玩家與電腦對戰。 前端老師已經寫好,遊戲初始畫面我已經做好,但覺得寫得有點亂。玩家點擊卡片到移動攻擊、進階攻擊方法則還沒有,如果用js我有信心能做出來。 同學聽到我們組的情況有好心借我看她寫的部分的code。其實越看越emo,她的code寫的好乾淨。 其實具體也不知道要問什麼問題,目前想法是先把架構想明白再來開發,但是問題是想不太清楚需要再加哪些class,又需要給哪些功能,最難的還是知道資料怎麼流的,語法也不熟,感覺這兩天開發是學到了很多,已經不求寫完整,只求弄明白,我想只是需要有人能指引方向,感謝。26
[請益] 這種情況要怎麼重構我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來,一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用22
[請益] git協同合作問題遇到一個情境 想請問應該如何操作 假設現在 有一個主分支release 兩個feature branch 第二個分支需要用到第一個分支部分代碼20
Re: [請益] Spring boot的依賴注入降低耦合的例子在這個時代依賴注入最重要的用途,特別是在後端開發是讓Application 在多個不同的 環境下(Development, Production, local, etc) 能夠根據profile 組出能正確執行的Application 多型在這裡當然有他的地位,但是一般來說,大部分不接觸system boundary的service objects 是不太需要多型的,如果是java,那種一個interface 只有一個implementation15
Re: [請益] 如何有效率的看code ?如果你沒寫錯的話 一年多看幾萬行code真的不多 我也是轉職仔,原本在ic house寫C做韌體,一個人負責一個.c/.h檔。一年才進三行code。 轉職後寫C++整個team大約十多人,負責的那一層有兩千萬行code。然後第一年就進快一萬行code。 我原本不會C++的,所以什麼framework,modern C++,design pattern,multithreaded 之類的都沒學過要重學。13
Re: [請益] 多型用在哪本魯 OO 不太好 但你這例子多型嗎 這就只是子類別繼承父類別的屬性吧 多型比較像這樣吧 class DataLoader {11
Re: [請益] 請問這樣的git使用方式是否是正確的?個人意見,僅供參考 不太確定常不常見,但看起來是合理的。 可以想到的好處和情況是 不同的service 可以分開Build,Build 之後的artifact 可以依照每個service 的開發進 度deploy 到不同的測試環境,利於不同進度的開發和整合。9
Re: [請益] 比物件導向更先進的程式設計思想?依照目前看CodeReview 大部分人寫程式的方式 其實都披著OOP的皮 寫不是OOP的程式 甚至還看過很愛嘴別人的主管4
Re: [請益] 多型用在哪ㄛ現在ㄉ想法4 沒有多型 只有介面 多型的用例之一 for(auto p_actor : actors) p_actor->act() 對ㄛ來縮 p_actor實際上到底是什麼 並不重要3
Re: [閒聊] ChatGPT是語言模型不是搜尋引擎這個敘述也太強烈了吧? StackOverflow 上面不是只有 code template,重要的是有很多的討論和推論。 而且如果有新的library出來,很多人也會在StackOverflow上討論 關於這個議題,我來分享我最近遇到的案例 最近在工作上寫code遇到一個問題是,我發現,