您到底是为谁编写该代码？

特别感谢许多阅读本文并为我提供有用反馈和建议的人：Anya Roltsch，Frank Schubert，Olga Hollister，Ravi Varshney，Ashansu Pant，Marcus Blankenship，Sandra Jones，Taylor Davenport。

编写代码是非常个人的行为。

软件开发人员在锻炼时会考虑要在工作中，汽车中，在家中编写的内容，有时甚至梦到自己必须做的工作或需要解决的问题。

最好的软件开发人员与他们编写的代码有着情感上的联系。 他们非常在意编写优雅，简单的软件，并展示出他们作为工匠和业务领域专家的能力。

另一方面，其他开发人员不理解或同情分析他们创建的代码，对其进行阅读，使用，使用和故障排除的同事。

在本文中，我将解释开发人员为什么要关心并考虑许多不同的角色以及在编写代码时会受到影响的人员。

我将通过描述软件工程团队的各种角色，然后解释开发人员编写的代码影响其工作的哪些方面来做到这一点。

软件工程团队

整个商业世界已经意识到，软件工程既是团队活动，又是技术职业。 由协作，热情，直接，诚实的人组成的软件工程团队所创造的软件要比功能失调的团队或单独开发人员通常要好得多。

团队中的每个开发人员都必须一遍又一遍地阅读他们创建和维护的代码，因为他们一起增强了代码库并对其进行故障排除。 他们还必须了解所使用的每种代码模式和抽象，当发生严重错误或业务思维发生重大变化而代码中使用的概念发生较大变化时，这尤其会带来压力。

你未来的自我

我朋友的女儿上学，在学年的第一天，所有的孩子都被问到了他们爸爸的工作。 她说：“我的父亲输入文字。” 开发人员每天写很多小时的代码，有时每天都要写。

每周编写如此多的小时，可能会导致开发人员在尝试优化通过简洁性进行打字所花费的时间时变得懒于使用代码模式。 结果可能是难以理解的变量名，过度优化，难以阅读的代码，过于宽泛的异常处理程序或忽略异常的异常处理程序，对业务需求而言复杂或关键的部分代码缺少注释或一致性差具有编码风格。

把它弄出来，把它做好，继续前进，直到将来的某个时候-“我们需要扩展blarg组件来做Y。” 无声的呐喊！ 这段代码是谁做的？ 我不能做它的头或尾！ 后来发生了一次“ git blame”，接着是脸掌-“哎呀，那是我吗？”

最小化代码中有关业务概念和业务逻辑知识的假设数量。 在代码中发表评论，说明哪些逻辑领域对业务异常重要以及为什么。 链接到描述源代码本身中代码支持的产品或服务的外部资源。

质量检查工程师

质量检查确保应用程序网页的样式和布局在3种不同操作系统上的4种不同浏览器上正确显示。 它们确保应用程序错误将有意义的消息返回给应用程序用户。 他们有意尝试滥用该应用程序，以验证当应用程序代码遇到意外输入时，该应用程序不会崩溃，并向系统开放以进行堆栈指针重定向攻击，远程代码执行攻击，SQL注入攻击或其他安全漏洞。

无论是通过手动测试还是通过自动化，QA都会努力确保每个版本都具有一致的用户体验和质量水平。

质量检查小组工作的一部分是在客户发现错误之前先发现它们； 错误通常意味着在完成特定业务工作流之前代码已暂停。 异常可能是有意的（拒绝来自用户的无效数据），也可能是服务器捕获了由代码引发的意外的，未捕获的异常，并在其浏览器中向用户返回了通用错误响应（例如HTTP状态代码500 ），或引发JavaScript异常，从而在浏览器中生成堆栈跟踪。

质量检查（QA）花了大量时间思考代码，执行代码以及对代码进行故障排除，以确保在客户看到代码时看起来像是一颗钻石。

逻辑地组织代码，编写有意义的，以用户为中心的错误消息，考虑用户可能如何误解业务逻辑并传递应用程序意外的输入。

待命工程师

硬件？ CPU？ 内存？ 网络？ 水平缩放？ 并行处理？ 那是什么？

大多数开发人员对所有这些术语都有很好的理解，并且对在本地运行其代码以进行开发或在托管面向客户的应用程序的生产中运行其代码的容器，虚拟机和硬件有所了解。

