SAP系統作為企業的信息系統，其生命周期通常是漫長的，比單個程序員的在職時間要長得多。早期實施階段花大力氣開發的自定義程序，通常會托付給企業內部或外部的運維團隊來維護——不管怎麽樣，一般不是最初的開發者了。即便是在運維階段，程序的創建者與修改者也常常不是一個人。不同的開發者，其知識基礎、技術水平、編碼風格難免有所不同，最早創建的程序，經過若幹個獨一無二的開發者的修改，可能會變得面目全非，失去可維護性。這時的程序可以說已經接近於死亡...因此，作為程序的開發者，我們需要讓自己的程序對修改有抵抗力，從而能在後人的維護下活的更久一些。

當然，抵抗修改的意思，並不是指妨礙後人修改程序。企業的業務是多變的、人們對需求的理解是不斷加深的，因而程序的修改也是必要

我認為問題的關鍵在於減少耦合度、理清程序職責的分配，清晰的程序描述也很重要：

耦合度即模塊之間的關聯強度。高耦合度的程序牽一發而動全身，只適合於需求十分穩定的程序。對於多變的ABAP程序來說，降低耦合度可以減少程序修改對其它部分的影響，是比較重要的。

單純的解耦工作有可能讓我們陷入為解耦而解耦的陷阱。了解程序的職責分配可以讓我們更加理性地運用技術，並且使程序對修改有更好的適應性。

程序的描述包含命名、程序結構這種“自我描述”，也包括程序註釋、技術文檔，以及需求文檔。這可能是最容易改善的一個方面。

下面結合具體的ABAP開發技術來談談我對它們的想法，因為只是根據自己的一些經驗的來寫，可能不是系統全面的介紹。

本文鏈接：http://www.cnblogs.com/hhelibeb/p/7891401.html

原創內容，轉載請註明出處

CDS視圖

SQL是讓很多程序員的頭痛的東西。過去，由於內表的存在，大家會用簡單的SQL取出較多的數據，然後在內表中處理它們。但在S4之後，SAP鼓勵將更多的工作交給數據庫服務器來做。可見日後的SQL將變得日益復雜，在復雜的SQL上進行修改可能會耗時較多、測試困難、不小心造成性能問題。ABAP CDS視圖的引入可以較好的應對這一問題。如果早期的開發者能夠利用CDS抽象出穩定的

（想一想我們是不是經常說這種冗長的話：XX屬性是通過關聯A表和B表，使它們的公司、業務編號和移動序號相等，在取消標識不等於‘X‘等情況下，獲取它的某一屬性，再到屬性對應到的分配表C，獲取有效期內的記錄。看完並理解這麽長一段話之後，也許交流的雙方已經忘記了自己在思考的其它東西。如果這種關聯邏輯在公司的需求中是穩定的甚至常常出現的，我們完全可以為它造一個“新詞”，即CDS視圖。基於CDS視圖，之後的溝通方式可以變為：到視圖ZCDSXX中，根據取消標識不等於‘X‘，獲取我們需要的XX屬性）

硬編碼與配置表

這二者的原理在於將對程序的修改變為“擴展”，在不幹涉或較少幹涉程序代碼的情況，完成功能的變更。

動態技術

動態技術是雙刃劍，Field Symbol和RTTS的使用可以使我們的程序變得十分靈活，但這樣的程序的可讀性通常不太好，而且對新手來說也絕對是很難修改的。因此，我建議盡量把它作為基礎功能的實現，和配置表結合、或者是通過新建子類的方式來實現功能的擴展。盡可能避免讓後人直接維護大量使用動態技術的程序。

中間層

在制作與其它系統對接的接口時，由於各方面的原因，會不時遇到對方希望變更接口的輸入輸出方式或者格式的情況。這時候，不是直接提供給對方包含業務處理邏輯的接口，而是建立一個外層接口，把原有的接口包裝起來，專門用來應對對方的修改，是一個好辦法。

寫有意義的註釋

據說寫程序不寫註釋是一種很糟糕的習慣，也有開發規範約束人們：必須要寫註釋。註釋當然是必要的，但是在實踐中，大部分人的註釋水平是不太好的，往往對閱讀起不到什麽正面作用，於是甚至催生了一種反叛的、矯枉過正的觀點：好的程序從來不需要註釋。

最近見到的一個典型的不好的註釋：

*處理數據
PERFORM frm_process_data.

這段代碼至少犯了3個錯誤。

1. 以文章來對比，FROM的名字即文章的標題，我們不應該在標題中寫明標題是標題。顯然，FRM的前綴是無用的，它給不了我們什麽信息。
2. “處理數據”似乎是對FORM功能的描述，這部分內容應該放在FORM的定義處，而不是調用位置。在調用位置的註釋，需要寫的是：為什麽這個FORM需要在這裏被調用？為什麽不是調用其它一個看起來相似的FROM？
3. 在註釋中寫“處理數據”這種泛泛之辭通常產生不了什麽意義，更不用說FORM名已經是process date（處理數據)了。這種重復有害無益。

這樣的註釋過多，大概就是很多人反感註釋的原因吧。好的註釋需要出現在合理的位置，需要寫“為什麽”而不是“做了什麽”。這還是挺考驗寫作者對程序的理解的，需要有“同理心”，預見讀者的需求才可以。

善用編輯器為自動生成的註釋模板，比如：

如果是函數、或者類的話，還可以寫專門的文檔：

善用異常

異常是個很有用的東西，但是我很少看到有ABAP開發者用它。我見到的程序大部分是用錯誤碼或者錯誤標識的方式來處理錯誤。以我的經驗來看，錯誤碼在單層的調用關系中是比較好用的，但是在多層的、復雜的情況下，異常比錯誤代碼要更容易處理和維護。而且異常有著較好的自我描述能力，這在程序的維護中是很有意義的。而很多錯誤碼，只有開發者本人知道是什麽意思，後續維護的人，只能認識到這是個錯誤...並不理解每個錯誤代碼的涵義。

避免全局變量

全局變量不好，這是所有開發者的共識。之所以專門還要拿出它來作為一個小節，是因為我覺得這個問題實在普遍且嚴重。可能因為大部分ABAP二次開發程序都是內容較少的報表，最常用的ALV報表類（函數）則要求其輸入的數據內表必須是全局變量，初入行的開發者通常是從全局變量寫起的，而較簡單的程序邏輯也讓開發者沒有承受全局變量帶來的麻煩....這種慣性使得不少開發者在日後開發相對大型的程序時也會大量使用全局變量。而程序的維護者通常沒有精力或能力來識別全局變量對程序的影響，從而在修改程序時造成了意料之外的結果。此外，不加釋放的全局變量也會帶來性能上的負擔。所以我認為開發者應該經常思考是否可以用局部變量代替全局變量、用值傳遞代替引用傳遞，時時註意避免全局變量帶來的麻煩。

歡迎大家發表自己對可維護性的看法，或者對本文的內容進行指點。

關於程序可維護性的一些想法