技术主管的瑞士军刀

作为一名技术主管的工作是令人非常振奋的，你每天都需要应对新的挑战，要解决新的问题，以此获得很大的满足感。但有些时候，为了改进你的团队，让它变得更强大，你还需要一些提示。有许多种技术可以保证我们所生产的产品质量，但其中最重要也是最强大的一点毫无疑问是反馈循环。如你所知，开发新软件比起科学研究更依赖于经验，这也是我们需要衡量指标以及小型的、但增量式的改进的原因，只有这样才能够满足用户或客户的需求。反馈循环是一种非常基础的、但又是非常强大的方法，它能够帮助我们和我们的团队通过每天的努力工作最终取得成功。通过反馈循环，你可以保证获得反馈以及衡量指标，让它们帮助你进一步改进你的产品。此外，多亏了反馈循环的存在，你可以将这些数据指标展现给经理层或技术架构师，以调整产品的技术决策，并为他们展示项目的进展情况，以及在开发流程中你的团队所遇到的问题。

下面这些技术中的大多数也许已经存在于你的组织中了，但你或许希望能够获得不同的指标，或缩短反馈循环，以便通过更多的信息来决定要采取哪种最佳的策略。

在本文中，我将乐于分享一些方法，以帮助你实现作为一名技术主管的最终目标，那当然就是打造一个强壮的技术环境，让开发者们可以依赖这个环境，并使他们每天都能够发挥出最高的水平，让他们感到安全，并且清楚地掌握代码的质量。

结对编程与代码复审

有两种技术能够为你带来第一时间的反馈以及益处，它们当然就是结对编程与代码复审。

让我们首先从结对编程开始。

当我们考虑这项技术的时候，首先要向经理证明，让两个人同时编写同一份代码的做法是否值得。如果你对结对编程已经有了足够的经验，那么你应该能够将生产力的下降控制在 15% 之内，同时做到增加代码的质量，并且促进团队成员之间共享知识，这种方式还能够帮助你在开发过程中尽早地发现 bug。最后一点看起来只是个很小的改进，但尽早发现 bug 有助于减少修复 bug 所消耗的精力，而如果你之后才发现这个 bug，那么公司可能会为此付出更大的代价，因为要理解一个“陈旧的”实现方式可能要付出两倍、甚至更多的精力。在进行结对编程的过程中，你需要记住两件事。首先，你应当鼓励团队每天进行几个小时的结对，并且每 30 分钟变换一次角色。其次，你应当创建一种适合结对编程的工作环境，开发者们唯一要做的就是为了实现这个软件而编写代码，因此不要安装邮件客户端或聊天工具，只要满足在这个项目上工作的最小化配置就足够了。

现在让我们来看一看代码复审。

我经常看到由于时间已经接近某个迭代的结束，甚至是接近最终的交付期限，而选择忽略代码复审这个实践的情况。代码复审对于将代码知识传递给所有团队成员、维护代码的一致性以及从技术角度改善项目来说是十分重要的。在我看来，主要问题在于代码复审往往是在代码完成几天之后才进行的，而如果你没有采取适当的做法，很可能会失去这一实践所带来的所有益处。如果你想从这个实践从获得最大的益处，我建议的做法是，当你在版本控制系统中签入代码之后，在同一天之内请你的同事帮助你检查你的代码。可以安排在一天之中专门抽出一些时间用于检查其他开发者的代码。记住，如果代码复审做好了，它将会成为一种非常强大与有效的手段。

增量式设计

这一点绝对是我最喜爱的反馈循环方式，如你所知，对任何项目进行过度的前期设计通常会导致错误的假设和误解，并且在技术方面会进行过多的猜测。从架构的角度来说，开发一个项目最好的方式是在每个项目开始时创建刚好足够的架构，只要它能够满足你和你的团队着手开发就好。然后在每个迭代刚开始的 30 分钟至 2 小时之内对架构与设计进行增量式的复审，专注于这个新迭代必须完成的任务。通过这种方式，你将创建出一种合理的架构，它能够完美地涵盖你的客户或公司的需求，并促进新特性的实现或进行重构。你将看到，在项目的开始阶段，你会在架构上投入较多的时间，但等到几个迭代结束之后，你会发现在架构上的投入时间减少了，你的架构的稳定性与高质量将会为你带来很大的益处。设计架构的最佳方式是使用一块白板，这样就能够从其他成员那里获得第一时间的反馈，并且你可以在白板上快速地添加、修改或是删除任意元素。记住，如果架构文档不能保持更新，在公司中就起不了任何作用。既然代码本身就能够解释各种设计决策，何必还要使用各种昂贵的建模软件呢？

