【整理】KISS原則介紹

KISS原則介紹

 

KISS 原則是用戶體驗的高層境界,簡單地理解這句話,就是要把一個產品做得連白癡都會用,因而也被稱爲“懶人原則”。換句話說來,“簡單就是美”。同樣在SAP系統的二次開發中適用,其核心思想就是“解耦,解耦,再解耦”,職責單一化,功能單一化爲以後的維護和重構都會帶來極大的便利。

Background

The KISS principle says that you should always choose the simplest solution for a problem. KISS is an acronym and can have any of the following meanings (the list is not exhaustive):

KISS 原則是說你應該總該爲一個問題選擇最簡單的解決方案。KISS其實是一個縮略詞,可以有以下任何含義(列表並不詳盡):

  1. Keep it simple, stupid.
  2. Keep it small and simple.
  3. Keep it sweet and simple.
  4. Keep it simple and straightforward.
  5. Keep it short and simple.
  6. Keep it simple and smart.
  7. Keep it strictly simple.

The basic statement of the KISS principle is similar to Occam’s razor, which says that in science the preferred theory is the one that makes fewest assumptions to explain observations (see Wikipedia entry on the KISS principle).

關於KISS 原理的基本陳述類似於奧卡姆剃刀定律,它是說在科學中,首選的理論是用最少的假設來解釋觀察結果的理論(參見維基百科關於KISS原理的條目)。

Tip:奧卡姆剃刀定律(Occam's Razor, Ockham's Razor)又稱“奧康的剃刀”,它是由14世紀英格蘭的邏輯學家、聖方濟各會修士奧卡姆的威廉(William of Occam,約1285年至1349年)提出。這個原理稱爲“如無必要,勿增實體”,即“簡單有效原理”。正如他在《箴言書注》2卷15題說“切勿浪費較多東西去做,用較少的東西,同樣可以做好的事情。”

舉個例子,日本最大的化妝品公司收到客戶抱怨,買來的肥皂盒裏面是空的。於是他們爲了預防生產線再次發生這樣的事情,工程師想盡辦法發明了一臺X光監視器去透視每一臺出貨的肥皂盒。同樣的問題也發生在另一家小公司,他們的解決方法是買一臺強力工業用電扇去吹每個肥皂盒,被吹走的便是沒放肥皂的空盒。同樣的事情,採用的是兩種截然不同的辦法,你認爲哪個更好呢?

 

Rule

Follow the KISS principle

Follow the KISS principle, and limit the complexity of your programs as far as possible.

遵循KISS原則

遵循KISS原則,並儘可能地限制程序的複雜性。

 

Details

The best solution to a problem is usually the one that is as simple, minimalist, and easy to understand as possible, while ensuring stability, understandability, and maintainability in addition to functional correctness.

There are plenty of bad examples of the KISS principle. Why is this?

1、Programs are too complex right from the start. This can be due to poor design or simply a rash, undisciplined programming style.

2、Programs are maintained for lengthy periods. Instead of creating new implementations for old and new functions together, new functions are simply added (usually using IF control structures) to old functions. Programs that were initially simple thus become ever more complex, although this is not justified by the complexity of the task at hand.

To develop according to the KISS principle, you should ensure right from the start that the complexity of the program remains manageable. Rules that support this approach relate to the structure and style of programs, in particular comments and complexity.

一個問題的最佳解決方案通常是儘可能簡單、極簡和易於理解的,同時除了功能正確性之外,還要確保穩定性、可理解性和可維護性。

KISS原則有很多不好的例子。這是爲什麼?

1、程序從一開始就太複雜了。這可能是由於糟糕的設計,或者僅僅是草率的、無紀律的編程風格。

2、程序要長期維護。新函數不是同時爲舊函數和新函數創建新實現,而是簡單地添加到舊函數(通常使用IF控制結構)。最初簡單的程序因此變得越來越複雜,儘管這並不是由手頭任務的複雜性所證明的。

要根據KISS原則進行開發,您應該從一開始就確保程序的複雜性和可控性。支持這種方法的規則要與程序的結構和樣式相關,特別是註釋和複雜性。

 

Note

If existing programs do not follow the KISS principle, and these programs need to be further developed, we recommend refactoring as appropriate. Refactoring refers to the process of manually or automatically improving the structure of programs while retaining the observable program behavior. It improves legibility, understandability, maintainability, and extensibility, as well as considerably reducing the related effort for troubleshooting and functional enhancements (see Wikipedia entry on refactoring). The (incremental) refactoring of an existing program is not only useful for following the above rule, but also for all following rules.

The refactoring of existing code is supported by the required coverage by unit tests. Comprehensive unit tests can ensure that a program behaves in the same way after the refactoring process.

如果現有的程序不遵循KISS原則,並且這些程序需要進一步開發,我們建議根據需要進行重構。重構是指在保留可觀察到的程序行爲的同時,手動或自動地改進程序結構的過程。它提高了易讀性、可理解性、可維護性和可擴展性,並大大減少了故障排除和功能增強方面的相關工作(請參閱關於重構的維基百科條目)。現有程序的(增量)重構不僅適用於遵循上述規則,而且適用於所有遵循的規則。

單元測試所需的覆蓋範圍支持對現有代碼的重構。全面的單元測試可以確保程序在重構過程之後以相同的方式運行。

 

Example

The figure below shows the structure of a method that does not follow the KISS principle. The method consists of approximately 160 statements and reaches a nesting depth of 12 levels. The method, which is only illustrated schematically, is a real example from a live ABAP program, which reached the state shown on the left after continuous additional developments. The method had become so complex that it was practically impossible to make another necessary change, and the developer was forced to refactor in line with the KISS principle.

下圖顯示的結構就是一個不遵循KISS原則的方法,該方法由大約160條語句組成,嵌套深度達到12層。該方法只是象徵性地說明了一個來自實時ABAP程序的例子,經過不斷的額外開發,該程序達到了如左側所示的狀態。這個方法變得如此複雜,以至於幾乎不可能再做一次必要的修改,開發人員被迫只能按照KISS原則進行重構。

The result is illustrated on the right of the figure. By splitting the method M into three methods, each with less than 100 statements and a maximum nesting depth of 5 levels, manageable modularization units were generated, which follow the rules for complexity, and allow the required modification to be made. Ideally, however, the state shown on the left side of the figure should never occur.

結果顯示在圖片的右邊,通過將方法M分解爲三個方法,每個方法的語句少於100條,最大嵌套深度爲5層,生成了可管理的模塊化單元,這些單元遵循複雜性規則,並允許進行所需的修改。然而,理想情況下,圖片左側顯示的狀態不應該出現。

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章