几个月前，我的一位同事建议了一本书。 出于好奇，我阅读并完成了《 智人：人类简史》 。
这是一本引人入胜的书，有很多要考虑的方面。 随着主题在各章中交织在一起，一个主题不断冒出，被认为具有挑衅性，但易于理解。
尤瓦尔（Yuval）描述说，为了使大型团体中的人们能够合作，他们必须创造出可以理解和重视的有序模式。 如上所述，是一种神话般的胶水 。
我问，有没有一种胶水可以有效地应用于我们的工程专业？ 作为工程专业人士，我们是否拥有我们珍视的神话般的粘合剂？
一切都在请求中
毫无疑问， 拉动请求或代码审查已成为每个交互和贡献的开发团队的命脉。 拉取请求是团队文化以某种方式体现的地方。 从某种意义上讲，这就是团队沟通和决策的方式。
正如尤瓦尔（Yuval）所描述的那样，自由市场系统，金钱和其他构架被人们相信和珍视，我们作为工程专业人士相信需求拉动。 我们都知道什么是代码审查以及它提供了什么价值。
还是我们？
随着许多其他代码审查的进行，有些事情是不正确的。 没有任何描述可以明确指出变更的意图 。 对于那些确实描述了变化的人，它们显得混乱而前后不一致。
价值胶水被稀释并且不能很好地粘合。 没有描述问题时，请求请求的价值是什么？
软件工程最重要的方面是描述变更的意图。 我们必须描述原因。 这是我们作为专业人员必须做的。
由于我们的专业分布在全球各地，因此耳听式对话将无济于事。 部落团队的知识也不足够。 描述必须是文字记录。
那么，解决方案是什么？
要求统一的拉取请求模板
一段时间以来，社区一直在请求请求。 社区中有许多职位可以做得更好。
一些最佳示例提供了首选模板 ，这些模板可以指导贡献者回答某些问题。 这是暂缓更改描述的好方法。
但是，社区尚未找到伪造描述性请求请求的答案。 许多专业团队经常跳过一些描述，而忽略了加强我们胶合的巨大机会。
一个例子
通常，工程团队必须更新外部依赖性。 这些更新发生的模式通常是神秘的。
谷歌“牛刀” 。 这是用于Android的视图依赖注入SDK。 但是，为什么会颠簸？ 我们要解决什么？
好的，现在我们明白了。 团队了解改进的机会 。
该说明确定了问题，解决方案以及原因。 我们可以通过测试，代码覆盖率，度量更改以及自动化和传达具体更改的其他独特方法等主题来进一步扩展模板。
统一模板的定义必须从问题和解决方案开始 。 一个团队应该意识到如何通过使用模板来传达变更，并拒绝那些没有提出请求的拉取请求。
作为一个额外的奖励，模板使重力在连续集成和交付系统中的灌篮高手原子合并提交消息中发挥了作用。
承诺可能会过分杀伤
如果主题标题和描述不清楚，则承诺缺乏价值。
确实，这些年来，有许多关于这些问题的文章。 对于非描述性提交的最直接解决方案是遵循50/72规则 。 该规则鼓励以特定方式传递主题和正文消息。
但是，大多数工程师并不遵循50/72。 一些工程师认为可以在主题标题的末尾放置句点。 他们的提交充满了票务系统，对于一些经验丰富的工程师来说，这些提交完全没有恶意。 提交消息几乎很难正确。 编写代码更加容易。
即使写得很清楚，也有一个哲学论点质疑提交的价值。 我们是否应该关心这些步骤，还是只关心合并请求合并，只要合并请求的格式正确且对任何一名工程师都不构成负担即可。
有人会说，在大多数专业工程团队中，最重要的描述是撤回请求。 不是形成它的小迭代。 推理很简单。 我们不是一台机器可以一次准确地记住七个以上的提交， 正负两个 。 有些团队也需要压缩和重新设置，因此一开始的提交是微不足道的。
对于这个难题，没有正确的答案。 唯一真实的常数是拉取请求模板，描述的机会以及是否记录在版本控制系统中。
一个值就是描述
拉取请求所花费的时间与编写遵循一致模式的简洁代码所花费的时间一样多。 测试应完全覆盖该代码。 我们重视拉动请求，因为它们为工程团队中的异花授粉提供服务，并保护对业务，代理机构或其他机构有价值的用户体验。
要求工程师解决难题。 第一步是写出问题所在，原因以及我们如何解决该问题。 有时会逐步执行一系列链接请求请求。
在计算机科学中有两件难事：缓存无效，命名和一处错误。
— 未知
命名很难。 但是， 描述事物变得越来越困难，并且充满了错误。 作为专业人员，我们有责任尽我们所能描述与环境相关的变革意图。
最正确的代码是未编写的代码，但最正确的描述是未编写的代码。
这里的论点是，如果我们不尽最大努力来描述更改，那么上下文将丢失。 这不仅会损害未来的贡献者，还会损害业务合作伙伴，代理商等。
那么，我们如何体现和捕捉上下文描述的价值，以便其他工程专业人士理解？
扩展鲍伯叔叔的程序员的誓言
关于我们作为一个有组织的机构的工程专业，我们社区中正在发生对话。 鲍勃叔叔发送这些烟雾信号的时候，我们别无所求。
一段时间以来，他一直在敦促我们作为工程师或程序员体现一些具体原则，否则政府机构会为我们做到这一点。
鲍伯叔叔的论点包括与其他专业团体的比较。 一个这样的例子描述了患者如何在医疗行业中因缺乏绝育而死亡，随着软件吞噬了世界，一大批人会无意中死去。 直到为时已晚，医学专业人员才知道未知，而工程专业人员则未知。
为了纠正这些问题，医学专业人员组织并形成了遵循诸如消毒技术之类的准则。 这些医疗专业人员能够将这些机构的座右铭交给他们，因此他们制定了自己的规则。 鲍伯叔叔也在问我们。
他将被证明是正确的，这将在我们的一生中发生。 但是，问题是我们是否准备好以一支有组织的专业人员队伍来承担这一责任？ 为了解决这个难题，鲍勃叔叔创建了《 程序员的誓言》 。
宣誓上面有很强的要点。 鲍伯叔叔为我们创造了强大的粘合剂。 但是，他错过了一条基本规则，我希望提供一个扩展。
10.我将尽我所能，尽可能多地传达变化的意图。
规则编号为10的点是要宣誓就执行所有其他规则。 我们是作家，应该尽我们所能来交流。
捆绑我们作为软件工程师的神秘胶水很多。 一种这样的胶水就是我们重视拉取请求。 让我们尽自己的一份力量来详细描述问题和解决方案的上下文，以便其他人可以迅速做出贡献并保护我们的用户。 它从思考和描述问题“开始”开始。 然后，我们必须用新的机会描述解决方案。 最终，所有工程专业人员都应坚持传达改变的意图。
From: https://hackernoon.com/no-description-provided-8d9e0f3a3abb