44

一段时间以来，我一直在编写一份清单，以帮助我分享编程方法的原因和想法，以及如何做某事。

为此，我想建立一个清单：

  • 最佳实践，
  • 最好的想法，
  • 最好的方法...

这有助于程序员以最有效的方式分析、思考、处理、解决和实施的能力。

我在整个 Stack Overflow 的问题中看到了数十条非常有价值的评论，但我找不到将它们放在一起的地方。关于 Stack Overflow 的观点最有争议。但是，我只是在寻找可以分享并帮助我的团队的明智见解，我通过更好的编程更好地处理和解决问题。

希望这可以成为收​​集一两个简明、深刻且易于分享、重复和回顾的衬里的地方。如果我们对每个答案都保持一条规则，那么投票赞成/反对可能是最容易的。

我将从第一个开始。

DRY - 不要重复自己 - 在代码、注释或文档中。

4

64 回答 64

52

总是让代码比你找到它时好一点。

于 2009-02-05T00:08:23.383 回答
52

代码在进入版本控制系统之前是不存在的。

于 2009-02-05T00:10:08.157 回答
35

不要害怕承认“我不知道”并问。

10 分钟询问某人可以节省一天的时间拉你的头发！

于 2009-02-05T00:28:41.957 回答
32

不要重新发明轮子

如果核心库中应该有一个函数 - 可能有。

于 2009-02-05T00:14:36.413 回答
32

KISS - 保持简单，愚蠢。
选择最简单的可行解决方案。
在需要之前不要让事情变得（太）复杂。
仅仅因为其他人都在使用一些复杂的框架来解决他们的问题，并不意味着你必须这样做。

于 2009-02-05T01:04:13.273 回答
29

可维护性很重要。

编写代码，就好像最终维护它的人很疯狂并且知道你住在哪里一样。

于 2009-02-05T00:27:51.630 回答
27

别人不会修。

如果问题引起您的注意，请拥有足够长的时间以确保以一种或另一种方式处理它。

于 2009-02-05T00:11:49.713 回答
26

除非有明显的问题，否则不要优化。
大多数时候，当人们在证明有必要之前尝试优化代码时，他们会花费大量资源，使代码更难阅读和维护，并且没有明显的效果。有时他们甚至会使情况变得更糟。

“我们应该忘记小的效率，比如大约 97% 的时间：过早的优化是万恶之源。”
——唐纳德·克努斯

于 2009-02-05T00:18:02.117 回答
24

它能有多难？
不要让任何问题吓倒你。

于 2009-02-05T00:17:21.277 回答
23

不要收集需求——挖掘需求

需求很少停留在表面上。它们深埋在假设、误解和政治的层层之下

通过务实的程序员

于 2009-02-05T01:01:12.357 回答
20

遵循SOLID 原则：

单一职责原则(SRP)

改变班级的理由不应该不止一个。

开闭原则(OCP)

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

里氏替换原则(LSP)

使用指向基类的指针或引用的函数必须能够在不知情的情况下使用派生类的对象。

接口隔离原则(ISP)

不应强迫客户依赖他们不使用的接口。

依赖倒置原则（DIP）

A. 高级模块不应依赖于低级模块。两者都应该依赖于抽象。

B. 抽象不应依赖于细节。细节应该取决于抽象。

于 2009-02-05T00:33:43.083 回答
16

我认为“Python 之禅”下列出的几乎所有内容都适用于每个“编程思维规则”列表。从 'python -c "import this"' 开始：

Python 之禅，蒂姆·彼得斯 (Tim Peters)

  • 美丽总比丑陋好。
  • 显式优于隐式。
  • 简单胜于复杂。
  • 复杂胜于复杂。
  • 平面优于嵌套。
  • 稀疏比密集好。
  • 可读性很重要。
  • 特殊情况不足以打破规则。
  • 虽然实用胜过纯洁。
  • 错误永远不应该悄无声息地过去。
  • 除非明确沉默。
  • 面对模棱两可，拒绝猜测的诱惑。
  • 应该有一种——最好只有一种——明显的方法来做到这一点。
  • 虽然这种方式一开始可能并不明显，除非你是荷兰人。
  • 现在总比没有好。
  • 虽然从来没有比现在更好。
  • 如果实现很难解释，那是个坏主意。
  • 如果实现很容易解释，那可能是个好主意。
  • 命名空间是一个很棒的想法——让我们做更多的事情！
于 2009-02-05T01:08:34.277 回答
16

最佳实践：用你的大脑
不要不考虑任何趋势/原则/模式

于 2009-02-05T07:58:32.080 回答
15

