软件开发者使用编码套路学习新的软件开发技能，这种方式在当前对于新技能的学习或是已有技能的完善是非常棒的。但是在我们的工作面对燃眉之急时，例如要达成最后期限、赶上发布日期、在遗留代码中解决故障等，使用编码套路并不能解决这时我们所面对的工作强度问题。本文给出了成为一名好的开发者所应具备的技能，重点强调了转变训练方法的重要性，这些训练方法可完善我们在高强度和具有挑战性环境中工作的技能。

一名好的开发者所应具备的技能

哪些技能对开发者是重要的？就此问题，不同的开发者会给出不同的回答。但是也不能将此问题理解成只涉及纯技术范围内的技能，否则也会令人失望的。好的技能知识的确非常有用，然而这并非问题的全部。一些开发者较多地侧重于技术技能，还有一些开发者将十分关注敏捷技能，诸如此类。这取决于如何理解软件开发者这个职位的目的所在。请试着回答一下下列问题：

我为什么做一个软件开发者？

我为什么要开发这个产品？

我为什么要去学习新的语言或架构？

我的产品的价值或影响力是什么？

如果对上述问题的解答中并未提及最终用户及他们的需求，这就意味考虑上有所欠缺了。

四项重要技能

作为一名好的开发者，第一项技能是时刻考虑着最终用户。你应确保知道最终用户的问题所在，了解最终用户的需求，然后再去开发那些可以解决最终用户的问题并满足他们需求的产品。软件开发就是这么回事。

第二项技能涉及所交付产品的质量。无缺陷交付是一种技能。显然，这很难达成，但并非是完全不可能的。我们很喜欢 Ed Weissman 在推文中所说的（如截图所示）。该技能应该可以一贯坚持，即在任何情况下都能够交付无缺陷特性的功能。显然这也意味着现有的功能没有被破坏。

第三项技能考虑的是对简易性的追求，不畏惧内在的和意外的复杂性。该技能与做分解和抽象的能力相关，即如何将复杂的系统和问题分解为小部分，使这些小部分形成反差以实现相互间的独立，并将它们组织起来，使得它们能在适当的抽象层级中被理解。在上述步骤中，必须要保持对正确抽象的关注，忽视掉那些没有必要的细节。这里我们推荐John Maeda所著的《简单法则》一书，该书真的是灵感之源。

第四项技能是关于如何将所有前面的技能合在一起，进而无需对任何事情（尤其是质量）做妥协就做到改进开发的速度。你的目标并非是不考虑前三项技能就空谈速度。你所寻求的也不仅是快速开发的效果，而且是高质量的和积极的快速开发效果。技能方法中最重要的一点是同时包容质量和强度。

充分休息

为了实现恢复、更新和再生，身体需要得到休息，而休息问题常常得不到开发者的优先考虑。我们中的很多人以熬夜工作为荣，甚至那些更加有天赋和经验的人也不外乎如此。你可以去读一下 Emily Beers撰写的探讨运动员和休息问题的文章 ，并认真考虑一下休息问题。

我们认为把这篇文章中的“运动员”替换为“开发者”也成立。在心理学领域，使用了“后视偏差”（Retrospective bias）这一术语解释为什么人们的记忆总是会和过去实际发生的事情不同，并且常常是将实际的事情罗曼蒂克化。该术语可用于解释为什么在我们熬夜之后，会忘记缺少效率以及其它的负面后果。牢记你的身体需要得到一些休息，很多时候躺下来休息会有助于自身的进步，睡眠也具有同样的功效。在解决生产率问题和高质量完成工作时，必须要做到好的睡眠（至少每晚睡眠八小时）和良好的休息。

增强技能的两个价值观

在上述技能之外，我们想再强调两个价值观，就是不责备但是不怜悯，以及兼容并包。

“不责备”指在每次发现了程序错误和缺陷时，你应该停止对当事人的寻找。为避免松懈情绪的产生，在做到“不责备”的同时也应该总是“不怜悯”。团队不应该去责备某人，而应力图去理解产生软件缺陷后面的深层原因、团队实践中存在着什么样的问题以及如何去避免这样的缺陷再度发生。

