成为一名优秀的程序员需要技能和一些常识。关键在于务实，并知道哪种解决方案更适合你的问题。面对挑战时，有一些软件原则可以指导你选择最正确的方法。
这些是每个开发者都应该了解并时常回顾的一系列指导方针。可以把它们看作是你编程时的秘籍。
始终如一地应用这些原则会让你从中级软件工程师向高级软件工程师的过渡更加容易。你可能会发现（很可能）自己已经在凭直觉应用其中的一些原则了。
原则有很多，我们只关注最重要的7个。遵循这些原则将有助于你提升自我，成为一名更出色的程序员。
1. 你不会需要它（You Aren’t Gonna Need It - YAGNI）
这个原则简单明了，但并不是每个人都能遵守。添加代码时，要确保它是当下需要的。不要因为你觉得某些代码以后可能有用就把它们留在那里。
在进行重构时这个原则同样适用。如果你重构一个方法/类/文件，不要舍不得删除那些没用的方法。即使它们过去有用，但现在没用了。
也许有一天你又需要它们了，那时你可以通过Git仓库让它们“起死回生”。
2. 不要重复自己（Don’t Repeat Yourself - DRY）
这个概念最早由安迪·亨特（Andy Hunt）和戴夫·托马斯（Dave Thomas）在《程序员修炼之道：从小工到专家》一书中提出。
这个理念围绕着“单一事实来源”展开。这到底是什么意思呢？
“在信息系统设计和理论中，单一事实来源（SSOT）是一种构建信息模型和相关数据模式的实践，即每个数据元素只在一个地方进行管理（或编辑）……单一事实来源系统提供真实、相关且可引用的数据。”——维基百科
保持单一事实来源有助于构建更可靠、更易于理解的代码库。
代码重复是一种浪费。你需要在两个地方维护相同的逻辑，在两个地方进行测试，而且当一个地方发生变化时，你必须记得修改另一个地方。
大多数时候，代码重复是由于对系统缺乏了解。在编写任何代码之前，要务实一点：先看看周围。也许这个功能在其他地方已经实现了，也许这个业务逻辑在其他地方已经存在了。复用代码总是一个明智的选择。
3. 保持简单，傻瓜（Keep It Simple, Stupid - KISS）
这个设计原则是20世纪60年代美国海军提出的设计原则。该原则指出，更简单的系统将运行得更好、更可靠。
你会发现这个原则和20世纪70年代出现的“重新发明轮子”有很多相似之处，“重新发明轮子”曾被用作商业和广告方面的隐喻。
应用到软件开发中，它的意思就是——不要过度设计。有时候，最聪明的解决方案就是最简单的那个。用简洁的方式构建高性能、高效的代码是很棒的。
如今，最常见的错误之一就是仅仅因为新工具很炫酷就尝试使用它们。开发者不应该仅仅因为新技术是新的就有使用它们的动力，而应该是因为它们适合这项工作。
4. 预先进行大量设计（Big Design Up Front）
这种软件开发方法至关重要，但很多时候却被忽视。在开始实施之前，要确保一切都经过深思熟虑。
“很多时候，提前把事情考虑清楚能让我们在后续开发中避免严重的头痛问题……在规格说明书中做这个更改只需要一两个小时。如果我们在代码中做这个更改，可能会让项目周期增加数周。我无法更强烈地表达我对预先进行大量设计的信念了，尽管极限编程的支持者们认为这是一种禁忌。通过使用这种方法，我一直都能节省时间并开发出更好的产品，无论极限编程的狂热者们怎么说，我都为使用这种方法而自豪。在这一点上，他们就是错的，我再清楚不过了。”
——乔尔·斯波尔斯基（Joel Spolsky）
很多开发者觉得如果还没开始编码就是没有进展，这是错误的。通过制定一个具体的计划，你可以避免自己可能需要重新从头开始的情况。
有时候，设计中的缺陷需要其他人参与讨论。这种讨论越早进行，对大家越好。
一个非常常见的反对观点是，修复问题的成本比规划它们的时间要低。这肯定是不对的。用户遇到的错误/不一致性越少，他们的体验就越好。你可能没有第二次机会去抓住用户了。
5. SOLID原则
这是最著名的软件原则。SOLID是以下几个单词的首字母缩写：
S）单一职责原则（Single - responsibility principle）
它的重要性怎么强调都不为过。每个对象、类和方法都只应有一个职责。如果你的对象/类/方法做的事情太多，最终就会出现著名的“面条式代码”。下面是一个例子：
这个方法看起来没什么问题，但它做得太多了：
-
在后端（BE）保存对象
-
处理用户界面（UI）通知
-
一些导航功能
另一个副作用是测试。纠缠在一起的功能更难测试。
O）开闭原则（Open - closed principle）
软件实体应该对扩展开放，但对修改关闭。我的意思是，我们不应该仅仅因为需要更多功能就重写方法/类。
继承是实现这一原则的好方法。在JavaScript中，主要通过组合来实现。
小提示：如果你修改一个实体来使其可扩展，那么你第一次就违反了这个原则。
L）里氏替换原则（Liskov substitution principle）
这个原则是指超类的对象必须能够被其子类的对象替换，并且应用程序仍应按预期工作。
I）接口隔离原则（Interface segregation principle）
这个原则是罗伯特·C·马丁（Robert C. Martin）在为施乐公司做咨询时提出的，这是一个很明显的原则。
“客户端不应该被迫依赖它们不使用的接口。”——罗伯特·C·马丁
软件应该被拆分成多个独立的部分。应尽可能减少副作用以确保独立性。
要确保你没有强迫对象去实现它们永远不需要的方法。下面是一个例子：
并不是所有动物都能飞、走或游泳，所以这些方法不应该是接口的一部分，或者应该设置为可选的。
D）依赖倒置原则（Dependency inversion principle）
这个原则的重要性再怎么强调也不为过。我们应该依赖抽象，而不是具体的实现。软件应该具有低耦合和高内聚的特性。
你不应该关心事物是如何构建的，而应该关心它们是如何工作的。一个简单的例子是在JavaScript中使用日期。你可以构建自己的抽象层。这样，如果你要更换日期提供程序，你只需要在一个地方修改，而不是在成千上万个地方修改。
有时候，构建那个抽象层需要花费一些精力，但从长远来看是值得的。
例如，date - io就创建了这样一个抽象层，使你可以与多个日期供应商一起使用。
6. 避免过早优化（Avoid Premature Optimization）
过早优化是指在还未证明优化是必要的情况下，开发者就进行不必要的优化。我认为如果你遵循KISS和YAGNI原则，就不应该陷入这种情况。
不要误解我的意思，尝试预测可能出现的问题是好的，但在深入实施细节之前，你需要检查这些优化是否真的有用。
一个非常简单的例子就是扩展。你不会因为觉得你的新应用会火就购买40台服务器。相反，你应该根据需要增加服务器。
过早优化可能会导致你的代码延迟，从而增加产品推向市场的时间成本。
很多人都认为过早优化是万恶之源。
7. 奥卡姆剃刀原则（Occam’s Razor）
“奥卡姆剃刀（Occam’s razor、Ockham’s razor、Ocham’s razor，拉丁语：novacula Occami）或简约法则（拉丁语：lex parsimoniae）是一种解决问题的原则，即‘如无必要，勿增实体’[1][2]，或者更简单地说，最简单的解释通常是正确的。”——维基百科
在编程世界中这意味着什么呢？不要在不需要的时候创建不必要的实体。要务实——想想是否真的需要它们，因为它们可能最终会增加你的代码库的复杂性。
总结
这些原则并不复杂。事实上，正是它们的简单性让它们如此美妙。如果你觉得不知所措，不要担心。目前，你只需要努力提高自己的意识，并尝试一次将一个原则融入到你的日常工作中。
有一些基本但强大的原则可遵循，这将有助于你成为一名更好的程序员，并让你更清楚为什么要做这些事情。
如果你已经在凭直觉应用其中的大部分原则，那么当你明白为什么自己一直以某种方式做事时，那种顿悟的感觉是很好的。
感谢阅读。
17万+
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
