搭檔程編

http://4rdp.blogspot.com/2008/11/blog-post_22.html

假設你是一位研發人員拆解一電子商品研究，通常外觀、結構、尺寸，最容易模仿。其次為電路設計，因為看得見的零件、電路，都可以一一抄襲模仿。唯獨程式這個區塊，除非你有其他辦法取得原始碼或是編譯後的機械碼(可以反組譯研究)，否則你只能觀察動作，猜測設計方法，功能越複雜的商品，就越難模仿設計。

同樣在電子產品開發過程中，工業設計(產品外觀)與機構設計是技術門檻較低的，設計到一半，有經驗的工程師大多數可以立即接手繼續設計。電路設計技術門檻更高一些，必須能看懂電路圖內隱含的設計概念，才能接續工作。軟韌體設計著重抽象思考能力，如果沒有說明文件或是相關概念，看別人的程式就像看天書，更別說接手別人的程式。

以往我所經歷的韌體專案，都是獨立設計，所有的程式以及整體系統概念很清楚，只要不是太複雜的問題，都可以很快解決。不過產品功能越來越複雜，就開始需要分工與他人同步設計，以縮短開發時程。但是分工合作之後，有時反而解決問題會拖更久時間。

複雜專案會由老鳥帶菜鳥，功能會一區一區寫，然後整合測試，發現奇怪情形就一起查問題。我要提醒的是，發生問題時，如果是菜鳥的程式問題，老鳥請花點時間幫幫菜鳥，如果問題拖了好幾天還沒解決，務必放下手邊的工作，幫菜鳥 Code Review，一定要看程式碼！不然瞎子摸象很難對症下藥，因為我曾經沒這麼做付出慘痛代價，信任菜鳥會依循標準設計、會找到方法解決，但是他始終找不到問題，因為忙手上的案子沒立即幫忙，拖很久還是沒解決，後來介入後發現整個程式架構不對，怎樣小修改都是無效的，必須重寫解決！

一般獨立性高的工作，單兵作戰即可，各自負責各自專案，但是需要他人協助時，別人如何介入呢？可採搭檔程編解決。假設有Ａ、Ｂ兩人平時各自負責自己的專案，每個禮拜抽幾小時時間，這禮拜Ａ幫Ｂ看程式，下星期Ｂ幫Ａ看看，這樣同事間有交誼往來，當某人有事請假，就可以臨時協助，不會不清楚別人在做什麼，而無法幫忙。並且互相檢查程式可以提升設計品質，以及設計功力。有些工作輪調安排不容易，但是這樣每週搭檔合作是簡易可行的。

當工作全丟給某人處理時風險極大，只要他出勤不正常或是要離職，都會對該專案產生極大衝擊，搭檔程編是處理這類問題的好方法。有些工程師比較內向不主動，這樣也可以讓他多跟別人互動。

搭檔程編，這個方法我是從 極致軟體製程 extreme Programming explained EMBRACE CHANGE 這本書學到的。培生教育出版集團 Kent Beck 著 李潛瑞譯