一次疲惫,烦躁,坚持,些许失败的重构经验

这是在**王座项目中一次重构 经历

骑宠翅三个系统的合并 以及兼容以后培养系统动态配置  终于是告一段落 虽然还有一些小的问题  但是可以慢慢优化了 

然后从结果上看，我认为这次的重构是失败的

1.时间上的问题  延期太严重  将近2个月的开发时间(当然这其中  处理很多其他的问题以及系统 导致拖延)

2.架构上的问题  从结果来看  其实架构上有很多问题

分析一下原因:

时间的问题----------------

先列一下开发进度吧

冥想           2天左右

服务器架构 5天左右

客户端架构 3天左右

然后就是各种各种的bug 层出不穷  这是本次重构最麻烦 占用时间最长的地方

这个问题有几个方面的原因

1.这个在一开始分配的时候 其实就是一个很费时 而且难度上不简单的工作了

但是服务器和客户端的共同进行 由于服务器的代码这3个系统有两个是我自己写的 还有一个也算了解 但是客户端虽然了解 但是并不是很熟悉

导致客户端有些问题 还是花费了很长时间才解决的

2.中间插了很多任务 以及 不相关的bug

这导致我必须要停下手头的活  延期处理  

新的系统编写 还会导致新的bug  导致骑宠翅的重构 还要在之后 不停的 时不时的延期处理

其次，骑宠翅的关联系统很多  导致的问题是 拖延的时间越长 其他系统的改变 以及新系统与骑宠翅的关联都需要延后

再其次，项目正在上线阶段  这又导致了 很多骑宠翅或关联系统 必须要在外网 及时处理  从而  外网和内网 形成了完全不一样的版本

3.天花乱坠的bug

bug会很多 这我早就料到了  虽然现在看来bug的数量级 其实可以接受

但还是花费了不少时间

4.设计之初没有想到的问题

有一些设计之初并没有想到的问题. 比如 数据库兼容问题(一直认为是 删档测试  完全没有考虑 老用户的兼容)

在这次的设计中  还是有很多地方 边写边想  导致了架构扭曲 最后还是有糊弄的地方

总体来说 时间上 有客观的原因 也有一些主观的怠慢

---------------------------

架构问题------------------------------------

时间花费多不要紧 但是架构最终出来的结果 也不是很满意

当然 我架构的功底确实不好 这是一次锻炼 

1.重构开始的前两天 我基本一直在冥想 以及 没事画画UML

但当我开始实践的时候  照着UML开始写  才发现 基本都推翻了  然后便开始了 边写边想边验证

这是我 架构经验尚浅的体现   

2.实际架构上的问题

.a 为了实现 策划可以配表控制 系统

我就让我 所有功能都分离开来  函数 功能 都尽量的降低耦合 

这样可以很简单 通过表来控制很多东西

然而 分离开后  还是有一些地方 有耦合  导致我必须在一些地方穿插使用 各个功能

这样看起来  使很多功能显得 很异样

.b 接口的设计 并不好 

虽然我很刻意的 将我的代码的 可读性加强了 

但我在实际使用上  自己都有  为什么要这样写,好乱的 想法。

总体来说 架构经验不足 有待提升

---------------------------------------------

这次的 重构 其结果我觉得并不理想 如果要打分我觉得并不及格

但是 和设计初衷 虽然时间有些长 但是目标算是勉强合格吧

落幕: 一次疲惫,烦躁,坚持,些许失败的重构经验