我们从“SoCraTes开发空间非会议”中理解了兼容并包的价值所在。作为首次参与这种非会议的人而言，我们并未感觉到自己就像个陌生人。每个与会的人都笑脸相迎，甚至是那些我们以前从来没有打过交道的人。与其他首次参与者一样，我们能迅速感到自身完全成为了社区的一部分。这是一种很棒的感觉。

下面将这些价值观用到新同事的身上。注意应尽快让新同事集成到团队中，帮助他们建立工作空间，尽快去与他们结对。做这些事情的目标在于使新同事在首日工作中不会感到自己就像是个陌生人。该方法不仅适用于在员工管理的角度意义上所说的入职，而且适用于在技术和工作开展角度意义上所说的入职。这意味着团队应该建立一个入职的环境，允许新员工从第一天就开始参与到工作的讨论和决策中。同样的价值观也应该应用到与其他利益相关者的交流中。但是不要遗忘掉自身项目相关的本地技能。例如我们的企业就使用了一种自制的架构，如果一名新员工在团队中表现良好，这就意味着他已经掌握了这个架构。

工作态度的重要性在于它对工作所产生深远的影响。如果你有机会参与到一个高积极性、高士气的团队中，你将很有可能会与同事愉快共处，提出好的想法、做出最好的工作。

技能并非仅限于技术

上文中所定义的技能的范围是非常广泛的。还有很多技能需要从敏捷方法论、XP实践、软件工匠社区以及许多可能并非与软件开发直接相关但是具有影响的事务中学习到。例如，团队可将“呜嘎嘎建筑师”（Ugg-Tect）这样的严肃游戏作为一种趣味实践。

在下面一节中，我们将侧重于训练的技术方面。更确切地说，我们将审视如何使用编程套路的，以及如何做到让训练更贴近于真实的生活。

在训练中增添强度

当前在教练传授和开发者学习软件开发基础（整洁代码、TDD等）时，编程套路是最为广泛使用的技术训练内容。编程套路对于软件开发基础而言存在价值，但在面对挑战性的情景时却很少够用，例如紧迫情景（例如达成最后期限、发布日期等），或是关键情景（例如在没有测试或仅是做了遗留测试的情况下，修正大型遗留代码库中的软件问题）。

不幸的是，很多开发者在面对激烈挑战时的第一反应是努力去尽快完成。但是在没有做好准备情况下就增加开发的速度，这将对工作的质量产生消极的影响。一些开发者将他们的开发工作看作是一种艺术而非绩效问题。实际上软件开发两者皆是。当在训练中增添强度之后，你就能适应挑战的出现，并将克服挑战去交付高质量的解决方案。

下面让我们看一下看如何才能做到。

学习一项新技能有三个阶段：

学习基础知识

协调性

强度

一定要确认在迈入到下一阶段前，已达成了本阶段的目标。

以重构为例

下面以重构问题为例去实施我们的训练计划。

学习基础知识

第一步，你首先应该知道重构问题的含义。什么是代码味道？如何使用重构编目清除代码味道？

Martin Fowler所著的《重构：改善既有代码的设计》一书是了解重构的必读书目。另一个值得关注的阅读内容是Uncle Bob的文章“ 转换优先级的前提 ”。还可在软件匠艺社区中找到一些值得关注的文章。对于 重构的基本规则 和 重构三法则 ，Adrian Bolboaca提供了一些好文章。

一定要掌握你所使用IDE的重构编目，并学会使用IDE提供的快捷方式，这可节省时间和大脑的处理工作，还有助于避免程序错误。本阶段的目标并非在于开发速度，而是去学会如何正确地重构，学会有助于高效重构的工具。为做到这一点，在本阶段中你应该可以识别出代码味道，使用重构编目去清除这些味道，并掌握你所使用的IDE。在训练中可以使用编程套路。在Emily Bach所著的《 Coding Dojo Handbook 》一书中，总结了一些有意思的编程套路，例如Gilded Rose、Yahtzee和Racing Car。

