软件编码原则

翻译 2015年11月18日 17:49:12

软件编码原则


原文链接:http://webpro.github.io/programming-principles


    每个程序开发人员都会受益于对编程的原则和模式的理解。
    为了给自己提供一个参考,我把这个概述写在这里。通过设计,讨论,或者回顾复习,它可能会对你有所帮助。
    要注意的是,它距离完成还有很长的距离,并且你也会经常需要在冲突的原则中做出取舍。

这一系列的灵感来之于 The Principles of Good Programming .我认为这更接近,而不是全部符合,我会自己加入一些相关的东西。
此外,我需要更多的原因,细节,和其他的资源的连接。如果你有任何促进的反馈或者建议,请告诉我。

内容


属性

模块/类作用

模块/类

KISS

大道至简。
大部分的系统,简单的总是比复杂的工作的更好。

为什么

  • 更少的代码可以节省书写的时间,拥有更少的BUG,并且易修改
  • 大道至简,至繁归于至简
  • 不是当没有东西可以添加的时候,而是在没有可以带走的东西的时候达到完美。

资源

  • KISS 原则
  • Keep It Simple Stupid (KISS)

YAGNI

用时实现。
YAGNI就是:"you aren't gonna need it"的简写:需要的时候再实现它(现在不需要它)

为什么

  • 任何只是在明天需要用到的工作特征,意味着它就是去了当前迭代需要的工作特征的作用
  • 这会导致代码的臃肿;软件会变得庞大和更加复杂

怎么做

  • 总是在你确切需要它们的时候实现它们,而不是你预见要用到它们的时候去实现。

资源

  • You Arent Gonna Need It
  • You’re NOT gonna need it!
  • You ain’t gonna need it

Do The Simplest Thing That Could Possibly Work

用最简单的方式实现需要的功能

为什么

  • 如果我们只是关注问题的本身到底是什么,那么真正的过程将会最大化的解决问题。

怎么做

-问一下自己:可以解决这个功能的最简单的方法是什么?

资源

  • Do The Simplest Thing That Could Possibly Work

Keep things DRY

在一个系统中每个知识点都必须只有一个唯一的,清楚的,权威的代表

一个程序中每个重要的功能块应该只在源文件中的一个地方去实现。
相似功能被不同的代码块声明的地方,一般可以通过抽象出不同的部分把它们组合到一个文件中。

为什么

  • 重复代码(有意或者无意)都会导致维护困难,不利于分离,并且逻辑矛盾混乱
  • 对系统中的任何元素修改,另一个逻辑不相关的元素不需要改变
  • 此外,逻辑相关的元素,所有的改变要可预见和一致,并且保持同步

怎么做

  • 把业务逻辑,长表达式,比如状态,数学公司,元数据等等,只放在一个地方
  • 识别系统中用到的每块知识的唯一,清楚的源文件,然后使用这个源文件来产生相应的实例(代码,文档,测试,等等)
  • 应用 Rule of three.

资源

  • Dont Repeat Yourself

相关

  • Abstraction principle
  • Once And Only Once is a subset of DRY (also referred to as the goal of refactoring).
  • Single Source of Truth
  • A violation of DRY is WET (Write Everything Twice)

Code For The Maintainer

易维护

为什么

  • 维护是任何工程最昂贵的阶段

怎么做

  • 想象自己是一个维护者
  • 编码的时候总是想象如果维护你的代码的那个人是个暴力倾向的精神病患者,并且知道你的住处
  • 用这种方式去编码和注释,不论什么档次的人拿起你的代码,会乐于阅读并且学习它。
  • 不要让别人去思考
  • 使用最少惊讶的原则(一看就明白)

资源

  • Code For The Maintainer
  • The Noble Art of Maintenance Programming

Avoid Premature Optimization

避免过早的优化

