什么是营销代码(为什么有些程序员打代码太慢)
作者|BeyangLiu
译者|弯月面
出品| csdn (ID: csdnnews)
为什么在关于开发者生产力的讨论中很少听到开发者的声音？有很多自以为是的开发人员生产力专家，但似乎他们更感兴趣的是推销一个概念，而不是准确描述开发人员的实际工作方式。正因为如此，我们只能看到一些高调的缩写，神奇的指标和方法论，却未能系统地思考这个问题。
开发者善于系统思考。我们的工作是系统建模和系统构建，经常会绘制图表和示意图来说明这些系统的工作模式。但是说到开发者自己的作品，是别人画的图，水平真的没那么好。我怀疑我是唯一一个担心生产力& quot专家& quot说吧。
难道我们不应该建立一种基于我们最直接的经验来思考我们工作方式的模式吗？难道不应该画出实际上能反映最真实世界的图画和图表吗？接下来，我们来试一试。
内部循环和外部循环SDLC(系统开发生命周期)是描述软件开发过程的最常见的图表。作为DevOps营销活动的支柱，SDLC很好地展示了将代码投入生产的各个阶段。然而，SDLC没有定义软件开发中最关键的步骤：代码本身是如何被理解和编写的。.
作为一名开发人员，回顾自己的工作，我觉得整个软件开发过程不应该只是SDLC展示的一个大循环，而应该以两个嵌套的循环:为代表
外环大致类似于SDLC，每个sprint、项目或产品发布都会经历一次。
内环包括读代码、写代码和运行代码。我们每天都要重复这个过程，直到代码完美为止。
在开发过程中，每一次接触到源代码，就进入了内循环。内部循环将在外部循环的多个点触发，例如：
学习和理解需要修改的代码；
创建新功能或修复错误；
修复CI中的错误测试；
查看补丁或回复评论；
调试和部署中的问题；
解决生产中的问题。
内环非常重要，它是创建软件的核心，但是很多组织会忽略内环。
心流状态是内循环中的最佳状态：心流.心流状态是指开发者受到启发、充满动力时的高度集中和超级生产力的状态。在这种状态下，开发者心无旁骛，忘我工作，可以享受到极大的乐趣。在这种状态下，开发人员可以随着思路的流动打出一串代码。为了进入理想的心流状态，我们需要注意内循环。
一旦达到流动状态，内部循环就会加速。但是，开发者需要长时间不间断的工作才能进入心流状态。一旦中断，就浪费了。作为一名开发人员，在努力完成工作的过程中，我最大的烦恼就是经常被人打断。可惜很多开发者的日常工作状态就像下图：
破坏流动状态的因素可能来自内部，也可能来自外部。
外部因素包括会议或来自其他团队成员的问题。
内部因素主要是因为其他需求，比如需要知道如何使用一个库，需要设置工具或者需要解决障碍。
我想每个程序员都在人生的某个时刻经历过第一张图，高效输入的感觉让他们彻底爱上了编程。但是很多开发者在从事专业编程时，往往会陷入第二张图所示的困境，这也是开发者痛苦和生产力下降的根本原因。
开发人员生产力的单位's图表揭示了一个重要问题：到底什么是& quot生产力& quot(上图中的Y轴)？很多开发者都能描述出大致的感觉，但是我们能给出一个更准确的定义吗？多少行代码？提交的数量？版本控制历史综合索引？似乎这些指标都不能很好的衡量开发者的生产力。
软件开发的核心是创新.不同于制造实物产品，软件开发的目标不是生产以前已经生产过的东西，而是生产新的有用的知识。创新的原子单位是迭代，迭代是一个内部循环的循环。
开发人员生产力的原子单位应该是内部循环的迭代。正确的单位不是代码行数，而是迭代频率。我们可以称这个数量单位为& quot开发商赫兹& quot。
进度是代码空间中的一个向量，在物理世界中，速度有两个分量：方向和速度.同样，开发人员的速度也可以分解为方向和数量。
速度分量代表内循环的迭代速度。开发人员进入流状态的次数越多，迭代就越快，新特性或补丁的发布就越快。
方向成分反映的是采用的技术方向，比如你用库X还是y，选择好方向是快速取胜的关键。选择了错误的方向，可能意味着一些步骤需要返工。
正确的方向决策意味着选择的技术有助于尽快实现端到端系统的启动和运行。快速启动端到端系统可以降低整个项目的风险。在指定的截止日期之前达到可发布状态意味着您可以使用剩余的时间做进一步的改进。我们不应该把目标视为
为一个点，而是应将其视为可接受结果的区域。先进入可接受的区域，然后再逐步改进。上述这些示意图将软件开发看作了一项个体工作。然而，实际上大多数软件都是由团队制作的。团队合作对于保证稳步、前后统一的进度至为关键。古语有云：一人独行走得快，与人同行走得远。
个体的速度往往不是很稳定。我们常常需要花费大量时间来熟悉代码，或者被外部因素扰乱个人的编程时间计划。但是，将每个成员的速度加起来，团队整体的速度就会更加趋于平缓。
如果某个团队的生产力持续低下，那么就应该想一想是什么因素导致团队所有成员的生产力下降。有时，这是由自然因素导致的，比如建立新季度计划的过程占用了过多的时间；而有时则是由一些更严重的原因造成的，比如士气问题、技术负债或缺乏明确的目标以及优先等级等等。
人们普遍认为，软件团队的生产力会随着团队规模的增长呈次线性增长，而且最终会下降。这个结论是根据并行计算和阿姆达尔定律得出的。计算机CPU数量增加一倍，程序的运行速度也会加快，但无法快至两倍。
对于计算机，并行速度减慢的主要因素是CPU需要切换上下文，并将工作分解为可独立处理的块。对于软件团队，主要因素是沟通开销、工作的依赖结构、领域专业知识以及上下文的获取速度。
我们可以将项目分解成多个可交付的成果物，成品是一个金字塔，我们必须按照由底到顶的顺序放置各个小块：
上图中不同的颜色代表不同领域的专业知识。如果你是具有多个领域专业知识的开发人员，则可以独自构建整个项目。或者，你也可以将这些任务委托给其他两个拥有某一个领域专业知识的开发人员：
两位开发人员的优势在于，他们可以并行构建单独的块，但仍然有一部分串行的工作需要彼此依赖（某些块必须按照一定的顺序摆放），而且他们还需要花费一定的时间熟悉代码，还会产生一定的沟通开销。
大家都希望两位开发人员完成项目的速度是一位开发人员的两倍，可惜这不过是一厢情愿的想法。实际上，我们甚至无法保证两个人的速度一定会有所提升。但是，如果分工良好，团队关系融洽，那么一定程度的速度提升是可以实现的。
然而，每增加一个人，协调任务的复杂性就会相应地增加。对于大多数团队而言，每增加一个人，收益就会大大减少。这就是为什么许多组织会优先考虑雇用和留住优秀的开发人员，而不是一味地扩大团队规模。此外，他们还会投资能够提高个人生产力并有助于协调大规模软件开发的工具。
在文本的开头，我说过，如果开发人员不谈论生产力的这些要素，那么我们的组织就不会意识到它们的重要性。
然而，更糟糕的是，一些人在想法设法地说服我们的组织相信其他因素更为重要。很多时候，我们会被塞进一个个框架内，他们认为软件创建不是一个发现之旅，而是一个缺乏想象力的小加工厂。没有人重视内循环（即理解与创建代码的循环），他们只会要求开发人员考虑机械的外循环。如果就连“跳转到定义”都有困难，那么强调“变更失败率”又有什么意义？作为工程师，我们没有将钱花在刀刃上，想法改善我们的工具，却一味地扩大团队规模，陷入经典的人月神话谬误，最终导致“三多”的败局：团队成员越来越多，代码越来越多，问题也会越来越多。
建立能够真实反映我们工作的现实，并尊重基本创造力的思维模式，不仅有利于每一位开发人员，而且对我们的行业和整个社会都有利。
*本文由CSDN翻译，未经授权，禁止转载。
原文链接：https://about.sourcegraph.com/blog/developer-productivity-thoughts