Get best of the week

纯代码：因果



作者：Victor Svirsky，DataArt高级Python开发人员/团队负责人

多少程序员，这么多定义，什么是干净的代码。面试时，我经常听到好的代码是易于阅读的代码。我同意，但是正如我的亲身经历所暗示的那样，这只是冰山一角。

告诉我们代码不再干净的第一个铃铛是，新功能的开发时间增加了，而系统中的改动最少，回归范围也增加了。这是由于以下事实：技术债务不断累积，系统中的各个组件之间紧密相连，并且没有自动测试。其原因可能是：

  • 外部-例如来自企业的压力及其对更快获得新功能的渴望。
  • 内部-开发流程不完善以及团队内部的互动，缺乏控制和开发标准或能力普遍缺乏。

不要将代码和体系结构的质量推迟一整天。在sprint期间，重要的是能够分离对业务直接有价值的任务（具有新功能的任务）和仅对业务具有间接影响的技术任务。分离的比例取决于项目的当前状态，时间范围和空手的数量。

什么是干净代码？


事实证明，代码是干净的，系统设计正确，仅阅读代码还不够。他必须具备其他素质：

  • . . , . , , .
  • , , . , . . , . , .
  • . . . -, OWASP.
  • — , . , , . , , . , .
  • . , . , .

为了避免对其代码质量进行主观评估，1961年引入了“代码气味”或“股票代码”一词。这是一组规则和建议，它们明确定义了是否应该进行重构。“气味”导致代码衰减，开发人员应始终努力消除它。重构的需要直接来自代码的味道，并且通过防止原因，我们可以避免后果。您可以在Martin Fowler的著作《重构》中详细了解应该开始重构的关键标志。改进现有代码。”

我应该写干净的代码吗？


绝对值得！但并非总是如此，并非在所有地方都值得对清洁度给予过多关注。

不要忘记代码的有用性和寿命。例如，如果您面临开发概念-PoC（概念证明）的任务，并且证明所选的技术堆栈可以执行此任务，则您的代码将在一两周内变得无关紧要。改进此功能是不值得的。

有意见认为，不必监视即将被替换的代码或系统部分的质量。由于某些原因，这是不正确的。高质量的工艺将使过渡或与新零件的集成更容易，更无缝和更快。在必须同时支持多个版本的代码的情况下，无疑可以简化工作。使用干净代码的回归错误数将少很多倍。同样，不要忘记没有什么比临时的更永久的了。可能需要几个月的时间来改进这部分代码，这仍然是积压的任务。

什么将有助于改善您的代码？


大多数程序员都梦想着可以快速而精美地编写代码，从而使所有功能都能在第一时间完美运行。但是，并非所有人都能成功地使代码不仅有效，而且易于理解。如何成功编写干净的代码？有两种方式-自组织和团队合作。



自组织


考虑几种可能的方法来提高单个代码的质量。这些建议适用于任何级别的开发人员。


  1. , — . — . IDE ( ) , , . IDE , . — .

    . , .
  2. open source
    . , . , . !

  3. , . . . , , 10, , . .

    . -, .

  4. . . . .

    . .


  5. . . - . , .

    — , , , , .


  6. , . — .
  7. !

    , .


大多数任务是团队解决的。在参与者之间分担质量责任非常重要。团队越大，保持产品处于良好状态的难度就越大。让我们考虑以上条件下的几种代码保留方法。

  1. 代码审查
    这是理解和执行的简单原则。包括代码作者在内的至少两个人检查该代码。

    检查代码时，需要考虑以下几点：

    • 其中一项是检查代码是否违反了代码协议的规则。此过程可以并且应该使用CI（连续集成）中的静态分析器来自动化。
    • 其他是无法自动验证的代码可维护性和错误处理。
    • , , . , ?

  2. (Continuous integration)

    , .

    , :

    • . . , . , , .
    • , , .
  3. (Coding onventions)

    . , . , , .

    , , , . . , , . , . , . .

    , , . — , - .

    . , . .


  4. , . , , .

    , . , . , , .

    -. . , . . , .


  5. , , . . , .

    , :

    • ? , . , .
    • ?
    • ()?
    • ?
    • — ?

    , , . , .


  6. , . SonarQube. :



    • — . , . , .


    • , — DRY (Don’t repeat yourself).


    • . . . , .


    • , , , .


    • . , . , .

***


代码中的错误类似于碳足迹。这是完全不可能逃脱的，光是过量的废气就不会杀死人类或其周围的自然环境。尽管如此，减少当今人在地球上的负面影响似乎是很自然的需要。以几乎相同的方式，编写干净的代码是每个开发人员的责任。无论选择哪种方式，都必须努力编写可理解的代码。

好吧，考虑到我们代码的使用寿命并评估进一步改进的可行性，如果您不能将纯粹变成一种迷信。关于人员，要记住的主要事情是：即使是我们开发的系统的一小部分都可能导致故障的用户，以及必须支持该系统的工程师。

More articles:


All Articles