[請益] 有公司用這種開發方式嗎?

[oomusou (oomusou)]

最近聽朋友說他們公司在台灣與美國都有研發單位

同一個project，台灣與美國的RD同時在做

同一份code台灣RD在上班時間寫，等到下班的時候

剛好是美國上班時間，美國的RD繼續寫

也就是同一份code有兩個人同時在寫，也就是24hr都有人在寫

台灣還有其他公司用這種方式研發嗎?

這種方式看起來理論上是一天當兩天用，

應該可以縮短一半的開發時間

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.250.68.242
推 Wolfken:可以，但前提是兩個人都要很熟這部分的code，而且要有好的
→ thinkniht:哇!!!好夢幻啊 夢幻到我都無法相信了一.一+
→ Wolfken:版本控制，然後兩人實力都有一定水準以上
→ andymai:分工要分好吧?如果真的是搞接力~那兩個人的coding style和
→ Wolfken:而且這只能當緊急時應急用，實際效率還是會比兩個人分開差
→ oomusou:聽朋友說他們spec很清楚，coding style也被要求的全公司
→ andymai:和觀念都要相近吧?不然光是trace前面的人寫的code就會花不
→ andymai:少時間...
→ oomusou:都一樣
→ Wolfken:所以才說兩個都要夠實力，不夠實力這樣玩會杯具
→ oomusou:聽朋友說他們並不是緊急才用，是每個project都這樣run
推 Wolfken:這樣玩壓力很大，因為你隨時知道你現在寫的code過幾小時人
→ Wolfken:家就會來看，寫得不夠漂亮人家搞不好就在背後罵了
→ andymai:罵就算了~會不會忍不住想改?改了會不會因為意見相左而發生
→ andymai:衝突?
推 Wolfken:這有點像Agile裡面的pair programming，但是那應該是兩個
→ Wolfken:人坐一起或是用視訊/電話遠端即時互相溝通
推 alongalone:pair programming 囉~~~~ 夢幻技能...XD
推 purplebfly:這個作法很笨...我聽過的公司做法是二組人同時各自寫同
→ purplebfly:一個程式,誰先完成就留下來,慢的就fire,效率最高
推 Wolfken:這種方法實際效率當然還是比兩人獨立差，因為每個人接手時
→ Wolfken:都還要花時間再去看人家之前做了什麼，不好用還要打掉重弄
→ Wolfken:所以應該只能在快掛掉時拿來應急用
→ TonyQ:這種玩法又缺乏溝通或有效的評鑑機制應該很容易四分五裂...
→ TonyQ:pair 是同時一起處理，這種拆分時段的不叫pair吧...
→ TonyQ:如果說白天寫晚上review 或反過來我就能理解
→ TonyQ:接續開發...@_@ 又不是在玩生產線
補充一下，據朋友說，他們公司都是很有經驗的RD

基本上只要spec寫得很清楚，其實大家寫出來的東西都差不多

也就是無論給誰寫，大家想到implement的方式都不會差異太大

