前言与自我回顾

欢迎大家来看我的文章，这次我挑战的主题是 Android 架构，就如同我简介中说的，关於架构方面的文章以及教学在网路上是非常丰富的，那为什麽我还要来挑战这一个大家都快写到烂的主题呢？因为据我所我观察到的，大部分都是介绍某个架构中有哪些组件 （Component），像是 MVVM 就是 Model, View, View Model，VIPER 的话就是 View, Interactor, Presenter, Entity, Router。还有他们各有哪些职责，然而却很少与实际的案例做结合，依据不同的使用情境来实作成不同的样貌。

我这样说并不是批评他们喔！要跟一个实际的案例做结合本身就需要花费非常大的篇幅来解释，从需求，分析到设计还有最後的实作，每个阶段都有非常多东西值得探讨，而且我相信很多人都看过或听过，架构是可以选择的，每个架构都有他的优点与缺点，这看起来是非常合理的一个论点，但是，实际在开发上真的是这样吗？那为什麽大家现在都在推崇 MVVM 跟 Clean Architecture？没有其他选择吗？在更深入说明之前，我想跟大家分享一下我从以前到现在的成长心路历程。

在一开始的 Android 发展中，大家其实是没有在很热络的在讨论架构的，大概在七年前吧，我的第一份工作是一个接案公司，那时面试的时候面试官都会问 MVC 是什麽，然後我也只能用网路上教的定义把他背出来，但实际上怎麽用还是完全不知道。甚至到後来我也完全没用过 MVC。到公司的第一个专案，是个档案管理系统 App，那时有一个很资深的前辈把大致上的架构都定好了，他负责底层的部分，我跟另一个同事则是负责 UI 显示以及串接资深同事所提供的介面，但由於我是新人，所以顶多就是解解 Bug 这样。到後来有一次前辈介绍架构时，才知道这个 App 有分三到四个不同的层，资料从底层传出来，我们需要使用 Callback 的方式来拿这些资料。那这是 MVC 吗？我也不知道，只觉得前辈很厉害，程序码都写得很清楚让我们一看就懂。

後来公司接了一个蓝芽手表的专案，全部让我负责完成，这次在前辈的协助下使用了事件驱动的架构，这专案很顺利的完成了，後来老板又接了另一个案子，也是一个蓝芽手表的 App，然後在沿用上一个专案的程序码之後，这专案在一个礼拜就完成了！值得一提的是，在这专案中，没有使用任何的 MVX 架构模式，在显示方面，我直接在 Activity, Fragment 做资料的串接，简单又快速！

後来到了第二间公司首次见到了“大泥球”（The big ball of mud），一个 Activity 中竟然有一万多行程序码！後来虽然有尝试着重构程序码，但是其成效有限，因为这专案的现况不允许有长时间的重构，要嘛就放弃这专案，要嘛就是加新功能看使用者会不会喜欢。

离开了这间公司之後，开始流行了 MVP （Model-View-Presenter），Google 在那时候有提供了一个 MVP 范例，算是给大家有一个指引，给想要入门架构的人知道可以怎麽做：一个 View 的 Contract ，还有配上一个 Presenter 去使用这个 Contract。加上那时候也开始学习写更多测试了，所以我那时候也很喜欢这个模式，因为这样的设计，就可以让我写很多测试在 Presenter 上。但快乐的时光总是过的特别的快，专案越来越大後，我开始感受到 Mock 物件是一件非常令人厌烦的事，为了要验证一个简单的流程，我竟然还要写十几行的程序码来做前置设定！然後最重要的测试程序码呢？往往不到五行！那我验证了什麽呢？我只验证了一个点击行为是不是会开启下一个页面，就这样！验证使用者的操作一定这麽复杂吗？在那时候，这是一个很想知道的答案。

在更之後，就是大家现在正在用的 MVVM 了，那时候也是 Clean architecture 这本书原文版出版的时间，我在第一时间就买了这本书，虽然一开始不太好懂就是了（尤其是相依反转那边）。我从中学到了很多，後来也在 GDG Devfest 有一个公开演讲，为了要准备这演讲，也让我了解的更深入。在理解了全貌之後，我越来越喜欢上它了，甚至我会想在所有的专案上都使用这个架构。也在差不多这时候，我开始观察到了很多...架构 library 。对於这个现象，我总觉得哪里怪怪的，为什麽需要有一个 Library 来帮我们做架构？但是也说不上来为什麽奇怪，如果有人要跟我吵我应该也没立足点ＸＤ。在 Clean architecture 中我看到的是每一个层级的相依性，外层认识内层，内层不认识外层，但是一定要有 Entity 或是 Use case 吗？我不确定，但是我能确定的是我不喜欢用一个 Library 来对我的专案动手脚。

在加入了 PicCollage 之後，让我眼界大开，我曾经以为，我已经没有东西可以学了，在架构的文献上我能看的几乎都看了，但是在这里我遇到了极度复杂的专案，很多问题不是靠 Clean architecture 的知识或是任何其他我过往的知识就可以解决的了，真为过去自满的自己感到丢脸。非常幸运的是，我刚进去的时候碰到架构的大整顿，在这里是使用 CTO 独创的 MDDV 架构，在帮忙完成这架构的过程中，慢慢做中学，现在事後来看，我在当时也犯了一些错误，也对这架构有些误解。

又在差不多一年之後，在同事以及主管的推坑下接触到了 DDD (Domain Driven Design)，看完之後又发现了一个新天地！这不是正是我们工作中需要的吗？如果从 PM ，Designer ，到 iOS ，大家都能够用共通语言沟通、维护、设计，那麽打掉重练的风险就能大大降低了不是吗？

以上就是我从工作到现在大致上的心路历程，接下来 30 天的内容将会分享更多我的心得，不知道读者你的故事又是如何呢？如果你从工作到现在只碰过 MVVM ，不管你是资历几年的工程师，我都强烈建议你可以开始试着做一个复杂的专案，在这转案中你会碰到很多大大小小不同的问题，而且这些问题复杂到需要把电脑暂时放到一旁，使用纸跟笔，画出元件跟元件之间的关系以及职责。最好的情况是，这个关系图，就算解释给非技术人员，他也是能够知道你在说什麽。

我在看 Clean Architecture 时很喜欢其中的一句话：The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity. 在导入架构时，整体系统的 Cost 是变高还是变低呢？对於程序员来说，产值是变高还是变低的呢？这是非常值得思考的。如果你要买房子的话，应该也不会奢望有完美格局，完美的环境，还有完美的邻居（除非你够有钱）。找伴侣也是同理，找工作也是一样，软件架构也是如此，没有最完美的架构，只有最适合你现在专案的架构。下一篇，就来正式开始介绍我这次的专案：线上便利贴。