2018年底，
熊猫聚会
＃9前端在萨马拉举行。 在这次活动中，我尝试了自己的新角色并作了演讲。 我叫Evgeny Kholmov。 十多年前，我还是一名学生，开始编程。 在过去的5年中，我一直在俄罗斯主要的银行开发远程服务系统，其中有2年的时间是经理。 在这段时间里，我参与了多个领先的俄罗斯企业应用程序的创建，经历了繁重的架构，集成和过程解决方案的荆棘。 根据我在开发多家大型互联网银行中的经验，我告诉mitap的客人，遵循良好的开发风格规则将带来什么好处。 那些动听的人物给观众留下了深刻的印象。 与会者确实使我不知所措。 在《哈布雷》的读者中，这个话题可能会引起热烈的反响。
您可以在YouTube上观看我的演示视频。
对于哈布罗夫斯克公民，我准备了报告的文本版本。
在研究代码可读性问题时，我遇到了一个有趣的主题StackOverflow。 它讨论了业务可读代码的重要性，以及它是否比性能和正确性更重要。 结果，根据社区成员的说法，最重要的标准是代码的可读性。
那时，我对代码可读性问题不感兴趣-我正在开发下一个互联网银行。 前端使用HTML5，AngularJS，LESS。 该项目是为俄罗斯最大的银行之一开发的。 我从Promsvyazbank转到了这个项目，在那里我开发了一个非常相似的互联网银行：相同的客户群，相同的用户数量，几乎相同的技术堆栈（HTML5，AngularJS，SCSS）。 但是，尽管项目之间有很大的相似性，但对我来说过渡仍然很困难。 一切都与风格有关。 这些项目的代码在设计和一般可读性上截然不同。 如果在Promsvyazbank中开发人员严格遵守指南，则在新项目中没有明确的样式规则。
那时，我才能够理解（甚至计算）大型项目为严格的样式指南带来的好处。 在分析了新项目的开发成本之后，我得出了与StackOverflow读者相同的结论：可读性是最重要的标准。
好的风格规则
John Papa为前端开发领域的知名专家AngularJS和Angular 2+创建了样式指南，以描述开发Angular应用程序时良好样式的规则。 在Promsvyazbank工作时，我了解了这些样式指南。 团队在所有项目上都清楚地关注了他们。 但是在新项目中，代码来自承包商，他们对编程风格没有那么认真的考虑。 在我的新团队中，我遇到了以前曾经完成的日常任务。 但是，这并没有给我任何好处，只有痛苦和折磨。
浪费时间的故事，或者为什么我们需要所有这些规则
John Papa的风格指南列出了很多规则。 重复列出它们是没有意义的，它们在
原始来源中已完美列出。 我将仅举几个例子，这些例子可以生动地展示专家建议的好处。
让我们从一个简单的开始
案例研究。 互联网银行的用户显示的汇率无关。 我的任务是在手术时加载当前课程。 我希望看到代码负责加载服务和组件中的汇率。 但是，当然，他不在那儿（否则我没什么可写的）。 事实证明，汇率是在app.run文件中的应用程序启动级别提取和过滤的，然后将其放入会话存储中。 显然这不是最佳方法。 另外，无论如何，要解决该问题，必须从那里取出代码。 花了整整一天的时间完成一个简单的任务。
现在，从样式指南中查看Bootstrapping规则（样式02-05）。
将用于启动应用程序的代码放在单独的文件中，不要将应用程序逻辑放在此文件中。 逻辑应放在服务和组件中。
百万个例子
正如您在上面看到的，仅忽略一条规则可能会造成麻烦。 但是，如果我们不立即听取一些建议，我们将遭受真正的严重后果。
案例研究。 我们的团队收到了任务：为住房和公共服务付款，请增加在付款中包括自愿保险金额的可能性。 在前端部分，这归结为一个简单的任务：在表单上放置一个复选框，如果包含该复选框，则会将保险费用添加到付款金额中。 在Promsvyazbank，我们很快处理了类似的任务。 但是在新项目中，一切都出错了。
由于付款模块的代码组织得非常不成功，因此该决定持续了几个月。 为了寻找最合适的选择，我们多次推迟了此任务，然后再次执行。 同时，银行在支付住房和公共服务方面存在困难。 最终，我们当然会解决这个问题。 但是我想知道通过这样一个简单的任务的例子，糟糕的代码会给组织造成多少损失。 我计算了解决问题所涉及的所有专家花了多少时间。 掌握了平均工资的统计数据。 我弄清楚了相关损失。 结果，我得出的结论是，如果我们在付款模块中最初有一个好的代码，我们将节省至少500万卢布。
查看John Papa的样式指南，我发现我们的模块一次违反了好代码的几条规则。 在评估了每个规则的影响程度之后，我确定了三个，违反这些规则最会使我们的工作慢下来：
- 统一规则-由于违反该规则，我注销了25％的损失时间；
- 单一责任-违反此原则导致整体损失35％；
- 提升-违反了这组方法，我认为我们当中40％的人最慢。
一律
我们的网上银行支持许多付款方式，其中某些付款方式彼此完全不同。 尽管如此，程序员还是尝试制作一种“通用”付款表格，该表格可以使用所有付款方式。
在表单本身上，组成了许多不同的块，这些块在某些条件下显示，而在其他条件下从未显示。 同时，它们由通用逻辑提供服务，这大大膨胀了ViewModel'i。
结果，所有这些导致了这样一个事实，即如果在一个地方添加了某些内容，那么不可避免地会在另一个地方掉落。 首先，事实证明该复选框的选择并没有改变金额。 我们试图解决金额字段。 但是在所有其他类型的付款中，该付款都无法编辑。 我们尝试用新字段替换金额字段。 但是验证的一般逻辑失败了：复选框可用，但是付款按钮不可用。 遇到类似情况了吗？
现在，让我们看看“一个规则”规则的内容。
每个单独的元素（例如组件或服务）都应放在单独的文件中。 您需要确保文件不会增长。 如果代码行数超过了不可思议的400，这肯定表明该组件值得破坏。
单一责任
当我们完成表单本身时，事实证明位于表单外部的功能停止工作。 例如，使用草稿付款的工作已损坏。 错误出现在操作历史中。 之所以发生这种情况，是因为除了付款表单本身以外的其他组件都与该表单的模型和付款控制器相关联。 更糟糕的是，尝试修复此功能使我们收到了损坏的付款表。
我们正在处理违反单一责任的经典案例。 长期以来，这一原则已包含在绅士的经验丰富的程序员集中。 他的风格指南明确建议在开发Angular应用程序时使用它。
应用单一责任原则（SRP）。
提升
我必须处理的最不便的事情就是浏览项目本身。 逻辑分散在几个文件中，并组合成一个难以理解的继承和委托层次。 从这些文件的名称来看，它们的用途根本没有实现。 文件位于不同的文件夹中。 在某些文件夹中，例如Controllers，以及许多其他文件中，我一直都在寻找当前所需的文件。 开发环境中打开的选项卡数量不适合计算机屏幕和我的脑海。 在调试过程中，到达帐户的第N个组件时，我已经忘记了走什么路以及为什么来到这里。 有时，有必要在调试器打开的情况下进行完全反向工程，以查找具有特定功能的文件位于哪个项目文件夹中。 对守则的累计仇恨使他的眼睛模糊，使他无法工作。
明智的样式指南也知道此问题。 为了解决这个问题，已经创建了LIFT规则组。 LIFT代表“定位”，“识别”，“平坦”和“尝试干燥”。 根据LIFT的原则，有必要以下列方式组织项目结构：
- 很明显，在哪里放置新组件以及在哪里寻找现有组件（查找）；
- 通过文件名（标识）清楚了组件的用途；
- 浏览文件夹，使用最扁平的结构（扁平）非常容易；
- 尝试不重复您的代码，但不要以其他规则为代价（尝试变干）。
LIFT方法由另外两个规则补充。
总体结构准则可为每个单独的组件创建一个文件夹，并将与此组件相关的所有文件分组。 例如，如果payment-form.controller.js文件不在Controllers文件夹中，而是在payment-form文件夹中与payment-form.html和payment-form.css一起使用，则更加方便。
按功能文件夹的结构建议创建单独的文件夹，并为项目的功能和主题区域使用相应的名称。 根据此规则，上述付款表格文件夹应与其他用于付款的组件一起位于付款文件夹中。
结果，如果代码的编写者遵循LIFT规则，则项目的结构将如下所示：
同意，这种用于组织代码的选项对读者来说更加方便。 而且他将为我们整个团队节省大量时间。
优秀的程序员去酒吧
我希望上面的例子听起来很有说服力，以使那些较早没有考虑过编程风格的读者可以渴望了解指南。 通常，良好阅读和维护的代码不仅对项目预算有利，而且对程序员本人也有利。 可读的代码更易于查看。 如果您需要同事的帮助，他们将迅速理解可读代码。 如果您只是新手专家，那么代码的可读性是您要做的第一件事。 即使您编写了非常正确且经过优化的代码，但绝对是不可读和不受支持的，您当然也会在团队中受到尊重，但是下班后您将不会被邀请到律师事务所。
如果这段文字使您想起或想起一些痛苦的熟悉事物，我将很高兴在帖子评论中看到它。