Donald Knuth名言:
程序猿浪废了大部分的时间用来思考,或者担心,程序的非关键部分的速度,并且这会严重影响到考虑测试和维护时的效率。
我们应该忘了小的效果,对97%的时间:都浪费在了过早的优化上面。然而我们不应该放弃那关键的3%。

要理解什么才是关键部分,而不是过早优化。

为什么

  • 对于瓶颈所在未知
  • 在优化后,可能不利于阅读和维护

怎么做

  • Make It Work Make It Right Make It Fast(可以工作,正常运转,快速就好)
  • 需要的时候才进行优化,并且只有在你发现瓶颈了后再优化

资源

  • Program optimization
  • Premature Optimization

Minimise Coupling

最小化耦合。

模块或者组件间的耦合就是他们之间的独立性;低耦合最好。
换句话说,耦合就是A代码修改后,B代码出错的可能性。

为什么

  • 一个模块中的代码修改之后,通常会影响其他的模块
  • 组装的模块间可能需要更多的工作或者时间来改变,因为依赖模块改变了。
  • 一个特别的模块可能会不容易复用或者测试,因为必须包含的依赖的模块改变
  • 开发者会畏惧改变代码,因为他们不清楚这会有什么影响。

怎么做

  • 消除,最小化,和降低需要关联的复杂度
  • 通过隐藏实现细节,耦合度就降低了
  • 应用迪米特法则

资源

  • Coupling
  • Coupling And Cohesion

Law of Demeter

迪米特法则

不要和陌生人说话

为什么

  • 它通常会导致紧耦合
  • 它可能会透漏更多的实现细节

怎么做

一个对象的方法应该只是调用:
- 对象本身
- 方法本身的参数
- 方法中创建的对象
- 对象的任何直接属性

资源

  • Law of Demeter
  • The Law of Demeter Is Not A Dot Counting Exercise

Composition Over Inheritance

使用继承

为什么

  • 类之间的耦合更少
  • 使用继承,子类可以容易的实现需要,并且打破LSP

怎么做

  • 测试LSP(可替代)来决定什么时候继承
  • 组合的关系是“有一个”或者“使用一个”,继承是“是一个”

资源

  • Favor Composition Over Inheritance

Orthogonality

正交的基本概念就是概念不相关的东西不应该在系统有关联

资源:Be Orthogonal

与简单相似:设计的越是正交,表达式就越少。学习,阅读,编码一种编程语言就越容易。
正交的特征意味着上下文的独立性;关键的参数具有对称和一致性。

资源:Orthogonality

Maximise Cohesion

单个模块或组件的聚合就是它形成一个有意义单元的职责程度;越高的聚合越好。

为什么

  • 增加了理解模块的难度
  • 增加了维护系统的难度,因为逻辑域上的改变影响多个模块,并且一个模块的需求变化会导致其他模块的变化
  • 增加了复用模块的难度,因为大多数的应用将不再需要模块提供的操作的随机组合

怎么做

  • 相关的功能集群共享一个唯一的职责

资源

  • Cohesion
  • Coupling And Cohesion

Liskov Substitution Principle

里氏替换原则就是对于对象行为的全部预期:
程序中的对象应该是可以用他们的子类型实例替换的,而不会影响程序的正常。

资源

  • Liskov substitution principle
  • The Liskov Substitution Principle

Open/Closed Principle

软件实体应该对扩展开放,对修改关闭。即在不改变源码的情况下扩展其行为功能。

为什么

  • 对已有代码的最小化改变提高可维护性和健壮性

怎么做

  • 书写可扩展的类(而不是可修改的)
  • 只是显示需要修改的可移动部分,其他的隐藏

资源

  • Open Closed Principle
  • SOLID JavaScript: The Open/Closed Principle

Single Responsibility Principle

单一职责原则,一个类应该只有一个可以改变的原因。
详细:每个类应该有一个单一的职责,并且这个职责应该被这个类完全封装。
职责可以用来定义为一个可以改变的原因,因此一个类或模块应该拥有一个,并且只有一个,改变的因素。

