• 博客访问: 586369
  • 博文数量: 65
  • 博客积分: 2315
  • 博客等级: 大尉
  • 技术积分: 2560
  • 用 户 组: 普通用户
  • 注册时间: 2011-11-22 18:00
文章分类

全部博文(65)

文章存档

2015年(3)

2014年(3)

2013年(9)

2012年(27)

2011年(23)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: IT职场

入职半年后的2013年6月份左右,淘宝浏览器团队和搜索团队被剥离出阿里巴巴集团,成为阿里巴巴与UC优视所成立合资公司——广州神马移动信息技术有限公司——的主体。在合资公司正式成立之前,主管在一次与我的面谈中告知“我们得成为一家小公司的一部分,且可能要重新基于Chromium的最新内核开发新的浏览器”(注:“新的浏览器”正是指现在的“UC浏览器电脑版”)。当听到这一消息时我非常高兴,因为看到这是一个难得的团队重新审视过去和甩掉历史包袱的契机。在这次面谈中,我回应主管“看来我得好好发挥一下”。也从这次谈话开始,我非官方地成为了开发团队的软件架构师。之所以说是“非官方”,因为我只是在内心任命自己成为了团队的软件架构师。

 

改变整个开发团队各种乱相的第一步是让工作有章可循,即制定开发活动的各方面规范。我在入职之初曾发起过《软件开发指南》(后面简称“《指南》”)的编写,初衷是试图通过工作规范化去改善团队的工作质量与效率,而此时要做的是全方位地充实其中的内容。

 

规范首先要立足于技术角度,指导团队解决在开发活动中因不遵守Chromium架构而导致的各种混乱问题。在之前的淘宝浏览器时代,团队对所扩展功能的代码采用集中组织的方式(如下图左边所示例的那样)。然而,这种组织方式存在两大弊病:一,表面上工程师无需完全掌握Chromium的架构就能开展工作,但也正因如此导致模块间存在混乱的依赖和耦合关系;二,由于没有清晰的架构,工程师增加文件和目录时完全没有指导思想,这进一步助长了混乱。新规范要求将一个功能模块采用“打散”的方式组织(如下图右边所示的那样),而“打散”到什么程度完全以Chromium的架构为参照,即要求扩展功能的代码与Chromium的架构完全吻合。尽管这一改变看似很小,但却迫使工程师在日常工作中得先理解Chromium的架构,所带来的积极影响却极其深远,因为它能彻底杜绝大模块的混乱问题!团队中的小盘同学有一次对我说“现在(按照规范)增加文件和目录很是轻松”,而这一工作之前很是让人纠结,那时大家能感受到别扭但却不知如何解决。

规范还得从技术层面解决自有代码与原生代码的解耦问题。由于我们的产品是对Chromium开源项目的二次开发,需要通过良好的软件设计解耦使得能快速跟进其发展步伐,以解决团队长期遭受的内核升级之痛。在淘宝浏览器时代,由于没有明确的规范,以及检查规范实施是否到位的手段,使得自有代码与Chromium原生代码难以明显区分,导致在每次内核升级时得花大量的时间进行代码合并,甚至对不少代码进行重放。新规范要求在Chromium原生代码中所变更的每一处都采用宏加以控制,其所达到的效果是我们只在Chromium的原生代码之上做加法。另外,宏在下次内核升级活动中起到了“灯塔”的作用(这是团队的雷翼同学做过3个内核版本升级后的切身体会)。新规范还从软件设计层面多方位指导如何实现解耦。

 

显然,《指南》中不可能规范开发活动中的每一处细节,这就需要整个开发团队有更为明确但抽象的开发策略以指导大家对所面临的未加规范的内容进行决策。为此,我在《指南》中明确“以快速跟进Chromium内核的发展”作为整个开发团队的开发策略。从用户层面,这一策略使得他们能更早用上安全漏洞更少、性能更好的产品;从开发团队层面,这使得我们能通过快速跟进的方式,将内核升级的工作以小步快跑的形式推进。这一策略的制定同样在将来产生了深远的影响,它甚至引发了开发团队与其他团队的一些思路碰撞,这是我们后续篇章要涉及的内容。

 

除了规范层面,在进入UC浏览器时代之初,团队在技术层面也积极储备。雷翼与小盘同学完成了git的部署并引导整个团队从SVN转向git;雷翼同学完成了buildbot的部署,buildbot使得我们能快速定位开发过程中引入的问题和及时发现对Chromium原生代码变更不符解耦规范的内容;小盘同学则开始着力于更深层次的性能优化;另外几位同学与我一道将淘宝浏览器的一些模块搬到了新的Chromium内核上,并对代码结构根据《指南》的要求进行了优化。

 

即便开发团队那时为UC浏览器电脑版的开发准备工作开展得如火如荼,但管理层对后续开发究竟基于淘宝浏览器还是最新的Chromium内核实施仍犹豫不决。基于淘宝浏览器开发的好处是项目时间更可控,但整个团队得背负之前的很多历史包袱,且很难借助这次开发新浏览器的机会卸去这些包袱;基于Chromium全新内核开发虽需要更多的开发时间,但这也是整个团队重新塑造自己的一次大好机会,只是当时管理层对团队能否抓住这次机会重塑并没有十足的信心。在最后一次开发团队内部开会讨论最终的实施方案时,好几位同学与我一道力荐基于最新的Chromium内核实施,为了说服大家采纳这一方案我以“这次不同,因为有我在”这句话想给团队带去更足的信心,而不少同学报以掌声表达了自己的意愿。

 

也就这样,整个开发团队酝酿好了抓住这次机会重塑自己!

 

至此,相信读者所看到的更多是技术因素,而没有管理因素的影子(读者会在将来的篇章中看到,请保持耐心)。对于中国的技术团队来说,我坚信促使整个团队改善的首要驱动力一定来自技术领域,只有采用以技术领域为切入点逐步渗透到管理领域的方式,才更有可能让团队发生质的变化。原因在于,不少工程师天然地将技术与管理做了明显的割裂,这些人关注的焦点在于掌握更广、更深的技术,对于管理能力并不大在意,且对自我管理能力很是不以为然。然而,真正专业的工程师也好、管理者也罢,很重要的一点却是他需要具备良好的自我管理能力。自我管理能力的普遍缺失,很好地解释了中国的技术团队为什么难以高效运作,也从某种程度上解释了不少工程师单干可以但合作却不行。

 

相信读者在自己所呆过的团队见过各种技术规范,但大多情形下这些规范被束之高阁。与之相似地,UC浏览器电脑版技术团队在技术规范的真正落地方面也经历了一定的过程,这是后一篇文章我们将一同回顾的内容。


作者微博:
@至简李云

阅读(2937) | 评论(1) | 转发(2) |
给主人留下些什么吧!~~

lyhabc2015-03-06 13:13:34

真的是相当深刻

评论热议
请登录后评论。

登录 注册