外在的環境時刻在變，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，從中找尋是否已有同仁寫好變身的程式。變身如此不易，如果已經有人實作，何必再自己打造呢? 況且如果寫得不好，到時候變成科學怪人可就不妙了!
