發達的工具會剝奪人的能力，能力被剝奪後經驗會開始狹隘，狹隘的經驗則會讓思維開始產生死角，有死角的思維......那不是文字可描述的。

（裝模作樣一下，講些打高空不著邊際的東西做為開場。）

因為IDE工具太發達，（哪怕僅僅是十年前的Eclipse，）Android工程師似乎都很習慣「一個Activity寫完所有功能」。——因為IDE工具的介面會幫開發者快速濃縮排列程式碼中的參數、函數、 內類別，不用物件導向也可以輕鬆管理大量程式碼，進而導致所有的功能在物件導向上都做得很「隨便草率」。
好的物件導向可以讓程式邏輯好懂好看，畢竟物件導向的精神之一就在於：用人類習慣可以理解的「萬事萬物」概念去規劃設計程式。
物件導向做得不好，程式就會不好懂，導致不好維護、或團隊擴編人力失敗。

除了物件導向以外，除錯也是個經常做不好的地方。
物件導向程式不好除錯。主要原因在於.......出錯的地方在於程式的邏輯？或在於邏輯要處理的資料？
邏輯錯誤就直接修正邏輯，但資料錯誤則是要回頭看「產生資料的邏輯是否有錯」，如果有錯就修正，如果沒錯就繼續回頭看然後「產生資料的邏輯所接收到的資料其產生的邏輯是否有錯」，如果有錯就修正，如果沒錯就......
傳統的除錯法其實就是「測試」。讓人力、或某種簡單可自動執行的程式去實際操作程式，然後期望可以找出「可能會導致錯誤的資料」、同時歸納出「導致資料產生的邏輯」.......
這種除錯法的問題在於人力或自動程式的能力其實很有限，測試的結果只能保證一個最小範圍的可靠性。像「90%的情況跟使用者可以可靠的操作」，然後...不管事前溝通再努力，一旦10%發生時，工程團隊就只能集體被抓去獻祭平息「高層的怒火」。
要應對這種情況，最合理的方式在於「用大量資料去測試邏輯」。
最好這大量資料本身也是用自動的方法、讓電腦幫忙大量動態（亂數）產生。

但這種情況等同另外開一個專案去產生另一套程式用來產生各種資料、再另外產生另一套程式去模擬成一套「會使用到同樣邏輯去處理資料」的程式並運作、然後還要再產生一組功能去記錄和分析測試的結果，然後......不管事前溝通再努力，一旦時程時程超時、人力預算爆表，工程團隊就只能集體被抓去獻祭平息「高層的怒火」。
一想到可能要面對高層的怒火，其實沒什麼人真的會走這條路，還是乖乖地走傳統的「人力」「簡單可自動執行的程式操作」就好吧......

當然還有另兩條路，那就是使用「UnitTest」框架和重度依賴AndroidStudio的分析工具。
但分析工具看起來再強大，它只是把90%工作變得好像很輕鬆、做起來很帥氣華麗而已。
而前者基本上很多情境跟任務中都不適用，很多時候依舊要仰賴使用UnitTest的工程師自己在裡面設計出一套功能來產生各種資料、還要盡可能讓UnitTest的運作真的能逼近「實際上處理資料的流程」...並不是說「UnitTest不好」，而是說要妥善使用它，依舊需要不少的人力成本與時間成本，偏偏這些都是很多專案團隊當初規劃時就否定的事情。（所以「凡事都要現成方案解決」這想法真的是「專案殺手」啊！）

除錯不好做啊！