资讯中心

小型创业公司应该如何打造工程师文化?

来自:山东衡庐科技 发布时间:2017/3/3 11:08:51 浏览次数:
  随着互联网业务飞速发展,很多技术团队也在急剧扩充。但是人多了,整体的效能却未必能提升。如何磨合团队,让团队高效运转,更好地完成业务目标,这是摆在很多技术领导者面前的一大挑战。
随着互联网业务飞速发展,很多技术团队也在急剧扩充。但是人多了,整体的效能却未必能提升。如何磨合团队,让团队高效运转,更好地完成业务目标,这是摆在很多技术领导者面前的一大挑战。 
  付钱拉从项目初创时的5个人到现在80多人的团队;从日交易量几千笔,到现在每天平均处理订单量100w-200w笔,每个月处理支付交易流水在300亿左右;从系统仅仅处于能用阶段,到系统架构根据业务的不断发展迭代多个阶段……这些改变和进步都源自于技术团队的一次次努力和挑战。今天,我们就来讲一讲付钱拉技术团队的工程师文化
  一个团队的文化氛围往往决定了团队的作战方式,发展方向。工程师文化是每一个研发团队都想努力达到的方向,但是文化的积累是非常困难的。首先技术团队都得做业务,业务往往会占住很多时间,精力会分散,容易疲惫。其次一些技术使用或者开发的内容往往被封锁在一个小圈子里,想学习的人接触不到,即使进行技术分享,也不能深入底层,往往草草了事,看似提高的技术的氛围,其实因时间久了,慢慢也就麻木了,容易丧失技术的引力。
  我们会用很多的时间来开发业务,而业务也的确是我们工作的重点,完全不能抛开业务空谈技术进步,这种技术的意义其实就是纸上谈兵。最佳的方式是快速学习快速实践,允许试错,逐步优化。其实我们发现最好的点就是如何把业务和技术结合起来,通过技术降低业务的难度,从而提高学习的时间。分享技术,让代码和思想都能得到升华。
工具化,框架化
  团队内部会每天早上开站立会,除了每日说明下昨日和今日工作情况,另外还会讨论收集下目前工作中的难点和最耽误时间的工作部分。然后后面一部分工作的内容就是如何通过技术来简化这部分工作,通过团队讨论加自我驱动,不断思考如何创新,优化目前的业务,让开发变得更简单,让人员有更多的时间去深入技术底层。
  每天我们消耗很大的精力来线上查看日志,来确定生产的问题,当初程序还很简单,只是两台服务器做了负载均衡,查看日志还算简单,几个Linux命令一组合便可以轻松检索出日志,但是随着业务增长,服务器开始变多,项目也逐渐变成服务化,分布式化,请求不一定会分散的服务器变多,日志变多更难查找,排序等都是问题,我们现在迫不及待的需要一个日志工具,把日志各台机器上汇总到一台机器上,然后通过grep命令来查找我们想要的日志内容。
  但是问题随之而来就是通过grep会越来越复杂,比如日志所在的文件夹过多,日志又经过压缩导致命令执行起来效率并不是很高,而且对于大段大段的有上下文的日志,不能很好的展示,所以我们就是建立一个索引,这样方便我们用web展示,另外经过我们的优化结合业务场景,日志的展示效果也得到突破,基本原来查日志需要半个小时到1个小时的时间,现在基本1分钟搞定。
  另外基于这套日志系统,围绕日志内容,我们开辟出了报警系统统计系统。日志系统研发过程中,需要学习和研究很多的技术细节,并持续优化和改进,现在发现我们的同步日志有时候会出现不稳定的情况,索引创建的也越来越大,需要将日志计划向比较成熟的ELK上靠拢,研究其长处,并结合我们的系统持续发挥日志系统的特长。
  开发中会使用很多成熟的开源项目,我们会结合业务使用场景对其进行扩展优化,让框架适应我们,而不是我们去适应框架。针对一些比较复杂的业务也会自己开发框架,以便简化了业务开发流程。
  日志中记录业务ID,是个很普通到不能再普通的需求,但是业务需要在所有日志每一行记录一下业务ID,甚至异常堆栈的每一行都有业务ID,我们扩展了Logback,以便开发人员根本不在意打印的日志内容是不是带换行符,都可以在每一行的行首自动加入业务ID。针对一些流程模块比较复用的业务,我们开发了模块自动组合调度框架,可以将原本需要在业务中写死的调度关系,抽象到XML中,通过在XML中简单配置,就可以实现节点功能的组合,并提供循环,条件判断等简单逻辑。
  这其中很多想法,都是团队成员在业务开发中逐步提出的,并充分利用工作间隙开发出来,目前看来这些工作反而提高工作效率,也降低了工作强度。
