一次模块划分的争论及其结局

公司最近正在对整个产品进行大规模的重构，把原先基于Web的产品线全部转向Android平台。随之而来的就是产品整体架构设计上的大讨论。作为其中一项最为旷日持久的争论的发起者，我觉得有必要把这个事件记下来。无论现在的思路或是观点是成熟的还是幼稚的。以后都可以引以为鉴。

先来描述一下我们要做什么。简单而言就是一个横跨各个内容源的书籍阅读平台。这个平台的目标不仅仅是方便用户在一个终端上，以一种统一的方式购买、阅读到所有内容源的书。同时，这个平台作为一个开放式的平台，也以方便内容源的接入为目标，这个平台就是起着这样一台读者与内容源之间的通道的作用。

这里的内容源是指持有内容版权的内容提供商，比如全国各家出版社、网络小说站点（如起点、红袖、纵横天下等）及其它数字出版资源提供商（如当当、淘花、云中书城、方正Apabi等）

这次改造的目标主要有这样几点：

1. 开放平台：提供Apple Strore这样的机制，让其它内容源的开发者可以有机会自主地接入这个平台。比如当当网可以用我们给的SDK自己做一个Android APK，在里面卖当当的书。
2. 升级管理：将原来一整个系统分拆成各个模块，各个模块可以独立地发布、测试。并使用强制升级的方式回避向后兼容的问题。

争论问题的背景是：不同的内容源所提供的内容的格式不尽相同。有EPUB，有PDF，有TXT，有SNB，也有DOC的。我们显然要尽量多地去支持这些书籍的格式。

争论的焦点在于：对内容的阅读这个功能，应该与每个内容源自身的APK合并还是分开实现？很多人觉得当然是要分开，但是其实现实中的问题没有这么简单。比如如下的几个问题：

1. 有的书不是整本购买，而是一章章地买。阅读器看到一半儿，发现有一章没有买，是不是发起购买呢？如果是，应该向谁发起呢？
2. 有版权的书，都是经过加密的，想解析这种加密好的文件，需要有Key，阅读器发现某一章没有Key了，找谁要Key呢？
3. TXT是整个的，没有章节，如果想为TXT附加章节信息，可能就要额外的实现，但是不同内容源的实现方式不同。如果章节列表在阅读中显示，阅读器又怎么知道不同内容源对于章节列表的定义方式呢？

诸如此类的问题还有很多。即便如此，我个人自始至终都坚持分开。但我的上级领导坚持认为应该合并在一起，一个APK应当包括分类浏览、购买、阅读等一整套的功能，自成体系。如果仅仅是我一个人坚持分开，显然不会有争论，级别在这儿摆着，他一句：“这个事情不要讨论了，就是这个样子的。”我就直接歇了。好在主导这次重构的两个架构师的意见和我比较一致。于是我们几个人在大庭广众之下（一时找不到会议室）争论了多次。最后上级的上级看不下去。把我们一票人拉去群体PK。

最后BOSS给的解决方案是这样的：

1. 如果讨论不清楚就合一块。以后有必要了再分开。
2. 这两种方式没有实质上的冲突，可以并存，也应该并存。只是先实现哪种方式的问题。
3. 讨论哪一种方式更好的时间，还不如直接让做的人自己选一个自己觉得爽的方试直接做了。

虽然我就是那个做的人，BOSS说我爽就行。但是对于这个解决方案我目前是相当的不满意。

从技术的角度，我觉得合比分要简单得多，先分着做，出现无法解决的问题，再合起来所用的时间应该比把一个系统拆分成不同模块所用的时间更少。先分着做，也能把层次关系尽早理清。

从管理的角度，做正确的事情，应该比做事的效率重要吧？