我个人在这方面的建议是，创建一个高级别的架构图，让它反映出系统中的主要组件是如何交互的，这样就能够了解你的架构是否可行，或者是需要继续改善。在这种情况下，很容易就能够生成这样一份架构文档，并且修改它也不需要花费很大的精力。

静态分析

每一位技术主管都应当掌握静态分析技术，因为它能够为你提供实用的指标，帮助你指出项目中的潜在问题，并着重指出需要改进的地方。在最常见的一些技术中，例如 Java、C#或 JavaScript 都提供了丰富的工具，以帮助你获取有关代码的信息，例如代码圈复杂度（cyclomatic complexity）或是为你展现项目的架构。在服务器上安装类似于 SonarQube 这样的工具同样能够帮助你实现这一目标。对于你的团队中所使用的任何一种技术，你都应当设置相应的规则让代码符合公司的规范。请记住定义这些必须遵循的规则，并对流程进行自动化，以促进你的团队去检查这些反馈数据，并通过数据了解到当前的问题。因为衡量指标能够帮助你改善现状，否则你很难了解某个变更是否改善了你的软件。

版本控制

作为技术主管，你应当成为整个公司的代码监护人。如果你的代码一团糟，那么在几年、甚至只是几个月之后，整个公司或某个团队就无法继续维护这个项目，或者是在实现新特性或分析如何解决 bug 时痛苦万分。

关于这一点，我建议你牢记一点，并且提醒你的同事，那就是“童子军规则”：

“永远保持离开时的露营地比你发现它时更整洁”

目前最佳的方案是使用 GIT 或 Mercurial。GIT 的知名度更高，并且有许多公司都在使用它，因此也意味着关于它的资源与文档更多，这也是我推荐你使用 GIT 作为版本控制系统的原因。但很常见的一种状况是，某个公司虽然在使用 GIT，但没有采取任何分支策略，这导致每个项目都处于无组织状态。你应当通过实现一种 GIT 流或 GitHub 流策略以避免出现这种情形。你会发现，实现这两种策略之一会提高你的开发者的生产力，并且能够避免在合并不同的分支时经常出现的冲突问题。所有开发者都应记得的另一点是在提交代码时适当地使用 tag，并且提供有意义的注释。尤其是当你开发的软件准备公开发行或是创建某些类库时，在创建分发包之前对你的每个稳定版本的代码进行 tag 是必须的。最后，但并非最不重要的一点是，在开发者提交代码时，要求他们准确地描述他们改变了哪些内容，并且如果可能的话，尽量做到频繁地提交，这样能够让他们更容易撤消代码或是处理代码中的冲突。

自动化

如果在公司级别上还没有定义自动化的目标，那么在每个项目的开始阶段就应当进行定义。在项目开发过程中必须有一种可复制的、并且可部署的解决方案，可以在开发过程中不断地重复应用。这样才能够保证最终所交付的产品是正确的，并且避免接近项目交付日期时才发现的各种问题。通常来说，你应该实现以下功能的自动化：

• 对项目的各种突变测试、集成测试、验收测试、回归测试与功能测试进行自动化，尽可能将你的版本控制方案与你使用的自动化工具结合在一起，让它测试每次代码提交，或是每次对 development 或 master 分支进行合并时运行测试。
• 在每次构建之前进行静态分析能够帮助你确保代码标准以及产品的质量
• 对每次 tag 操作或发布进行 tag 流程及版本控制管理
• 将项目部署到测试环境中，以便 QA 人员进行测试
• 将项目部署到生产环境

