重写的理由

    系统运行一段时间后，总会找到重写的理由，理由大致如下：

1. 有更新更强大的技术出现；
2. 代码质量控制不好或原有设计有缺陷，出现了很多坏味道；
3. 原有开发人员流失，新旧交接不好或新人不喜欢维护他人代码(又有几人愿意维护他人代码呢？)；
4. 政治原因；

    但真的必须重写吗？原有系统真的就那么不堪吗？

 

    话说3年前，还在上家公司，由于公司的不景气，很多同事离职了，服务器端的大部分代码落到了我的手里，当时刚刚被play framework和scala折服，男人的本性总是喜新厌旧的，于是，利用业余时间，用play 1.2 和scala重写了公司的核心业务模块。

    开始只是为了理清原有系统的积累了好几年的逻辑，经过两个月的废寝忘食，终于几乎重写了原有系统，代码量减少到1/10，逻辑更加清晰，架构更加合理。

    于是向外行CTO汇报了该工程的存在，CTO觉得这是自己的英明领导的伟大体现，竟然力挺该工程，测试后，出现了不少兼容性问题，坏就坏在“几乎”两个字上，程序可是爱憎分明，毫不将就的。还好我对原有系统比较熟悉(已接触该项目两年)，经过差不多1个月的测试、debug，成功上线。

 

    虽然成功的重写了系统，但其中的辛酸，劳累，其中的风险，还是让人后怕的。这次成功，纯属侥幸，主要是因为：

1. 业务简单，且我对整个系统比较了解；
2. 代码量不大；
3. 时间比较充裕；

所以一切还在可控范围之内，下边的故事，就是彻头彻尾的悲剧了。

 

    因为外行CTO被人发现只是滥竽充数后，新CTO的空降便顺理成章了，所谓一朝天子一朝臣，新CEO重金挖了许多高人，不乏新浪等大公司的墙角；可他们的问题是：对业务不了解；高人自由办法，CTO和新浪sir商量后，决定用PHP在一个月内重写系统，理由如下：

1. 创业公司都用LAMP；
2. 新浪就用LAMP；

    于是，我的工作变成了每天宣讲业务，不，是口述业务，然后由专人用叫做PHP的文法书写出来......

    新系统毫无架构可言，毫无模块可言，毫无设计可言，或许所谓高人，便是无招胜有招吧。

    后果可想而知，代码量翻了20倍不止，高人果然适合做大工程，只是迟迟无法上线，据说到现在，该系统也没有上线成功。

 

    这两天本想重写现在的某个系统，回想下这段往事，觉得还是重构比较合适，毕竟没到系统无法承受的地步，如twitter。

    冲动是魔鬼，重写需谨慎！