这绝不是详尽无遗的清单，而是我在IT工作了数年之后的主观排名。 希望您发现其中一些有用的

 

以下链接提供了该文章的俄语版本

谢谢吉娜！

1.童子军规则

"一定要让营地的清洁剂比您发现的要干净"-这是一个很好的生活准则。 当您靠近营地时，即使不是由您自己造成的，也应使其清洁。 这是侦察兵的规则之一。 编程同样适用。 正如罗伯特·C·马丁（Robert C. Martin）所说："让代码比发现的要好"。 如果我们发现别人写的一些难以阅读的应用程序，并且花了一些时间来理解，那就让它至少好一点。 如果它不在我们正在处理的任务范围之内，则可以始终创建一个新的小型技术任务，对其进行详细描述并将其带入下一个冲刺。

此规则的简约版本更像是在公共厕所中唱歌。 我们至少应该至少不恶化它所处的条件。我们必须记住，有些人有一天会接管我们开发的那部分应用程序，并尝试对其进行修改。 让我们不要让生活更艰难。

2.考虑问题，而不仅仅是解决方案

软件开发人员确实非常擅长实施解决方案。 我们了解语言，模式，库，框架，并了解如何使用它们。 问题在于，从业务的角度来看，我们经常做的事情没有任何意义。 您正在开发的某些功能可能与企业所有者不知道的现有功能重复。 有些可能没有经过深思熟虑，将永远无法发布到下一个版本，或者根本没有用户会使用它们。 那是浪费时间，金钱和挫败感的巨大浪费。 很多人都不想问开发人员他们的意见，只是假设他们的工作就是交付功能。 没有商量。 仅技术工作。

开发人员每天都在使用该应用程序。 他们知道每个功能，即使没有人使用它。 有时，从业务角度看似乎容易完成的任务需要花费数月的开发时间。 有些似乎几乎不可能的工作要花几天时间。 原因是将要实施一项功能的人员与提出该功能的人员之间缺乏沟通。 两者之间存在巨大差异：

· 为用户的购物车创建永久存储

· 用户应该能够保存他们的购物车，并在移动和Web应用程序上使用它

第一个很简单。 无话可问。 第二个要难一些，因为它使您思考推理，而您将成为提出给定问题的解决方案的人。 关于细节，功能要求，质量属性和其他方面，会有很多问题。 由于您现在不仅是执行者，因此解决方案将更好地解决。

3.考虑总拥有成本

有时会偷工减料，以后跳过测试，留下临时解决方案并承诺稍后进行纠正，这是非常诱人的。 在大多数情况下，如果它不会破裂，您将永远不会。 将有一个新任务，优先级，要实现的功能和要解决的问题。 您将遇到的问题是这样的应用程序可能会损坏。 而且，将很难修复。

功能的总拥有成本是从开发开始到部署，维护再到终止所花费的金钱和精力的总和。 如果我们在开发过程中采用捷径，那将是最便宜的部分。 您可能发布的速度更快，但是维护会很麻烦，用户会感到不满意，并且总的来说，所有东西都比它应该的贵。

第一次做就总是更好

4.使用SOLID

在编程中，有很多很棒的规则以首字母缩略词形式出现：DRY，KISS，YAGNI，SOLID等。 SOLID是一组规则，可以帮助使代码更整洁并避免常见的陷阱。

在将代码推送到存储库之前，这可能是一个很棒的清单。 该课程是否支持"单一责任原则"？ 可以用同一层次结构中的任何其他类替代该类（是否满足LSP）？ 这将有助于过滤掉许多未来问题的来源。 理解并有意识地运用每条规则背后的原因，将使您成为一名更好的程序员，并提高代码审查的质量。

5.使用设计模式

在大多数情况下，您不是第一个尝试解决您面临的问题或实现具有类似要求的功能的人。 已经有成千上万的CRM，CMS，银行系统，聊天室，在线商店，市场以及人们能想到的基本上任何可能的应用程序类型。 您正在开发的系统可能是市场上最好的，或者具有其他人所没有的某些极其先进和独特的功能。 不过，大多数工作在某种程度上都是参考性的。 其他人可能会尝试以多种不同的方式来做到这一点，甚至描述整个过程。 它可以为您省去很多麻烦，并为您提供更好的解决方案。

四人帮有一本很棒的书，介绍了一些可用于解决常见问题的可重复模式。 它写于1994年，但那些仍然有效和有用。 在软件中，那是古老的时代，但是现在我们在编写代码时面临的问题并没有太大不同。 从那以后，出现了许多新的设计模式。 了解他们可以使您的工作轻松得多。

所有设计都是重新设计。 向他人学习

6.最小化复杂度

