关于短绒棉，代码质量，一般质量和质量管理

害怕你的欲望；它们可能成真。
民间智慧。

一对夫妇希望结婚并找到永恒的幸福。 婚礼后，我立即在教堂炸毁了他们的汽车。
一项愿望补助金，电影60号公路。



关于管理以及在这种情况下的质量的另一个哲学注释包括三个部分：非常抽象，适度抽象，具体和单独的结论。 它批评了目前使用短绒棉的做法。

关于质量的非常抽象的部分

首先，我想谈一谈质量，或者说是任何事物的质量管理，是关于广义上的产品，人类活动产生的产品，无论是创建新产品（编写代码或图片，设计太空飞船），切断多余的产品（雕塑） ，碾磨，选择优质水果）或进行转化（运输，冷冻，包装，从汽油生产汽油和塑料）。

好的产品有一些迹象表明它是高质量的。 不同的产品有不同的标志。 例如，好水果闻起来可口，外观好，味道好。

现在，我将给出一个双曲线示例，稍后，我将直接转到代码。

想象一下，我们有一家水果店，有一个问题，我们的水果开始卖得不好，而竞争对手有直接的渠道。 我们进行了一项研究，发现柜台附近的气味对游客不利。 竞争对手商店里的气味就像。 哦，发现了问题，根据气味的顾客满意度指数！ 解决这个问题吧，这里有芳香疗法市场部，我们只是将自动安装装置放在架子附近，并散发出苹果园的美妙气味。 他们做到了。 顾客对气味的满意指数自然会上升。 直到现在，买家人数甚至更少。

如果您认真看待，最初的问题可能会完全不同：

1. 我们的竞争对手销售同样高品质的水果，但他们在我们之前进行了芳香营销，并以香气吸引了参观者。
2. 我们的水果很好，但竞争对手的水果确实比我们的水果好（品种，储藏等）
3. 我们的水果烂了。 他们只是烂了而臭。
4. 去年陈列柜后面的水果烂​​了，我们希望我们仍然可以出售它们。 他们从那里发臭。
5. 竞争对手种类更多
6. 一般而言，竞争对手与我们的水果一样，摆出的果实更加精美。
7. 那里便宜得多
8. 那里的卖家很漂亮，在我们这个地方，巴巴曼娅（Baba Manya）代替了...

显然，只有在第一种情况下，芳香营销才能帮助我们。 在某些方面它可以提供帮助，但可以掩盖真正的问题，但在第三方面，它要么不采取任何措施，要么会引起更大的反感。 哦，问题是水果多久腐烂一次。

实际上，当出现此类问题时，有必要对原因进行全面分析，并分别针对具体情况做出决定。

更夸张的

您有绿色的西红柿，而且您知道只有红色的西红柿被出售。 无需油漆西红柿。 可以加快乙烯的成熟速度 。 它将完全成熟，而不是绘画。 如果无法加速，则有必要扔掉这些西红柿，换个新的，已经很好的西红柿。

换句话说，如果您对最终产品的质量不满意，则说明其生产链中存在问题，您需要分析和更改过程，而不要在输出中进行涂装。

好吧，你明白了。 如果有异味，香水将无济于事。

关于代码质量的适度抽象部分

在好的代码的属性中，我们将发现（没有按重要性排序）：

• 风格的一致性
• 可读性
• 表现
• 可扩展性
• 体系结构和模式的透明度。

这主要是通过开发人员的自律和技能水平来实现的，以及在有许多开发人员时通过代码样式协议和体系结构协议（MVC，MVVM，ECS，成千上万个）来实现。 高质量代码的出现要早于linter，任何约定和体系结构模式。
短绒的大多数规则都是纯修饰性的，它们解决了由于统一使用小型和本地实践而增加了代码可读性的问题。 此处的行长，变量名称，const（无修改），有时甚至对函数的圈复杂度引入了限制。 这不是关于特定规则，而是关于这些规则通常是修饰性的事实，它们有助于使代码看起来更好。 这里的关键词是看 。

当任何指标开始用作目标时，它就会失去其作为工具的价值。
对古德哈特法则的自由解释。

现在让我们用西红柿做一个比喻。 我们还不够成熟。 自动棉绒将告诉我们：“看看这里，没有正确的颜色。” 程序员将做什么？ 很多时候画。 这是我批评棉短绒的主要思想。 现在，我将举一个具体的例子，然后得出一个结论。

细节

PixiJS 2018年2月2日（一年前）。

请求池到达 。 底线是以前使用恒定数量的点来绘制曲线，这显然不是最佳的。 建议使用狡猾的算法来估计曲线的长度。 该算法不是火箭科学，但绝对不是显而易见的，该算法于2013年发布， 并被其作者的一篇文章引用（https中有问题）。 他通常在个人页面上保留的幸福。

有一个C代码（16行）：

float blen(v* p0, v* p1, v* p2) { va,b; ax = p0->x - 2*p1->x + p2->x; ay = p0->y - 2*p1->y + p2->y; bx = 2*p1->x - 2*p0->x; by = 2*p1->y - 2*p0->y; float A = 4*(ax*ax + ay*ay); float B = 4*(ax*bx + ay*by); float C = bx*bx + by*by; float Sabc = 2*sqrt(A+B+C); float A_2 = sqrt(A); float A_32 = 2*A*A_2; float C_2 = 2*sqrt(C); float BA = B/A_2; return ( A_32*Sabc + A_2*B*(Sabc-C_2) + (4*C*AB*B)*log( (2*A_2+BA+Sabc)/(BA+C_2) ) )/(4*A_32); }; 

