【IT168 技术文章】

    很多团队都有tech lead这个角色的存在，但同时很多团队对这个角色都缺乏明确的定义。大多数时候，团队只是指派其中经验最丰富、技术最精熟的开发者来担当tech lead。但除了“tech”的成分之外，这个角色还有“lead”的成分，这就决定了他不仅需要技术上的能力，还要眼观六路耳听八方，才能带领团队──至少是开发者们──取得成功。

    Tech lead需要关注的事情可谓纷繁芜杂。把这些事情分门别类，我们可以看到，这个角色大致有三方面的职责：技术决策者、流程监督人、干扰过滤器。

    技术决策者

    从技术的角度，tech lead需要关注以下三个方面：架构设计、局部设计和关键技术点。

    参与架构设计

    系统的架构通常是在项目初期的quickstart阶段设计出来的。这个架构设计包含的都是高层面的内容，例如C/S或B/S的选择、开发平台、编程语言、数据迁移策略、集成点、部署结构等。

    尽管架构师（architect）是架构设计的主要负责人，tech lead还是会参与设计过程，以获得对系统全局的清晰了解，并且尽早发现架构设计中不合理或者风险较高的部分。

    主要关注点：

    选择什么平台和编程语言？

    需要和什么系统集成？需要使用哪些第三方软件或工具？

    给自己画一张集成架构图：先用虚线圈出为用户提供服务所需的整个系统范围，再用实线圈出将用主要编程工具（例如J2EE或者Ruby on Rails）开发的应用程序，两者之间的其他东西就是你需要集成的目标。找出集成点和集成方式。留住这张图并保持更新，你会经常用到它。

    如何部署？如何迁移现有数据？

    开发团队日常部署到什么环境？UAT（用户验收测试）和性能测试的环境由谁部署？生产环境由谁部署？部署的频度如何？开发和测试使用的数据集从何而来？数据迁移是部署过程的一部分吗？除了自动化部署脚本之外还需要什么额外的环节吗？

    团队的技能是否与项目需求匹配？

    攻克技术难题

    作为“tech”lead，解决技术上的难题、为团队扫清前进道路，自然是题中应有之义。由于具备对系统全局架构的了解，tech lead能够识别出项目中可能遇到的技术挑战，及时进行研究和实验，尽力使其不对开发工作造成阻碍。

    主要关注点：

    集成点是否得到妥善处理？

    能成功集成吗？用于集成测试的环境到位了吗？出错的情况妥善处理了吗？

    如果技术栈中的某一部分出现问题怎么办？

    项目中用到的第三方组件有谁熟悉？如果是开源软件，相关的社群在哪里？如果是闭源软件，我们能得到其生产厂商的技术支持吗？

    确定设计方案

    敏捷项目中，大部分设计都是在项目过程中做出的，其中有些设计会对系统整体产生较大的影响，有时甚至会改变起初的架构设计。所以贯穿整个项目，tech lead需要保持对系统整体和细部的把握，选择适当的设计方案，或是通过重构让好的设计浮现出来。

    主要关注点：

    代码中是否出现明显的bad smell？

    是否看到明显的大类、长方法或者重复代码？条件逻辑嵌套太深了吗？本应属于模型的逻辑在视图或者控制器里堆积了吗？是否应该考虑做一做对象健身操？（参见《ThoughtWorks文集》，第6章）

    局部设计是否会对系统造成明显的损害？

    这个设计会严重损害性能吗？它是一个安全漏洞吗？它是难以测试的吗？它损害了系统遵循的概念一致性吗？

    团队是否正在进行关于设计和重构的讨论？

    要在局部设计上具备发言权，tech lead就不能脱离开发工作──不写代码的人是无权评价代码的。在讨论细部设计时，tech lead需要把握一个微妙的平衡：既不要过于民主而耗费太多时间，也不要过于集中而使团队成员失去学习和思考的机会。一个好的实践是：每天早上把所有开发者召集起来，用15～20分钟浏览前一天编写的所有代码，这样每个人都有机会在看到bad smell时指出。

    流程监督人

    为了保障开发工作顺畅进行，tech lead需要从以下三方面入手来保持对开发流程的关注：开发环境、持续集成和测试。

    开发环境

    Tech lead需要保障良好的开发实践得到贯彻，尤其是当团队中有较多缺乏经验的成员时这一点就更显重要。一家公司内部很可能有一些成熟的开发套路，这也使得每个tech lead的责任更重大：如果团队成员在一个项目中没有养成好习惯，受损害的不仅是这一个项目，还有整个公司的习惯套路。

    主要关注点：

    如何使开发团队拥有统一的环境？

    IDE的设置和快捷键如何同步？shell设置和别名如何同步？数据库设置如何保持一致？需要将开发环境虚拟化吗？

    如何实现一段代码并提交？

    开发者从哪里获取验收条件？编写代码时应该遵循哪些惯例？功能完成之后是否需要邀请BA/QA快速确认？提交代码之前应该如何进行本地构建和测试？提交时的注释格式有什么要求？

    ThoughtWorks的很多Ruby on Rails项目都采用“rake commit”这个任务来提交代码。这个任务会从svn服务器更新代码、执行本地构建、运行测试、要求开发者输入符合格式的注释内容、然后提交修改内容。我们通常还会给这个命令指定一个shell别名“rc”，这样我们只需要敲三下键盘就可以开始一次标准的提交。

    如何结对编程？

    哪些任务需要结对？哪些任务可以不必结对？结对的轮换合理吗？是否有谁在某一个任务上做了太长时间？是否有谁对某一部分完全不了解？结对过程中大家都全心投入了吗？是否需要用特别的结对方法来引导经验较少的团队成员？需要开发者和QA结对吗？

    Tech lead同样需要与团队成员结对，有时是为了理解某一部分的实现，有时是为了指导和帮助队友。Tech lead应该始终牢记自己是开发团队的一份子，每天都应该尽量安排出时间参与结对；同时其他开发者也应该谅解tech lead还有其他职责，不要因此拒绝和他结对。