作者TonyQ (自立而後立人)
看板Soft_Job
標題Re: [請益] 沒有版控的開發與未來發展
時間Wed Sep 11 10:06:04 2013
: → logooo77:不覺得沒做管控不好 09/11 01:00
: 推 logooo77:我覺得你可以把你的經驗先試著放掉 然後在做互相比較 09/11 01:03
: 推 logooo77:茪H自己來會先比較好 09/11 01:04
你不覺得你上面這兩句推文跟你底下這些推文剛好衝突嗎？
跟你價值觀不一樣的就把經驗放掉，然後你的經驗就放不掉這樣。XD
我覺得別這麼複雜，講自己經驗就好了，
不用去講別人放不放掉，放不掉的是誰都還不知道。
有沒有做版控的 team 我都有待過，
沒做的地方我自己做，幾乎最後都成功感染到大家都有做。
有做的地方還可以藉由版控彼此討論怎麼協作更有效率。
: → logooo77:^個人 你順便可以評估一下 09/11 01:05
: → logooo77:因為在這軟體開發的路上，沒有一種做法一定是鐵則 09/11 01:11
: → logooo77:以前我要帶年紀很大的工程師，光是git就讓他們考倒他們了 09/11 01:11
: → logooo77:從我自己開始使用版本控管，到開始導入到公司，花了不少 09/11 01:12
: → logooo77:時間跟撰寫文件，後來他們也認同這種做法 大家一起用 09/11 01:12
: → logooo77:當然途中還有一些新技術安插進來，但實際用過後不符合 09/11 01:13
: → logooo77:效益，也沒辦法讓產能或減少問題產生 09/11 01:13
重點是問題在哪，這才是重點，要討論的是哪些環境不能用或沒效益，
還是你想要看我點名哪幾家公司用 zip 存版本控制常存到丟三落四的。XD
還是你想要我點名某幾家，因為沒做版本控制系統，
所以 source 掉了之後只能從 production 上 decompile 回來重寫的。
這些我都碰過，他們的確比沒做版本控制產生了更多問題。
這不是技術崇拜的問題，現實是做了版本控制有助於 co-working，
做了會因為 merge 產生 conflict 造成額外負擔，那是你的專案管理問題，
太多人在同時編輯同一個檔案而且又彼此不知道對方在幹麼，
你不做也只是在賭運氣。
版本控制本來就不是增加產能的，他是拿來買保險的，
應該說他主要的產能在於當意外發生的那一刻，
還有協助彼此在編輯時對於 conflict 產生瞭解與討論。
沒有版本控制系統的情況下，
連別人到底改了你系統中哪一個檔案你都不知道，
然後你很容易不小心就蓋過去了。
然後每次 deploy 就在那邊提心吊膽有沒有東西沒處理到，
以後追修改也不知道當初改什麼。
這不是工程師能力的問題，因為工程師沒有讀心術。
: → logooo77:我覺得身為一個軟體開發者，有時候要多試試不同環境 09/11 01:14
: → logooo77:才能找出你當時擁護或崇拜某些事物的價值 09/11 01:15
: → logooo77:（文字打得亂七八糟，傷眼請見諒，來不及編輯） 09/11 01:16
: → atst2:有些事別人已經吃過虧的，何必自己再去吃一次虧來驗證? 09/11 01:24
: 推 damody:把硬碟打壞再來問好嗎？ 09/11 01:36
: → logooo77:那就別待那間呀ˊ_>ˋ。 09/11 02:55
: 推 logooo77:通常要改變，就先從自己開先試，不習慣就離開 09/11 03:05
: 推 logooo77:還有我也說了，不然就自己做控管就好，以後真的有事在說 09/11 03:12
: → logooo77:另外就是，我不認為新進去的員工，可以馬上原先的作業流 09/11 03:27
: → logooo77:程進行一些修正，因為你還要先跟老員工周旋 09/11 03:27
: → logooo77:atst2 關於別人吃過虧 這件事情 我覺得這個很有趣 09/11 03:30
: → logooo77:或許別人提出的solution 很合你的胃口 09/11 03:31
: → logooo77:但套用在別人上不見得是好事，甚至是麻煩 09/11 03:31
: → logooo77:若有心要改變，就得先瞭解他們的生態 跟作業方式 09/11 03:32
: → logooo77:有問題再進行修正 09/11 03:32
: → logooo77:不然我覺得未來會讓別人覺得你很難搞或很難相處 09/11 03:32
: → logooo77:因為你沒有先跟團隊成員在同一個水平做事會 09/11 03:33
: → logooo77:很容易產生一些猜疑，或覺得對方能力很差怎麼樣的 09/11 03:34
: → logooo77:我覺得導入git跟導入任何新技術都差不多 09/11 03:35
: → logooo77:有心改變請先多瞭解 沒心請離開該公司 心力交瘁傷身ㄟ 09/11 03:35
我覺得你其他的論點我都還算同意，但不做版本控制系統，
只是把系統意外的機會賭在個人的資質與天份上。
要就來討論為什麼版本控制系統沒解決到問題，
只丟一句「不符合效益」我想這裡很多人都不會認同。
其實我是覺得現在都 2013 年了，
沒做版控這種等同於要程式員扛起更多責任壓力的作法，
跟慢性自殺沒甚麼兩樣啊。
不過有件事情倒是有道理的，沒有能力跟興趣採用更適當與安全的工具，
改善自己開發環境的 team & team member ，
早一點走一走也好，能逃多遠有多遠，真的。
說當事人要自己弄好自己的版控是一回事，
連版控的優點跟狀況都看不清楚是另一回事，覺得有必要正本清源一下。
說句難聽的，那些所謂的麻煩，不過就是食古不化跟不見棺材不掉淚，
看過好些人也是嘴硬，結果最後版本炸死了才在那邊哀。
這跟吵什麼 naming rule 那種純自爽的東西是完全的兩回事。
這是專案的核心，這是許多建置工具的基礎，也是團隊中協作的一個核心角色，
應該說任何專案你一定逃不了版本控制的影子，不管你用 zip 壓或是怎樣，
除非大家都一起上 production 改 code。
既然有方便的 tool ，不管是 svn 、 git 或是其他 VCS 或 DVCS 。
我是認為國內團隊早晚都會學著跟上的。
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.46.8
※ 編輯: TonyQ 來自: 61.230.46.8 (09/11 10:07)
※ 編輯: TonyQ 來自: 61.230.46.8 (09/11 10:08)
※ 編輯: TonyQ 來自: 61.230.46.8 (09/11 10:11)
→ realmeat:等到某功能那天要回復到之前一定時間點的版本 09/11 10:15
→ realmeat:就會知道有沒有版控差了到底有多少 09/11 10:15
※ 編輯: TonyQ 來自: 61.230.46.8 (09/11 10:17)
→ TonyQ:btw 我在沒版控的狀態下寫了兩年專案後才開使用版控的。 09/11 10:31
推 CRPKT:2013 年了也還是有人主張 disable javascript 啊 XD 09/11 10:39
推 ledia:同樣是買保險, 我論等等就有人開始吵 unit test 了 09/11 10:41
推 tom19830924:借標題請問 我公司是有用SVN 可是我嫌它有點過時 我想 09/11 10:43
→ tom19830924:自用git 可是git好像付費才能private 所以我還是得照 09/11 10:43
→ tom19830924:公司流程走比較好嗎？ 09/11 10:43
推 jlhc:我也想問git類似的有辦法自己搞private環境嗎？ 09/11 10:45
推 SansWord:付費才能 private 的是 git hub 不是 git 09/11 10:46
→ qrtt1:tom19830924 指的是 github 而不是 git 吧，你 typo !? 09/11 10:46
→ SansWord:git hub 只是一個公開的 git repository 09/11 10:47
→ SansWord:要自己建 git repository 當然是可行的。 09/11 10:47
→ qrtt1:bitbucket 可以放 private repo。 09/11 10:47
→ SansWord:另外我想問 tom 為什麼覺得 svn 過時。 09/11 10:48
→ SansWord:因為我們也是用 svn, 正在評估要不要換到 git 09/11 10:48
→ qrtt1:想自己架 server 或只用 local 也行，也有人丟 dropbox 09/11 10:48
→ qrtt1:但我覺得丟 dropbox 不是個好方案xd 09/11 10:48
→ qrtt1:SansWord 不覺得每回 merge 壓力都很大嗎xd 09/11 10:49
推 soniccol:我前公司的某個PM連教她用msn跟ftp都學不太會... 09/11 10:49
→ soniccol:別說svn，所以公司就賠錢了XD 09/11 10:49
→ askeing:付費的是github，可以自己建local repository 09/11 10:50
→ askeing:我覺得svn應該不算過時，只是方便性來說git有些特性很不錯 09/11 10:51
→ askeing:譬如沒網路的地方，git可以自己改自己commit，有網路才推 09/11 10:51
→ TonyQ: git 很不錯，但我不覺得 svn 過時，用途不一樣。 09/11 11:10
→ TonyQ:git 雖然功能強大，但缺點就是學習曲線過長。 09/11 11:10
→ TonyQ: 不過 git+ dropbox 會因為 dropbox 的衝突管理機制讓 .git 09/11 11:10
→ TonyQ:髒掉，長期來看不是好事，建議至少找個地方架個 remote repo 09/11 11:11
推 SansWord:那我了解了，我們很少用到 merge....這可能才是盲點。 09/11 11:49
→ SansWord:我是有考慮私底下使用 git 管自己的部份。 09/11 11:50
→ qrtt1:SansWord 所以連 branch 都沒開嗎xd? 09/11 11:52
→ realmeat:git 用不用是看需求, 當時我的評估是svn我的team就夠了 09/11 12:12
→ realmeat:git有他的好處但是我用不到 09/11 12:13
→ realmeat:conflict merge這件小事並不在我評估範圍內就是 09/11 12:13
→ realmeat:git抓下來就能玩了, 評估這件事不是看單看網友說 09/11 12:16
→ realmeat:起碼要抓下來玩弄一下 (大誤 09/11 12:17
推 RouterHsieh:如果要在公司內架private repo的話，gitlab是好選擇 09/11 15:34
推 SansWord:branch 用在產品 tag 後的管理，功能性的branch 有開過 09/12 00:17
→ SansWord:可是 merge 的時候實在太令人髮指，所以不敢開了。 09/12 00:18
→ SansWord:目前是由 pm 調和大家開發的部分，所以不會有同一個區塊 09/12 00:18
→ SansWord:多人編輯的情況。所以也就沒開 branch 了。 09/12 00:19
→ andymai:功能性的branch...光想到就覺得很難不留下技術債...Orz 09/12 00:58
→ andymai:而且是在自己沒意識的狀況留下的~事後要merge...真可怕... 09/12 00:59
→ logooo77:TonyQ 有些地方讓您看不懂，先說聲抱歉 我沒辦法寫清楚 09/12 05:35
→ logooo77:也另外感謝版主回應 -w- 09/12 05:36
→ TonyQ:「不覺得沒做管控不好」 << 09/12 10:43