分工與合做

前兩天項目組出的一個問題，問題不大，可是有點上火。 新需求到來的時候，項目組通過分析和討論，對需求作好了開發計劃，並明確了分工。分工是以需求內部的功能流程為基準，以流程各步驟的接口為界，將各個接口的內部實現分給不一樣的開發人員；接口邊界上的交互由接口兩邊的開發人員自行商定。 問題就出在這個分工上。當我負責的部份須要調用其餘人提供的接口時，我發現我獲得的服務要麼根本無法運行，要麼運行後獲得的不是我須要的結果。 無法運行的那些服務，最離譜的一個是有一位同事修改了某個實現類的接口，可是卻沒有通知其餘人。直接導致了我這裡通過原接口去調用服務實現時報錯。還有一些是配置上的錯誤，大小寫的疏忽等。 運行後得不到我要的結果的那些服務，基本都是對接口作了過度實現，把一些應該在接口以外完成的操做放到了接口內。但是接口內的操做並不符合接口外上下文的需求。還有少數情況是提供的接口只有光溜溜的一個方法，沒有任何的說明、註釋，使我調用起來徹底不知道該傳什麼參數、會獲得什麼結果。尤爲是遇到幾個簽名很類似的接口方法時，實在是一頭霧水。 問題暴露出來的時候，有點無奈。因為急著調試完整流程，我越俎代庖把出問題的地方都改正了。可是窩了一肚子氣，次日站會上把幾個同事說了一通。情緒上發洩完了，理智的來總結總結。 分工分的是什麼？應該是結果。需求的分析、計劃都是針對結果來作的。把一個計劃後的任務分給我，意味著我交付的結果應該是完畢的。交付的結果不能使用、不能滿足需求，都是個人問題。 可是分工不表示不合做。分工只是針對結果，但實施過程必須要合做。每一個分開的任務都不是孤立的，寫出來的接口和服務是給人調用的，那麼接口的定義就要和調用者討論；多人為同一個接口開發不一樣實現時，也應該互通有無，以避免有人須要對接口作出調整時別人不知道。 其實想到的就這麼多。這次吃了一塹，不知道同事們肯不願長一智。但無論怎麼說，下次要是出問題，我可再也不越俎代庖了。