Software Cinema

在 Martin Fowler 的 Refactoring 書 [1] 中提到 :

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure.

然而, 究竟 external behavior 如何認定, 甚麼算是 external behavior, 而甚麼又不是呢 ?

也許我們應該從 refactoring 的目的來看. refactoring 的目的是為了整理目前的 code ( 目前探討 refactoring 停留在 code level 居多, 因此沿用 ), 以便以較少的 time & efforts 進行後續的 software changes [2][3] . 因此 refactoring 可以視為是一種 data pre-processing 的技術, 目的在於把 data, 也就是 code, 調整到一個方便進行後續處理的狀況. 而對於後續要進行的處理來說, 其實 refactoring 的步驟並非是必須的, 只是為了降低整體程序的花費而進行 refactoring, 因此自然不希望在進行 refactoring 的過程中, 會改變 code 本身對於原本要進行的 software changes 之意義. 而這些不允許被改變的部份, 就是 external behavior.

換句話說, 在 refactoring 中, external behavior 的認定跟所要進行的 software changes 有關, 而所要進行的 software changes 又跟 software engineers 有關. 最常見的可能是由 test cases 所保證的 external behavior, 這類型的大多跟 software functionality change 比較有關, 也比較容易理解.

但是從另外一個角度來說, refactoring 畢竟還是改變了 code structure, 對於整個 source code 的意義還是造成了些許的改變, 只是這樣的改變對於要進行的 software changes 來說是否需要關心罷了. 比如說 pull-up-method, 改變前後的意義考量到原始的設計還是有差別的. 只是當我們的目的是方便後續的 maintenance 工作時, 這個差別就會被忽略不計.

然而這樣對於 software maintenance 長期來說是好事嗎 ? 或者只是炒短線的作法呢 ? 畢竟在 [2][3] 中似乎都沒有針對往後其他無關原本預計進行的 software changes 作探討. 然而所作的 refactoring 的的確確影響到了之後相關的 maintenance 工作之進行. 我們應該不能僅僅針對所預計進行的 changes 作有效評估才是.


References

[1] M. Fowler, Refactoring: Improving the Design of Existing Programs, Addison-Wesley, 1999.
[2] E. Stroulia and R. Leitch, "Understanding the Economics of Refactoring," In Proceedings of the 5th International Workshop on Economics-Driven Software Engineering Research (EDSER-5): The Search for Value in Engineering Decisions, May 3-4, 2003, Portland, OR, USA, pp. 44-49.
[3] R. Bahsoon and W. Emmerich, "Applying ArchOptions to Value the Payoff of Refactoring," In Proc. of the 6th Int. Workshop on Economics-Driven Software Engineering Research, Edinburgh, Scotland. pp. 66-70. IEE.

Cenqua : The Commentator 是一個有趣的想法, 但是看他說明的時候請注意到網頁最下方, 有一行小小的字寫著 : "Promotion running only for April 1".

先假設有這樣的一個 tool 好了, 根據網頁上的文宣, 其實 The Commentator 主打的並非 automatic commentating, 而是 personalized automatic commentating. 在加上 comment 時, 是可以根據你個人的 commentating 習慣, 來產生 "看起來" 是你手動打出的 comments.

換句話說, 其實 The Commentator 是一個 Personalized Comment Decorator, 其前端還需要具有一個 Comment Add-on Suggester 來找出在程式碼的哪個部份會需要加上何種 comments, 形成一個 unified comments, 然後再利用 Personalized Comment Decorator 來對於該 comment 加上潤飾. 而 Personalized Comment Decorator 的潤飾其實是一種 view 的轉換.

如上圖, 利用一個 Comment Add-on Suggester 作為前端, 判斷要加上甚麼樣的 comment 內容, 在 source code 與 comment 之間作 logic (syntax) transformation, 而在後端是利用 Personalized Comment Decorator 作 view (semantic) transformation. 在 Personalized Comment Decorator 的設計上要特別注意不能落入 AI 過去的死胡同, 我們不是要嘗試讓 Personalized Comment Decorator 變成 programmer, 而是要嘗試讓 Personalized Comment Decorator 能夠產生最接近 programmer 想要的結果.

