關於接口開發和聯調的一些感想

最近項目上在作銷售訂單、預付款申請、貿易合同傳輸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我的來承接某某當初的工做，結果還不如某某作的好。這個故事可能存在另外一種解釋：角色設置的混亂使得那位舊人承擔了太多，新人們在承接這些工做時，角色依然是不明確的，此時人數的增長反而起到了反作用，致使他們沒法產出與能力匹配的工做成果。

此外，在跨系統的接口開發中，參與人員須要注意各方對角色的設置和認知可能有所不一樣，應該儘早明確這方面的差別，以避免形成誤解。

等待時作什麼

聯調時會出現一種現象：一我的在改剛剛發現的問題，其它人則進入「事不關己」狀態，開始聊天玩手機或者作其它工做。我以爲這不是一個有益的現象。

在進入這樣的狀態以前，建議先按如下順序作檢查：

1. 發現的問題是否和接口聯調有關，在不影響聯調的前提下，可不能夠將它記錄到問題清單中，過後再改？
2. 在其它人作修改的時候，本身和其它參與聯調但不須要改東西的人可不能夠進行一些異步的工做，好比爲聯調中的下一項小工做作準備？
3. 能不能用電腦代替手機，來作本身想作的事情？

九我的等待一我的工做是一種低效的工做方式，而智能手機的出現甚至可能會下降那惟一一人的工做效率，讓你們等待更久的時間。（參考 智能手機如何綁架了咱們的大腦，華爾街日報）。所以要儘可能避免這種狀況發生。