项目微管理1 - 孤军
四代去FX入职的时候恰好是8月的最后一天，秋老虎正狰狞的向世人展示着她那锋利的獠牙。虽然明知是“兔子的尾巴-长不了了”，但是此时魔都炎热的天气还是深深的折磨了一把四代，来到公司的时候，四代的后背已经完全湿透了。
到了公司，四代刚好赶上技术部的全体会议。从会议上四代了解了技术部的构成，以及自己所处的团队：PC团队，组员只有一个，那就是他自己。
四代入职后的第一天就是在了解前年和去年的开发计划中度过的。最近几年，PC软件已经成了不折不扣的大忽悠，很多的功能都是年年计划年年晃点。如何在现有的状况下开始四代回来的第一个版本，还真是个麻烦的事，每个功能都是催了那么久，每个功能似乎都很重要，千头万绪，犹如一团乱麻，如何才能找到那个关键的线头呢？四代陷入了深深的沉思中。
在经过一番思考之后，四代还是两眼一抹黑。没有办法，四代只能从最基本的做起，那就是通读软件的核心代码，然后再思考如何开始。
在阅读代码的过程中，四代想起了会议上提到的因为性能原因，需要升级底层数据库的事，他突然眼前一亮，那可不就是苦苦寻找的线头吗？从升级底层数据库开始，再向上重构数据库访问技术，然后再向上更新上层的业务逻辑和界面，这不是很好的开始吗？这个作为软件接下来第一个版本的重点，不是非常合适吗？从更长远的角度来说，重构就是修改现有代码使其更合理，为以后做好新功能的开发提供技术上的准备。
说干就干！为了避免把已有的代码搞乱，四代迅速的配置好了源代码管理工具，从里面复制出一个专门的PC代码分支，然后在里面开始进行升级数据库的操作。事后想想，在后来大范围重构中，代码几近崩溃的时候，四代还能从容进行修改，心里想着大不了重新再来，这个另立分支做法还真的给四代提供了非常强大的底气。确实，不仅仅是代码重构，任何事情，有时候确实需要提供一个在失败后还能重来的机制。
升级数据库的版本看起来似乎比较简单，实际操作起来却非常繁琐，在这个过程中，需要进行大量的兼容测试，这几乎是覆盖了软件的所有功能。软件工程就是这样，每一个新版本的研发，都必须要考虑和老版本的功能和数据兼容。
一切似乎很顺利，不过很快四代就发现了一个严重的问题，那就是上层的数据访问技术已经过时了，必需也要在这一次进行相应的升级，不能像四代最初的打算那样，完成了底层数据库的升级以后再更新数据库访问技术。没有办法了，数据访问层也要随着数据库一起升级！也好，反正对比原计划，也就是下一步的重构目标稍微提前了一些，既然撞上了，那就一起搞定吧，狭路相逢勇者胜嘛！
一个月以后，数据库和底层的访问技术升级结束，效果还不错，新版本就是新版本，效率和并发性提高了不少。接下来就是上层对象了，上层对象要略微麻烦一点。
顶层的对象之间依赖太复杂了，而且估计一直也没想过要拆分，每次添加新的功能的时候，都是一直就往同一个工程中不断添加新对象，而这些对象的加入，又使得原本就相当复杂的对象关系变得越加复杂，简直称得上雪上加霜，恶性循环。这样的结果是这个核心的工程越来越大，每改动一行代码就要重新编译，升级的时候也得加入升级包中，导致升级包比正常大很多。
这样，拆掉这个超级大工程就是迫在眉睫的一个工作了，好在四代也不是第一次干这个事了。在OJ的时候，他就试过把一群依赖复杂的对象组成的网状结构重构成以一个事件对象为唯一中心的星状结构，这一次只不过涉及的对象比较多，范围比较广而已，四代步履轻快的倒了杯咖啡，开始了这次实际上一点都不简单的重构。
四代无论如何也没想到，这次的重构几乎折磨的他看到事件就想吐，大量的顶层对象和业务逻辑层对象相继涌入到这次操作中，随着修改的对象的不断增多，四代提交代码的压力越来越大。在长达几周的修改中，四代一度曾想中止剩下的重构，不过在考虑即将出现的扩展性的时候，四代还是咬了咬牙，坚持着完成了这次艰难的通信机制的升级。直到几个月以后，当另一位兄弟加入团队，需要在两个对象之间交互的时候，他说了一句：“师兄，这个事件系统这么好用，两个对象不用互相引用，只要通过这个事件系统，可以很方便的交互。”啊哈，是啊，只是这样一句话，四代觉得内心一下子充满了暖暖的感觉，那次艰难的重构是值得的。
当这些重构工作都结束以后，剩下来的事都比较简单了，就是发布新版本，升级用户机器上的软件了，虽然过程中也冒出了一些新问题，不过大多都顺利的解决了。
还是在这个版本的开发过程中，PC的招聘计划已经启动了，四代已经不间断的接触了许多的面试者，不过无一例外的是，这一阶段的面试者都折在了基础知识这一环，四代实在想不明白，到底是自己要求太高了，还是面试者的水平太低了，难道一直要这样，“所有的事都自己扛”，这可不是一名合格项目经理干的事哈，四代不禁摇了摇头，轻轻发出一声叹息，继续着手上的工作。
版权声明：本文为dxy1982原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。