2012年4月21日 星期六

彼得潘變身蝙蝠俠的重複問題 (The Evils of Duplication)



外在的環境時刻在變,App的開發亦然。整個美術設計或是操作流程一瞬間打掉從練已經是見怪不怪,App程式設計師必須努力去適應的事情。

然而此時程式的寫法就很重要了。比方原本App的魔王是佛地魔,彼得潘變身為哈利波特的程式碼重複出現於多個重要關卡。到時候當規格將魔王改為小丑時,彼得潘必須變身為蝙蝠俠,但若是我們有一處遺漏忘了改正,玩家將看到哈利波特對決小丑的詭異畫面。

Tip: Don't  Repeat Yourself
解決重複問題的方法很簡單,只要學會不要重複。然而就像不說冷笑話,即可解決冷場問題般,都是說來容易,實現超難! 要不說冷笑話,得了解冷笑話的成因。同樣的,接下來我們也來分析常見造成重現象的原因和解法:

1.  Imposed Duplication
人在江湖,身不由己。環境因素使然,不得不重

(1) Multiple representations of information
很多時候,同一個資訊在Server端和App端都需要。以音樂App為例,在Server端定義了表示專輯的table,而App端也同樣需要定義一份。然而,到時候如果專輯table需要新增欄位,由於重複問題,我們需要同時修改兩個地方。

解法:
利用code generator。比方將專輯需要的欄位定義為xml檔。到時候Server端和App端只需讀取此xml檔,然後利用code generator 即可產生新的專輯table,因此每次修改只要更改xml檔一處。

(2) Documentation in code
程式的comment常常是造成重複的凶手! 如果comment鉅細靡遺地說明程式的實作,當程式修改時,comment也需要一併修改。但往往隨著日積月累,程式已經改了不下千回,comment卻還是原封不動,保持在最初的狀態。這樣子的comment,比沒有comment還糟,因為它將讓後繼接手的人誤解,不知該相信comment還是程式碼。


解法:
好的程式碼一目瞭然,其實不太需要comment。如果真的需要寫comment,不寫對不起自己的良心,也請謹記只須表達此段程式的目的,而不用解說實作的細節。

(3) Documentation and code
文件和程式往往保有一定程度的相依性,造成不得不然的重複。

解法:
類似code generator的概念,從文件產生程式。

(4) Language Issues
因為程式語言的特性造成重複。比方C語言裡常常看到同樣的東西必須於.h宣告,.c裡定義。

解法:
利用一些自動化的工具幫忙。比方從.c的定義自動產生.h的宣告。


2.  Inadvertent Duplication
不自覺的重複。此問題往往緣由於不良的程式設計。比方我們定義了Book類別,於其中宣告以下3個member。
(1) price
(2) amount
(3) priceSum
其中priceSum等於price * amount。因此每當定價或銷售量改變時,我們也要記得更新priceSum。惱人的重複問題就這樣靜稍稍產生了。因此,比較好的寫法是將priceSum定義為method,而不是member,如此即不會有忘了更新的問題。


3. Impatient Duplication
人類的懶惰天性使然。以前面提到的彼得潘變身哈利波特為例,若是我們能夠定義成method,於傳入的參數指定變身後的角色,即可解決重複問題。然而往往因為schedule的壓力,或是趕著下班後和女朋友的月球漫步,我們直接將原來的程式碼copy paste。反正功能完全正常,而且還能節省時間提早將App上架,自己,老闆,女朋友,消費者全都開心。可惜,事情往往無法盡如人意。過不了多久,當規格修改,由於重複問題,我們需要徹底清查程式碼每個角落,將彼得潘變身為蝙蝠俠。如果不小心遺漏了,還得花更多的時間找尋和加班。記住,出來混總是要還的,到頭來只會自己,老闆,女朋友,消費者都不開心!

4. Interdeveloper Duplication
因為團隊合作造成的重復。此問題是所有重復問題裡最難解。畢竟自掃門前雪尚且不易了,更何況是團隊成員間的溝通協調。由於缺乏溝通,彼得潘寫了一份變身哈利波特的code,虎克船長也寫了份變身佛地魔的code。

Tip: Make It Easy to Reuse 
建立一個易溝通,彼此常交流,方便Reuse的環境是解決此問題的不二法門。比方我們可以建造一個團隊的知識庫Wiki,從中找尋是否已有同仁寫好變身的程式。變身如此不易,如果已經有人實作,何必再自己打造呢? 況且如果寫得不好,到時候變成科學怪人可就不妙了! 




 


沒有留言:

張貼留言