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

前言

KISS（Keep It Simple Stupid）

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

• 要谦虚，不要认为自己是个天才，这是你第一个误解。只有谦虚了，你才能真正达到超级天才的水平，即使不行，who cares！你的代码那么stupid simple，所以你不需要是个天才！
• 将你的任务分解为4-12小时的子任务。
• 把你的问题拆分成多个小问题。每个问题用一个或者很少的几个类来解决掉。
• 保持你的方法足够小，每个方法永远不要超过30-40行代码。每个方法都应该只处理一个小小的问题，不要搞太多uses case进去。如果你的方法中有多个分支，尝试把他们拆分成多个小的方法。这样不仅容易阅读和维护，找bug也更快。慢慢的你将学会爱。
• 让你的类也小点，原则和上面的方法是一样的。
• 先解决问题，然后开始编码。不要一边编码，一边解决问题。这样做也没什么错，但你有能力提前把事情切分成多个小的块，然后开始编码可能是比较好的。但也请你不要害怕一遍遍重构你的代码。另外行数还不是为了衡量质量的标准，只是有个基本的尺子而已。
• 不要害怕干掉代码。重构和重做是两个非常重要的方面。如果你遵循上面的建议，重写代码的数量将会最小化，如果你不遵循，那么代码很可能会被重写。
• 其他的任何场景，都请你尝试尽可能的简单，simple，这也是最难的一步，但一旦你拥有了它，你再回头看，就会说，之前的事情就是一坨屎。

DRY（Don’t Repeat Yourself）

我对DRY的理解：

• 尽可能的减少重复，如代码重复、文档重复、数据重复、表征重复、开发人员重复（相同的功能不能的开发人员的优自己的实现）
• 不重复造轮子，能够使用开源的解决方案的情况下没有必要再实现一遍。
• 重复的事项，尽可能的使用自动化程序解决。
• 不要过于优化，过度追求DRY，破坏了程序的内聚性。

YAGNI – You ain’t gonna need it

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

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

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

• 更少的代码维护

• 更少的代码测试

• 事情发生变化时更少的代码可重构

• 更多时间用于更重要的功能

• 更多时间用于文档编制

而且还包括：

• 节省了编译/移植的时间
• 节省了测试运行的时间
• 生成时/运行时节省了资源
• 不必以某种方式保留的知识

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

Code For The Maintainer

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

Be as lazy as possible.

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

偷懒还包括：

• 不要重复发明轮子

• 过度优化是万恶之源

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.

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

 

我也就理解到如下几点知识：

1、简约，合理最小化任务分步解决

2、减少重复，开源现成使用

3、功能需求合理化，基本不出现的需求场景可以暂时忽略

4、新内容引入需要充分验证

5、任何程序代码必须先验证测试通过

 

相关的准则，包括：

• 最小化耦合关系：代码片段（代码块，函数，类等）应该最小化它对其它代码的依赖。这个目标通过尽可能少的使用共享变量来实现。

• 最大化内聚性：具有相似功能的代码应该放在同一个代码组件里。

• 开放/封闭原则：程序里的实体项(类，模块，函数等)应该对扩展行为开放，对修改行为关闭。换句话说，不要写允许别人修改的类，应该写能让人们扩展的类。

• 单一职责原则：一个代码组件(例如类或函数)应该只执行单一的预设的任务。

• 隐藏实现细节：隐藏实现细节能最小化你在修改程序组件时产生的对那些使用这个组件的其它程序模块的影响。

• 笛米特法则(Law of Demeter)— 程序组件应该只跟它的直系亲属有关系（例如继承类，内包含的对象，通过参数入口传入的对象等。）

 

架构师应该遵守的编程原则 (qq.com)