（「哪些Guide與設計模式是無用的？」「全部！」）

「設計模式 Design Patten」
這東西並不是種程式碼，而是種用存粹口語文字描述的概念與策略思維，它的運作方式有點像是：「某專案的起始工程師甲使用了模組X，接手的工程師乙只需要知道工程師甲使用了模組X，就會知道工程師甲的程式碼會長什麼樣子，也能快速掌握如何擴充、如何除錯、如何升級、如何進行專案客製修正。」

像Android對Activity設計了「生命週期」特性，這本身就是種設計模式，很多平台的模組都有「生命週期」的概念，（但具有生命週期概念的各平台元件長得還是有點不太一樣，精通Android APP的生命週期，並不表示能夠快速掌握Windows App的生命週期。原因.......不言自明啦！）

所以...設計模式並不是用來提供一個可以具體解決什麼問題或產生什麼功能的技巧，它真正的價值僅僅是方便工程師互相溝通而已。

但現實運作碰到幾個問題...

很多工程師自己對設計模式的認知變得很狹隘，明明是使用了相似的設計模式，但「慣用A元件」的工程師似乎會被認為是「不懂/不具備/不熟練如何使用B元件的技術」。（這其實是「認為工程師在到職前就要懂各種需求的施工技巧去完成專案任務」的延伸。）
而且「使用設計模式去進行開發」的策略經常被執行了一半。
以Google自己來說，像ListView跟RecyclerView這兩個「List介面」的實作物件中，都使用了Adapter去進行「大量產生重複View」，而後者算是用來取代前者的新增支援/擴充元件...這大概是因為Google工程師懶得去修正或擴充ListView，就乾脆新增一個「策略上不相容」的元件，來想辦法讓List的樣貌在Android上可以更多元......
什麼叫「策略上不相容」，簡單來說，要改用RecyclerView，就要針對專案進行大量的打掉重做（而不僅僅是修改）。將專案程式中使用ListView的地方改成使用RecyclerView，結果Adapter的程式也要重做，呼叫Adapter的地方也要重做。
簡單來說，Google的工程師自己就犯了我在Day 4中講的「懂很多的工程師」會犯的毛病！——它幾乎不管其他要遵循它所釋出的元件與標準的工程師會死得多難看。

也許我可以把這件事情講的好聽點：這些工程師忘了Adapter本身是個設計模式，但View一樣也是個設計模式，既然是具有相同概念、也計劃被用來解決同樣問題的View，彼此之間應該要在物件導向使用上有種策略連續性......但那就不誠實了，而且Google身為一個累犯，實在不值得我說謊為他們掩飾。

所以......為什麼很多專案在技術上會死掉？
因為在元件升級（專案維護）這件事情上，主導的工程師並沒有在管其他工程師死活，就擅自的跟隨（認可）了Google工程師的無腦行為。
因為在選取專案工程師這件事情上，是否真的懂策略性思維（設計？使用？配合現有的設計模式？）比不上「讀了多少Guide」「讀了多少核心套件程式碼」這類的事情來的重要，所以專案會碰到問題無法解決、會忽然失去擴充性、會忽然無法維護。

(任何Guide與設計模式都可能變成無用、拖累專案的廢物，如果思維上不遵循著一些正確態度、或沒有避免去犯「會問哪些Guide與設計模式無用」這類的錯時。）