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

看板Soft_Job作者 (oomusou)時間12年前 (2011/11/10 21:48), 編輯推噓21(21推 0噓 63→)
留言84則, 25人參與, 最新討論串1/19 (看更多)
最近聽朋友說他們公司在台灣與美國都有研發單位 同一個project，台灣與美國的RD同時在做 同一份code台灣RD在上班時間寫，等到下班的時候 剛好是美國上班時間，美國的RD繼續寫 也就是同一份code有兩個人同時在寫，也就是24hr都有人在寫 台灣還有其他公司用這種方式研發嗎? 這種方式看起來理論上是一天當兩天用， 應該可以縮短一半的開發時間 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.250.68.242
推
11/10 21:50, , 1F
可以，但前提是兩個人都要很熟這部分的code，而且要有好的
11/10 21:50, 1F
→
11/10 21:51, , 2F
哇!!!好夢幻啊 夢幻到我都無法相信了一.一+
11/10 21:51, 2F
→
11/10 21:52, , 3F
版本控制，然後兩人實力都有一定水準以上
11/10 21:52, 3F
→
11/10 21:52, , 4F
分工要分好吧?如果真的是搞接力~那兩個人的coding style和
11/10 21:52, 4F
→
11/10 21:52, , 5F
而且這只能當緊急時應急用，實際效率還是會比兩個人分開差
11/10 21:52, 5F
→
11/10 21:53, , 6F
聽朋友說他們spec很清楚，coding style也被要求的全公司
11/10 21:53, 6F
→
11/10 21:53, , 7F
和觀念都要相近吧?不然光是trace前面的人寫的code就會花不
11/10 21:53, 7F
→
11/10 21:53, , 8F
少時間...
11/10 21:53, 8F
→
11/10 21:53, , 9F
都一樣
11/10 21:53, 9F
→
11/10 21:53, , 10F
所以才說兩個都要夠實力，不夠實力這樣玩會杯具
11/10 21:53, 10F
→
11/10 21:55, , 11F
聽朋友說他們並不是緊急才用，是每個project都這樣run
11/10 21:55, 11F
推
11/10 21:55, , 12F
這樣玩壓力很大，因為你隨時知道你現在寫的code過幾小時人
11/10 21:55, 12F
→
11/10 21:56, , 13F
家就會來看，寫得不夠漂亮人家搞不好就在背後罵了
11/10 21:56, 13F
→
11/10 21:58, , 14F
罵就算了~會不會忍不住想改?改了會不會因為意見相左而發生
11/10 21:58, 14F
→
11/10 21:58, , 15F
衝突?
11/10 21:58, 15F
推
11/10 21:59, , 16F
這有點像Agile裡面的pair programming，但是那應該是兩個
11/10 21:59, 16F
→
11/10 22:00, , 17F
人坐一起或是用視訊/電話遠端即時互相溝通
11/10 22:00, 17F
推
11/10 22:12, , 18F
pair programming 囉~~~~ 夢幻技能...XD
11/10 22:12, 18F
推
11/10 22:12, , 19F
這個作法很笨...我聽過的公司做法是二組人同時各自寫同
11/10 22:12, 19F
→
11/10 22:13, , 20F
一個程式,誰先完成就留下來,慢的就fire,效率最高
11/10 22:13, 20F
推
11/10 22:16, , 21F
這種方法實際效率當然還是比兩人獨立差，因為每個人接手時
11/10 22:16, 21F
→
11/10 22:17, , 22F
都還要花時間再去看人家之前做了什麼，不好用還要打掉重弄
11/10 22:17, 22F
→
11/10 22:17, , 23F
所以應該只能在快掛掉時拿來應急用
11/10 22:17, 23F
→
11/10 22:17, , 24F
這種玩法又缺乏溝通或有效的評鑑機制應該很容易四分五裂...
11/10 22:17, 24F
→
11/10 22:17, , 25F
pair 是同時一起處理，這種拆分時段的不叫pair吧...
11/10 22:17, 25F
→
11/10 22:18, , 26F
如果說白天寫晚上review 或反過來我就能理解
11/10 22:18, 26F
→
11/10 22:18, , 27F
接續開發...@_@ 又不是在玩生產線
11/10 22:18, 27F
補充一下，據朋友說，他們公司都是很有經驗的RD 基本上只要spec寫得很清楚，其實大家寫出來的東西都差不多 也就是無論給誰寫，大家想到implement的方式都不會差異太大 這算是『英雄所見略同嗎?』 ※ 編輯: oomusou 來自: 111.250.68.242 (11/10 22:54)
→
11/10 22:53, , 28F
這不是郭董用的方法嗎... 可是不是寫程式
11/10 22:53, 28F
→
11/10 22:54, , 29F
管理得當~應該相當不錯 不過現在不都會切部份一起且還好吧
11/10 22:54, 29F
推
11/10 23:01, , 30F
我比較想知道他們的專案成功率有多少...
11/10 23:01, 30F
→
11/10 23:09, , 31F
最近有種這個版越來越像傳產版的感覺了一.一
11/10 23:09, 31F
推
11/10 23:19, , 32F
如果先把架構和介面定義好，換手的時候就不用review了
11/10 23:19, 32F
→
11/10 23:23, , 33F
把架構和介面定義好就是"分工"了吧~這樣當然沒問題~有問題
11/10 23:23, 33F
→
11/10 23:23, , 34F
的是"接力"~接別人留下而未完成或有問題的東西...
11/10 23:23, 34F
推
11/10 23:32, , 35F
應該不只是spec要寫清楚, 每個人的程式習慣還要被規範到一致
11/10 23:32, 35F
推
11/10 23:37, , 36F
要這樣做得有前提 不然效能很差 品質也很差
11/10 23:37, 36F
推
11/10 23:47, , 37F
上手有bug要改的話, 改完再給上手時能不出問題嗎? :O
11/10 23:47, 37F
→
11/10 23:48, , 38F
還有手上的code在時間到的時候還沒寫到能跑unit test的
11/10 23:48, 38F
→
11/10 23:49, , 39F
程度的話, 下手該如何接手?
11/10 23:49, 39F
→
11/10 23:54, , 40F
我很懷疑真的是"同一份code"嗎? 還是同一個專案的不同
11/10 23:54, 40F
→
11/10 23:54, , 41F
module?
11/10 23:54, 41F
→
11/10 23:56, , 42F
我們家的每個人的同步率已經高到一個極致了，不過我們也做
11/10 23:56, 42F
→
11/10 23:56, , 43F
不到這種程度的 switch . 除非工作真的只是組裝零件程度
11/10 23:56, 43F
→
11/10 23:57, , 44F
確定是同一分module
11/10 23:57, 44F
→
11/10 23:57, , 45F
就是每個步驟都很小 沒有太大的步驟 不然應該很難吧
11/10 23:57, 45F
→
11/10 23:58, , 46F
我想不出這麼做有任何的好處欸...
11/10 23:58, 46F
推
11/11 00:06, , 47F
假如腦內想法不是分兩套的話,融在一起完成是可行的.
11/11 00:06, 47F
推
11/11 00:07, , 48F
好處是可以趕進度，就算效率只有1.5個人的水準，依然是有
11/11 00:07, 48F
→
11/11 00:07, , 49F
賺到時間，在deadline剩沒幾天時可以這樣拼拼看
11/11 00:07, 49F
→
11/11 00:09, , 50F
不過在這樣弄之前，就要同一個module兩個人都在開發跟解
11/11 00:09, 50F
→
11/11 00:10, , 51F
bug好一段時間，對這部分掌握度都很高才行，要到即使其中
11/11 00:10, 51F
→
11/11 00:11, , 52F
一人休假，另一人也能完全cover他的工作，完全不用去問
11/11 00:11, 52F
→
11/11 00:12, , 53F
我現在的project就有這樣搞過，我們每個人都是互相可以
11/11 00:12, 53F
→
11/11 00:13, , 54F
backup，大家對整體的code都熟，要這樣搞就可行，不過每個
11/11 00:13, 54F
→
11/11 00:14, , 55F
人交棒前還是得作到一個段落，至少compile要過，能有基本
11/11 00:14, 55F
→
11/11 00:14, , 56F
的function能動，就算還不能動也要交待清楚做到哪個地步了
11/11 00:14, 56F
→
11/11 00:15, , 57F
基本上一定要對code很熟，所以你的partner跟你一講他改了
11/11 00:15, 57F
→
11/11 00:16, , 58F
哪些，不用多解釋你馬上就知道大概了，再稍微看一下code就
11/11 00:16, 58F
→
11/11 00:18, , 59F
可以開始接了。還有雙方也要對design都很了解，怎麼實作也
11/11 00:18, 59F
→
11/11 00:18, , 60F
有共識，差不多就是那樣做大家都心理有數，只是差把code寫
11/11 00:18, 60F
→
11/11 00:18, , 61F
出來而已，那就不會出太大問題
11/11 00:18, 61F
→
11/11 00:23, , 62F
兩人平行完成各自的module不也是一樣的效率嗎 ~_~
11/11 00:23, 62F
→
11/11 00:23, , 63F
甚至還少了很多互相review的effort
11/11 00:23, 63F
推
11/11 00:24, , 64F
眼前只有一個module要完成的話呢?
11/11 00:24, 64F
→
11/11 00:28, , 65F
如果這個module大到或急到一個人搞不定的話~就考慮再切吧
11/11 00:28, 65F
看了大家的討論，我仔細想想，這種開發方式好像有以下這些好處 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)
推
11/11 00:34, , 66F
我覺得比較需要在意的是: 另一位做了哪些驗證?
11/11 00:34, 66F
→
11/11 00:35, , 67F
寫程式也像是在寫歷史紀錄, 你自己寫下的歷史, 別人不一
11/11 00:35, 67F
→
11/11 00:36, , 68F
定能夠親身經歷過, 所以才會需要切出function之類的, 並
11/11 00:36, 68F
→
11/11 00:36, , 69F
加上一些驗證說明.
11/11 00:36, 69F
→
11/11 00:37, , 70F
要用這樣的作法,就勢必不需要兩個人都體驗過全部的歷史.
11/11 00:37, 70F
推
11/11 00:49, , 71F
原PO還是問清楚 "一份code" 裡面是怎麼劃分的
11/11 00:49, 71F
→
11/11 10:19, , 72F
其實不用~SA有弄好，寫作規範有訂好，大家都可以
11/11 10:19, 72F
推
11/11 12:41, , 73F
抓BUG時,就掛點了!!
11/11 12:41, 73F
推
11/11 14:05, , 74F
找到的人夠好 又有管理 只是大部分公司很難做到
11/11 14:05, 74F
推
11/11 21:35, , 75F
怎麼不外包到印度等第三世界國家去?
11/11 21:35, 75F
→
11/11 21:36, , 76F
一定更便宜....既然功能可以切這麼清楚
11/11 21:36, 76F
推
11/12 02:05, , 77F
我想到的是兩個人意見不合的時間應該會不少 需要花很多時
11/12 02:05, 77F
→
11/12 02:06, , 78F
間溝通XDD 我相信code中不同function給不同人做可以這樣搞
11/12 02:06, 78F
→
11/12 02:06, , 79F
同辦公室兩個人做同一部分都可以吵翻天了~何況有時差的
11/12 02:06, 79F
→
11/12 15:39, , 80F
你在推文的回應，也有同樣的問題，假設人力成本無限。
11/12 15:39, 80F
→
11/12 15:39, , 81F
打錯了，假設人力沒有成本。這時當然有你說的好處。
11/12 15:39, 81F
推
11/14 02:40, , 82F
唯一的可能就是你朋友狀況外，不然就是你誤解了～
11/14 02:40, 82F
→
11/15 20:42, , 83F
這兩人是雙胞胎吧
11/15 20:42, 83F
→
11/21 02:17, , 84F
HP聽說全球三班制 每個team 8小時
11/21 02:17, 84F
‣ 更多 oomusou 的文章
文章代碼(AID): #1EkzOida (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 19 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 oomusou 的文章
文章代碼(AID): #1EkzOida (Soft_Job)