很多时候我开发过程中老纠结,总觉得很多地方可以做的更好,但是却没有办法去改变什么,有时是没时间,有时是知道问题但是想不到很好的解决思路,有时是多种想法,也知道优劣,但是权衡评估不出哪一种好。

每一次尝试新的方式的时候,这种感觉尤其的强烈,刚开始使用一种新玩意儿的时候,用的特别矬,过段时间来看就是shi一样,但是有时候看到之前的一些无意的做法,又觉得很赞,相同的是都不记得当时的想法了,所以我觉得整理每天一个总结是有必要的,能够看到自己想法的一个变化。

目前,我正在对公司新项目的公共模块进行开发设计,公司没有产品部门,所以很多需求都是领导层敲脑袋想的,然后由人整理一下就开始开发,所以到现在我感觉我们leader对项目还是没有完全理解,不知道这个项目最终实现是一个什么样的产品,定位是什么...

不吐槽了,切入正题,做到今天我发现我做的公共模块其实可以分的更细,而且分的更细,灵活性就更高了,也变得明朗很多了。比如说现在正在做点赞系统、评论系统、关注系统等,这些系统都有一个共性,就是它们往往不是独立呈现的,都是伴随着其他主体内容的呈现而附属着呈现的,所以我称它为伴生系统类型。

多数伴生系统,都有着累计数,因为这些伴生系统都是独立的,不在乎使用方是什么,只要传入对应格式的数据即可,那么累计数应该给谁记录呢?我选择了把累计值的记录放在了伴生系统自己这儿,这是我最初的想法。这种做法对于单个记录的累计值查询肯定没问题,但是对于列表呢?而且多种伴生系统都有统计,一个个查?显然这是病态的,所以现在我又把累计值抽离出来了,做了一个专做累计的模块,既然伴生系统有这么一个共性,而且还惹到开发的我很不爽,那就好了,抽离出来单独对付。

总结

当做一个项目模块化的时候,最开始是从业务上分割,然后是功能性的分割,最后就是提取公因数式的分割了。但有时也不能分的太细,这个度的把握还需要自己判断。