張偉把第7層結丹，結成後！
閉著眼睛，看著剛結出的第7層，感慨萬千啊，既是驚歎，又是敬佩，更是震撼！
驚歎於，如此巧奪天工的設計！
我們可以推演下，這種嵌套的網體結構，有多麼的巧妙和適用！
就剛的例子，一個函數從他的角度隻被調用了一次，他確實隻被一個函數調用了，可是這個調用他的那個函數，被彆人調用了50次，而這50次，又有一個函數又被彆的函數、或彆的程序調用了200次，那麼一開始那個函數加起來就被調用了250次！
現在的情況，如果不是這種調用邏輯的設計，那麼第一次的那個函數，就會像《詩雲》自然語言的邏輯，這個函數，或者這個函數對應的處理邏輯，就要在250個地方，編寫250次！
如果這個處理的代碼量是1000行的話，就代表，就這一個處理邏輯，就占據了，25萬行的代碼量！如果用這種嵌套的代碼設計，有且僅有1000行代碼！
這有什麼好處呢？那好處可太大了啊！
比如這1000行的處理代碼有一個bug，如果是這種嵌套設計，你隻需要對這1000行的處理函數進行修改，就等於修改了250處了！
而如果用傳統的編程方式，就是張偉一直引以為傲的10萬行的，編碼邏輯！那麼就得修改250次！隻要任何一個地方忘記修改，那麼就是一個真實的錯誤！
而為什麼有些it非常忙，就是這個原因，你會發現同一個問題，在不同的地方重複出現！就是因為他們采用了傳統的編碼結構，同一個處理邏輯，不是用這種嵌套的函數結構，而是在每個地方都寫一遍，雖然每次都修改了，但是架不住有250處地方要修改啊！這就是為什麼說靠譜的it很閒，不靠譜的it很忙的原因！
一個問題，實際你隻改了一次，卻達成了250個地方都改了的效果，所以你不忙啊！因改一個地方，隻需要2分鐘啊！
而改250個地方，就是專門改，都需要500分鐘，8個多小時，而真實情況是發現一個地方，就改一個地方，沒發現，就不改，就成了一個一個的地雷了，等著被踩到，爆炸！
所以你會發現他天天很忙，在改各種問題！
當然這個設計也有一些問題，比如首先就是如果不熟悉，就會像張偉這種，迷失在程序運行的各種嵌套中，這就真的形成了一個巨大的迷宮！傳統模式寫的代碼，debug起來就很簡單了，一杆子捅到底，沒有那麼多彎彎繞，岔路口，就是一條純粹的代碼運行直線，就像張偉寫的那些報表，就是純粹的從上往下直線運行！
其次如果需要修改，要是考慮的不夠周全，就會非常的麻煩，那就是牽一發動全身！萬一改錯了，就會影響到250處地方！當然如果修改好了，也等於同時修改好了250處地方！
相對來，這種架構，肯定是優勢遠遠大於劣勢！
還有就是敬佩！為什麼會敬佩呢？
上麵說的那個改250次的例子！如果作為一個程序員，其實是無法改變的現實！
如果要實現，首先需要架構就采用這種模式進行設計的！隻有在這套架構下，才能達到，改一次實現等於修改了250次的效果！否則就是故意為難程序員，這種為難等於“巧婦難為無米之炊”！
就好比，你是一個nb到爆炸的泥瓦匠！給你的建築圖紙，是三層小樓！你無論如何也蓋不出迪拜大廈啊！
你說當時設計sap這套架構的那幫人，是不是神人！在帶入下時間，80年代！就設計好了！
此刻的張偉，對那幫sap架構設計者，簡直是驚為天人啊！
張偉甚至覺得那幫人是穿越者！就像網絡小說裡帶著金手指的穿越者！
還有就是管理上，sap首先是由德國工程師開發，然後是全球的工程師開發，在時間上，跨越了周期，在地域上跨越了國家，可是這套機製下的架構，所有為sap貢獻的工程師，都遵循這樣的規則，大家都是活生生的人啊！能在跨越時間，跨越空間的大尺度上，來做到步調統一，這是多麼難能可貴的管理啊！
張偉清晰的記得，當年大學的軍訓，就走幾步路，要走整齊，整整訓練了2周！
這種全球協同，而且是40年時間的全球協調，保持步調一致，這是多麼強悍的管理能力啊！
你說值不值得敬佩！
還有就是震撼！為什麼又是震撼！