架构师应该遵守的编程原则

　　架构师应该遵守的编程原则

　　大家好，我是互联网架构师！

　　程序员拥有一个较好的编程原则能使他的编程能力有大幅的提升，可以使其开发出维护性高、缺陷更少的代码。以下内容梳理自StactOverflow的一个问题：编程时你最先考虑的准则是什么？

　　目录

　　KISS（Keep It Simple Stupid）

　　KISS原则是英语 Keep It Simple, Stupid 的首字母缩略字，是一种归纳过的经验原则。KISS 原则是指在设计当中应当注重简约的原则。总结工程专业人员在设计过程中的经验，大多数系统的设计应保持简洁和单纯，而不掺入非必要的复杂性，这样的系统运作成效会取得最优；因此简单性应该是设计中的关键目标，尽量回避免不必要的复杂性。

　　这个首字母缩略词根据报导，是由洛克希德公司的首席工程师凯利·约翰逊（U-2 、SR-71等的设计者）所创造的。虽然长久以来，它一直是被写为 “Keep it simple, stupid”，但约翰逊将其转化成 “Keep it simple stupid”（无逗号），而且这种写法仍然被许多作者使用。词句中最后的 S并没有任何隐涵工程师是愚蠢的含义，而是恰好相反的要求设计是易使人理解的。

　　说明这个原则最好的实例，是约翰逊向一群设计喷射引擎飞机工程师提供了一些工具，他们所设计的机具，必须可由一名普通机械师只用这些工具修理。因此，“愚蠢”是指被设计的物品在损坏与修复的关联之间，它们的难易程度。这个缩写词已被美国军方，以及软件开发领域的许多人所使用。

　　另外相类似的概念也可作 KISS原则的起源。例如“奥卡姆剃刀”，爱因斯坦的“一切尽可能简单”、达芬奇的“简单是最终的复杂性” 、安德鲁·圣艾修伯里的“完美不是当它不能再添加时，它似乎是在它不能被进一步刮除时实现的”。

　　有两种软件设计方法，一种是尽可能的简单并保证没有什么缺陷。另外一种方式是尽可能的复杂并保障没有什么缺陷。而第一种方式相比第二种更加困难。

　　保持简单（避免复杂）永远是你应该做的第一件事，简单的代码不仅写起来简单、不容易出Bug，还易于维护。简单规则下，还包括：

　　如何把Kiss原则应用到工作中？

　　参考链接：Do The Simplest Thing That Could Possibly Work：

　　DRY（Don’t Repeat Yourself）

　　DRY即Don’t repeat

　　ourself（不要重复你自己，简称DRY），或一个规则，实现一次（One rule, one place）是面向对象编程中的基本原则，程序员的行事准则。旨在软件开发中，减少重复的信息。DRY的原则是“系统中的每一部分，都必须有一个单一的、明确的、权威的代表”，指的是（由人编写而非机器生成的）代码和测试所构成的系统，必须能够表达所应表达的内容，但是不能含有任何重复代码。当DRY原则被成功应用时，一个系统中任何单个元素的修改都不需要与其逻辑无关的其他元素发生改变。此外，与之逻辑上相关的其他元素的变化均为可预见的、均匀的，并如此保持同步。我对DRY的理解：

　　相关规则有：

　　

　　代码复用：

　　YAGNI – You ain’t gonna need it

　　YAGNI 是You Ain’t Gonna Need It（你不会需要它）的简写，是极限编程的关键原则。YAGNI意思非常简单：仅在您真正需要它们时才去做，而不是在您认为或预见将来可能需要它们时就提前做了！

　　您可以将YAGNI视为即时制造的拥护者。在这种情况下，制造业正在编写代码并交付功能。只有当有人真的需求功能存在时，您才可以开始工作并创建它。否则，您将保持自己的懒惰！

　　它为什么如此重要？没有编写的每一行代码都是时间，因此可以节省金钱。但是，甚至更多！它是：

　　而且还包括：

　　它可以防止什么？如今，大多数软件开发都是根据客户的需求进行的。无论您是在产品公司，在提供开发服务的公司还是在其他地方工作。总是会在某处某人想要具有某个功能。是您的客户要求具有某个需求的功能，还是产品经理响应客户的反馈的功能。无论实际驱动者是谁，无论是早晚，这都是实际需求的体现。您正确预见未来功能请求的机会非常低。因此，您很有可能实现某些功能，而不是您的实际利益相关者想要的功能。过早地执行某些操作很可能会导致一切都被丢弃。这是一个没人真正喜欢的场景！然后，有时会发生另一种情况：没有人真正需要该功能！

　　Code For The Maintainer

　　为维护者编写程序。比如让代码有自解释的功能。在你编写代码的时候永远记得将来需要维护他。

　　参考链接：

　　Code For The Maintainer：

　　Be as lazy as possible.

　　人类因“偷懒”而进步。懒惰只是创造了需求。需求本身并不算进步。满足需求形成了进步。

　　偷懒还包括：

　　参考链接：

　　Do The Simplest Thing That Could Possibly Work：

　　

　　Programming is only the road, not the way.

　　编码只是一种实现方式，而不是解决方案。编码只是告诉电脑应该如何去做。要编写高效、可靠的软件需要精通算法、最佳实践等其他与变成相关的内容。

　　编程前需要先了解你要解决的问题是什么。编程只是手段并不是目的。能实现并不代表需要实现。知道什么时候不需要编程或没有必须要去编程。

　　If you are in a hurry, stroll along slowly.

　　If you really are in a hurry, make a detour.

　　如果你很忙，那就放慢速度。如果你真的很忙，那就先放一放。这听起来很愚蠢，但是千万不要让自己陷入会导致后期问题的妥协。如果你正在编写程序的核心部分，尽可能保证精确。如果你在编写离核心代码较远的方法，可以尽可能的加快速度。

　　Know your path, Neo.

　　知道你的实现路径，你需要了解你每天使用的环境、工具及其他依赖的内容，并且把它调试到适合自己的配置。如果你的编程环境真的很好，那么你编程中的基本不需要关心他。如果你需要完成一项任务，最好的方式是不要引进“新的内容”，只有当你完全掌握“新的内容”的时候再去考虑引入。

　　If it wasn’t tested, it is broken.

　　如果没有经过测试的代码都是不能运行的。

　　与程序沟通时分辨原因和结果，与人交流时要分辨事实和观点

　　相关的准则，包括：

　　原文链接：What do you consider the 1st principle(s) of programming?

　　参考链接：Programming Principles