在RIT ++上，Nikita Sobolevn （ sobolevn ）亲自提出了关于公司代码和流程质量的讲道。 特别敏感，请倒入甘菊茶，但我们不建议您离开屏幕。 您可以不同意这些观点，坚持谈论电视节目是团队保持健康氛围的关键，并声称您不需要严格的linter和CI框架即可编写良好的代码。 但是，如果您曾因工作失败而指责他人，则应阅读或观看 Nikita的故事。你曾经做得不好吗？
我工作了很长时间。 我的公司太糟糕了。 一切都非常糟糕，一无所有，一切都与众不同。 我们有令人作呕的流程，讨厌的客户和无能的开发人员。 对此无能为力。 当一切都变得如此糟糕时，您只是不知道该怎么办，从哪里开始。 您感觉自己像一个痛苦的齿轮，无法影响任何事物。
当我说一切都不好时，我的意思是我们有：
- 错误的代码-没有人考虑过代码的质量，甚至没有人可以制定出代码的质量。
- 不好的过程。
- 我们无法正常沟通，
- 我们没有做客户想要的。
是的，这是外包开发，但这并没有使它变糟。 人们像那样使她。
“人们做得很糟糕，是人们应该为流程不良，代码不良和客户不良这一事实负责。”-这种想法折磨了我很多年。 我不喜欢自己的工作，这应该归咎于人们。
我将所有可能的罪行归咎于人们，并认为它们是问题的主要根源。 我希望有一天它们会改变，或者其他人会出现，并且一切都会好起来的。
认真地说，我想到了以下事实：其他公司聘用的是根本不同的人，他们的内部素质和专业水平有所不同，而这些其他人来自不同的考验。
但是到了某个时候，我开始猜测也许人们不应该受到指责-也许是一个不同层面的错误，而在某个地方发生错误的时间要早得多。 然后出现校正路径。 只有这样，您才能将自己保存为开发人员。
我意识到我们需要一场革命，一切都需要改变：我的工作方式，感觉，工作方式并没有成为我的考验。 我想在一个好的地方工作。
只有一个问题-
是我的公司 。
我就是发起这场革命的人。
我意识到
您需要更改所有内容才能再次享受您最喜欢的业务。 我喜欢编程，我准备每天工作12个小时，并称之为休息和工作。
因此，我非常痛苦地意识到所有的失败。 他们不仅与我最喜欢的业务联系在一起，而且与我的财务，我的自我意识和与他人的关系联系在一起，并在我的一生中得到了强烈的体现。 当某事对我不利时，我无法休息，我想不起其他任何事情。
我认为为了改善自己的生活，我现在能做的最重要的事情就是做好自己的工作。 为此，我需要
重新考虑我们所经历的所有混乱并为之整理秩序。
但是当您看到混乱时，您看不到模式-没有任何东西可以表明它应该是怎样的。
摆脱混乱来创造秩序是一种很难的创造行为。
您需要从头开始，以了解一切何时陷入混乱。 您需要确定新订单并向自己解释该怎么做。 这些都是美丽的话：“让我们一切都好！”。 但是您开始工作，却并不真正了解要改变一切要做什么，没有想法。
您获得的教育和阅读的书无济于事，因为您在此之前所做的一切都是从这些书和这种教育中学到的。
问题陈述
然后我想-最大的问题是什么？ 不允许生活和工作的最痛苦的地方在哪里？ 我意识到这是
问题的
陈述 。 对我而言，设置任务一直是非常可选的。
我认为你们中的许多人已经从标题“修复产品上的错误”中看到了这项任务。 我们有很多这样的东西，我将它们写成一行，然后人们做错了一些事情，并试图纠正它。 我想：“他们为什么不自己思考？ 你到底在做什么 您需要修复一个简单的错误，而不必做所有这些废话。”
然后我没有意识到我真的设置不好任务。 但是到了某个时候，我仍然意识到我需要以一种完全不同的方式来做到这一点，并且我制定了一些原则。
任务应该简短 。 不是在描述如何“修复产品上的错误”方面，而是本质上是简短的。 简短的小任务很方便。 他们对任何人都可以理解：初学者，普通的，有经验的开发人员。 每个人都可以理解并完成这样的任务，例如，在半个工作日之内。 您可以从这里开始。
任务应有序 。 当他们设置任务时，他们通常不认为应该按照什么顺序进行。 但是，任务可以相互阻塞，并行化，或者如果提前完成等会给其他任务增加复杂性，等等。
关于任务的顺序，很少有人说：将它们带到Jira或Trello，然后从那里拿走。 但是很少有人思考，以什么顺序，为什么以及为什么顺序就是这样。
所有任务必须是 单独的 。 这是什么意思？ 任务是存在于项目中且始终属于某人的实体。 有时候，在问题的描述中，您会发现：“谢尔盖，玛莎，请更正此问题。 你知道怎么做。” 您无法做到这一点，您需要提供整个上下文，以使此任务成为其自身中的一个个体，以便任何阅读它的人都能完成它。 这样就不会有关于项目的零散知识，并且在此任务的框架中也没有隐藏的意义。
当任务变得个体化，短暂而有条理时，人们开始按照我想要的方式来完成任务。
只是改变了沟通方式，我确保做过这种胡说八道的人开始做我想做的事-这不是魔术吗？ 这不是很多容易改变的证明。 我开始深入研究这个问题。
我们经常使客户失败，没有做对他有利的事情。 我认为，如果开发人员开始理解我们的任务并按需完成任务，他们能否理解客户的真正需求并按照客户的意愿去做？
我试图将其组合成一个两面的人物，他一方面认为像开发人员，另一方面却像客户一样。
这不是新任务。 通常，这种方法称为
域驱动设计 ，并且已经成功应用了很多年。 我决定采取最好的方式-一种沟通，工具，技术的方法，并尝试使开发人员了解需要做什么才能满足客户的需求。
这项任务非常困难，我仍在研究解决方案。 但是我为自己制定了一个简单的公式。
要求 。 一切始于他们，客户以需求的形式向开发人员表达了我们的意愿。 客户端有条件地说：“我要求登录页面正常工作。” 他们的意识开始出现，以表格，列表，图形等形式出现。 需求仍然是您项目中最重要的部分。 这是您最高级别的工作。
但是这些要求对于开发人员而言是无法操作的，它们太高层次且过于原始。 首先，程序员需要文档。
文档和要求是孪生兄弟，这是双重统一。 要求-这是您需要做的，而文档-如何做到的。
当我意识到原则上可以根据需求生成文档时，这已成为我们业务流程的重要组成部分。 我们学习了如何以特殊格式记录需求并生成文档。
测试 。 下一步的逻辑步骤是验证其是否有效。 我们开始测试需求，以确保我们确实在做所需的事情。
最有趣的是，我没有发明任何东西-我没有写一行代码来使其工作。 我只是采用了现有技术并收到了：需求，它们是文档，它们是测试。
下一步的逻辑步骤是将代码放在整个事情上，因为代码是我们直接参与的。
代码 -为此，一切实际上都已开始。 为了使客户和开发人员建立联系，您似乎需要深入了解其中一个，并确保他们彼此了解。 但是要深入研究，您可以使用相同的工具并将其连接起来，以便开发人员开始了解正在发生的事情。
在这里您可以阅读我在实践中的操作方法。
一旦我们将不同的实体巧妙地交织在一起（代码是唯一的！），开发人员和客户便取得了非常重要的成就：
我们的开发人员终于开始从事业务所需的工作 。 他们停止介绍这样的内容，因为他们了解了需求并理解了需求，了解了需要完成的工作。
为了确保执行，我们有以需求形式编写的测试，这些需求足够清晰，可以在代码中以可理解的语言实现，并根据这些需求编写
好的代码 。
沟通交流
我已经多次提到“沟通”。 我喜欢和我的朋友和家人聊天，但不喜欢上班。 在工作中，我必须与人沟通-我不是以此为基础选择他们的。
很多时候，工作中的交流无济于事 。
我们都是人，因此我们都与同事就非工作性话题（讨论电视节目等）进行沟通。 幸运的是，此缺陷是可以修复的。 为了了解对我们而言真正的灾难性交流，您可以查看各种示例。
首先，人们彼此分心，从流动的状态中流泪。 该名男子刚站起来说了一句话-我现在该怎么办？ 他为什么告诉我他想传达这一点？
还是集会。 我讨厌他们，坐在会议上时，我总是觉得自己很白痴。 每个人似乎都了解一些东西，他们有聪明的面孔，我想念一个，并想知道它什么时候结束。 我想离开，因为我们讨论的所有内容都可以更快地讨论。
集会会占用大量时间，并且没有好处。
还有其他几个重要问题，例如，人们开始在这些集会上发誓。 想象一下，您被安置在一个小房间里，到处都是你不想见的人。 您想离开，而这些人使您做出一些严肃的决定。 很自然地，虐待开始了-首先是被动侵略，然后是明显的侮辱。 不幸的是，这是无能为力的，因为人们是存在冲突的人。 无论您如何设法缓和局势，无论您如何挑选不发誓的好人-
人们都会发誓，这很正常 。
我们的商人还有另一个问题-
消失 。 您的前端或开发人员可以轻松停止一天的响应。 尤其是远程工作的人们可以简单地关闭电话并单方面结束对话。
这些问题和其他一些问题似乎是无法解决的。 您不能教导所有人都要善良，无冲突，负责任-这是根本不可能的。
但是您可以忍受。 作为一个现实主义者，您可以理解生活就是这样：人们会消失，诅咒，不想与您交流-这是正常的。 我解决了以下问题-结构化的交流。
要构建通信，只需采取两个步骤：
- 立即转到电报并将其删除。 一旦您删除了社交网络上的所有页面，人们将无法写信给您。
- 之后，启动一个频道并说您只能以这种方式进行交流。
当您处于可以向他人支配您的意愿的位置时，您可以教他们进行交流。 您表明
，沟通应该结构合理且对所有参与者有用 。
我们选择通过GitLab进行通信。 如果您有任何疑问，请在GitLab中提出。 如果您想提出一些奇怪的问题，请在此处提出。 如果您了解到没有地方可以提出这样的问题，那么也许就不需要问了。
我们仅就工作主题进行交流 。 如果有人想讨论《权力的游戏》-很抱歉，我们正在努力，并与您的朋友讨论《权力的游戏》。 如果您想讨论一项新技术，请创建一张票证，让我们进行讨论：也许它将使该项目受益。 但是“权力的游戏”肯定不会为该项目带来好处。
结构化的交流使不同的人相同。 GitLab甚至具有相同的化身-一个化身为字母K，另一个化身为C，我不知道这些人是谁。 我不在乎它们是什么，主要是它们在结构内进行通信。
在我们建立了沟通，与客户建立合作关系，学习了如何编写易于理解的票证之后，就该开始编写代码了。
代号
这里有一个新的问题在于等待-
人们不知道如何编写代码，这很正常 。 我曾经以为别人写的代码不好，我也很好。 但是后来我意识到我自己正在编写错误的代码。 过了一会儿，我意识到
所有人都在写不好的代码 ，这很好。
人们不是必须写代码。 编程是一个侵略性的环境，一个人不容易对此产生倾向。 该代码具有很多复杂性：体系结构和大量信息。 在分布式系统中，这通常很糟糕。 一个人很难应付信息流。 这是正常的。
但是，如果是这样，您可以对此做些事情并学习如何在这些条件下工作。
为了解决这个问题，您需要
严格的 CI和测试，以严格限制您所做的工作。 它必须是
最后的判决 -回答问题，好的代码还是不好的工具。 只有通过观察，CI的全能眼才能告诉您您的工作是精通还是会留在舞台上。
当然，这样的配置项是
不可避免的。 一旦某人获得了掌握母带的专有权，所有构建过程的尝试就会瓦解，因为这个人开始做各种废话。
不可避免且严格的CI提供了一些更酷的功能。 这是一个
发展的机会
，因为现在有了一个可以在其上建立基础的条形图：随后的每个代码段都比上一个更好。 随后的每段代码都为项目增加了价值，并提高了CI。 随后的每段代码都是迈向开发的一步。
准备好基础之后，就可以继续进行。
但是人们仍然会犯错误，因为即使以最严格的方式配置的CI也
无法捕获所有错误 。 它们将出现在其他人甚至都不会想到的地方。
该怎么办？ 您可以返回通常的策略并说：“您犯了一个错误，请更正。 您编写了错误的代码-请学习编写代码。” 这是一条不好的道路，不会导致发展。
为了真正正确地编写和开发产品，您需要一种新的方法和新的思维方式。
无懈可击的环境
我称这种方法为“无懈可击”的环境-这意味着
我从不怪任何人 。 如果您的项目中有bug，这就是项目问题。 该错误应予以修复，以使其不再发生。 如果这是代码中的错误，则需要编写回归测试。 如果这是项目基础结构中的错误，则需要编写一个可以防止该错误的工具。
当您不仅开始修复错误并希望一切都不会在生产中崩溃时，而是在系统级别上对其进行纠正时，您便开始
创建和创建-创建新工具，开发新方法和体系结构模式。 您开始思考，并确保不会再次出现错误。
对错误的不间断工作将开发人员带到了根本不同的水平。 您开始为开发人员发明工具，实施它们，进行升级等。
我现在谈论的创造是巨大的。 当您尝试使用这种方法时，您会发现一个事实，即现在存在的一切，尤其是对于某些编程语言，还不够严格。
有一次我想知道我是否可以编写一个
linter ，使每个人都编写相同的代码。 我非常严格，并提出了所有可能的规则。
但是人们仍然编写不同的代码 。 这非常相似，但是我总是可以理解，这段代码是由不同的人编写的。 因此，我的linter仍然不够严格-等待新版本发布。
方法仍然存在，我们正在等待机器响应，程序是否完成。 它行之有效，因为此类工具有助于工作。
但是我们一定不能忘记，
人们是这一过程的必要参与者 。 无论您进行了什么出色的技术设置，即使该人的经验丰富的外观没有通过您的代码，即使CI通过了，仍然有可能导致您的头发直立。
一方面，我们已经解决了我们的问题，但是我们拒绝了非常糟糕的代码。 但是，尽管如此，我们还没有与他完全隔离。
需要代码审查过程 。 如果代码没有通过代码审查，那么您之前所做的一切都是没有意义的。
只有在上一步有了基础的情况下，下一步才有意义。
, , , - CI . , , . - — .
— .
—
. . : « , ?!» , , .
: , . , , , — : . , .
- — . , , , : « ? . , - ». — , - , - . .
— , — .
— , . , .
, , . . . , .
, , , , . , , , .
, , , , , , , .
— . , — , , , .
, . , , .
open source , .
. , , , — .
. , , , , . , — , — . , .
. , . : — , — . .
. , , — ? , , , . .
. , , — , . - , , . , . open source.
. , , , , , . , , , .. !
. : . - , . , , . . , , . .
. , , - , . -, .
. , . - — , . , .
, . , . , .
Agile , . QualityConf , ++, — . , , .