测试驱动开发 (TDD) 让程序员晚上睡得更好

澄清一下：有些人似乎认为 TDD 只是一种不称职的编码人员从 A 到 B 跛行的方式，而不会让所有事情变得太多，如果你知道你在做什么，那就意味着不需要 (unit)测试方法。这完全忽略了测试驱动开发的重点。TDD 大约是三件事（更新：显然是四件事）：

  1. 重构魔法。拥有一整套测试意味着您可以进行其他疯狂的重构特技，在应用程序的整个结构之间进行调整，而不会错过由此产生的 200 种疯狂的微妙副作用中的任何一种。即使是最好的程序员也不愿意在没有良好（单元）测试覆盖率的情况下重构他们的核心类和接口，因为如果没有它们，几乎不可能追踪所有小的“涟漪效应”。

  2. 及早发现陷阱。如果您以正确的方式编写测试，则意味着强迫自己考虑所有边缘情况。通常，一旦实际开发开始，这会导致更好的设计选择，因为编码人员已经考虑了一些可能需要不同继承结构或更灵活设计模式的棘手情况。在初始规划和分析期间，这些更改的需求通常并不明显或不直观，但这些确切的更改可以使应用程序更容易扩展和维护。

  3. 确保编写测试。TDD 要求您在编写代码之前编写测试。当然，这可能会让人头疼，因为与编写实际代码相比，编写测试是乏味的——而且通常也需要更长的时间。但是，这样做是确保编写测试的唯一方法。如果您认为代码完成后您会记得编写测试，那您几乎总是错的。

  4. 强迫你写出更好的代码。由于 TDD 强制所有代码都是可测试的（在对其进行测试之前，您不会编写代码），因此它需要您编写更多解耦代码，以便您可以单独测试组件。所以 TDD 迫使你编写更好的代码。（谢谢，Esko）

于 2009-02-05T00:13:30.537 回答
15

在你问你的同事并打断他的编码之前先谷歌一下。

于 2009-02-05T08:29:07.587 回答
13

更少的代码总比更多的好，只要它比大量的代码更有意义。

于 2009-02-05T00:18:41.790 回答
13

懒惰的程序员的习惯

当你第一次被要求做某事时，就去做（对）。

第二次要求您执行此操作时，请制作一个自动执行此操作的工具。

第三次，如果工具不能解决问题，请设计一种特定领域的语言来生成更多工具。

（不要太认真）

于 2009-02-05T01:10:09.767 回答
10

成为变革的催化剂

你不能强迫人们改变。相反，向他们展示未来的样子并帮助他们参与创造它。

通过务实的程序员

于 2009-02-05T00:58:13.410 回答
10

调试时不要惊慌

深呼吸并思考！关于可能导致该错误的原因。

通过务实的程序员

于 2009-02-05T01:08:38.117 回答
10

您可以复制和粘贴以使其正常工作，但您不能保持这种状态。

重复的代码是一个中间步骤，而不是最终产品。

于 2009-02-05T01:10:48.767 回答
9

这既是你所说的，也是你所说的方式

如果你不能有效地传达它们，那么有伟大的想法是没有意义的。

通过务实的程序员

于 2009-02-05T00:59:34.030 回答
9

始终编​​写代码，就好像最终维护您的代码的人是一个知道您住在哪里的暴力精神病患者一样。

来自：编码恐怖

于 2009-02-05T08:02:46.173 回答
7

尽早发布，经常发布

于 2009-02-05T00:07:17.273 回答
7

Build Breaker 购买午餐

于 2009-02-05T00:11:57.497 回答
7

首先正确构建它。让它快第二。

于 2009-02-05T00:34:51.927 回答
7

经常进行代码审查

代码审查和重构是一项持续的任务。在我看来，这里有一些关于代码审查的好处：

  1. 它提高了代码质量。
  2. 它有助于将可重用代码重构为可重用库。
  3. 它可以帮助您向其他开发人员学习。
  4. 它可以帮助您从错误中吸取教训，并刷新您对以前编写的天才代码的记忆。
于 2009-02-06T06:36:32.943 回答
6

任何可能影响应用程序运行方式的东西都应该被视为代码，这意味着将其置于版本控制中。尤其是构建脚本和数据库架构和数据 (.sql) 文件。

于 2009-02-05T00:40:39.357 回答
5

约定优于配置

特别是在约定很强大并且可以牺牲一些灵活性的情况下。

于 2009-02-05T00:09:00.857 回答
5

参与开源开发

如果您在项目中使用开源代码，请记住将您的错误修复和改进发布回社区。这本身不是一个开发最佳实践，但它绝对是程序员努力争取的心态。