這算是『英雄所見略同嗎?』
※ 編輯: oomusou         來自: 111.250.68.242       (11/10 22:54)
→ yabe1225:這不是郭董用的方法嗎... 可是不是寫程式
→ final01:管理得當~應該相當不錯 不過現在不都會切部份一起且還好吧
推 yydon:我比較想知道他們的專案成功率有多少...
→ thinkniht:最近有種這個版越來越像傳產版的感覺了一.一
推 codemonkey:如果先把架構和介面定義好，換手的時候就不用review了
→ andymai:把架構和介面定義好就是"分工"了吧~這樣當然沒問題~有問題
→ andymai:的是"接力"~接別人留下而未完成或有問題的東西...
推 Elly:應該不只是spec要寫清楚, 每個人的程式習慣還要被規範到一致
推 followmeyo:要這樣做得有前提  不然效能很差 品質也很差
推 leicheong:上手有bug要改的話, 改完再給上手時能不出問題嗎? :O
→ leicheong:還有手上的code在時間到的時候還沒寫到能跑unit test的
→ leicheong:程度的話, 下手該如何接手?
→ shadow0326:我很懷疑真的是"同一份code"嗎? 還是同一個專案的不同
→ shadow0326:module?
→ TonyQ:我們家的每個人的同步率已經高到一個極致了，不過我們也做
→ TonyQ:不到這種程度的 switch . 除非工作真的只是組裝零件程度
→ oomusou:確定是同一分module
→ TonyQ:就是每個步驟都很小 沒有太大的步驟 不然應該很難吧
→ shadow0326:我想不出這麼做有任何的好處欸...
推 CJHhelper:假如腦內想法不是分兩套的話,融在一起完成是可行的.
推 Wolfken:好處是可以趕進度，就算效率只有1.5個人的水準，依然是有
→ Wolfken:賺到時間，在deadline剩沒幾天時可以這樣拼拼看
→ Wolfken:不過在這樣弄之前，就要同一個module兩個人都在開發跟解
→ Wolfken:bug好一段時間，對這部分掌握度都很高才行，要到即使其中
→ Wolfken:一人休假，另一人也能完全cover他的工作，完全不用去問
→ Wolfken:我現在的project就有這樣搞過，我們每個人都是互相可以
→ Wolfken:backup，大家對整體的code都熟，要這樣搞就可行，不過每個
→ Wolfken:人交棒前還是得作到一個段落，至少compile要過，能有基本
→ Wolfken:的function能動，就算還不能動也要交待清楚做到哪個地步了
→ Wolfken:基本上一定要對code很熟，所以你的partner跟你一講他改了
→ Wolfken:哪些，不用多解釋你馬上就知道大概了，再稍微看一下code就
→ Wolfken:可以開始接了。還有雙方也要對design都很了解，怎麼實作也
→ Wolfken:有共識，差不多就是那樣做大家都心理有數，只是差把code寫
→ Wolfken:出來而已，那就不會出太大問題
→ shadow0326:兩人平行完成各自的module不也是一樣的效率嗎 ~_~
→ shadow0326:甚至還少了很多互相review的effort
推 CJHhelper:       眼前只有一個module要完成的話呢?
→ andymai:如果這個module大到或急到一個人搞不定的話~就考慮再切吧
看了大家的討論，我仔細想想，這種開發方式好像有以下這些好處

1.由於當天在接別人code時，一定要review一下別人寫的code，所以趁機可以

  做一次code review，也可以順便看看兩人對spec的認知與邏輯是否有差異，

  可以提早發現一些bug

2.由於是兩個人同時寫一份code，也就是兩個人都對這份code與架構都有一定的了解

  若一人突然離職或者請假，另外一個人還是可以馬上接手，對project的傷害會最小

3.公司透過這種方式讓member交互的開發同一份code，可以有效的讓整個公司的

  coding style趨於統一，而不是只是嘴巴喊喊而已

這種方式雖然不是很正統的Agile pair programming，不過好像又有點那種味道...
※ 編輯: oomusou         來自: 111.250.68.242       (11/11 00:39)
推 CJHhelper:我覺得比較需要在意的是: 另一位做了哪些驗證?
→ CJHhelper:寫程式也像是在寫歷史紀錄, 你自己寫下的歷史, 別人不一
→ CJHhelper:定能夠親身經歷過, 所以才會需要切出function之類的, 並
→ CJHhelper:加上一些驗證說明.
→ CJHhelper:要用這樣的作法,就勢必不需要兩個人都體驗過全部的歷史.
推 CJHhelper:原PO還是問清楚 "一份code" 裡面是怎麼劃分的
→ alexlucifer:其實不用~SA有弄好，寫作規範有訂好，大家都可以
推 ppHomer:抓BUG時,就掛點了!!
推 popoblue:找到的人夠好 又有管理 只是大部分公司很難做到
推 atpx:怎麼不外包到印度等第三世界國家去?
→ atpx:一定更便宜....既然功能可以切這麼清楚
推 SHOOTA:我想到的是兩個人意見不合的時間應該會不少 需要花很多時
→ SHOOTA:間溝通XDD 我相信code中不同function給不同人做可以這樣搞
→ SHOOTA:同辦公室兩個人做同一部分都可以吵翻天了~何況有時差的
→ howshou:你在推文的回應，也有同樣的問題，假設人力成本無限。
→ howshou:打錯了，假設人力沒有成本。這時當然有你說的好處。
推 ykjiang:唯一的可能就是你朋友狀況外，不然就是你誤解了～
→ rofellosx:這兩人是雙胞胎吧
→ dumpweed:HP聽說全球三班制 每個team 8小時