用TDD保持企业管理软件快速迭代


      36kr上近期有篇文章说到 ---- 对许多创业公司来说,最大的压力就是“迭代太慢”。的确!创业型的公司不论是资金、规模都很难与大企业竞争,唯有创新、并快速成长保持领先。这其中最重要的就是产品的快速迭代能力。

      我们做的OurATSSaaS招聘管理系统,属于企业管理软件。2B软件本身产品结构复杂,HR类软件对权限等管理要求非常苛刻,相对一般企业管理软件就更复杂。通常企业管理产品开发1-2年后就会遇到共同的几个难题:

      1.       如何让团队的每个工程师充分理解软件的设计需求,保证代码正确和严谨,避免Bug的产生。

      2.       如何在工程师人员流动时,保证后继的工程师能读懂前面工程师的代码

      3.       出现Bug时,怎么找到Bug

      现有的解决办法基本上是一面让软件设计者编写尽可能详细的设计文档,用一套庞大而复杂的版本管理体系;一面建立和开发团队规模相当的测试团队,不断为软件体检。

      现实是:

     1.       设计师和程序员都淹没在一版又一版的技术文档之中(设计文档本身中有没bug都很难说),几乎一半时间都耗费在这些上面。

     2.       让工程师理解复杂的招聘业务各种场景实在是难为他们了。

     3.       在代码改动时,难以保证不会影响软件其他部分的逻辑(要知道程序员多数只熟悉自己负责的那1%的部分,仅仅了解一下其他99%的代码是怎么回事都可能是“mission impossible”

     4.       读别人的代码已经很痛,要找别人代码中的Bug,估计上吊的心都有了。

     5.       测试人员通常只测最主要的功能

      于是,一个又一个bug潜伏下来,不知道哪一天就会出来作祟,系统越大、Bug越多、越难找,一个一个补丁程序就像头痛医头、脚痛医脚一样治标不治本。随着时间的推移,系统就像一个千疮百孔的老人,稍碰一下就可能崩溃。工程师大部分时间都在维护系统,而不是让系统变得更好。有时候甚至害怕对它进行改动,因为不知道是不是会产生一连串无法预知的问题。最终,快速迭代只是美好的愿望。

       云招科技2010年成立,开发OurATS招聘服务系统在2012年以前都是用传统的敏捷式方式,研发人员的流动,离开的工程师编写的代码中隐藏的问题逐渐暴露出来,新接手的工程师难以下手,修修改改就如无底洞,根本不知道改完一部分后面还有没有其他问题。

      当时团队中有人提出一个大胆的想法,可不可以试一试TDD开发模式。

      做过系统研发的朋友是知道的,这意味着在此期间,系统不能做任何升级。作为一个创业型的公司,几个月产品不升级意味着你可能就会落后,可能就是死亡。抵制的情绪还有另外一个原因,就是整个研发团队都没有经历过TDD的开发模式,不知道是否能够成功,而且虽然觉得需要几个月,但到底需要多长时间、会碰到什么问题,谁也不知道。但不做改变,我们就会在传统方式下慢慢陷入代码维护的泥潭,就像致命的慢性病,迟早要了我们的小命。

      公司面临着,改变意味走向一条通向光明之路,但随时倒在路上,所有的付出都付之东流;而不改变意味着一条难以自拔的不归路。

      一切争吵最后回归到“用代码说话”,我们的核心技术团队尝试用TDD做了最核心、最基础部分的验证,认为TDD是可行的。

     所有的讨论都结束,一切都归到我和我的创业合伙人如何决定了。

     20122月年我们并没有太多的犹豫,决定 ----“做”。

     我们和销售和客户服务团队沟通,做好现有客户和潜在的需求管理;研发团队开始着手代码的翻新。

     时间就像烤炉,焦灼者创业团队所有人的心。幸好所有的合伙人都非常坚定,而且系统体验过去一直都还不错,而且是2B的业务,所有老客户都保留下来了,在此期间我们还签了一些新客户。

     5个月后,改造完成了!!!

     这里只是简单的一句话,只有我和我的技术团队伙伴知道那是怎样的一段日子,此处略去一万字。

     在这段时间里,所有的研发人员和代码就如同练武功,易经洗髓一般,脱胎换骨。

     3年过去了,我们已经能非常自信而骄傲的说选择TDD的决定完全正确!!

     现在即使系统功能已比3年前丰富很多,我们做到:

     1.       保持平均5天升级一次(这可以企业管理级软件!同类的Taleo是半年升级一次)

     2.       每个研发人员提交自己的代码时都很自信,5*8的工作时间,没有加班(我们鼓励大家业余时间充分休息,自主学习、研究新东西,很多难题是工程师利用这些时间琢磨和解决掉的,TDD最初的论证也是工程师利用了不少业余时间完成的)

     3.       团队没有测试工程师(我们的成本都会转嫁给客户,用更少的人创造更多价值,最终让客户受惠)

     4.       没有技术文档(工程师不用写文档、看文档,想来心情会很好!)

     5.       人员流动也完全不用担心,新来的工程师只需专注完成自己的代码部分,是否与系统其他已有代码兼容、是否符合原有设计,只需用个十几秒跑一遍所有测试程序就好了,这样新人可以很快融入项目,为项目做出贡献

     6.       每年发现的Bug仅有10个左右,查找和解决根本不算什么

     7.       每次升级上线都非常轻松,不用担心上线第二天会有一群用户来投诉

      同时由于TDD改造后的基础,我们还完成了产品系列化,即将一套代码中的部分功能组成功能强度多个级别的产品。Salesforces正因为做到这一点,它的客户可以根据自身规模、需求和价格承受能力选择合适的产品阶梯,各产品阶梯可以无缝升级到更高级的版本。

      TDD改造的好处还有很多,不一一描述。

 

      如果你打算做的软件比较复杂,希望未来能保持快速迭代,建议从开始就采用TDD的模式,不要像我们走到中间再改,会耽误很多时间,市场不会允许每次都这么幸运!!


Recruiting is tough.  OurATS makes it easy.