注：本人身為SAP諮詢顧問，故以下以SAP開發語言ABAP作為例子，其他語言雷同。
在SAP領域，做開發的人很多，會ABAP的也不少，但真心懂ABAP，懂開發的人卻不多。很多人從事開發行業，只是單純為了開發而開發，為了寫程式碼而寫程式碼。只要能夠實現功能，哪怕裡面埋了很多雷挖了很多坑也無關緊要，甚至BUG百出。SAP系統最注重的是程式碼的質量以及執行高效率和簡潔，否則一旦程式有問題，影響的並不是程式本身，而會影響到實際企業生產，甚至一定程度上影響到決策層的判斷。跟SAP其他模組一樣，ABAP沒個大幾年的累積經驗是無法成為大神級別的，除非是天生天賦異稟。因此會點ABAP語法和開發並沒有什麼了不起，跟其他諸如.net、Java和PHP等語言一樣，培訓一段時間就能夠上手了，但真的要做到把控需求，功能可擴充套件延展性就難了。也印證了一句話：會ABAP的不稀奇，懂ABAP才難求；會業務模組的不稀奇，即會業務又懂開發才萬金難求！
以下列舉幾項，簡要說說會開發和懂開發的區別：
一、更新錯誤問題
會開發的人：迴圈一百次，每次暫停一秒後再Insert表，直到成功為止，如果100次了還失敗，那就忽略！所以一旦出現這樣的情況，程式就會卡死；
懂開發的人：Try一下，捕獲訊息號和文字丟擲，然後RollBack。但如果是無關緊要的表（如日誌表），直接就忽略掉；
如下圖神奇的程式碼：
二、多重邏輯判斷問題
會開發的人：IF能寫多少就寫多少，哪怕功能裡面都是重複的邏輯；
懂開發的人：採用ABAP的動態語法，將重複的功能整合在一起，區別就在動態語法判斷上；
如下圖程式碼：
三、SAP增強的寫法
需要說明的是SAP增強是對系統標準功能和邏輯的一種延伸和更改，需要非常的慎重，同時最好有參數列來做開關控制，輸出的訊息也得有長文字做描述；
會開發的人：找到一個增強就興奮不已，然後直接寫程式碼，不考慮任何擴充套件和開關控制，也是直接Message出來訊息，很難追蹤；
懂開發的人：不僅做了引數控制，同時還會做事務程式碼或程式名的判斷，至於Message則在SE91裡面做訊息號新建引用，方便維護和追蹤！
如下圖神奇的程式碼：（程式碼裡還有很明顯的錯誤，如果是修改採購訂單，則會一直報錯誤，提示費用申請單已經存在）
四、前後邏輯不一致的問題
會開發的人：想到哪裡就寫到哪裡，不用判斷上下文的邏輯銜接；
懂開發的人：邏輯嚴謹性很強，做到前後資料和邏輯一致；
如下圖神奇的程式碼：
以上程式執行的結果就變成了（金額和單價擴大一萬倍）：
五、SAP介面模式之爭
會開發的人：認為Webservice是萬能統一的，所以不管第三方系統是什麼平臺和語言，一律用Webservice來做介面，更要命的是所有介面都共用一個出口地址。並且認為RFC不安全不穩定；
針對介面的開發，不管是輸入還是輸出，一律用行型別來做多筆記錄的傳輸。無視SAP系統警告說會降低介面的效能；
懂開發的人：除非第三方平臺是上古時代開發的或者語言非常老舊，否則儘量能用RFC就用RFC，並且善用Table頁籤和“例外”的功能；
如下圖神奇的程式碼：
又比如輸出結構：
針對這種處理方式，SAP系統會毫不留情得給出這樣的警告：
六、統一資料來源問題
會開發的人：針對使用者的需求，來一個寫一個功能，哪怕報表邏輯都是類似的，於是寫得多了難免會發現同樣的數值往往在不同的地方不一致；
懂開發的人：針對使用者的需求，凡是功能類似的都做成一個可重複使用的介面或函式，所有需要用到的地方都呼叫它取值，統一資料來源；
這裡沒圖！
七、註釋問題
相信每個開發人員都會遇到看前人的程式碼，然後又沒有任何註釋的那種絕望感！
會開發的人：根本不知道啥叫註釋，也重來不會註釋；
懂開發的人：在非常重要的地方會加入業務需求的說明，以及每一行重要程式碼的設定說明；
如下圖神奇的程式碼（誰能知道這個是什麼鬼？）
八、匯入模板是啥樣的？
這個或許可以說是使用者體驗問題，但在IT眼裡看來，這分明就是懂不懂開發的問題！
會開發的人：做好批導程式，就扔在那愛誰誰，一段時間之後連自己都不知道匯入模板應該是啥樣的，是TXT文字匯入還是Excel匯入，只能繼續看程式；
懂開發的人：在批導的畫面做一個按鈕可以下載模板；
如下圖（相信所有人看到下圖都會一臉懵逼）：
以上大概列舉了我在做專案過程中所遇到的主要的問題，還有很多很多開發相關的事故，都是那些只會寫程式碼而不懂系統邏輯的新手寫的。比如基本的資料存在性校驗、比如資料讀取錯誤、基本的除數不能為0的判斷、針對 FOR ALL ENTRIES IN 不做存在性檢查、使用 BINARY SEARCH不做排序等，從來不懂什麼叫測試。遇到這樣的事故，有時候會哭笑不得，要給IT增加不少的負擔。也只能感嘆一句，會開發簡單，懂開發難，懂業務又懂開發，簡直萬金難求！