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