适时的重构
  一个项目运行久了,经过业务需求的迭代,经过很多名开发人员的变更,总会产生一些让人不太满意的代码,要么来源于对某些业务理解的不太深,要么来源于对一些紧急变更的后遗症,我们在团队内部总是强调,尽量避免凑活,追求性能极致,追求简单美,往往遇到这种情况,我们会适时的引入重构,避免破窗效应,让一个项目越来越杂乱。
  重构其实不仅可以重新梳理下我们的业务场景,梳理我们代码的逻辑,让其更贴合业务,更重要的是可以让开发人员有机会再次设计我们的系统,结合一些更好的开源项目和技术,提升团队的技术氛围。
  每一次重构其实对于一个项目来说都是无比艰难的决定,上有新业务的需求,下有重构的使命,时间紧迫,希望得到很好的效果,压力都会比较大。但是就是这种环境很容易锻炼人,使人飞速成长,通力合作,团队也会得到很好的磨练。
  1. 首先我们考虑先要梳理项目的痛点,重构其实更重要是解决现在的实际问题
  日志混乱:记录的自定义格式千奇百怪,关键入参和返回结果打印不全,生产运维困难,不能很快的找到一个业务流程,需要在上下文中筛选。
  缺少数据字典:导致每个名词的定义各有不同,但字面意思相近,变量千奇百怪,不方便维护。
  新业务添加复杂:相近的业务代码,没有抽象,导致新增要通过复制粘贴,然后调整差异的地方,导致开发工作量大,bug频出。
  工具类多:每个人都各自添加各自的,其他人不知如何使用。
  废弃代码多:废弃代码不知道是否有用,方法写了,看不到引用的地方,不想删也不敢删。
  代码由于业务的不断改进,逻辑已经不再那么清晰。
  2. 提出更高要求,例如提高项目承载能力,应对更大业务需求。
  制定明确的开发规则,例如同层之间不允许互相调用,日志的打印细则。
  明确接口,SQL的含义,避免模棱两可的情况出现,更能精确的优化。
  频繁请求的热数据考虑加入缓存及更新机制。
  合理的优化框架,让业务代码更加纯粹。
  根据上面的总结汇总设计重构方案,并制定开发计划,白天开发,晚上review代码,总结调整方案。引入新的技术和新的理念。新技术对于程序员来说是有很大吸引力的,化被动学习为主动学习,技术气氛浓厚。新的理念的引入,化解了很多旧有问题,改变了旧有开发方式,让业务代码更简单。最重要的代码再次回到开发人员的掌控中。
强化的技术氛围
  其实前面介绍的工具化,框架化和实时重构,本质上其实是简化了我们的运维成本,同时也提高了大家对技术的钻研兴趣,用学习的技术解决实际的生产问题。另外还有挺重要一点就是平时工作中多鼓励大家钻研技术,鼓励刨根问题,鼓励知识共享。鼓励思维创新,鼓励组建技术小组,攻克技术难点。开展黑客马拉松,强调竞争,合理奖赏。另外在工作之外,会组织一些游戏竞赛,一来放松心情缓解疲劳,一来团队合作增加彼此了解。
 
总结与反思
  其实工程师文化就是一种放松的,自我驱动的技术文化,在这种文化下,通过成员的自我创新,通过技术手段,降低工作强度,优化业务数据,将技术与生产的需要相结合,并做到极致,从而使人在这个环境中得到飞速成长,团队也飞速进步。工具化,框架化强调DRY原则,避免重复,提高工作效率。实时重构避免代码质量恶化,重新设计提升代码品质。技术氛围创造来良好的环境,促进工程师文化持久留存,人人受益,团队才会受益。
 
作者介绍
  周恒,付钱拉高级架构师,曾在东南融通,宜搜任职,负责高并发框架,推荐系统的研发和项目管理工作,多年金融行业和互联网实战经验,擅长于后端技术,专注于互联网高并发高响应系统的设计。
售前咨询售后服务技术支持