从某维护系统的架构改造谈起–公用代码库(旧)

| Comments

这是刚到公司时写的~

有时候真是不看不知道,这样一个每月数亿业务量,数十亿营收的大型系统,原来也就是这样的质量。 我们可以想象这种系统一开始都是美好的,只是渐渐的变味了。就拿我们这边java的来说,原来也应该是有公用代码库的,只是那么久每人去维护,项目赶工, 自立山寨的情况多了,这些东西的反向价值就越来越明显了。典型的表现有:

  • 自立门户的现象很突出,经常可以找到n个方法是做同样事情的;
  • 神级的类很多,例如某个类可以提供字符串,时间,web,业务相关的操作;
  • 公用类代码质量良莠不齐,有很多明显写得不好的地方(曾经有个数千行的类就给我砍倒1/3代码);
  • 缺乏公用库的document和quickstart

这样造成浪费,花了很多冤枉时间去实现已有功能,缺乏统一规划。大家都有体会,维护一个杂乱无章的系统是多么的困难, 在这种系统想写出漂亮的代码是很考水平的。现在代码库又特别庞大,怪不得很多同事慢慢地就给系统同化了, 缺乏持续改进的动力。在上次retro会议的时候,针对缺乏统一的公用代码库的问题,针对质量和维护的问题,我提了一些做法:

公共代码库迁移

  1. 方向是在保留现有逻辑的基础上,针对新添加的功能和修改的功能,逐渐迁移到新的公用库。
  2. 至于公用库的选材,主要是从各大现有公用库进行提炼,对神级类进行拆分,并结合开发人员提需求的做法,形成我们的公用库。
  3. 为了避免山寨的出现,培训和文档是必须有的。
  4. 针对如何让程序员接受并找到新公用库的问题,建立新的source目录,并在文档上通过目录-包结构-类的层次做好文档(javadoc)。
  5. 除了必要的培训之外,主要的审查方式还是通过每天的code diff和定期的code review来做到大家对公用库的认同和理解。
  6. 维护是要靠大家去推动的,就像上面说的,由程序员反馈需求或提供补丁的方式,保证公用库的持续改进。

现在工作进展还算顺利,过段时间再看看效果怎样,或许咨询一下顾问看看有没有改进的地方。

Comments