从本质上讲，软件开发是一项复杂的任务。 不要使其变得不必要的复杂。 有时通过在函数中引入一些额外的" if"或"循环"来实现一些业务规则非常诱人。 开发将更快，但是代码将变得更暗，添加新功能只会使其变得更加复杂。 如果出现问题，将更难找出原因。

有一个伟大而又非常简单的度量标准，其秘密名称为" Cyclomatic Complexity"。 它是在70年代推出的，但仍然非常有用。 此度量标准衡量代码执行的多种方式。 每个条件语句和循环都将得分加+1。 分数越小越好。 当我们分析一种方法时，分数在范围内：

· 0-10：代码结构合理，不应引起意外问题

· 10–20：代码非常复杂，并且有很多潜在的执行路径可供测试。 重构候选人

· 20–50：代码非常复杂，应进行重构

· 50岁以上：必须进行重构

可读性比性能更重要。 该声明有一些限制，但从长远来看，可读性基本上是有回报的。 您可以使用更少的错误来更改代码。 微观优化可能很容易使您的代码变得一团糟，并且不会给用户带来太多价值。

7.不要一个人做

听起来可能违反直觉，但是编程是一种社交活动。 隐藏在地下室黑暗中的程序员时代已经结束。 分享专业知识和经验变得越来越重要。 在最坏的情况下，您要与之交谈的人将成为您的橡皮鸭，但很可能您会收到一些有价值的反馈。 有人可能会发现您根本没有考虑的解决方案中的问题。 从不同的角度看待是一个很好的工具，并且非常容易获得。

任何人都不应对已部署的代码负责。 提供新功能是团队而非个人的工作。 代码审查，配对编程，拉取请求是一种工具，可以承担一个人的责任，并将其移交给具有最佳跨职能技能的一群人。 对于可能影响整个公司业绩的重要功能，开发人员的责任实在太大了。 这种情况非常不健康，绝不应该发生。

8.测试是必须的

尽早发现错误非常重要，可以节省大量的工作量和客户的愤怒电话。 尽早发现问题使他们更容易解决。 在开发特定应用程序时，我们能够最好地记住所有细节和逻辑。 我们记得做出特定决定的所有理由以及如何调试每个应用程序。 修复错误的成本会随着时间呈指数增长。

> Source: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

 

9.学习英语

共享知识一直是软件社区的基础之一。 大多数信息是用英语编写的，并且易于访问。 目前，它是软件世界中最流行的语言。 如果您不会用英语读写，您将会遇到很多困难，并失去很多机会。 而且，几乎每种语言的语法默认情况下都是用英语书写的。

用英语写注释和名称也是一个好习惯。 它使代码更整洁，并且与语法更加一致。 如果我们要与他人（尤其是来自不同国家/地区的人）共享代码，那么基本上没有比英语更好的方法了。

10.多任务使你变得愚蠢

人们根本无法一次做好多件事情。 软件开发需要使用抽象概念，并且通常需要构建非常复杂的思维模型。 如果您分心或开始从事其他工作，那么您将失去一切，必须从头开始。 此外，有多项研究证明多任务处理对性能，生产率和智商有负面影响。

> Source: https://insights.sei.cmu.edu/devops/2015/03/addressing-the-detrimental-effects-of-context-

 

我曾经在软件公司参加过一次培训，介绍了一种非常有用的实践。 如果您没有任何预定的会议或电话，则可以自由播放"西红柿"。 规则非常简单-您无需与任何人交谈。 如果有人问您任何问题，您将用一个单词回答："西红柿"。 因此，您表明自己正在工作之中，不想被打扰。 人们处于"西红柿模式"时，他们还会在日历中显示选定的时间。 完全"蕃茄"化并不总是一件好事，但这是一种改善性能的有趣方式。

11.少做多好

更少的代码和更好的维护基础架构。 有很多人喜欢在他们的应用程序，模块，服务器，节点，pod，微服务或任何其他东西中吹嘘大量的代码行。 应用程序中的每一行代码都有可能具有最高的质量，并且恰好位于正确的位置。 但这是非常罕见的情况。 如果您可以使用较少的资源来完成相同的工作，则应该这样做。 质量是目标，而不是数量。

资源：

· "每个程序员都应该知道的97件事"，Kevlin Henney

· " Scrum：在一半的时间内完成两次工作的艺术"，Jeff Sutherland

· Robert C. Martin，"清洁代码"

· GoF的"设计模式"

· https://stackoverflow.com/questions/9097987/calculation-of-cyclomatic-complexity

· https://martinfowler.com/bliki/OpportunisticRefactoring.html

· https://Appliedpsychologydegree.usc.edu/blog/to-multitask-or-not-to-multitask/

(本文翻译自Jakub Kapuscik的文章《11 rules of effective programming》，参考：https://medium.com/swlh/11-rules-of-effective-programming-8932f2d99711)