你的代码上线后会发生什么？
你的代码上线后会发生什么？
作为运营团队成员，我如何成为一名更好的开发人员。
这是我给最近加入我们的实习生做的一个简短的演讲。如果你了解内情，这听起来可能过于简单。这是有意的。
软件
出于本文的目的，让我们假设任何通过在计算机中执行一组指令(代码)来解决特定需求的工具都被认为是软件。
它是如何产生的？
简发现一遍又一遍地计算她的日常开支是重复的，约翰发现自己想知道如果有一种更简单的方法来跟踪他需要支付的所有账单该多好——他们直觉地认为是一台机器或一款软件来做这些平凡而重复的事情，让他们的生活更轻松。
很难建立一个硬件机器(螺丝、螺母和螺栓)来记录你每天需要做的所有事情。但是，嘿，我们有一个愚蠢的机器可以执行我们给他们的指令。它能执行任何指令吗？比尔·布莱森说:
很长一段时间，我都不明白这么贵、这么先进的东西怎么会这么没用。然后我想到，计算机是一台愚蠢的机器，有能力做非常聪明的事情，而计算机程序员是聪明的人，有能力做非常愚蠢的事情。简而言之，他们是天作之合。
T4，给电脑写一组指令让它为你做点什么不应该那么难。或者有人想了想，为计算机写了一堆指令(代码)，于是一个软软件就诞生了。我说不应该是,因为如果真的很难，为什么会有100 个专为 Android 开发的 ToDo 应用？有没有想过，即使有100 个应用，却很难找到满足你需求的东西？编码不难，但是开发软件难。
应用软件的类型
不同的人和组织开发了几种类型的软件，这些软件被出售、订阅或免费赠送。概括地说，有 4 种类型(有多种方法来分类，但这只是对一个外行用户来说应用软件的简化):
- COTS —商业现成软件。这些应用程序包括 Microsoft Office、iMovie editor for Mac、Adobe PhotoShop、Oracle database 等。你得到了一个预建的应用程序，可以随心所欲地使用它。
- SaaS —软件即服务。这是当你不拥有软件，但你为你的使用付费。例如，Gmail for business 是一款可以通过浏览器使用的应用程序，但不像 MS Office 那样使用 CD(可安装文件)来安装。你为使用付费，可以根据你的业务定制它，但你不拥有 Gmail 软件，也不维护它(如果应用程序不运行，启动它或修复问题或自己购买服务器)。
- 网络应用 —这些是公司开发的软件，你可以用来访问公司的服务。帮助你进行网上交易的银行网站就是一个例子。亚马逊或易贝这样的电子商务网站是另一个例子。这些都是公司自己维护的，你作为用户不用为使用应用本身付费。
- 移动应用——智能手机普及后我们大多数人的生命线。手机上的小软件，要么像计算器一样独立在手机上，要么像优步一样与网络应用程序对话来存储和检索信息。
- 最后，我们有工具、实用程序和软件模块(称为库)，帮助我们运行上面列出的其他软件。
它们是如何建造的？
要构建一个像样的软件(或者一个应用程序，我们会互换使用)，必须要做很多事情。
- 首先，应用程序的想法(主要由需求驱动，有时由贪婪驱动，有时由竞争驱动)，例如，我想要一个帮助我管理待办事项列表的应用程序。
- 第二，我们的应用程序应该做什么事情。用技术术语来说，这被称为由产品所有者管理的功能积压——例如，我希望我的 ToDo 应用程序在设定的日期和时间提醒我关于 ToDo 项目等等。
- 第三，应用程序应该是什么样子——这曾经被归类为 UI 设计，但它更广泛，包括 UX，用户体验，由设计师管理——例如，我的 ToDo 应用程序应该有一个突出的绿色 + 图像，当我触摸它时，应该会打开一个表单，我可以在其中添加一个新的 ToDo 项目。
- 最后，执行我们 backlog 中所有功能的实际代码——比如应用程序应该将我的待办事项列表存储在某个地方，以便我以后可以查看它，或者我应该能够将某个项目标记为完成，并且应该在旁边显示一个绿色的勾号，等等。
你造过飞机吗？
构建软件应用程序与构建飞机非常相似。一群工程师坐在一起，设计和制造发动机、机翼、座椅、驾驶舱、厕所，一直到飞机上的最后一颗螺丝和螺母。要么像空中客车这样的公司制造 A380，然后卖给阿联酋航空这样的航空公司(COTS)，要么你可以租一架飞机用于商务或休闲(SaaS)，或者你可以驾驶由某人运营的 A380，并支付从 A 地到 B 地的费用(网络/移动应用程序)。
关于如何编写更好的代码(或建造飞机)，已经有几十年的工作和文献了。这篇文章不是关于这个的。让我们快进几个月，到飞机制造完成并准备进行首次飞行的时候。换句话说，代码已经写好了，我们的 ToDo list 应用程序已经可以使用了。我将继续飞机的例子，但是您可以将它类比到我们的待办事项列表应用程序。
好吧，我们造了飞机。但是谁驾驶它并让它继续飞行呢？
此后，会发生以下部分或全部情况:
- 我们制造的产品存在问题——一个座位的安全带有问题——也就是一个缺陷。
- 用户希望飞机有更多的功能，比如通过触摸按钮从座位上订购食物——也就是增强功能。
- 飞机的其他问题——飞行需要太多燃料，速度不够快，需要经常检查以查看是否有任何东西看起来要坏了——也就是性能问题、停机时间等。
在大多数公司，上述事情都留给了被称为运营/运行/维护*团队的专门团队来处理(我们 A380 中的飞行员、空姐和地勤人员)。他们的工作是确保飞机在空中飞行，平稳飞行，没有任何用户面临任何不适，拧紧这里的几个螺丝，在一些严重的情况下，即使起落架出现故障，也要安全着陆飞机——软件术语:维持正常运行时间，提供小的错误修复和增强。
有时，运营团队没有能力处理像引擎故障(代码中的错误公式或逻辑)这样的大问题，在这种情况下，他们会打电话给构建引擎的人(编写代码的开发人员)看一看。顺便说一句，这些开发者，一旦他们的第一个[release](https://en.wikipedia.org/wiki/Software_release_life_cycle)完成，要么:
- 根据用户的反馈改进 A380 这在 SaaS、COTS、移动应用和许多网络应用中都有发生——并发布下一款
[version](https://en.wikipedia.org/wiki/Software_versioning),即 A380.1
运筹学
- 与大公司(也称为企业)的通常情况一样，预算是为第一个版本分配的。明年，一些其他团队得到他们的预算，这些开发人员可能会被转移到其他团队。他们制造的 A380(可能有缺陷)一直在飞行，直到问题/改进需求变得如此之多，以至于保留它不再经济。因此，他们最终购买了下一个令人敬畏的版本 A381(讽刺的是，是由拥有 buggy A380 的同一团队以同样的方式建造的)。
这就是你的代码(A380)所发生的事情
你的代码会一直被修补、更新、滥用和压力测试[goes live](https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_.28GA.29)由没有经验的人，有经验的人在压力下，那些只是在等待读研时编码的人。事实上，任何像样的应用程序在维护阶段花费的时间都比开发阶段多。
[即使应用程序有很高的需求，用户不断地要求新的功能，应用程序能做的事情(并且做得很好)也是相当有限的。在某个时候，我们要么会耗尽要构建的功能或构建它们的资金，要么技术会过时，我们不得不重新构建应用程序。虽然这可能不适用于科技公司/巨头，如谷歌/脸书/推特/亚马逊，但它通常发生在妈妈的 Pop 商店网站、企业网络应用等。]
那些不知道你写代码时在想什么的人，会以让任何开发人员都害怕的方式修改代码。[我不是贬低维护团队的工作，但他们只是必须修补它，并在更严格的 SLA 下保持应用程序，这意味着必须做出妥协，而且通常是以代码质量为代价]。商业软件通常是在如此多的约束下构建的，人们开始期望它会有缺陷。这意味着，在任何给定的时间和高度，我们的飞机都有问题等待发生。
但是作为一名开发人员，您为什么要关心呢？
每一次，你忘记了代码的常识方面，你使用户和操作/支持人员的生活变得悲惨。如果您正在享受周末支持，而一位拥有 1 小时 SLA 的白金客户在周日凌晨 3 点打电话给您，您最好接电话。如果日志和代码不能帮助我弄清楚发生了什么，愿上帝帮助你——我会诅咒你，你的导师和老师，父母，祖父母，还会为你的孩子祈祷。
在我职业生涯的早期，我写过一些糟糕的代码。我从来不去想我做完后会发生什么。直到两年后，在一个周五的晚上，当我正要登上火车时，我接到了我们支持团队的电话(我已经把我的名字作为代码的作者名，这是你看到的最佳实践),要求我帮助解决一个问题，因为他们看不到任何日志，代码是 100 多行嵌套循环和 if-else 条件。我看了看代码，想不出我在代码里想做什么。我自己的代码。我成功地混迹于未来。然后我意识到有多少人的周五晚上被我的代码搞砸了。我做了一年的运营人员的工作，以了解从这个角度看开发人员是什么样的。我们长得不好看。
那么，作为开发商，我们该怎么办呢？
遵循最佳实践并运用我们的常识。在建造飞机时，想想乘客和机组人员，以及所有的一切。
为良好的用户体验而优化——我宁愿舒适而不是其他(除了安全)。像狭窄的腿部空间这样的事情，因为我们想塞更多的座位，我们只能在厕所旁边有一个门，因为我们一直都是这样建造飞机的，或者因为我们先建造了座位，现在它们不能移动，这都不是良好的飞行体验。
模块化代码— 如果我们作为开发者，没有把飞机造得足够好，一名机组成员可能要花 30 分钟才能弄清楚安全带的两端到底通向哪里。因为可能会有很多其他问题，30 分钟的运营团队时间太宝贵了。而且你也不想拆下座位去修托盘桌或者厕所门。
日志— 问题是不可避免的，至少他们是这么说的。因此，当问题发生时，提供足够的信息，以便机组人员或乘客可以很容易地判断出睡眠声音来自哪里。与其说something went wrong，seat belt on 27c is not working会更有帮助。
测试过的代码— 这就像一个检查表。当飞行员修理漏油时，如果他有一个清单来确定一个适当密封的油舱是什么样子的，这将使他的生活变得容易。
可读代码— 确保我们构建的东西易于理解，便于他人在紧迫的期限内修改。
设计原则— 遵循你工作领域的惯例、标准和原则。不要因为我们应该有不同的想法，就为波音和空客 A380 设计不同类型的安全带。我希望Logout按钮让我退出，而不是打开一个反馈表单。建造能做好一件事的东西。你的飞机不需要座位摇摆选项，尽管这很酷。
无论您选择何种编程语言或技术，还有许多其他通用的最佳实践。跟着他们。我不在乎你是否写了最聪明的代码，在 x 行之内做了十亿次运算。如果我在驾驶飞机的时候不能修好它，那么代码无论有多漂亮都是一种负担。
但是我们有银弹 DevOps。我们所有的问题都会迎刃而解！
我可以声称不，你没有把 DevOps 做对！大约 95%的时间都是正确的。虽然大多数顾问和供应商告诉你 DevOps 会解决你的问题，但是记住 [没有什么灵丹妙药](https://en.wikipedia.org/wiki/No_Silver_Bullet) 。如果你**
- 跨预算(或产品，视情况而定)轮换您的开发人员，或者
- 你有一个专注于一件事的团队(Linux 专家 vs Angular 专家 vs Java/C#专家),他们是孤立的，或者
- 有些人的工作是确保毫无疑问地严格遵循流程，不惜任何代价降低风险，绘制关于开发人员生产力的图表，并为固定的故事点优化流程
- 一百万件其他违背 DevOps 原则(如果你谷歌 DevOps 原则，人们有 4、3 或 5 条原则。似乎我们不能就我们同意的基本原则达成一致。
你的问题可能更糟，但可以通过实施 DevOps 来解决。
TLDR；
您的代码大部分时间花在维护上，而不是开发上。当你编码的时候，要同情其他人(用户、测试人员、操作人员、支持人员、开发人员等等)。另一个人可能是你。不，DevOps 不是灵丹妙药——要么你还没准备好，要么你还不需要它。
注意事项:
*Operations team 是一个笼统的说法，我用它来指代所有部门，包括监控、基础设施、小漏洞修复、应急响应团队等。从技术上讲，当你具体说明时，会有巨大的差异，但是这篇文章过于简单化了。
