100天土鸡饲养计划（45）

今天继续做公司的工作，甚至书都没看~

下班前和总监聊了下关于项目的管理，因为现在建了很多的Service，其它们大多是定制的，重用性很差，而把原来三个项目的Service都放在一起，取名就是一件很难的事情，因为会有大量的重名，它们甚至传入的参数都相同，仅仅只返回值不太相同。

总监讲了一些，再结合我自己的思考，总结下就是：

一，重用分为业务的重用和技术上的重用，如果满足技术上的重用，那么就需要尽可能的将服务原子化，那么代码的重用性就能达到很高，但是这样会带来业务上和性能上的冗余，比如原本有3个功能，需要查询同一个表里，A,B字段，B,C字段,C,D字段，作为技术上的重用，那就会写一个方法把A,B,C,D4个字段都返回了，这样把3个功能变成一个功能，但是这样做，就会带来性能冗余，某些方法从业务上来，可能就真的只需要A,B字段，如果这个查询业务的使用频率非常高，那么查询多余字段带来的性能负担就会很重。

二，现在将三个项目的Service放在一起，是因为目前还看不出哪些业务是核心业务。这本来是架构师从开始就应该知晓和设计好的，因为某些原因，总监没有做好这些工作。通过聚合服务，可以看出来哪些微服务是被经常调用的，业务会经常跨库查询。经常调用的微服务，就可以写成核心业务，核心业务以业务为最重要，就会冗余一部分性能已符合绝大数的服务。而经常需要跨库查询的业务，就反应出，要么是业务不合理，有些数据并不是这个业务所必须得，那就砍掉。要么就是我们的数据库设计不合理，需要把这些字段冗余一部分到其他库，以免跨库查询，或者把整个表都移走。

三，到后期需把读操作和写操作区分开，我没有特别的理解到，浅浅的认识，或许是因为读操作，频度会比写操作高很多，那么写操作可以更偏向于技术重用，而读操作又分核心业务和非核心业务，非核心业务就可以随意操作，而核心业务又分是否高频操作，高频的，还是得定制化Service，确保性能，低频的可以做好业务重用。这部分还未想的特别明白。

四，这是我自己的思考，我认为，所有的框架结构，甚至说所有的技术都是为业务（现实）服务的，如果业务上确实有需要，那么就应该得到满足，当然，业务也不能想要什么就有什么，需要前期就做好需求分析。关于这个，我也有一些其他的想法，很多时候，有些功能是无法预见的，特别是和人打交道的，人是特别善变的，今天喜欢这个，明天可能就会喜欢其他的，所以再完成需求分析以后，开始开发以后，新的需求又会出现，市场上某一业务需求变得特别火，而原项目又没有，你必须要加，但这可能就伤害到原有的框架，这种情况我想，应该是100%会出现的吧。在这种情况下怎么办？难道还真的和业务死磕到底，不加？其实我觉得这种情况应该毫不迟疑，立即加入，代码又不是非要符合文档标准和框架结构才能运行。那这样的功能越来越多，框架就变得越来越脆弱，这样可以吗？只能说第一，这个框架设计的就不太好，不易扩展，架构师能力的高低大抵就体现在此。二是，没有任何一个框架是能适应所有的业务，并能无限扩展的。当这种特殊的情况越来越多，那么就是时候重构了，我想这才是业务和技术最大的矛盾点。不可否认，很多程序员，包括我自己，都不是工作狂，都希望做一些工作然后就休息一会儿，如果真像我刚才提出的，有合理需求就得满足，那不就得不停的工作，先不停的实现业务，等业务实现完了，又换新的框架，然后不停的重构，重构完又不停的写新业务...如此往返，听下就觉得很累，但放眼华为，BAT他们每天高强度，长时间，难道真的只是业务有那么多？QQ这两年更新的版本，几乎也就是加一两个不太重要的功能，但他的研发人员可是数量庞大！这么多人，能力还这么强，还工作这么久，估计不只是完成业务吧~当然，这都是我自己YY的，我总觉得，业务才是价值的最直接体现。

罗里吧嗦又写了一堆~