为什么

  • 维护性:改变应该只是在一个模块或类中需要

怎么做

  • 应用卷曲原则

资源

  • Single responsibility principle

Hide Implementation Details

隐藏实现的细节。一个软件模块通过提供接口来隐藏实现细节,并且没有任何的无关信息

为什么

  • 当实现改变时,使用接口的客户端不需要改变

怎么做

  • 最小化对于类和成员的访问
  • 不要成员数据设为public
  • 避免在类的接口中实现私有的方法
  • 隐藏更多的实现细节来降低耦合性

资源

  • Information hiding

Curly’s Law

克里法则就是关于为任何的特定的代码选择一个单一的,清楚定义的目标:就是做一件事情。单一原则

  • Curly’s Law: Do One Thing
  • The Rule of One or Curly’s Law

《软件工程》——编码

编码的目的是使用选定的程序设计语言,把模块的过程描述翻译为用该语言书写的源程序。源程序应该正确可靠、简明清晰,而且具有较高的效率。在编程的步骤中,要把软件详细设计的表达式翻译成为编程语言的构造,编译器...
  • u013067402
  • u013067402
  • 2014年10月09日 22:09
  • 1623

【软件设计】六大设计原则讲解

1. 单一职责原则 -Single Responsibility Principle SRP,Single Responsibility Principle: There should...
  • scboyhj__
  • scboyhj__
  • 2015年08月21日 23:05
  • 8017

软件架构设计的六大原则

1. 单一职责原则(Single Responsibility Principle - SRP) 原文:There should never be more than one reason fo...
  • u012562943
  • u012562943
  • 2017年07月26日 09:50
  • 806

软件设计的7大原则-自己的理解

选自javaweb软件工程设计七大原则。
  • fengchao2016
  • fengchao2016
  • 2017年01月23日 11:53
  • 439

软件设计模式、目标、原则

软件设计模式 一、设计目标: ⑴、软件设计目标:正确性、健壮性、灵活性、可重用性、高效性 1、正确性:也就是满足应用程序的需求。 2、健壮性:是指软件对于规范要求以外的输入情况的处理能力。也就...
  • ljheee
  • ljheee
  • 2016年05月27日 19:10
  • 2230

软件工程的七条基本原则

1、 用分阶段的生命周期计划严格管理     在软件开发与维护的漫长的生命周期中,需要完成许多性质各异的工作。这条基本原理意味着,应该把软件生命周期划分成若干个阶段,并相应地制定出切实可行的计划...
  • mydriverc2
  • mydriverc2
  • 2015年07月27日 14:02
  • 2152

免费直播编码软件应用技巧

本文对一款免费直播编码软件进行了介绍,主要介绍了如何自己搭建直播系统,视频直播编码系统的软件与硬件环境,尤其是采集卡的选择,对初学者朋友或许有益,因此在这里转发这篇博文。...
  • ababab12345
  • ababab12345
  • 2016年11月11日 23:38
  • 2058

常用编码软件简单使用记录 1 : 自主编码器

用于转码或者编码的软件很多。但是实际上编码器的数量是是相对比较少的。很多编码软件都算是编码器的GUI。它们外观不同,但是实际上都调用了同样的编码器。比如说一般情况下编码H.264的时候都调用了x264...
  • leixiaohua1020
  • leixiaohua1020
  • 2014年09月07日 11:47
  • 7898

软件设计6大原则

(1) (2)里氏替换原则()Liskov Substitution Principle LSP
  • u012656834
  • u012656834
  • 2014年07月08日 14:42
  • 1193

架构师应该编码吗?

架构师从编码中来,通过构建原型、框架和基础,实验新技术,代码评审等必不可少的编码活动最终完成产品的交付。难道不应该编码吗?...
  • caowenbin
  • caowenbin
  • 2015年03月02日 19:15
  • 2517
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:软件编码原则
举报原因:
原因补充:

(最多只允许输入30个字)