最近項目上在做銷售訂單、預付款申請、貿易合同傳輸OA審批等功能，也經曆到了自己遇到過的最糟糕的接口聯調。SAP與泛微OA之間的對接有比較成熟的方案，我們的工作過程不順利，終究是人的原因。我想把自己的一些看法記錄下來，留作教訓。
内部名還是外部名？
不同系統間的接口開發工作中的一個難點是接口提供者和被調用者對接口的不同了解。同樣的一個概念，在不同系統中可能有不同的名稱；同樣的一個名詞，在不同系統中又有可能有着不同的意義。在理想情況下，确定接口字段的定義和描述的人，應當對兩個系統的領域語言有所了解，有能力找到其中的相同與不同點，并且在相關的文檔中做出準确的表述，讓雙方的參與人員了解自己的意圖。
在現行的接口開發流程下，通常會由SAP業務顧問和對接系統的相關負責人來确定接口字段的名稱和意義，而SAP業務顧問在這當中又起着主導性的作用。實際上，SAP業務顧問有着豐富的業務和系統知識，理論上是有能力處理好相關工作的。但在實踐當中，不少業務顧問似乎對自己的工作還沒有足夠的認識，是以人們看到的文檔是類似這樣的：
假如讀者是熟悉SAP系統的人，可能會知道：SUPERFIELD是采購訂單相關事務螢幕中的一個擡頭字段，它時而對應供應商，時而對應工廠等内容；NAME2，NAME3來自于NAME1，它是SAP系統主資料表中的常見字段名，意為名稱；BUKRS大概來自于“公司代碼”的德文寫法，也是SAP系統中公司代碼的技術名稱。
這樣的文檔，即便目标人群是SAP系統的開發者，也不是完全合适。比如供應商在SAP中的技術名稱通常是LIFNR，所謂SUPERFIELD，是一個意義不明的通用名稱，容易給讀者帶來困惑。
而在SAP與非SAP接口的開發中，這樣的文檔是不太合格的。顯然一個非SAP系統的技術人員，沒有義務懂得SUPERFIELD和BUKRS的名字來源，是以在接口中應當使用字段的外部名，而非内部名。如果要傳遞正确的資訊給人們，盡量減少誤解，應該采用如下的比較合理的定義方式：
一個有經驗的SAP開發者十厘清楚VENDOR即SAP中的LFA1-LIFNR，COMPANY即T001-BUKRS。一個非SAP系統的開發者大概也能看懂這幾個詞的意思。這樣一來，産生誤會的可能性就降低了，思考的負擔也降低了。因為沒有人需要再死記硬背“NAME3”的含義。
名與實
“名不符實”是全社會共同面對着的難題，在開發工作中也不例外。我開發的某個接口中存在一個字段NETWR1，本來的意義是“淨值”（Net Value），在一次口頭需求變更後，它變成了“總值”（Gross Value），但接口文檔依然保持着如下模樣：
我很希望文檔的撰寫者可以對它的字段名、描述、長度做出合理的修改，也對她做出了建議。但是我的願望最終被忽視了，理由是工期緊，并且我“沒有準确了解需求”。
需求文檔是人們了解系統中自定義業務邏輯的重要依據，如果需求文檔中存在大量的名不符實的東西，那麼一段時間過去後人們隻能從代碼中考古，了解前人的工作了。
比較有趣的是，最不喜歡撰寫可靠文檔的人，同時也往往是最喜歡要求“來個開發，幫我debugger一段代碼，看看這些程式到底在做什麼”的人。從這個角度看，他們無愧是提高ABAP開發人員就業率的功臣...
聯調的前提
良好的工作流程和良好的的程式一樣，可以清晰的讓人明白一段行為何時開始、何時結束。
這裡的“時”指的應當是時機和非時間，即它不是一個單純的時間點，而是一個結合了條件的時間點...
對接口聯調的工作而言，我認為，存在一個基本的前提條件，那就是接口已經通過測試。
接口聯調的重要目的是發現問題、解決問題。解決問題的前提是定位問題，而定位問題的區域範圍越小，就越容易用較小的成本解決問題。
如果接口聯調時，雙方的程式都處于一種極為不确定的狀态，那麼聯調中一定會暴露大量問題，且需要密切和低效率的溝通來确定問題發生在哪一方。兩個不确定的程式交織在一起。而這兩份不确定，又給整個聯調帶來了更多額外的不确定..本來是用于調試接口本身的問題的時間，可能會被天馬行空找bug的過程占用。
在這個項目當中，有的接口開發人員甚至沒有使用Postman或者SoapUI之類的工具對自己的接口做最基本的測試，而調用接口的代碼，在聯調時居然常常沒有完成，需要現場編寫..編寫時又發現提供的接口與文檔不一緻等情況。令人無言已對。
明确角色
在接口相關項目中，可能涉及的角色包括業務分析人員、開發人員、測試人員、運維工程師、産品經理、架構師、項目經理等。盡管在實際工作當中，可能有一個人身兼數個角色的情況存在，我們依然有必要明确每個人的角色、每個角色的的工作内容和責任範圍。
如果僅僅以完成工作為目标，而忽視了參與人員的角色，容易造成資訊的錯誤傳達和項目混亂：一些處于“中間地帶”的工作配置設定會引起争議；項目有人員變動時，工作很難順利接續；工作内容可能會變得依賴于有權力的人的指令，大部分參與者難以發揮自己的主觀能動性；相關人員的觀點存在沖突、誤解而不能及時消除，使得工作産物中存在缺陷。最終，每個人都疲于奔命，卻難取得較好的工作成果。
坊間常常流傳一個佳話，故事中，某某員工能力很強，離職後，公司新招3個人來承接某某當初的工作，結果還不如某某做的好。這個故事可能存在另一種解釋：角色設定的混亂使得那位舊人承擔了太多，新人們在承接這些工作時，角色依然是不明确的，此時人數的增加反而起到了副作用，導緻他們無法産出與能力比對的工作成果。
此外，在跨系統的接口開發中，參與人員需要注意各方對角色的設定和認知可能有所不同，應該盡早明确這方面的差異，以免造成誤解。
等待時做什麼
聯調時會出現一種現象：一個人在改剛剛發現的問題，其它人則進入“事不關己”狀态，開始聊天玩手機或者做其它工作。我覺得這不是一個有益的現象。
在進入這樣的狀态之前，建議先按以下順序做檢查：
- 發現的問題是否和接口聯調有關，在不影響聯調的前提下，可不可以将它記錄到問題清單中，事後再改？
- 在其它人做修改的時候，自己和其它參與聯調但不需要改東西的人可不可以進行一些異步的工作，比如為聯調中的下一項小工作做準備？
- 能不能用電腦代替手機，來做自己想做的事情？
九個人等待一個人工作是一種低效的工作方式，而智能手機的出現甚至可能會降低那唯一一人的工作效率，讓大家等待更久的時間。（參考 智能手機如何綁架了我們的大腦，華爾街日報）。是以要盡量避免這種情況發生。