于 2009-02-05T01:53:15.700 回答
5

了解您使用的工具

在你明白为什么要使用它之前，不要使用它；不要在不知道为什么的情况下使用工具；不要依赖你的框架或语言设计器总是适合你的情况，但也不要假设他们是错误的，直到被证明是错误的！

于 2009-02-05T12:40:51.290 回答
4

思考！关于你的工作

关闭自动驾驶仪并进行控制。不断地批评和评价你的工作。

通过务实的程序员

于 2009-02-05T01:05:28.340 回答
4

把你的工作想象成一门手艺，而不是一项职责。

于 2009-02-05T02:12:08.860 回答
4

退一步看全图

每隔一段时间，你应该从你的代码中退后一步，用抽象的术语思考你在做什么。如果你不这样做，你会忽略几天后会回来咬你的东西。

我喜欢深入研究代码，但有时我需要回到表面呼吸一些空气……

于 2009-02-05T10:30:47.463 回答
3

计划第一，设计第二，代码第三，始终测试。

于 2009-02-05T00:23:00.970 回答
3

  1. 受众——我们构建的一切都是为了受众，最终用户和其他编码人员都将使用它。确保两者都可以使用。

  2. 简单——如果你发现自己实现了一些复杂而令人费解的东西，你可能会错过一个更有效、更简单的解决方案。

  3. 质量，而不是完美——记住什么是重要的——在一个时间范围内提供质量。如果您将估算值翻倍，那么提供完美将无法节省您的时间。

于 2009-02-05T01:09:23.433 回答
3

如果你被卡住了，就说出来（即使你只和橡皮鸭说话）

于 2009-02-05T12:14:03.137 回答
3

永远不要告诉企业一切！

重构是你工作的一部分，而不是需要讨论的事情。如果您总是添加一点“估计”时间来进行必要的重构，那么就不会有任何抱怨！

于 2009-02-08T00:59:00.033 回答
2

设计模式是你的朋友

确保将《四人帮》的副本放在某处作为参考。

于 2009-02-05T00:11:35.063 回答
2

不一定是艺术，但一定要准时

新闻界的一条老规矩，我必须通过艰苦的方式学习。

于 2009-02-05T01:14:33.593 回答
2

始终构建原型。十分之九，这将是值得的一天/一周/一个月。推论：在原型上花费的时间长度应该与主要项目的长度/大小成正比。

于 2009-02-05T11:12:18.690 回答
2

雅尼

你不需要它

批评你的所作所为，AKA 认为！

于 2009-02-05T20:19:11.363 回答
2

请参阅博客文章实用程序员快速参考指南。*

于 2009-02-05T23:46:57.543 回答
2

数量永远胜过质量

编码更多（即使它不是很好）将使您更好地了解好的代码应该是什么样子。

于 2009-02-06T13:21:46.870 回答
1

宣布一切。永远不要将 15 个函数嵌套到 1 个变量中。

于 2009-02-05T00:34:11.040 回答
1

与其说“我不知道”，不如说“我想知道”。它将您的方法从避免/反应转变为主动发现和增长。

于 2009-02-05T00:43:14.500 回答
1

红色，绿色，重构！

TDD 或测试驱动开发。

  1. 为您要开发的功能编写测试，确保它们失败，因为您还没有编写任何代码。

  2. 编写使测试通过所需的最少代码量。

  3. 根据需要进行重构，以提高效率或清晰度。

  4. 重构后，确保您的测试仍然通过。

于 2009-02-05T00:43:48.167 回答
1

这来自史蒂夫麦康奈尔

“每一行新代码都应该通过调试器单步执行”

于 2009-02-05T05:04:36.267 回答
1

从来没有你想的那么容易

这是对另一个答案的回应，但并不矛盾！两者都是应遵循的宝贵原则。

于 2009-02-05T10:42:25.490 回答
1

对于数据库...

尽可能标准化。然后再次正常化。

拥有一个良好的数据库（在结构和数据方面）对于减轻编程压力至关重要。

于 2009-02-05T20:32:32.537 回答
1

您的代码应该非常简单，以至于任何查看它的人都可以在不阅读任何文档的情况下理解它的作用。

但无论如何不要忘记记录所有内容。

如果您的 API 使用起来不是很简单，那么 API 就有问题。重构它，直到不费吹灰之力就能正确使用。

在您编写任何代码之前，请先研究一下框架是否已经为您尝试做的事情提供了内置支持或可扩展接口。

于 2009-02-06T06:49:06.133 回答
1