应谨记重构是一种在维持应用行为的同时，通过完成小规模的“自动”转化而改进代码和架构的过程。在重构的训练项目中，应始终将全局情况牢记于心。

协调性

第二个训练阶段是将在第一阶段中所学到的内容协调地应用于新的编程套路或自身项目中。例如，你可以去尝试使用Sandro Mancuso所定义的Trip Service编程讨论、J.B. Rainsberger所定义的Trivia编程套路，或是应用 mikado方法 。本阶段中需要你去熟悉IDE中的所有重构特性。你会有信心去将杂乱代码转换为整洁代码，并将此应用到新的编程套路和在开发的项目中。

强度

第三个阶段是增添强度。在这个阶段开始前，你必须达到对练习得心应手，可以高质量地完成练习，并多少有些精通的感觉。一旦达到了这些要求，你就可以着手去改进开发速度。

你可通过重构复杂代码实现强度。一个增添强度的方法是改进完成编码套路所需的时间。在这种情况下，要勇于将你的工作与其他开发者的工作做对比。看上去 BeFaster 网站给出了一种好的绩效比较方法，并可学到他人的快速开发方法。另一个小窍门是观看那些受到青睐的开发者实战。 YouTube的Codurance 频道 中包含了一些有意思的截屏录像，建议每个开发者都应该看一下。记住，如果改进开发速度导致了软件错误，那么速度的改进将毫无意义。应总是将软件质量置于开发速度之上。

实践软件开发的工具

同行间的会面、观点分享和想法交换是改进软件开发的一个重要方式，也是建议、想法和反馈的一个很好来源。当然，是否采纳新发现取决于你自身。

本地聚合和活动

你可在自己的城市中去寻找聚会。聚会是接触其它有才华开发者的绝好机会，从新成员那里学习，并享受这种乐趣。

在公司内部组织培训项目

在午餐时间或是工作日之外，你可以和同事组织一场时长60到90分钟的会议。这是一种很好的编程讨论方式，可在安全氛围中开展有意义的讨论。

最后，我们强烈推荐在团队中至少每周组织一次mob编程培训项目。在其中不要使用编程套路。使用你的生产代码就可很好地分享理念，并可以激励团队成员间的凝聚力。

个体培训

个体培训从练习开始，编程套路完全适用于此。本文中已经给出了一些编程讨论。但是谨记，为获取知识你必须反复练习直至养成习惯（最好是养成下意识的反射）。不要嫌多次重复编程套路是个麻烦。

如果想要学会一个新的编程语言，你每年至少要使用上一次。对此 Exercicsm.io 网站给出了一个很好起始点。该网站提供了一些按复杂度排序的练习，并提供了相应的单元测试。

如果你想在代码练习中得到乐趣，可以尝试一下 CodinGame 网站。该网站通过对真实项目最终期限的模拟实现训练强度的增添，其中一个很好的例子就是“Clashes of Code”游戏。还可通过解答智力游戏获得乐趣，这些智力游戏的挑战不仅来自于时间上的压力，而且更多的是来自于所需解决问题的内在复杂性。CodinGame还组织了竞赛，竞赛中对需解决的问题会保密至竞赛开始。该竞赛给出了排行榜。在CodinGame竞赛中出人头地，你必须能编写出整洁且高效的代码。

使用度量改进编程技能

开发者与度量间有着复杂的关联。度量早已被开发者使用，尤其是在面对绩效问题时。这里开发者所达成的共识是，如果没有一些类型的度量做测定，绩效问题的处理工作就非常像是博彩，只能凭运气取胜。

另一方面，有非常多的度量和KPI会令开发者生厌，例如工时单和甘特表。这些被开发者看成是用于监管和控制的，或是用做炫耀目的的。正因为这个原因，当你和开发者探讨度量时，大家相互之间总是会存在着猜疑心。

将度量作为工具

