最近相当一段时间里抱着玩耍的心态在互联网创业公司晃悠。现如今互联网创业环境浮躁，没有BAT光环，基本也就是打个下手，写点业务逻辑。
相比原先为整个系统和团队负责，做点业务功能倒是没啥压力。我也乐得轻松愉悦。
技术总监之类的坑还是让那些闪着金光冒着烟的前BAT员工来吧~
毕竟，用他们的话说，“外企不怎么忙，技术能好吗？”。我还是决定低调点。好在薪资不低。$.$
我是一个喜欢说故事的人，在技术领域天天都有有趣的故事可说。可惜就是比较懒，懒得码字记录它们。
今天的故事实在是有些意思。
这个公司的技术总监来自BAT，简历可以说相当完美。原平台架构部门就职，如今加入创业，理所当然地担起了整个公司的技术领导的担子。
这公司产品能力很强，产品上市不到一年，市场占有率很快已经让行业巨头感受到它的存在感。
由于业务飞速发展，代码逻辑倒也不成为瓶颈。本身的技术团队说不上个个实力拔群，至少算是激情洋溢，产能惊人。看着SVN的提交记录，有时候我都忍不住惊叹一个人一天能折腾出来那么大一坨代码。
业务针对中国若干大市场有着不同的规则。比如华东市场和华北市场有些业务计算的策略中的参数有些不同，又或者西部市场有一些额外的策略。总体就是一个数据策略计算引擎。
在刚开始的时候公司专注于被誉为创业必争之地的东北三省，毕竟得三北者诸侯。随着公司的成功，慢慢的开始兼顾其他的地区。业务策略模块的实现逻辑也越来越臃肿，加上了许多基于条件判断不同地区的不同应对方式。在此过程中迅速扩张的团队也开始面临一些问题。
比如，负责东北市场的同学改了东北市场的业务逻辑，却常常一不小心会弄坏华北市场的策略模型。
而公司服务器的发布流程也因为是初创公司的关系，“并没有时间和精力纠结那些复杂的流程，那会拖慢我们的速度”。因此常常是某个开发写完某个功能，自己完成测试，编译一个版本就往服务器上放。所有的开发者也被告诫任何时候提交的代码都有可能上线，因此没有完成的功能的半成品必须由配置控制这些半成品逻辑不会真正开始工作。
但事实往往不尽如人意。只有三五个人的时候，不出岔子是因为大家足够仔细。公司的开发团队慢慢的变成了20个人以上，发布版本不出问题简直成了一种运气。再加上技术团队“为了避免代码merge，所有人必须频繁提交代码，每半天提交一次，出现conflict的情况，必须重新拿一个干净的代码重做自己的逻辑，这样最多也就是浪费半天的工作量而已”。 显然似乎这个BAT的大拿并不知道SVN的merge功能其实相当完善，同文件支持同步开发。
我也曾小心翼翼地问过不少人及为什么不用多态和IOC来隔离不同市场的参数也策略模块，用接口抽象系统，得到的答复基本如出一辙：我们是创业公司，我们必须快，没时间搞那个。
频繁的提交代码加上把所有逻辑放在一个方法里，导致服务频频出错。天天一肚子火训斥开发人员的总监觉得应该对此做点什么。
于是他决定把西部和华南战场对现有逻辑进行解耦。这个解耦的方法就是拷贝一份工程代码到另一个开发目录下进行西部战场的开发，再如法炮制一份华南战场的代码。
这带来的效果是立竿见影的。西部市场和华南市场的逻辑独立，不会影响现有服务。找几个程序员分别负责其中一块，各自开发各自的，谁除了问题就是谁的责任，简单明了。
但慢慢的，也是必然的，一些新的问题出现了。最初的东北市场的版本主程对系统做了一系列的调整和优化，其中相当一部分对全国市场都有意义。而其他的两份代码拷贝里却没有相关的特性。简单的代码合并已经变得很难，因为三份拷贝的代码各自又有了一些变化，导致乍看相同细思极恐。
没办法，机械的合并代码已经不可行，只好大家都把东北战场的所有优化逻辑在自己的版本上重新做一次。由于三个版本结构在开发演变中发生了一些变化，其中的一部分变得麻烦重重。
而最头疼的部分在于ｓｖｎ的提交记录并非以feature为单位，主程一天提交20次代码，其中的细节改动和细碎逻辑难以琢磨，有一些乃至连他本人也想不起来前后的联系。整个团队开始无休止的加班，测试，修复问题。而部署和测试又会消耗掉大量的时间和精力。所有部署都人工进行，开发人员对部署上线的版本做测试，对比三个版本之间的细枝末节的差别，测试中的细节遗漏在所难免地侧漏能灌满一个西湖。
开发团队还是那么激情洋溢，人们还是充满笑容。因为业务在扩张，因为我们在加班，因为大家都那么忙。
谁谁谁说过，创业公司，不忙是没前途的。不是吗？