關于一次模塊劃分的爭論及其結局
公司最近正在對整個產品進行大規模的重構，把原先基于Web的產品線全部轉向Android平臺。隨之而來的就是產品整體架構設計上的大討論。作為其中一項最為曠日持久的爭論的發起者，我覺得有必要把這個事件記下來。無論現在的思路或是觀點是成熟的還是幼稚的。以后都可以引以為鑒。
先來描述一下我們要做什么。簡單而言就是一個橫跨各個內容源的書籍閱讀平臺。這個平臺的目標不僅僅是方便用戶在一個終端上，以一種統一的方式購買、閱讀到所有內容源的書。同時，這個平臺作為一個開放式的平臺，也以方便內容源的接入為目標，這個平臺就是起著這樣一臺讀者與內容源之間的通道的作用。
這里的內容源是指持有內容版權的內容提供商，比如全國各家出版社、網絡小說站點（如起點、紅袖、縱橫天下等）及其它數字出版資源提供商（如當當、淘花、云中書城、方正Apabi等）
這次改造的目標主要有這樣幾點：
開放平臺：提供Apple Strore這樣的機制，讓其它內容源的開發者可以有機會自主地接入這個平臺。比如當當網可以用我們給的SDK自己做一個Android APK，在里面賣當當的書。
升級管理：將原來一整個系統分拆成各個模塊，各個模塊可以獨立地發布、測試。并使用強制升級的方式回避向后兼容的問題。
爭論問題的背景是：不同的內容源所提供的內容的格式不盡相同。有EPUB，有PDF，有TXT，有SNB，也有DOC的。我們顯然要盡量多地去支持這些書籍的格式。
爭論的焦點在于：對內容的閱讀這個功能，應該與每個內容源自身的APK合并還是分開實現？很多人覺得當然是要分開，但是其實現實中的問題沒有這么簡單。比如如下的幾個問題：
有的書不是整本購買，而是一章章地買。閱讀器看到一半兒，發現有一章沒有買，是不是發起購買呢？如果是，應該向誰發起呢？
有版權的書，都是經過加密的，想解析這種加密好的文件，需要有Key，閱讀器發現某一章沒有Key了，找誰要Key呢？
TXT是整個的，沒有章節，如果想為TXT附加章節信息，可能就要額外的實現，但是不同內容源的實現方式不同。如果章節列表在閱讀中顯示，閱讀器又怎么知道不同內容源對于章節列表的定義方式呢？
諸如此類的問題還有很多。即便如此，我個人自始至終都堅持分開。但我的上級領導堅持認為應該合并在一起，一個APK應當包括分類瀏覽、購買、閱讀等一整套的功能，自成體系。如果僅僅是我一個人堅持分開，顯然不會有爭論，級別在這兒擺著，他一句：“這個事情不要討論了，就是這個樣子的。”我就直接歇了。好在主導這次重構的兩個架構師的意見和我比較一致。于是我們幾個人在大庭廣眾之下（一時找不到會議室）爭論了多次。***上級的上級看不下去。把我們一票人拉去群體PK。
***BOSS給的解決方案是這樣的：
如果討論不清楚就合一塊。以后有必要了再分開。
這兩種方式沒有實質上的沖突，可以并存，也應該并存。只是先實現哪種方式的問題。
討論哪一種方式更好的時間，還不如直接讓做的人自己選一個自己覺得爽的方試直接做了。
雖然我就是那個做的人，BOSS說我爽就行。但是對于這個解決方案我目前是相當的不滿意。
從技術的角度，我覺得合比分要簡單得多，先分著做，出現無法解決的問題，再合起來所用的時間應該比把一個系統拆分成不同模塊所用的時間更少。先分著做，也能把層次關系盡早理清。
從管理的角度，做正確的事情，應該比做事的效率重要吧？
原文鏈接：http://www.cnblogs.com/nankezhishi/archive/2012/01/10/2318643.html
【編輯推薦】