许多开发人员没有考虑该过程的黑暗部分-由于不存在必需的配置参数而导致程序无法启动，当计算资源的RAM或磁盘空间不足时（凌晨2点），意外崩溃（尖叫声）警报，唤醒应召唤人员，然后该人员必须设法进入计算机，登录一个或多个系统，进行有针对性的故障排除，根本原因分析以及中断/修复工作以更正运行时发生的错误。

当程序中发生重要动作时，编写有意义的日志消息，向错误消息添加有用的上下文，并确保2 AM苦苦挣扎的人可以理解这些错误消息，以弄清事务处理器为何不处理事务。 精心组织代码，即使是非编码人员也有机会了解发生的事情以及原因。

现场可靠性工程师/三级工程师

另一组通常在情况最糟糕之前才看代码的人：系统崩溃，无效数据存储在数据库中，用户无法登录，Web界面间歇地显示空白页面或与最终用户系统不一致生成的错误消息。

这些人深切地关心理解代码的逻辑和布局，以便在发生运行时问题时，他们可以帮助工程团队修复错误-通过确定逻辑在代码中的何处出现，失败影响了多少人以及故障的严重性。 故障可能是程序意外退出或性能问题-为什么原本只需要300毫秒的应用程序功能现在需要10秒钟？

当业务工作流程错误发生时，引发异常并创建有意义的日志消息，以显示发生了什么以及为什么。 命名类，函数，方法和变量，以便分析代码的人员可以在最坏的时刻（即代码被破坏时）理解其流程和功能。

最近加入团队的软件开发人员

作为团队中的最新开发人员会感到焦虑，特别是如果在解散了前一个团队之后新组建了一个团队，或者该团队非常成熟并且已经建立了自己的代码模式和期望。

还记得成为新人时的感觉吗？ 如果您不这样做，请花点时间思考一下-您必须弄清楚源代码维护实践，编码标准，代码组织标准，命名约定，代码模式和代码中使用的特定于域的术语，以及它们如何映射到业务术语。

最大限度地减少理解代码所需的隐含上下文和知识。 使用众所周知的和易于理解的代码模式来组织代码和组合在一起的组件，从而形成整个应用程序。 学习并遵循由使用应用程序编写语言的开发人员社区规定的习惯用法。使用在业务领域中广泛使用和接受的术语来命名变量。

入门级软件开发人员

作为团队中的最新开发人员，难点是什么？ 成为入门级开发人员！ 在学习团队实践的基础上，您正在学习如何设计，开发和交付代码-许多新的思维模型和实践需要学习。

入门级开发人员经常被要求修复错误，因为错误是具有明确目标的重点任务，并使开发人员接触到系统的许多部分。 作为入门级开发人员的Bug面临什么挑战？ 作为入门级开发人员，可能需要花费大量时间阅读和理解代码。 有许多新的业务和软件工程术语需要学习，有许多问题需要理解以了解代码并找到错误的修复程序。

避免在变量，函数，方法和类名中使用术语。 在代码中使用简单的模式。 遵循单一责任的原则。 通过编写易于阅读和理解的代码来帮助您团队中的入门级开发人员。

产品经理

产品经理，产品负责人，项目经理，Ui / UX员工，业务分析师，Scrum Master。 工程团队需要许多角色来创建业务需求，路线图和上下文，以创建可为公司带来价值的应用程序。

想一想推动公司软件开发需求的人员。 在应用程序中学习和使用特定于业务领域的概念，以使应用程序的代码和其他组件很好地映射到业务级别的术语，并且需要使与业务人员的对话更容易理解。

技术经理

那人。 确保您获得报酬的人，希望指导您，保护您的注意力和注意力，帮助您的职业发展，对工作和家庭生活保持平衡有同情心的人，希望看到您尽力而为的人通过积极的支持，指导以及明确的战略和战术目标，帮助您保持最佳绩效。

在编写代码时，请考虑一下您的经理-做一名工匠，使每一行代码都很重要，花足够的时间进行设计，提出问题，并在编写代码之前与团队讨论实现的方式。

结论

在软件工程团队中，有很多人使用，关心和依赖软件开发人员编写的代码-对他们有同理心，理解和赞赏，并在创建程序时考虑它们。

我想念谁？ 还有哪些其他角色或角色在乎代码？ 在您的公司，您的团队，您的专业领域中，谁在乎我没有谈论过的代码？

现在，继续设计和创建应用程序，它们对您的专业，您的同行和与您一起工作的其他专业人员以及您的软件工程团队创建和维护的代码有更深的同理心，理解和尊重。

From: https://hackernoon.com/who-are-you-writing-that-code-for-anyway-69cx310s