Cenqua : The Commentator 並不全然是不可行的, 甚至在 code generation tool 越來越多, programming phase 正在邁向 fully automation 的同時, 這樣的 commentating tool 或許會變成在 maintenance phase 相當關鍵的產品也說不定.

今天因為 project 的原因, 想裝起 Joomla ! 來試試看. 但是 Joomla ! 的網站上好像暫時停止 download 以及 demo film 的下載, 原因不明. 想說好吧, 不然就用 Mandriva 內建的 Joomla packages 裝好了. 結果剛勾選完, 驚訝的發現居然相關的需安裝 packages 包含 Joomla 總共高達 36 個 @@


雖然說裡面包含了 Apache 跟 PHP 相關的 packages, 但是重點是我之前系統中並不需要安裝這些, 這些是由於 Joomla ! 的需要才有相依性安裝的.

藉著這個機會剛好想嘗試一下很久以前就發現的問題 : Package Manager 好像都沒在紀錄 package installation dependency 的, 因此想移除某 software 時也一併移除之前因為相關性才裝的 software, 好像無法透過 package manager 的幫助達成.

所以裝完 Joomla ! 後, 又故意把他移除試試看. 果然, Mandriva 內建的 package manager (RPMDrake) 只會偵測到 Joomla ! 相關的兩個 packages.


而在移除過後, 再度選擇裝回去, 就會發現現在只需要裝兩個 packages 了. ( 就是剛剛移除的 Joomla ! 相關 packages. )


這個結果意味著, 在 Joomla ! 被安裝時, 因為相依幸而被安裝的其他 packages ( Package In ), 在 Joomla ! 要被移除時 ( Package Out ), 並不會自動地被移除, 或是詢問使用者是否要一併移除. 然後就這樣留在系統中, 成為不知哪時才會被用到或是被更新的 useless packages ( Packages Left Behind ).

事實上要紀錄 package 被安裝時的 dependency associations 應該不是難事, 甚至當你要移除某個 packages 時, package manager 也會提醒你此 package 目前被哪些 packages 所依賴, 如果移除可能會出現問題. 顯見這些 dependency 資訊應該已經有被紀錄起來, 為何在 remove package 時, 卻不提醒使用者一併移除可能之後不會用到的 packages 呢 ?

我能想到的主要原因只有一個. 因為整個系統嚴格上來說並不受 package manager 管轄, 所以當面臨移除的指令時, package manager 並無從知道是否之前因為 dependency 而安裝的其他 softwares, 在 package manager 管轄之外, 被其他經由使用者自行安裝的 packages 所利用, 這樣的 dependency association 目前是無法經由 package manager 所紀錄的. 因此 package manager 無法在殘缺的 dependency association information 底下, 確保 package 的移除不會出現問題.

然而不用 package manager, 靠管理者更難做到上述的 package dependency analysis. 是否有更好的方法, 可以 statically or dynamically 對於整個 system 內的 package dependency 作分析, 進而蒐集相關資訊, 使得管理者可以在 remove package 時, 很清楚的知道應該把哪些 packages 也一定移除嗎 ?

TagSEA [2] 是好一陣子前看 ICSE paper [1] 時發現的 tool, 當時就覺得蠻有趣的, 不過好像中文網站還沒有太多的介紹. 作者群在 ICSE 的那篇 paper 是 tool demonstration short paper, 應該蠻容易看懂的. TagSEA 網站上也可以直接看的到.

如其名, TagSEA 的主要功能在於能夠讓你隨意在程式碼上加上各種 tags. 有些是 TagSEA 已經訂好的 common tags, 例如 TODO tag, 而你也可以自定習慣的 tags. Tag 的位置可以在程式碼上, 註解上, 或是空白的部分. 加上 tag 的方式可以採用手動以 Java comment 語法加上 @tag 標籤, 或是直接在要註解的地方按 mouse 右鍵, 從選單中加入 waypoint (TagSEA 稱呼在 source code 中被標上 tag 的 location 為 waypoint). 在 waypoint dialog 中可以再指定要創造新的 tag 或是採用既有的 tags. 更詳細的說明在 TagSEA 網站上有很多易懂的 examples. 值得注意的是用 @tag 標籤加上的稱為 parsed waypoint, 而利用選單加上的稱為 resource waypoint. 這在後面製作 presentation tour 時會有差別.


