我正在为我的团队编写一个编程思维规则：你是什么？
我一直在列出一个列表，这有助于我分享编程方法的原因 ，以及如何做某事的想法。
为此，我想创build一个列表：
- 最佳实践，
- 最好的想法，
- 最好的办法…
帮助程序员以最有效的方式进行分析，思考，接近，解决和实施的能力。
在堆栈溢出的问题中，我看到了数十个令人难以置信的宝贵意见，但我找不到让我们把它们放在一起的地方。 有关于堆栈溢出最有争议的意见。 不过，我只是寻找可以共享的智慧洞见，并帮助我的团队，通过更好的编程来更好地解决问题。
希望这可以成为一个简洁，深刻，易于分享，重复，复习的一两个内容。 如果我们对每个答案保持一条规则，那么最简单的方法就是上/下。
我将从第一个开始。
干 – 不要重复自己 – 在代码，评论或文件。
总是让代码比你find的时候好一点。
代码在进入版本控制系统之前不存在。
不要害怕承认“我不知道”问。
10分钟问人可以挽救一天拉你的头发！
亲吻 – 保持简单，愚蠢。
select最简单的解决scheme。
在他们需要之前不要让事情变得复杂。
只是因为其他人正在使用一些复杂的框架来解决他们的问题，并不意味着你必须。
不要重新发明轮子
如果核心库中应该有这个function的话 – 可能就是这样了。
可维护性很重要。
编写代码，好像最终维护它的人是疯狂的，知道你住在哪里。
别人不会解决它。
如果有问题引起您的注意，请保持足够长的时间，以确保这样或那样的照顾。
除非有明显的问题，否则不要进行优化。
在大多数情况下，当人们试图优化代码之前，他们会花费大量的资源，使代码难以阅读和维护，并且没有引人注目的效果。 有时候甚至会变得更糟。
“我们应该忘记小效率，大约97％的时间：不成熟的优化是万恶之源。”
Donald Knuth
它能有多难？
不要让任何问题威胁到你。
不要收集要求 – 挖掘他们
要求很less在表面上。 他们被埋在深层的假设，误解和政治之下
通过语用程序员
遵循SOLID原则 ：
单一责任原则 （SRP）
class级改变不应该有一个以上的原因。
开放原则 （OCP）
软件实体（类，模块，函数等）应该打开进行扩展，但是closures进行修改。
Liskovreplace原则 （LSP）
使用指针或基类的引用的函数必须能够使用派生类的对象而不知道它。
接口隔离原理 （ISP）
客户不应该被迫依赖于他们不使用的接口。
依赖倒置原理 （DIP）
A.高级模块不应该依赖于低级模块。 两者都应该取决于抽象。
B.抽象不应该取决于细节。 细节应该取决于抽象。
最佳实践： 使用你的大脑
不要没有考虑到任何趋势/原则/模式
我认为几乎所有在“Python的禅”中列出的所有内容都适用于每个“编程思维规则”列表。 从“python -c”开始导入这个“”：
Python的禅宗，由蒂姆·彼得斯
- 美丽胜过丑陋。
- 显式比隐式更好。
- 简单胜于复杂。
- 复杂比复杂好。
- 平面比嵌套更好。
- 稀疏比密集好。
- 可读性计数。
- 特例不足以打破规则。
- 虽然实用性胜过纯净。
- 错误不应该默默通过。
- 除非明确沉默。
- 面对歧义，拒绝猜测的诱惑。
- 应该有一个 – 最好只有一个 – 明显的方法来做到这一点。
- 尽pipe这种方式一开始可能并不明显，除非你是荷兰人。
- 现在比从未好。
- 虽然从来没有比现在更好。
- 如果实施很难解释，这是一个坏主意。
- 如果实施很容易解释，这可能是一个好主意。
- 命名空间是一个好主意 – 让我们做更多的！
testing驱动开发（TDD）使编码器在晚上睡得更好
只是为了澄清一下：有些人似乎认为TDD只是一个无能的编码器从A到B的跛行而没有把所有东西都搞得太多，而且如果你知道自己在做什么，那就意味着不需要（单元）testing方法。 这完全错过了testing驱动开发的观点。 TDD约三（更新：显然是四）的东西：
重构魔术 。 拥有一套完整的testing意味着你可以做出其他疯狂的重构特技，整个应用程序的整个结构，而不会错过由此导致的两百个疯狂的细微副作用中的一个。 即使是最好的程序员也不愿意在没有良好的（单元）testing覆盖的情况下重构他们的核心类和接口，因为如果没有它们，就几乎不可能追踪到它所带来的所有“连锁反应”。
尽早发现隐患 如果你用正确的方式写testing，那就意味着要强迫自己考虑所有的边缘案例。 通常情况下，一旦实际开发开始，这会导致更好的deviseselect，因为编码人员已经考虑了一些棘手的情况，可能要求不同的inheritance结构或更灵活的devise模式。 在最初的规划和分析过程中，对这些变化的需求往往不明显或者直观，但是这些确切的变化可以使应用程序更容易扩展和维护。
确保testing写入 。 TDD要求您在编写代码之前编写testing。 当然，这可能是一个痛苦的屁股，因为写作testing是比繁琐的编写实际代码 – 而且往往需要更长的时间。 但是，这样做是确保testing完全写入的唯一方法。 如果你认为在代码完成后你会记得写testing，那么你几乎总是错的。
迫使你写更好的代码 。 由于TDD强制所有代码都是可testing的（在进行testing之前不要编写代码），因此需要编写更多的解耦代码，以便可以独立testing组件。 所以TDD迫使你写更好的代码。 （ 谢谢，Esko ）
谷歌之前，你问你的同事，并打断他的编码。
只要代码比许多代码更有意义，代码越less越好。
惰性编码器的习惯
你第一次被要求做某事，做（右）。
第二次你被要求做，做一个工具，自动做。
第三次，如果该工具不能削减它，devise一个领域特定的语言，以生成更多的工具。
（不要太认真）
成为变革的催化剂
你不能强迫人改变。 相反，向他们展示未来可能如何，并帮助他们参与创造它。
通过语用程序员
debugging时不要惊慌
深呼吸，思考！ 关于什么可能导致错误。
通过语用程序员
你可以复制并粘贴它来工作，但是你不能这样离开它。
重复的代码是一个中间步骤，而不是最终产品。
这是你说的话和你说的方式
如果你没有有效的沟通，没有好的想法是没有意义的。
通过语用程序员
总是编码，就好像最终维护你的代码的人是一个知道你住在哪里的暴力精神病患者一样。
来自： 编码恐怖
build立断路器购买午餐
早发布，常发布
先build立它正确的。 让它快速秒。
经常进行代码审查
代码审查，因此重构是一个持续的任务。 在我看来，以下是代码审查的一些好处：
- 它改善了代码质量。
- 它有助于将可重用的代码重构为可重用的库。
- 它可以帮助你从你的开发人员那里学习。
- 它可以帮助你从错误中学习，并且重新记忆你以前写过的天才代码。
任何可能影响应用程序运行的东西都应该被视为代码，这意味着将其置于版本控制之中。 尤其是构build脚本和数据库模式和数据（.sql）文件。
参与开源开发
如果您在项目中使用开源代码，请记住将错误修复和改进发布回社区。 这本身并不是一个开发最佳实践，但它绝对是一个努力的程序员心态。
了解你使用的工具
除非你明白你为什么要使用它，否则不要使用模式。 不知道为什么不使用工具; 不要依赖于你的框架或语言devise者总是适合你的情况，但也不要以为他们是错的，直到certificate是！
约定优于configuration
特别是在公约很强的情况下，可以牺牲一些灵活性。
