新组小记

从原来的组过来这边,原来已经快四个月了。单纯从同事相处来说,相比以前,好像总少了点什么,闷而不骚,是我之前对这里的评价,但我错了。

这四个月,做了两个比较大的项目,其中包括重构和一个目前未开放的新功能,单纯从技术上来说并不没有涉及到很多复杂的东西,但总是有学习到东西的,接触到整个IM后台构架的设计,通用服务器框架的设计等等。

刚开始过来更多的是阅读别人写的服务器框架代码,有多线程同步的,也有单线程异步的,目前这边从业务考虑上更多的是用单线程异步的代码,实际上这比同步的代码难写得多;甚至还花时间过了libevent处理消息的整个流程,收获不少。

收获的同时也会发现自己的一些缺点,细细想来,有两点需要改进。

要重视前期设计

我刚来到这个组时,刚好遇上重构。我当时承担的是业务逻辑服务器的开发,这部分相对比较杂,又同时跟七八个服务器打交互,所用的开发框架又是纯异步的,再加上刚开始对业务逻辑还不熟悉,所以那时候比较纠结。

实际上纠结的并不是如何去实现,而是这么多流程如何实现才能使冗余更少。可惜的是刚开始设计时没能考虑到所有的情况,当然选择的设计很简单,每一个业务流程都为单独的一个类,基类抽出共同数据和共同操作,并且抽象出一个接口让每个子类实现状态机。刚开始就犯了两个错误了,基类抽出的共同数据实际上是通过proctected开放给子类的,因为基类跟子类都会直接操作到这部分数据,实际上这时候封装性就已经被破坏了,后来我改动基类里面的数据成员都异常困难,因为一变动要改的地方太多了,所有的子类都需要改动,这涉及到几十个流程,也就意味着有几十个子类需要变动;前期设计也没有考虑很多,一边写代码一边将共同的逻辑抽出来做为基类的一个函数,甚至后期出现了重复实际同样功能的函数,当然,名字不一样。

前期设计考虑的不足还导致后来加入监控代码、统计代码和请求队列限制等相当困难,这部分更多的是因为由于后端的连接类对象没有用一个共同的代理来管理,导致加入这部分甚是麻烦。就拿请求队列限制来说,这需要在每次发送请求之前都进行判断,如果队列里面未处理完的请求数超过这个限制就不再发送请求并返回23给客户端。由于发送请求的逻辑代码到处都是,这就意味着必须找出每一处引用到发送请求的代码并在前面加入限制判断。如果之前就考虑到之个用连接代理来管理的话,这个改动就很少了,只需要在连接代理里面做判断即可,别的引用到的全部不需要变动。

以前上设计模式课时没有什么觉悟,因为就写着几百行的代码,后续基本上不维护,这时候硬套个设计模式进去基本上没啥意思,因此很多理解根本就不深。但是当自己的代码量成千上万行,且需要大量的后期维护跟功能增强时,有些东西才会慢慢理解得透彻。有些东西真的要自己走下弯路才能明白其中的奥妙所在。

加强沟通能力

这次的新功能需求,实现上功能实现并不复杂,基本上两天左右就完成功能代码。但是却在需求细节变动上耗费了三四天的时间,且相关的逻辑代码一直在变来变去,上午是这样,下午要改成那样,第二天又要再改回来。

归根到底,一个原因是产品那边细节考虑不足,看到这个点不足就改这个点,导致没有一个平衡点;一个原因是自己在修改细节时没有考虑更多并及时跟产品沟通反馈,甚至到后期明知改动只是剪这里的布去补那里的洞而已,却懒得再去跟产品沟通,因为前期跟产品沟通没有让他明白自己的想到的问题,导致他坚持自己的想法从而后期又有变动。

总结

以前总是不懈于花太多时间在前期设计上,写代码随意性很大,总是只着重要实现的技术细节,这次也算是吃到恶果了。现在自己的模块代码有时候看着就是阵阵蛋疼,总想着花时间重构一下。刚好这些天开始有空,对比着以前的需求变动做了进一步的设计,国庆假期也将近了,刚好可以利用这段时间重写一遍。

如何让别人明白自己想说的话,确实不容易。虽然别人有时候没有留意听或者听不明白自己的想法会让自己很不爽,但是不爽归不爽,如果不沟通明白,后期自己会更加不爽。

同时意识到粗心也是自己的一个硬伤,考虑问题没有更多地考虑细节,这很多时候是很致命的。像自己提测时总会等到提测后才发现还有某些问题之前改重都是没有替进提测包的,导致自己和测试人员增加了额外工作,这是非常不好的。

 

标签: ,
文章分类 生活

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*