创业公司前期遇到的问题

凡夫俗子

今年的8月31日，我在凤凰网办完了离职手续，第二天就开始跟随原来的头头在一家创业公司里正式工作。新的公司是做红酒生意的电子商务网站，我负责整个网站的底层和中间层的技术，大部分是和具体的业务逻辑无关的，这也正符合我的兴趣。

放弃在大公司里无忧的工作、不算低的薪水来到创业公司，是出于多方面的考虑。其一是挖我过去的头头在我看来是个比较靠谱的牛人，无论是在技术上还是 管理上都有很多值得学习的地方；其二是觉得自己还没有经历过创业公司的前期阶段，如果最终成功了，作为初创团队成员，个人的回报应该也不会太少，如果最终 失败了，也是在自己年轻的时期，还有机会重来，而且期间还能发现不少的问题，这样当日后有机会参与创业时，无疑是一笔财富。

开始阶段，人员紧张

算上我在内，技术部门一共有三个人是从凤凰网被头头挖过来的。还有六个刚刚从培训学校里出来。大部分业务逻辑的代码都由那六个新人来完成，另外两个 有经验的程序员则负责一些管理工作，一个管前台，一个管后台。我呢？负责开发框架、底层基础设施，手下没有人，唯一的管理对象就是我自己，保证自己的开发 进度，不让其他人因为基础设施不完善而耽误工作进度。

六个刚刚毕业学员水平参差不齐，第一个大任务就是培训，包括如何使用SVN，如何使用开发框架，甚至有的连开发工具都不熟悉，对HTTP本身也是一 知半解。培训这些在工作中必须用到的技术大约花了一周多的时间。带着没有工作经验、水平又参差不齐的新人做事，能极大地考验管理者的水平。如何把工作细 分，落实到每个人的身上，如何保证代码质量，马上就成了一个摆在眼前的严峻的问题。所以在前期，每天晚上都要汇报工作进度，遇到的问题，并且还需要由我们 几个人负责审查代码，帮助他们养成好的编码习惯。这一期间，除了我以外，开发工作几乎没怎么进行。

前期基础平台的开发

负责基础平台开发的就只有我一个人，头头给我设计大体方案，之后的策略、技术细节等等他就不怎么管了。这样对我而言的一大好处是可发挥的地方比较 多，很多方案的选择自己都能做主。对我的一大挑战是，所有必需的基础平台都应该在其他人正式开始开发之前就准备好。时间少，任务多。

消息中心

我做的第一个项目是消息中心，负责传递、分发网站的各个子系统的通信消息。由于网站对消息响应的实时性没什么要求，所以我采用的方案是用传统的 MySQL实现消息的存储队列，用PHP程序定时查询，消息处理部分采用IoC模式将子系统接收到的不同的消息分给不同的子程序模块。

消息中心开发的一个败笔也是用了MySQL，原因是当时不知道Redis，更不知道Redis里已经有了blocking list，可以很优雅高效地实现消息队列。整个基于MySQL的消息中心只用了大约四天就可以使用了，之后立刻把精力投入到下一个项目中去。

主键服务

这个也是头头的想法，为不同的表提供不同的主键生成策略，实质上就是一种提供表主键的Web Service。由于需要挂接各种不同的主键生成算法，于是我很自然地用了《Head First设计模式》第一章里讲的“策略模式”。这个项目比较简单，很快就做完了。

凡夫俗子

简单工作流服务

这是我接手的最复杂的一部分。工作流的目的是把单据的各种审批流程串联起来，而且还需要做到灵活可变。涉及到和ERP的多个接口的对接。工作流服务 是在企业软件中很常见的部分，但由于我之前一直都是在互联网公司里，对企业开发近乎一无所知。头头用了好几天的时间帮我理清各个流程、各种概念，然后又做 了个前端展现的界面。我在此基础上实现数据的流转，挂接到ERP上。整个项目大约用了三周多的时间才搞出来。

工作流服务的有些代码相当复杂，属于难以维护的那种。我比较后悔当初没有用个好用的ORM工作，如果我很熟悉Doctrine的话，估计代码的复杂 度能降低不少，但限于时间，我也没有十足的把握说可以先学习Doctrine再着手工作流的开发，自己做个简单的ORM还要考虑各种特殊情况，时间上也没 把握，所以也只好用了比较笨重的方案硬着头皮做下去 。

邮件服务

邮件服务这个需求都后期才分给我。简单来说就是实现一个邮件发送队列。做这个的时候我已经比较了解Redis了，所以大胆地冒了一次险，用Redis来实现邮件外发队列。经验表明Redis在这里用得还算比较合适，连续平稳地运行了数个星期都没发生过问题。

BI数据报表服务

这也是个比较麻烦的项目，本来是想交给一个计划要来的写Java的来做的，可是因为各种原因，那人没来，所以很自然的这个项目又落到我的头上了（人员问题始终是个大问题）。更不幸的是，此时离内测期限已经不多。

这部分遇到的问题比较多，一大原因是需求、设计不是我能做主的，需要由产品设计部门出。而他们又需要市场运营部门的意见。绝大部分时间消耗在沟通上。最后给我的原型草稿在我看来还很繁琐，但也没别的办法，毕竟他们就是想这样设计的，我也不便太多的干涉。

此外，还有一些像日志存储、图片处理、条形码生成模块等底层设施也需要我来做。做了这么多的底层服务，最担心的是真正上线以后它们的稳定性。绝大多数业务逻辑都是跑在我写的这些底层平台上的，一旦我的程序出了严重的问题，事情就麻烦了……

内测前期，需求变更

有些事情，明明是需要在前期做的，却偏偏被推到了最后。业务部门的人也需要明白，真实世界的程序员们并不是像电影《社交网络》里演的一样能一晚上搞 出个Facebook来的。产品部门是需要和业务部门一起明确需求的，虽然作为程序员，应该有能力让自己的程序具有灵活可配置的特性，应该有能力想到日后 各种需求的变更、功能的扩展。但如果所有这些问题都需要程序员去考虑，为未来的各种可能的变化都做好准备，那么产品设计的人还有多少存在的意义？

目前网站即将上线，下一阶段的想法是逐步重写我之前的那些代码，甚至部分逻辑可能会使用其他的语言，用最合适的方法实现。只要保持接口不变，上层业务逻辑的代码就无需改动。我就可以在自己的小天地里做各种折腾了。

凡夫俗子

毕业五年决定你的一生