TagSEA 對於 waypoints 提供了 hierarchical tree view (上圖左下方), 以及有趣的 cloudsee view.

CloudSee view 雖然好像有些趕流行, 但是對於想一眼看出不同 tags 數量關係還蠻有用的, 況且 programming environment 內實在需要出現一些有趣點的東西, 可以紓解 debug 壓力 :p


不過在右方的 tag message list 有點小 bug, 當新增 tag 時, tag message list 不會馬上更新, 需要等到再加一個新 tag, 或是 mouse 右鍵 tags -> show waypoints 才會更新.

TagSEA 內的 waypoint 應該是沿用自 GPS 系統的稱呼 [3], 可以想見 TagSEA 其實定位自己是 Eclipse 上的 GPS navigator 系統. 因此同樣地, 數個 waypoints 以特定順序串在一起就形成 route (同樣來自於 GPS 系統) [1], 而一長串的 route 其實就是一個 navigation tour.

TagSEA 也提供 Tour 的幫手功能 (但是需要 Eclipse 3.3 以上), 藉由 Tour 功能, 你可以快速地利用已經標好的 tags, 在 Eclipse 上建立一個簡單的 presentation (進行的步驟在 TagSEA 網站上寫的很清楚了). 只要執行編輯好的 Tour, 然後利用播放鍵就可以很順利地依照你的 plan 進行 presentation, 再也不用擔心 present 到一半卻忘了要開哪個檔案, 或是找不到要講的那段 code, 或是忘了本來要開的 view 是哪一個 -- 是的, Eclipse 上的 view 也可以作為建立 presentation tour 時的一的造訪點 (其他可以加的東西都在右側的 Tour Palette 上). 但是這裡要注意的是, 如果你要 Tour 自動根據 tag 換到該位置, 必須要是 resource waypoint 的 tag 才可以, 如果只是 parsed waypoint, 似乎 Tour 不會有反應.

執行後的 Tour 會在上方出現播放控制盤, 可以看到目前的位置, 也可以前後播放, 不過還沒有辦法直接跳躍到某個步驟.

可以看到當執行第一個步驟時, 畫面就自動切換到第一個 resource waypoint 所 tagging 的地點了.


另外除了 Tour Palette 上可以加的東西, 以及 resource waypoint 之外, PowerPoint 之類的也可以加到 Tour 裡面, 我嘗試了 OpenOffice.org 系列, odt 檔案可以, 但是 odp 就會出現一些顯示的問題, 不過這些問題應該跟 TagSEA 無關, 是 Eclipse 本身的問題 (OpenOffice.org 會直接以 OLE 物件的方式開啟在 Eclipse 視窗內, 而 PowerPoint 會獨立開啟), 我也嘗試了 PDF, 但是會出錯, 根據錯誤訊息應該是我 local 端的設定問題. 換句話說只要你 local 端有相對支援開啟的 software, 應該都可以順利在 presentation 過程中開啟. 下面是開啟 odt 檔案的樣子.


從 tool 的角度來看, TagSEA 算是蠻小巧好用的 tool, 而我喜歡他的另外一點是, 從 research 的眼光來看, 這個小 tool 有相當大的潛力. 現在 TagSEA 只能在 code 上加 tag, 而別忘了 Eclipse platform 上的 plug-ins 幾乎快涵蓋了整個 model-driven software development, 雖然有些 plug-ins 還不算太成熟, 但是當 TagSEA 可以更順利地支援直接在 use case, object model, analysis model, architecture design, detail design 上加註 tag 時, 想想他將會有的 power, 給 software developer 提供的 traceability service 以及 consistency checking service, 還有很多可能的應用, 都可以建立在這一個看起來很簡單的 tool 身上去實現.

我想這是包含我在內的許多台灣研究學生, 經常忽略的一點, 在我們手上的許多小想法因為他們簡單, 所以擁有更大的發展空間, 老想著重新作出全新的東西, 會讓我們的研究工作前進的十分緩慢. 好好地利用已經有的東西, 往上堆積新的價值, 才是一直以來研究該有的方式.


References

