Re: [閒聊] 各位工作有遇到甚麼很扯的事情嗎?

看板Soft_Job作者 (.)時間11年前 (2012/09/19 01:24), 編輯推噓4(4推 0噓 38→)
留言42則, 8人參與, 最新討論串28/28 (看更多)
※ 引述《PeacockLiu (小書生)》之銘言： : 那次開始我取消她check in到master的資格 說到這種團體合作code的同步更新工具, 我覺得就我個人來說是不太看好這種模式的, 除非你一整個team都很強.默契也很好, 用這種工具會有 1+1=2(這應該已經是最理想的了)甚至 1+1>2 的開發效率, 不然我看到的情況是,會為了很多同步問題.溝通認知問題, 浪費不少時間在這些整修上,更甚至衍伸出責任歸屬不清問題, 我還是覺得,除非project真的大到一定的規模, 不然還是一人獨立就全部負責單一project, 然後利用工具來當成備份性質使用就好, 或是最少也切割成可以單獨獨立的子prject給個別負責, 最怕就是幾個人混雜在一起,相依性極高,互卡來卡去, 一下子哪裡沒更新到.一下子衝突.一下子要抓到底誰的部分出問題.... 減少了相依性,一定會增加程式碼的累贅度,不過很多利弊考量下, 或許是比較好的做法,再不然就是核心共用的部分, 應該要分配給比較有經驗可靠的人. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.70.79.227
→
09/19 01:28, , 1F
用這種 tool 旨在爆炸時可以有前一個板本可以追，不是在增加
09/19 01:28, 1F
→
09/19 01:29, , 2F
開發效率...把程式碼切割清楚跟工具沒有關係，是 Team work
09/19 01:29, 2F
→
09/19 01:29, , 3F
本來就該有的方法論，如果沒有這種工具又需要頻繁修改同樣幾
09/19 01:29, 3F
→
09/19 01:29, , 4F
個檔案（ex.設定檔、語系檔），只會死得更快...
09/19 01:29, 4F
→
09/19 01:32, , 5F
我也是認為備份才是重點 不過很多人是想拿它來當協同創作
09/19 01:32, 5F
→
09/19 01:32, , 6F
其實你仔細想想，那些 conflict 只是透過這個機制才浮上檯面
09/19 01:32, 6F
→
09/19 01:32, , 7F
，某個角鍍上是好事，比起他們改了之後才發現雙方檔案都被改
09/19 01:32, 7F
→
09/19 01:33, , 8F
。那時候死傷一定更慘重。
09/19 01:33, 8F
→
09/19 01:33, , 9F
只要有兩個人以上同時編輯同一份code base，就一定會有衝突
09/19 01:33, 9F
→
09/19 01:33, , 10F
，有個機制上衝突浮上檯面其實不是"增加成本"，而是降低溝通
09/19 01:33, 10F
→
09/19 01:34, , 11F
成本。這是我的看法。
09/19 01:34, 11F
→
09/19 01:34, , 12F
當然你說，那我專案都切成一個人作不要有衝突不就好了，現實
09/19 01:34, 12F
→
09/19 01:34, , 13F
是，就算只有一個人，只要 workspace 有兩個以上還是會自己
09/19 01:34, 13F
→
09/19 01:34, , 14F
跟自己打架...ex. production vs localhost
09/19 01:34, 14F
→
09/19 01:35, , 15F
只是自己不知不覺中吸收掉這些成本所以沒有浮上檯面而已
09/19 01:35, 15F
推
09/19 01:35, , 16F
若有兩人以上開發同一模組是常態，其實可以考慮 branch
09/19 01:35, 16F
→
09/19 01:36, , 17F
平常各自開發時在自己所擁有的 branch 上開發
09/19 01:36, 17F
→
09/19 01:37, , 18F
要看conflict 的類型..像語系檔這種東西 用什麼都很難躲. XD
09/19 01:37, 18F
→
09/19 01:37, , 19F
再律定特定的時間點或周期進行 branch merge
09/19 01:37, 19F
→
09/19 01:37, , 20F
只能靠切 bundle 來盡量避免 conflict 讓大家編輯的語系盡量
09/19 01:37, 20F
→
09/19 01:37, , 21F
錯開。
09/19 01:37, 21F
→
09/19 01:37, , 22F
當 merge 時，兩個要一起坐下來解 conflict
09/19 01:37, 22F
→
09/19 01:38, , 23F
如果說各自功能單元蠻獨立的 method 之類的，切 branch 就很
09/19 01:38, 23F
→
09/19 01:38, , 24F
有效。
09/19 01:38, 24F
→
09/19 01:39, , 25F
其實切 branch 是為了平常時大家可以分別作業，不用互卡
09/19 01:39, 25F
→
09/19 01:40, , 26F
merge 時再把會 conflict 的地方一次處理掉
09/19 01:40, 26F
→
09/19 01:41, , 27F
畢竟解 merge conflict 所佔的時間百分比不會太大
09/19 01:41, 27F
→
09/19 01:42, , 28F
在進行merge工作時把相關PG都叫進會議室一起解conflict
09/19 01:42, 28F
→
09/19 01:48, , 29F
順便複習 pair (triple/quadruple/quintuple) programming
09/19 01:48, 29F
→
09/19 10:51, , 30F
解一個檔案的一個 conflict 不花什麼時間，但是解五十個檔案
09/19 10:51, 30F
→
09/19 10:51, , 31F
的五百個conflict 就很難說了。XD 要看什麼樣的 conflict。
09/19 10:51, 31F
推
09/19 10:57, , 32F
能累積到五十個檔案的conflict大概至少有一兩個月沒merge
09/19 10:57, 32F
→
09/19 10:59, , 33F
那就縮短 merge cycle 吧，隔太久沒 merge 對大家都是災難
09/19 10:59, 33F
→
09/19 11:00, , 34F
無論使用什麼仙丹都無解
09/19 11:00, 34F
推
09/19 12:59, , 35F
確實切割功能、分清權責、實做前的協調都能盡可能的減少事
09/19 12:59, 35F
→
09/19 13:00, , 36F
後conflict的發生~而且為什麼不是一早就update~下班前comm
09/19 13:00, 36F
→
09/19 13:01, , 37F
it前解conflict?每天都該保持程式碼的一致性~不是嗎?
09/19 13:01, 37F
→
09/19 13:39, , 38F
這根本不是工具的問題 而是使用工具的人的問題吧
09/19 13:39, 38F
→
09/19 13:40, , 39F
怎麼可能每個project都一個人沒有team work
09/19 13:40, 39F
→
09/19 21:38, , 40F
這篇真的是超神奇的經典..XD
09/19 21:38, 40F
→
09/19 23:05, , 41F
看到備份兩個字, 我笑了
09/19 23:05, 41F
推
09/20 02:21, , 42F
人的問題++
09/20 02:21, 42F
‣ 更多 erspicu 的文章
文章代碼(AID): #1GMAvcoa (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 28 之 28 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共28篇)
‣ 更多 erspicu 的文章
文章代碼(AID): #1GMAvcoa (Soft_Job)