� IT 這行一定會碰到技術和需求 (requirement) 相��的時候，有些來自業務部門的需求�嘛是天馬行空��然就是疊床架屋。以技術的角度來說，往往�是��到，而是值�值得�的�題。

學界訓練技術人æ��，是教導學生找出好的解答，就算ä¸�是最佳解，至少也應該è¦�找出次佳解 (suboptimal solution)。”Dirty-hack” 並ä¸�在學校教導的範疇內。å�³ä¾¿é€²å…¥æ¥­ç•Œï¼Œæ‰€è¬‚的技術大師也往往是因為能夠æ��出漂亮的架構或是清楚的系統介é�¢è€Œå�—到尊敬，而ä¸�是因為 “總是能讓一個陳舊的系統還å�¯ä»¥é�‹è¡Œ” 而å�—人稱é�“。如果說 MBA 畢業生其實å�ªè¦�學會在一上任就喊 “組織é‡�組” å°±å�¯ä»¥ç•¢æ¥­ï¼Œé‚£è³‡æ·±ç³»çµ±æž¶æ§‹å¸«æˆ–許也å�ªéœ€è¦�會 “reboot”, “re-install” å’Œ “re-architect” å°±å�¯ä»¥æ··å�£é£¯å�ƒäº†ã€‚

�是���生�是沒有�則的，需求 (requirement) 是沒有止盡的，永�會有一個新的生�需� Dirty hack，永�會有一個新客戶想�而當�沒考慮到的需求。這也是跟�一個拋棄�的網站最大的��，因為拋棄�的網站沒有維護的�題�沒有陳年的商業�輯�沒有新需求注入。

先�我�為好的架構是系統穩定最��的因素，但後來發�，商業網站的程�碼和商業�輯是切�開的，並沒有一個架構有辦法讓商業�輯自�一格。除��生�的變化種類減少，�然網站的程�複雜度就��能會減少。一旦�輯複雜，就�有走� dirty hack 一途。

æŸ�種程度上這也解釋了為什麼大公å�¸æ²’辦法åƒ�新創å°�å…¬å�¸ä¸€æ¨£å¿«é€Ÿç”¢ç”Ÿç¶²ç«™ï¼›æ‰£æŽ‰ç¹�複的內部æµ�程，程å¼�設計師è¦�擔心的ä¸�是 “我加了什麼新功能?”，而是 “我æ�žçˆ›äº†ä»€éº¼èˆŠåŠŸèƒ½?”

純技術性的想法是，拋棄舊的架構，在新的架構把所有�西�寫。��走這�路��功是難上加難，想�你必須抄寫一張已經被立�白塗抹了�幾年的手寫�稿，�怎麼知��在寫在上�的�西，真的是它表�上的��呢?

é‡�新架構的å�¦ä¸€å€‹å•�題是，這段時間你的研發能é‡�就被佔滿了；你在原地è¸�步，å�ªå¸Œæœ›æœªä¾†å�¯ä»¥è·‘得比競爭者快 — 我希望你能活到那時候。

就因為這其實並�是個簡單的�題，所以�讓能夠妥善處�這種�題的公�能夠脫穎而出�。��，這樣更好玩，�是嗎?