我，作为一个按模块开发的偏执坚持者，深彻的体会到了按功能开发给我带来的痛苦。我目前工作单位的项目就采取这种按功能开发的模式，让大家心力交瘁。所以在这里吐槽一下问题出在哪里
1.耦合性###
高内聚、低耦合是高质量的代码的基础标准之一。模块开发由于分工明确，团队之间协作完全通过API来沟通，除了一些公共的工具类以外，相互间的代码基本上可以把耦合性降到最低。负责DB的和负责网络的给负责逻辑的提供API，负责逻辑的给负责UI的提供API，这样，开发者之间只要关心API对方是否易用就可以了，不但能极大程度降低耦合，而且还能提高API质量。
2.API质量###
大概相互之间协作只有通过接口相互调用才能避免相互重叠的时间。比如，前端和后端沟通完全是通过协议，除了协议之间相互没有其他瓜葛，这样也就避免了重叠时间的效率流失，而相互之间沟通的桥梁的质量由双方面负责，所以质量自然不会差，谁也不愿意被对方吐槽自己提供的API难用。
3.可测试性###
良好的API接口顺理成章的为可测试性打下了坚实的基础，至少在模块API之间的交互能做到低耦合，从而有了良好的可测试性。相比团队成员每个人都要从协议层到DB层，再到逻辑层，最后展现到UI层，把代码写成一锅粥效率与质量的提升绝不止一点。
4.阅读一堆人的代码和阅读一个人代码###
我的同事们可能已经辛辛苦苦的把某一个可复用的功能写好了，但是我怎么知道？成百上千的API很难一一沟通。相比之下，最高效也是最搞笑的做法就是我自顾自的写一套。虽然阅读他人代码是对能力的一种考验也是一种提升，但是，无论如何，阅读他人代码对于项目来说时间成本都极大的高过寻找自己写过的代码。何况，如果在一个按照功能划分工作的项目组中，如果有5个成员，我可能面临着要阅读参杂在一起的其他四个人的代码的窘境，如果说阅读其他某个人的代码是对能力的锤炼的话，阅读其他一堆人揉在一起的代码那肯定是对工作积极性的无情消耗。就像，我每天去健身房锻炼一个钟头，我会有健康的身体，但是如果我把我的所有行李用一天时间从一个房子搬到另一个房子，那是对体力的消耗。两者无论如何也不能混为一谈。所以，按照模块划分很好的解决了这个冲突，每个人可以专注自己的逻辑，专注自己的代码，我的责任是用提供高质量和高效率的API为团队提供帮助，由团队对整个项目负责，而不是碰到某个功能的问题，把责任全部推给小A小B或者小C，这样完全浪费掉了团队应有的优势。
5.沟通API与跟踪未知代码对比###
如果我需要获取一段数据的话，我很乐于问负责DB的同时要一个API，然后我可以专注我的界面实现，我想，我的界面实现会是很优秀的。如果，我需要获取一段数据，但是没有负责DB的同事支持，那我可能会去自己去写DB，然后发现DB中也没有数据，然后我又要自己去写网络，然后发现逻辑处理上还要再搞一搞，最后，终于拿到数据了，我展现在界面上，然而这时我已经忘了我之前界面上又哪些我还没搞好的东西，数据展示出来了就万事大吉了。最后我的DB代码，我的网络层代码的质量就随便吧，因为我赶着实现功能，把时间和思路都用在了模块间跳跃上，哪里还记得有哪些坑没填？然后，我的同事可能会说，这代码真尼玛的难跟，跟进去完全不知道这2B是什么逻辑。一遍一遍的跟，最后理顺了，也要下班了，然后第二天早上update一下代码，发现，又特么变了。@！#！@#
6.一个app与一堆app的区别###
接着上面的论点，我更觉得，如果按照功能去划分工作的话，那跟每个人负责一个有这个功能的APP没什么区别。最后的结果是本来一堆功能组成的一个APP变成了一群各自为政的人做出的一堆APP拧在一起，貌合神离。
7.UI 风格参差不齐###
如果一定要按照功能划分的话，如果UI也要按照功能划分的话那真是很！@#￥的事，每个人的开发习惯不同决定了UI风格不一样，有可能A喜欢用14号字，B喜欢用15号字，C喜欢和AB用不一样的字号，最后的结果是每个页面看起来都很诡异，然后想了很久才发现，特么的字大小都不一样，完全没有统一标准，最后还要一个个的调整，而且很容易漏掉某个页面，开发完成的APP又成了一堆APP杂糅在一起。
8.代码层级划分对编译效率的影响###
对于比较大型的项目，编译速度对工作效率的影响非常明显，如果我每修改一个文件要编译700多个文件，那真是很操蛋的体验。所以，个人喜欢按照模块把项目剥离、解耦，然后对于不常修改的模块用静态库来植入工程，这样就省去了这部分代码的编译时间，对于模块开发，这个非常容易实现，焦点还是在低耦合上。把编译效率提升50%对于大多数小公司的工程来说绝不难做到，只不过这取决于工作的方式和团队对效率的尊重，因为可能根本没人想过这效率提升有什么用，编译时候抽颗烟，看看微博也挺好。
9.对时间掌控精度###
如果我每天都做一样的事，那么我肯定比较容易判断出这件事需要花掉我多少时间，我也很容把这件事情做的质量很高。
10.bug响应时间###
有些bug是非常难以定位的，但是有一点是比较清楚的，就是，Bug肯定在某个API中可以追踪，这样只要把关注点放在API上就可以定位到问题出在哪个模块，这样就相对容易定位的多，这种方式类似于二分法。一锅粥的代码如何二分？从发现Bug到UI人员负责定位责任归属，如果确定不是UI造成的问题那肯定是API的问题，这样就把现象分发给逻辑层，逻辑层再去确定是逻辑层本身的问题还是DB或者网络接口的问题，这样把问题分发解决要比一个人跟踪很多自己本来不熟悉的逻辑要高效的多。
最后，review###
如果要我说流程开发相比模块开发有什么优点，那可能对整体业务的了解应该更多。但是代价是消耗了大量的时间和大量的重复劳动，未免过于奢侈。如果把用模块化开发节省下来的时间安排到Review中，专注的了解某一部分一定更加高效。但是，Review这种事，很多时候是不能明着做的，你懂得~
归根结底，是效率问题。我会为我浪费掉得时间觉得愧疚，因为，那本来是属于我的青春。
网友评论