当你在项目的开始阶段定义了这些步骤之后，你将发现，当你不得不在某个项目上线几个月或几年之后对它进行重新编译时能够避免大部分的常见问题，你也能够在代码一次次发布的过程中调整它们的质量，保证一个很高的代码标准，并获得所需的衡量指标，以计划某种在你的团队或整个公司之内进行改进的策略。

敏捷方法

你需要维护的东西不仅仅是技术流，信息流也是任何项目取得成功的关键所在。没错，你不是一位 Scrum Master，但你应当帮助 Scrum Master 去促进信息的流动，甚至帮助产品负责人定义用户故事，并了解在适当的时机加入一些技术性的用户故事以改善代码质量，通过指出潜在的技术问题帮助团队调整用户故事的规模等等。因此，出于这些以及其它多种原因，对于技术主管来说，充分地了解例如 Scrum、Kanban 和 XP 等最常用的框架是十分重要的。因为作为一名领导，你应当能够通过示范的方式领导你的团队，为他们展现，并鼓励他们遵循敏捷的最佳实践，并指导他们获得成功。

实践社区（COP）

对于任何技术团队来说，在每天的日常工作中分享经验和知识，从而提升自己是必须做到的一件事。组织一种两周一次或每月一次的实践社区能够有效地帮助我们实现这些目标。一般来说，COP 是一次讲座，技术团队中的某些可以将他或她在目前所接手的项目中使用的某个优秀的方案，或是某种对整个团队很实用的最新技术或方法论分享给大家。如果公司的规模足够大，我建议可以按照技能种类划分这些会议，某个 COP 专门针对 QA，某个针对后端开发者，另一个针对前端开发者等等。这样一来，会议的内容也会变得更垂直与更实用，而不是浪费时间讨论一些大家在短期内或较长一段时间内不会用到的技术或方法学。一次出色的实践社区活动应当在举办前 7 至 10 天开始准备，推举出 1 至 3 个演讲者，让每个人进行 20 至 30 分钟的演讲。如果演讲者只有一人，我建议让他准备一个最多 45 分钟的主题，然后将活动的第 2 部分用于问答与讨论。

在会议中设立一位协调者是必须的，至少在第 2 阶段，他可以鼓励与会者分享他们对于演讲内容的想法。保持整个会议环境更友好并且易于合作，这有助于团队在表现它们的技巧时更为自信。这种方式也能够产生一种共享的知识，通过它促进在整个组织中引入新技术和方法学的过程。作为技术主管，你应当有能力组织这种会议，促进大家的交流，并且找到让整个部门或公司都感兴趣的主题。有时候，为了打破每日工作的重复性，我建议可以一共观看一些技术会议的视频或是会议讲座，或是邀请某些外部的演讲者为团队分享一些垂直的主题，然后对此进行开放式的讨论。

总结

以上所说的这些都是作为一个技术主管应当掌握的关键工作与技术，并且应当在他或她的每日工作中鼓励同事也这么做。

你必须保持灵活，并拥有足够的技能，在任何情况下都采取正确的方式，让它保持与你的业务需求一致，并且符合公司的战略。

最后，但并非最不重要的是，我乐于为你分享我最喜爱的一条格言，以鼓励你开始改进你的标准：“千里之行，始于足下” —— 老子。

关于作者

Luca Mezzalira来自于意大利，他是一位热情的技术主管，在前端技术，例如 Javascript、HTML5、CSS、Actionscript、Haxe 和 Lua 方面具有超过 10 年的经验。Luca 对于软件架构方面体现出了极大的热情，并且高度专注于为每个项目创建最好的解决方案，以实现项目的主要目标。他目前居住在伦敦，专注于研究 JavaScript 框架与库，尤其是 React 和 React Native，以及 web 和移动性能，当然还有敏捷技术。Luca 也是一位国际性的演讲者（在全球已经进行了超过 60 场演讲）、是伦敦敏捷领导社区的共同组织者，也是Packt Publishing 出版社的技术审查员。

查看英文原文： The Swiss Army Knife for Technical Leads