从本质上讲，度量应该是一个帮助你去做决策的日常工具。开发者是工程师，使用严谨科学的方法是一件正常的事情。如果你并未深刻理解你的起始点和目标所在，将不能有效地和持续地做事。度量的确是一个有助于你获悉自身状况的好工具。

一个使用度量的例子

例如，为改进你的IDE技能，一个做法是尽最大可能使用键盘快捷键。你可按如下过程去做：

第一步当然是学会这些快捷键。但这是不够的，因为如果不使用它们，你的技能并不会真正地提高。为实现对此技能的测定，你必须要跟踪自己的进展。

第二步是设置一个度量。对于本例而言，度量可以是未使用和使用了快捷键间的比例。

最后一步是去使用该度量。你可以定义一个目标观察进展情况。

使用这个方法，你可基于目标事实观察到IDE技能缺失问题的改进情况。相比于“跟着感觉走”的方法，你将能在目标达成中感受到更多的个人满足感。这里顺便说句题外话,IntelliJ的Key Promoter插件和生产力指导工具为这类实验提供了很多的便利。

说服经理为你提供改进时间

说服经理为你提供时间并非一件易事。培训是一种好的实践，这是几乎所有管理者在某种程度上所具有的共识，但是工作积压的压力常导致他们做出短期考虑的反应。学习新技能常被管理者作为那一类低优先级的任务。导致该问题的另一方面在于企业困境，这种困境可描述为CFO与CEO间的如下对话。

CFO：“如果我们培训了员工而员工又辞职了，那会发生什么？”

CEO：“如果我们不去培训员工而员工又留下来，那会发生什么？”

我们如何去打破这样的现象？对此并没有放之四海而皆准的解决方案，这取决于情境，并与很多因素（管理者、企业文化等）相关。那么我们应该如何做呢？

分享共同的心态

解决方法的第一部分是提醒你的经理，产品反映了一个团队。产品是团队的直接产出，因而具有更多技能的员工才会开发更好的产品。培训是一个双赢的情况。可以通过因特网搜索关键词“团队就是产品”去寻找令人信服的论据。

建立你的例证

在寻求经理的支持时，可以通过引用经理的话去建立你的例证。让经理更轻松地理解你的诉求的正确性。你的经理可能将会使用你的论据去向他的经理论证你所提出的论点。

精益问题解决过程是一种通用工具。它有助于构建请求。该工具可用如下的四个迭代步骤进行描述：

问题描述：问题是什么？

揭示问题不得到解决会导致什么后果：问题的重要性是什么？

找出假定的导致原因：根本原因是什么？

通过对解决方案的实验进行确认：解决方案是什么？

如此，你首先必须要回溯并思考这项技能：它为什么很重要？对于业务来说有什么潜在的问题？通过陈述对客户、团队及自身的影响，你可以更生动地把问题陈述出来。如果能给出度量就更好了，这是一个加分项。经理们都喜欢事实。

这里给出一个遵循上述四个步骤的请求例子，就是“在过去的Y周中，我们收到了由客户提出的与数据库相关的X个软件问题，因此团队必须花费Z天去解决这些问题。导致问题的原因是我们的存储过程不支持我们客户实际及未来的业务增长。我们并不具有开发稳定存储过程的技能。基于此，我建议我们对该问题做培训上的投资。”

有这样的工具在手，就能轻易地说服经理。

让培训物有所值

你得到培训时间只是一个开端。为充分利用培训，你一定要好好组织一下培训项目。如果你的经理能从中看到比较好的结果，你将更有可能得到做下一次培训的时间。

结论

本文讨论了如何在软件开发中改进开发速度和质量。软件开发被一些开发者看成是一种艺术而非绩效问题，在我们看来两者皆是。但是与软件开发的艺术相比，绩效问题却很少得到探讨，并总是被作为是一种禁忌话题。大多数开发者都反感谈及开发速度，乃至度量或指标。本文中，我们力图去打破这个禁忌，分享我们对于开发速度的想法。我们希望本文及关于这些问题的演讲将可有助于给出对这个争议性话题的有效探讨。