我正在为我的团队编写一套编程思维规则:你的是什么？

Question

我已经在列表上工作了一段时间,这有助于我分享编程方法和想法的原因以及如何做某事.

为此,我想建立一个包含以下内容的列表:

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

这有助于程序员以最有效的方式分析,思考,接近,解决和实施.

我在Stack Overflow的整个问题中看到过几十个非常有价值的评论,但是找不到我们将它们放在一起的地方.Stack Overflow上有最有争议的观点.但是,我只是在寻找可以分享并帮助我的团队的圣人见解,并通过更好的编程来更好地解决问题.

希望这可以是一个收集一两个简洁,深刻且易于分享,重复,审查的衬垫的地方.如果我们按照每个答案保留一个规则,那么最简单的投票可能是最容易的.

我将从第一个开始.

干 - 不要重复自己 - 在代码,评论或文档中.

Answer 1

始终保持代码比找到代码时更好.

Answer 2

在进入版本控制系统之前,代码不存在.

Answer 3

不要害怕承认"我不知道"并提出要求.

10分钟,有人可以节省一天拉头发!

Answer 4

不要重新发明轮子

如果在核心库中应该有它的功能 - 可能有.

Answer 5

吻 - 保持简单,愚蠢.
挑选一个最简单的解决方案工作.
在他们需要之前不要让事情(太)变得复杂.
仅仅因为其他人都在使用一些复杂的框架来解决他们的问题,并不意味着你必须这样做.

Answer 6

可维护性很重要.

编写代码,好像最终维护它的人是疯了,知道你住在哪里.

Answer 7

其他人不会解决它.

如果您的注意力出现问题,请将所有权保留足够长的时间以确保以某种方式处理.

Answer 8

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

"我们应该忘记小的效率,比如大约97%的时间:过早的优化是所有邪恶的根源."
- 唐纳德克努特

Answer 9

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

Answer 10

不要求收集 - 为他们挖掘

要求很少出现在表面上.他们被埋藏在假设,误解和政治的层面之下

通过实用程序员

Answer 11

遵循SOLID原则:

单一责任原则(SRP)

一个班级改变的理由绝不应该是一个原因.

开闭原理(OCP)

软件实体(类,模块,函数等)应该是可以扩展的,但是关闭以进行修改.

利斯科夫替代原则(LSP)

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

接口隔离原理(ISP)

不应强迫客户端依赖于他们不使用的接口.

依赖倒置原则(DIP)

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

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

Answer 12

我认为"Python的禅宗"中列出的几乎所有内容都适用于每个"编程思维规则"列表.从'python -c'开始导入这个'':

Tim Peters的Python之禅

• 美丽胜过丑陋.
• 显式优于隐式.
• 简单比复杂更好.
• 复杂比复杂更好.
• Flat优于嵌套.
• 稀疏优于密集.
• 可读性很重要.
• 特殊情况不足以打破规则.
• 虽然实用性胜过纯洁.
• 错误不应该默默地传递.
• 除非明确沉默.
• 面对模棱两可,拒绝猜测的诱惑.
• 应该有一个 - 最好只有一个 - 明显的方法来做到这一点.
• 虽然这种方式起初可能并不明显,除非你是荷兰人.
• 现在比永远好.
• 虽然从未往往比好正确的现在.
• 如果实施很难解释,这是一个坏主意.
• 如果实现很容易解释,那可能是个好主意.
• 命名空间是一个很棒的主意 - 让我们做更多的事情吧!

Answer 13

最佳实践:使用你的大脑
不要在没有考虑的情况下遵循任何趋势/原则/模式

Answer 14

测试驱动开发(TDD)使编码员在晚上睡得更好

Just to clarify: Some people seem to think TDD is just an incompetent coder's way of limping from A to B without borking everything up too much, and that if you know what you're doing, that means there is no need for (unit) testing methodologies. That completely misses the point of Test Driven Development. TDD is about three (update: apparently four) things:

1. 重构魔法.拥有一整套测试意味着你可以制作疯狂的重构特技,在你的应用程序的整个结构中使用它,而不会错过由此产生的200个疯狂微妙副作用中的一个.即使是最优秀的程序员也不愿意在没有良好(单元)测试覆盖的情况下重构他们的核心类和接口,因为如果没有它们,它几乎不可能追踪它造成的所有小"涟漪效应".

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

3. 确保测试得到编写.TDD要求您在编写代码之前编写测试.当然,这可能是一种痛苦,因为编写测试与编写实际代码相比是繁琐的- 并且通常也需要更长时间.但是,这样做是确保测试完全写入的唯一方法.如果您认为在代码完成后您将记得编写测试,那么您几乎总是错的.

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

Answer 15

在你问你的同事并打断他的编码之前谷歌.

Answer 16

只要代码比许多代码更有意义,代码就越多越好.

Answer 17

惰性编码器的习惯

当你第一次被要求做某事时,做(右).

第二次要求您执行此操作时,请创建一个自动执行此操作的工具.

第三次,如果工具没有削减它,设计一个特定于域的语言来生成更多工具.

(不要太认真)

Answer 18

成为变革的催化剂

你不能强迫改变人.相反,向他们展示未来将如何,并帮助他们参与创建它.

通过实用程序员

Answer 19

调试时不要惊慌

深呼吸,思考!关于可能导致错误的原因.

通过实用程序员

Answer 20

您可以复制并粘贴以使其正常工作,但您可能不会这样做.

重复代码是一个中间步骤,而不是最终产品.

Answer 21

这就是你所说的和你说的方式

如果你不能有效地传达它们,那就没有意义.

通过实用程序员

Answer 22

总是编码好像最终维护你的代码的人是一个知道你住在哪里的暴力精神病患者.

来自:编码恐怖片

Answer 23

早发布,经常发布

Answer 24

建立破坏者购买午餐

Answer 25

首先纠正它.快点第二.

Answer 26

经常进行代码审查

代码审查和随后的重构是一项持续的任务.在我看来,这里有一些关于代码审查的好东西:

1. 它提高了代码质量.
2. 它有助于将可重用代码重构为可重用的库.
3. 它可以帮助您向开发人员学习.
4. 它可以帮助您从错误中吸取教训并重温您之前编写的天才代码.

Answer 27

任何可能影响应用程序运行方式的东西都应被视为代码,这意味着将其置于版本控制之下.特别是构建脚本和数据库模式以及数据(.sql)文件.

Answer 28

约定优于配置

特别是在惯例很强的情况下,可以牺牲一些灵活性.

Answer 29

参与开源开发

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

Answer 30

了解您使用的工具

在你明白为什么使用它之前不要使用模式; 不知道为什么不使用工具; 不要依赖你的框架或语言设计师总是适合你的情况,但也不要认为他们错了,直到证明是!