[1] L. Cheng, M. Desmond, and M.-A. Storey, "Presentations by Programmers for Programmers," In Proceedings of the 29th international Conference on Software Engineering, pp.788-792, 2007
[2] TagSEA, URL : http://tagsea.sourceforge.net/
[3] waypoint @ Webster's dictionary, URL : http://www.websters-online-dictionary.org/definition/waypoint

Google Blogger 之前已經提醒過台灣時間今天下午 3:00 左右會暫停服務 10 分鐘左右, 估計是進行過必須重新啟動系統的 maintenance 工作. 相對來說, 所謂 "台灣網路創業成功案例" 的無名小站, 就我之前輾轉看到的公告, 似乎都需要停止服務接近一天以上 (而且還都選在假日, 加班有錢賺 ?), 從這種小事情就可以看到服務供應商的 maintenance 能力, 對於自身的定位, 以及對於市場競爭的覺悟.

Google Blogger 只停了 10 分鍾不代表 maintenance 工作只進行了 10 分鐘, 在此之前我認為可能長達三個工作天以上完成這個 maintenance 作業. 而經過事前審慎的規劃分析, 降低所有的 complexity, 得到的結論就是一個詳細的計畫, 以及最後需要 10 分鐘的暫時停止服務. 然而無名小站的整天停止服務就不知道是什麼原因會需要這麼久了.

Non-stopping applications 的議題在 academic 已經有二十多年以上的討論, CS 領域的研究人員很早以前就意識到 Non-stopping applications 在 maintenance 上必須要被克服的種種問題, 許多大學研究所的 fault tolerance 課程多少都有介紹到. 然而理論是一回事, 業界的公司在實行時還是需要考量到花費的 costs 問題. 大部分的一般性支援 non-stopping adaptation or maintenance 方法還是需要額外的 hardware/software redundancy, 這同時也是比較容易達成的方法.

我並不是在說沒有作到 Google Blogger 的 10 分鐘就是罪惡, 而是從這種小事情就可以看出服務供應商的能力與決心. 我自己也在管理一個平均上站人次在每日 200 ~ 300 人的小型系站 BBS, 偶爾我也必須暫停服務以更新軟硬體, 更別說當被攻擊或是硬體損壞時, 停個幾天的服務也是可能的. 由於經費以及我可用的時間限制, 我所能作到的最好結果就是這樣, 這也反映出我所 maintain 的這個 BBS 其目的以及定位就是只有給系上的學生使用, 我也沒有什麼市場競爭的考量. 當然我可以花更多的心思去爭取經費, 作到 non-stopping service, 但事實是, 我並不需要.

然而放到 business domain 來說, 作為 company manager 也好, project manager 也好, 你對於你的 product, 有著怎樣的 maintenance 能力, 有著怎樣的定位以及理想, 你用什麼樣的 strategy 去應付市場的競爭, 這些因素在在透過許多小事情會展現出來. 作為提供 product 以及 service 的人, 如果在這些小地方隨便應付, 恐怕休想你的 product 會有美好的將來. 而作為聰明的投資人或是使用者, 應該更需要從這些小地方應該就要開始判斷這個 product 的 reliability, 畢竟我們可不希望付出的時間成本就悄悄地埋葬在 awful manager 的手裡.

最近我有一個關於 code commenting 的想法, 正交由學弟妹進行計畫以及撰寫 paper 中, 剛好找別的資料時又看到一篇有趣的文章 : Ryan Campbell 早在 2005 年寫的 Successful Strategies for Code Commenting [1]. 文章中列舉了數種 code commenting 的樣式, 探討了 comment readability 甚至 comment reusability, 嘗試從各個面向, 探討一個好的 code comment 應該要有的長相. 文章內的其他連結也都很值得一讀.

然而, 我們真的需要這些 successful strategies 嗎 ? 或是更準確地說, 我們需要為自己或是 project 找一套 successful strategies 嗎 ? 誰又能負責對於是否 successful 作 evaluation ?

Software engineering 的書裡常說, software 的存在是為了讓人們可以更加專注在於他們應該思考的事情, 而不需要去在意可以透過 software 解決的事情. 而選擇或是擬定 comment strategy, 真的是 programmer 在撰寫 comment 時, 應該要花時間去思考的事情嗎 ?

Referfences
[1] R. Campbell, "Successful Strategies for Code Commenting," August 2005,URL : http://particletree.com/features/successful-strategies-for-commenting-code/