Skip to content
优秀的编程原则(译)
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
README.md

README.md

优秀的编程原则

翻译自: Principles of Good Programming

DRY - Don’t repeat yourself

不要重复自己

这大概是编程最基本的原则。也由此产生了很多编程的概念(比如循环,函数,类,等等)。一旦我们开始重复自己,就应该考虑做一下抽象了。

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle

抽象原则

抽象原则也和 DRY 原则有关,“程序中的每段核心功能代码应该只在源代码中的一个地方实现”。

http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!)

代码简洁

代码简洁是一个很重要的目标,写简洁的代码耗费的时间更少、bug 更少、更易于修改。

http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it)

如果某个功能你还用不到,就不要去实现它。

http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work

用最简单的方式解决问题

时常问自己“能解决问题(完成需求)的最简单的方式是什么?”,有利于设计方案的简洁明了。

http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think

不要让我思考

这正是 Steve Krug 的一本关于 web 可用性的书的标题,同样适用于编程。代码应该保持简洁易读,如果读起来太过复杂,应该简化一下。

http://www.sensible.com/dmmt.html

Open/Closed Principle

开闭原则

软件功能(类,模块,函数等等)应对拓展开放,对修改封闭。换句话说,不要写需要别人修改的类,要写便于别人拓展的类。

http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer

写易维护的代码

几乎所有代码都是需要长期维护的,不管是你自己维护还是别人维护。即使是自己的代码,一段时间以后自己也可能忘记里面的逻辑,所以相当于写代码的人和维护的人不是同一个。有这么个方法“写代码的时候记着,将来维护代码的人是一个知道你住在哪里的变态暴力狂”。

http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment

减少误导

这个原则通常在接口上被提到,但在代码里也很重要,代码不应该误导阅读者。注释的说明要和代码一致,函数名要和函数内容一致,要避免迷惑和误导。

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle

单一功能原则

一段代码(类或函数)应只实现一个单一的定义清晰的任务。

http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling

低耦合

代码的任何部分(代码块,函数,类等等)都应该减少对其他部分代码的依赖,要尽量减少变量共享。“低耦合通常是结构优秀的计算机系统和好的设计的标志,配合高内聚,就能实现高可读和易维护的目标”。

http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion

高内聚

实现一个功能相关的代码,都应在同一个模块中实现。

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details

隐藏实现细节

隐藏实现细节,当内部逻辑修改时,能够减少对其他使用者的影响。

http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter

迪米特法则

代码应该跟有直接关联的部分交互(比如类继承的父类、包含的对象、传入的参数,等等)。

http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization

避免过早优化

代码还在正常工作的时候不必考虑优化,除非运行速度不及预期,并且最好在有量化数据对比的前提下进行。“我们应忽略小的影响,大约97%的情况下:过早优化是万恶之源” -- Donald Knuth。

http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good

代码复用

代码复用可以提高代码可用性并减少开发时间。

http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns

关注分离

不同的功能应分开管理并有明显界限,要最大程度降低模块间代码的重叠。

http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change

拥抱变化

这是 Kent Beck 一本书的子题目,也是极限编程和敏捷开发的一个宗旨。很多其他的原则都是基于期望并拥抱变化的初心,一些传统的软件工程原则比如“低耦合”都有利于更简单的修改代码。不管你是不是极限编程爱好者,这个原则对写代码都很有帮助。

http://www.amazon.com/gp/product/0321278658

You can’t perform that action at this time.