尽早发现错误：

  • 使用静态类型语言，以便编译器和静态分析可以帮助您。
  • 单元测试（第一个或最后一个）
  • 代码审查
  • 持续集成
  • 最后，最重要的事情——持续学习。
于 2009-02-06T06:57:48.907 回答
0

了解SOLID原则（或任何其他原则或方法）的意图。

于 2009-02-05T00:47:36.707 回答
0

有些事情做得比描述的要好

不要陷入规范螺旋——在某些时候你需要开始编码。

通过务实的程序员

于 2009-02-05T01:07:21.597 回答
0

努力寻找需要最少代码的解决方案。

于 2009-02-05T01:16:39.083 回答
0

创建软件就像……盖房子。

您可以尝试在没有蓝图、计划、经验、建筑师或合格技工的情况下构建它。

因此，它几乎总是会花费更多、花费更长的时间，并且充满未来、持续不断的惊喜，需要你的时间和金钱。

仅仅因为有人可以在没有蓝图的情况下建造棚屋并不意味着他们应该这样做。

于 2009-02-05T02:01:57.680 回答
0

我在上一份工作中为我的团队创建了一个文档，因为他们没有任何编程指南、建议或任何东西……它开始变得相当大，但一切都说得通。

我很乐意分享。但这不仅仅是一条规则，它更像是“编码指南”。

以下是我的文档包含的示例大纲：

        A. 源代码
           一种。格式化
           湾。变量命名
           C。错误处理
           d。日志记录
           e. 文本编辑器
           F。范围声明
           G。评论/评论块
           H。文档
           一世。API/库开发标准

       B. 源代码控制
          一种。入住/退房
          湾。版本信息
          C。什么属于源代码管理？

这是A部分的一个例子。 

源代码

文本编辑器：

文本编辑器的选择完全取决于开发人员。字体应该是等距的，不大于 18 并且不小于 8。虽然这是开发人员的选择，但代码注释应该出现在源文件的顶部，指示哪个编辑器、字体、字体大小以及缩进大小（如果适用）应该在场。有关更多信息，请参阅评论/评论块。 

标签：
标签不应该在源文件中。制表符应替换为空格，并且缩进为 4。 
行尾：
行尾应采用 CRLF 格式。大多数 {your company name} 源代码都在 Windows 平台上，因此应将行尾设置为 CRLF 以便在 Windows 上可读。任何源文件中都不应混合行尾。 
线长：
大多数行的行长不应超过 200 个字符。很长的单语句源行是可以接受的。函数定义或函数调用应该被分解（并记录在案）。（有关更多信息，请参阅 API/库部分。）

当然，这适用于美国，您的 MMV，您必须调整规则以匹配您的编码风格。

于 2009-02-05T02:07:05.610 回答
0

不要试图让事情变得更简单。

知道你在做什么比单元测试更可取。

了解技术优于测试驱动开发。

你为什么要用反复试验的方法来浪费你的生命？

于 2009-02-05T08:20:11.723 回答
0

“我只是看不到它怎么会失败”只是“它会失败，我只是看不到如何”，并且重新排列了单词。测试一切！

于 2009-02-05T11:45:29.653 回答
0

  1. 理解/演练好的、坏的和丑陋的应用程序代码。您将更好地了解哪些有效，哪些无效。

  2. 与人（包括 IT 和业务）交谈，不要害怕提出问题。这以两种方式对您有用：-

    a) 你变得更平易近人，因为你看起来比不说话的书呆子更人性化

    b) 您对应用程序进行编码/设计的方法是基于真实的答案——不仅仅是文档/电子邮件，这可能已经过时了。

于 2009-02-05T13:28:13.877 回答
0

始终为您的代码编写文档！半年后你不会记得它是如何工作的。所以不要在没有文档的情况下编写任何代码！

于 2009-02-06T08:23:38.373 回答
0

第一次从来都不容易。之后每次都可以轻松完成。这就像你第一次开车去某个地方时试图找到一条捷径。在 GPS 之前。

于 2009-02-06T19:19:45.523 回答
0

根据定义，没有单元测试的代码是被破坏的。

不言自明。

于 2009-02-08T00:54:06.363 回答
0

对某事（流程/软件）知之甚少的人是世界上最危险的人。

于 2009-03-10T00:46:07.767 回答
0

编写不言自明的代码（然后仍然记录它），其中包括

  • 有意义的名称避免缩写，尤其是辅音簇
  • 刚刚引入的函数使真实代码像伪代码一样读取
  • 在一个代码单元等内保持抽象级别不变。
于 2009-04-11T19:59:13.983 回答