先放結果，圖面大約就是如此，原圖太長了，超難放，當個示意圖就好，且似乎是因內含程式碼，整篇字體七零八落，花了一小時寫內容，卻花了三小時調字體或改貼圖。
組織圖當然也可以在點入時再加上一些Detail或頁面的變化，過程比想像中還更容易些，步驟說明如下。
要在網頁呈現樹狀圖，第一個聯想到的一定就是ul、li的tag，網頁呈現組織圖的第一個步驟也是如此。
以上基本的概念應該不難理解，網頁開啟時算出程式碼後的工作，
１．將以上的HTML Code塞入HtmlData的RTF欄位中，因一般欄位有長度限制，建議使用RTF
２．將第一個ul隱藏，因為原始碼只是提供了來源，還是透過CSS在上圖的chart division中呈現。
基本上只要再加上以下的CSS和jQuery toolkit就大功告成了。這是實際測試，去蕪存菁後的最精簡版本，這些全是open source，可以自行Google取得原始碼。如果要修改顏色大小字體方框粗細等屬性，就在jquery.jOrgChart.css中自行設定即可。
有些資源甚至不用下載，來源直接連至google，安全又方便，如
以上很快速地分享完了，但其實今天的主題是遞迴，也就是在網頁開啟時該如何計算組織的HTML Code。
在公司架構的上下層關係連結中，部門文件中大都會有一個”上層單位”的欄位，也就是記錄著此部門的上層單位。
基本邏輯是，先取得一個最高組織Ａ後，畫出第一個框框，再去比對有沒有以此部門為上層單位的部門集合（也就是此部門Ａ的下層單位），有的話就找第一個部門Ｂ１畫框框後，同樣去找有沒有以此部門Ｂ１為上層單位的部門（也就是此部門Ｂ１有沒有下層單位），如果有就再繼續找其下層的第一個部門Ｃ１畫框框後，再往下找，如果沒有，就回到這層的第二個單位Ｃ２畫框框並往下找，等這層都結束了再回上一層畫第二個框框Ｂ２並往下找。。。直到第一層的下層單位Ｂn都跑完為止。
聽起來超繞口的，將執行順序畫成圖就一眼明白！
我們舉個例子，今天有一個大箱子，箱子打開後，裡面還會有幾個箱子，而每個箱子再打開後，每個箱子裡又可能有幾個箱子，也可能打開是空箱，就這樣一直下去，沒有規定數量，也沒有規定層數。而其中有一個不確定大小的盒子裡面放著一顆寶石。
如果要用一支程式表達，把這紙箱打開後找出寶石，該怎麼做？打開第一個大紙箱後，再打開第一個中紙箱，若還有小紙箱就繼續打開第一個小紙箱，小紙箱打開如果沒有紙箱了，就開啟第二個小紙箱，等小紙箱都開完了，再回上層去開第二個中紙箱。。。。。。直到找到寶石為止。
這個過程你會發現，與平行執行的迴圈不同，遞迴是以縱軸在執行，且不像迴圈有著特定的層次或數量，用迴圈不是做不到，只是很痛苦。
以流程圖來表示更為明顯，你只需要一個步驟。
以遞迴的觀念，提供另一個思考的方向，當你要得到１到１０的總合，其實就是將１０再加上１到９總合，而１到９的總合，就是９再加上１到８的總合。如此一來，就是由大到小，將自己加上前面數字的總和，在程式裡必須不斷去呼叫自己，直到為０才離開，再一層層地返回加總回去。
在程式中，X + getSum ( X - 1 )為一反覆執行的過程，直至X=0出口才返回。
從這二個例子中，可以發現很有趣的，是它後進先出的概念，一再重複呼叫自己直到出口點，完全沒有用到迴圈便能夠處理所有迴圈的問題。這類程式的優點，是將複雜的問題切割為細小可處理的小程式，增加可讀性，並重覆使用。
以生活化的說法，「遞迴」就像是拿著一面鏡子站在鏡子前，可以看到鏡子裡的自己拿著一面鏡子，裡面又看到自己拿一面鏡子．．．相同的影像不斷反射，而每次的影像都縮小些，而每個影像都是另一個影像的完全縮影。
而每次呼叫自己時會將資訊不斷堆疊在記憶體中，耗用的記憶體相較於迴圈是較大的，直至出口捲回時才將記憶體一一釋放，所以一個正確的出口相當重要，一但出錯便會踏入無盡迴圈直至耗盡記憶體而當機身亡。
回到剛才說的取得所有部門的程式，就這麼簡單，而且，效能超好。
其實以現有的網頁混搭技術，幾乎沒什麼想法是無法落實的，只是每種技術要耗費多少時間金錢，也取決於公司願不願意讓你研究、為你投資及維持更長久永續的產品生命。
一個每天見證著各式系統興起與落幕，且在程式文字上過著科技刀尖舔血日子的工程師，願意掏心掏肺地寫出這麼一段誠實到近乎荒誕的文章，真可謂佛心來著了。
探究和創新才是程式設計的本質，但這在不在乎程式設計師生命週期和生涯規劃的公司，是永遠無法被理解的。一個每天處理大量重複性事務的工程師，才是短視主管急於量化爭功的最佳工具，用著不明就裡的程式模組，也不被鼓勵提升，創新永遠只是簡報和口號，在日復一日的歲月消耗下，結局不是拉拔至管理階層的共犯，就是冷酷地放逐重練，順便再靠北一下停留在二十年前的程式工具和品質。台灣最不缺的就是這樣的公司。
沒有留言:
張貼留言