并将以下代码（JS）发送到请求池：

 /** * Calculate length of quadratic curve * @see {@link http://www.malczak.linuxpl.com/blog/quadratic-bezier-curve-length/} * for the detailed explanation of math behind this. * * @private * @param {number} fromX - x-coordinate of curve start point * @param {number} fromY - y-coordinate of curve start point * @param {number} cpX - x-coordinate of curve control point * @param {number} cpY - y-coordinate of curve control point * @param {number} toX - x-coordinate of curve end point * @param {number} toY - y-coordinate of curve end point * @return {number} Length of quadratic curve */ _quadraticCurveLength(fromX, fromY, cpX, cpY, toX, toY) { const ax = fromX - ((2.0 * cpX) + toX); const ay = fromY - ((2.0 * cpY) + toY); const bx = 2.0 * ((cpX - 2.0) * fromX); const by = 2.0 * ((cpY - 2.0) * fromY); const a = 4.0 * ((ax * ax) + (ay * ay)); const b = 4.0 * ((ax * bx) + (ay * by)); const c = (bx * bx) + (by * by); const s = 2.0 * Math.sqrt(a + b + c); const a2 = Math.sqrt(a); const a32 = 2.0 * a * a2; const c2 = 2.0 * Math.sqrt(c); const ba = b / a2; return ( (a32 * s) + (a2 * b * (s - c2)) + ( ((4.0 * c * a) - (b * b)) * Math.log(((2.0 * a2) + ba + s) / (ba + c2)) ) ) / (4.0 * a32); } 

该代码是完全根据短绒棉布的设置设计的。 指示了所有参数的说明，原始算法的链接，一堆常量（根据不混合运算符linter的要求）：排列了1个括号。 即使出于性能考虑，api并非客观地完成，而是使用单独的参数，因此通常在JS中通常会更好。
有一个问题。 此代码构成了完全的垃圾。 （试图用俄语标记该表达方式是不正确的，这在西方出版物中已广泛用于表达问题的程度，而且似乎是适当的）。


很大的长度回来了，上面有很多点，这很好，上面有一个限制，它起作用了。 以前，此模式默认情况下处于禁用状态，但随后又对所有人打开（由于另一个错误）。 修复已经践踏的方式 。 我没有联系提交的作者，也没有问他为什么决定放括号，但是我觉得他启动了linter，其配置文件已经在PixiJS中了。 这位短毛猫告诉他，您的代码很糟糕，因为它缺少方括号，请添加方括号。 选项“ no-mixed-operators”表示您没有写权

 2*2+2*2 

因为它会导致可读性差。 有人创建了这个选项，然后有人将其包含在项目中，这意味着许多人认为它很有用。

结论

我不想说棉绒是邪恶的，但我认为对它们的使用是邪恶的。 我们（从人类的角度而言）能够自动识别良好代码的一小部分迹象，主要是括号之类的化妆品。 Linters可以很好地用作分析代码质量的工具，但是，一旦我们将Linter的要求提高到强制性要求的框架，我们就会非常满足这一要求。 除了合规，我们一无所获。 这是将照相机放在传送带上的西红柿中，然后将所有不够红的油漆上漆的方法。 在我们为开发人员提供了一种评估代码外观质量的工具之前，他可以发送错误的代码，然后我们才能看到它。 现在，错误的代码将被更好地掩盖。 它将模仿一个好的代码，因为上面有所有外部代码都表明有好的代码。 而且，由于所有代码都是一致的，因此我们将失败者当作评估工具使用。 我们有一个评估工具，但是现在不存在了，但是带括号的代码虽然有时不存在，但是这些是详细信息。 总的来说，我认为 linter 是一个很酷的工具，但前提是不能满足要求 。

是的，在这里我们可以说没有测试，您不需要复制粘贴代码，这是stackOverflow开发，不需要在您不理解的项目中插入代码。 就是这样。 这是错误代码的标志。 但是，lint帮助使它在外观上与项目中的其他所有内容相似。 但是，lint永远不会检查您是否理解自己写得很好。

换句话说，我相信短绒棉衣的正确用法是定期作为项目负责人启动短绒棉衣，并评估其进展情况。 好吧，规则之类的方括号之类的方括号，从原则上讲，我认为是有害的。 当我们发现某人提交的代码质量很差时，有必要了解他为什么这样做并更深入地解决此问题。 自然，您不需要用手来格式化代码；我欢迎以各种可能的方式使用自动格式化程序，但是直到他们以任何方式接触到代码的语义部分。 如果我们强迫人们用短绒棉把代码带到标准中，那么我们实际上将绿色的番茄涂成红色。 而且，将很难理解它实际上是绿色的。 在由一群不同的人组成的开源项目中做什么，这个问题更加复杂，但是即使在这里，您也可能会考虑做什么。

值得一提的是，我对短毛绒的态度是在很久以前，三年多以前就形成的，但是当短毛绒玩笑时，我在实践中找不到合适的榜样。 所以我找到了他。 我一直在寻找它的事实表明，问题并没有那么广泛，或者注意到负面影响有多么困难，但是我认为本文将是有用的。 请记住，短绒棉是一种工具，就像其他任何工具一样，它可能会有害和有益，并且有时会导致您使用任何工具割伤自己。