- 当时 tags:
- work published: true comments: true
最近有机会带着两个弟兄做一个老产品的技术改造。起因是测试发现产品的并发性很差，反馈回开发部门作下一个版本的改进。一查代码发现在网络通信时，原本异步的NIO，发送线程居然被强行加了wait同步等待远程返回。线程不能被释放，前端的请求被排队，吞吐量根本上不去。
这是root cause，其实进了代码里面的问题更多。于是产生了对这种feature driven development的怀疑。我曾经觉得列出 feature，做好代价估计，然后大家各自去实现的方式很理性很可控。如果宏观地看，黑盒地看，这种方式对项目管理很友好。但是最近看这种方式下开发出来的产品，问题还是很多的。当开发人员面对一个feature却缺少对产品整体架构的足够了解，他很容易倾向于用quick and dirty的方式\打补丁的方式解决问题，而忽略新feature对架构整体的挑战。长期下来，软件的功能不断演进，架构却停留在早期，维护成本越来越高，神秘的陷阱越来越多。这时，每次发布都要通过测试部门的蛮力测试，这个过程中除了修bug还要克服无数的invalid的bug。What the hell!!!
另一方面，从开发人员的角度，我认为Don't repeat yourself是每个程序员必须牢记在心的编程行为准则。无论技术好坏，经验是否丰富，只要坚持这个原则，程序员总会趋向于做一些抽象做一些设计，我想是不会写出太让人发指的代码的。最近查看遗留代码，里面实在是太多copy/paste了。对新增的功能，甚至通过重载加copy/paste来实现。如果不能怀疑同事能力的话，只好认为这是工作态度问题了。管理者往往是不会看到这么细节的问题（其实是严重的问题）。
面对这样的系统，我最初的想法是通通推倒然后模块化。虽然考虑了工作量，可是尝试了一周还是发现老的基础根本无法剥离开，多年前的设计者根本就没有考虑模块化/解耦合的问题。有句话说得好: if you cannot split it, you cannot scale it. （对数据显而易见，对程序其实也一样）然而放弃这么大规模的久经考验的代码又不现实。这周开始又只好改变策略小步快跑，虽然不治本，但是就这个阶段来说，看到改造的效果对我们这个小组意义更大。这是在内心的洁癖和现实的局面间做的不难的取舍。
尽管困难重重，还是争取抓住这个机会能对自己有个提升。需要驱动弟兄们接受和实现自己的想法，和自个一个人闷头干是完全不同的。