良好编程原理

11-07-25 banq
The Principles of Good Programming

Artima最新文章,作者正在搞C培训,总结以下几个原理:
1.DRY(拧干代码不要有水分) 不要有重复代码,很多概念实际就是为此存在,比如loops function和classes等等,如果有重复,进行抽象。http://en.wikipedia.org/wiki/Don%27t_repeat_yourself


2.抽象原理,和DRY有关,代码中没一个重要的功能块都应该拧干抽象一下。http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

3.KISS(Keep it simple, stupid!),简化避免复杂是关键目标,简单代码花费时间短(代码写得少,脑子动得不见得少),少代码有较少BUGs和更易于修改。(banq:耦合都很高的代码有时很简单,但不易于修改)http://en.wikipedia.org/wiki/KISS_principle

4.避免创造YAGNI,不要增加你不需要的功能:http://en.wikipedia.org/wiki/YAGNI

5.做最简单只要能工作的设计,始终问自己,这样简单设计能够工作吗?http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

6.不要让我思考,代码应该易于理解。http://www.sensible.com/dmmt.html

7.开闭原则 软件实体如classes类 模块和functions应该开放易于扩展,但是不允许修改,不要写其他人能够修改的类,而是写出人们能够扩展的类(banq:可用面向对象的继承 实现等方法扩展多个子类)。

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

8.写代码要值得将来维护。http://c2.com/cgi/wiki?CodeForTheMaintainer

8.做最少令人惊讶的事,代码易于理解,名称等各方面不要让人产生惊讶的副作用。http://en.wikipedia.org/wiki/Single_responsibility_principle

9.最少耦合,代码(代码块,函数,类,等等)的任何部分,应尽量减少对其他地区的代码的依赖关系。这是通过使用尽可能少的共享变量 。“低耦合往往是一个结构完善的计算机系统的标志和一个好的设计,高凝聚力相结合,实现更高的可读性和可维护性的总体目标

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

10.最大化凝聚性:相同功能代码应该在同样一个组件中。http://en.wikipedia.org/wiki/Cohesion_(computer_science)

11.隐藏实现细节,隐藏实现细节,将允许改变执行代码组件,而最低限度影响的任何其他使用该组件的模块(实现细节怎么做是战术,做什么是方向战略)http://en.wikipedia.org/wiki/Information_Hiding

12.迪米特Demeter法则 ,代码组件只应该和他们的直接关系联系(直系血缘关系),如他们继承的父类,包含的对象和参数传递的对象http://en.wikipedia.org/wiki/Law_of_Demeter

13.避免过早优化,除非你的代码比你预期慢,否则不要提早优化,过早优化是罪恶根源,http://en.wikipedia.org/wiki/Program_optimization

14.代码能够重用是好的,重用代码提高代码的可靠性,缩短开发时间。http://en.wikipedia.org/wiki/Code_reuse

15.分散关注:不同功能区域,应该由不同代码和最小重叠的模块组成。(AOP是分散关注典型模式)

16.拥抱变化,这是一本Kent Beck书籍副标题,也被认为是极限编程和敏捷方法在一般的宗旨。最大限度地减少耦合使代码更容易改变。无论你是一个极端编程的医生,这种方法对于编写代码是有道理的。






14
banq
2011-07-25 14:33
2011年07月25日 14:28 "@banq"的内容
KISS(Keep it simple, stupid!) ...


很多人误解KISS原则就是不要设计,不要松耦合,就象老子倡导无为被误解为什么都不做一样。

根据我个人经验,KISS原则应该是使用合适的设计方案,而是否找到合适度却是一个很费时费力的过程,有过多次重构经验后应该就比较轻松。

banq
2011-07-26 14:47
程序program和软件software是有区别的:

程序能让计算机懂即可,软件还要让人能懂。

http://en.wikipedia.org/wiki/Computer_program对程序program定义:A computer program (also a software program, or just a program) is a sequence of instructions written to perform a specified task for a computer

http://en.wikipedia.org/wiki/Computer_software对软件software的定义: software is a set of programs, procedures, algorithms and its documentation。

banq
2011-07-26 15:14
当软件开始复杂时,软件质量就非常重要。软件质量是软件架构的重要因素之一。

软件质量是所有软件工程师在建立新系统或增加新功能时必须考虑的。,而遵循良好编程的原则是保证软件质量的重要途径之一。



banq
2011-07-26 18:00
2011年07月26日 15:14 "@banq"的内容
程序能让计算机懂即可,软件还要让人能懂。 ...


程序员和软件工程师是有区别的,前者只要写出计算机能运行的代码即可,后者不但要计算机能运行,还要能让其他人懂。

所以,很显然,软件工程师要比程序员高级,待遇肯定应该高,将“软件工程师”叫成“程序员”简直是侮辱。

让“程序员”见鬼去吧,那是一个已经过去的时代。

jeffrey4chartcrm
2011-07-27 17:20
程序上升到软件,编码上升到工程的概念,程序员理应提升到工程师的级别。现在写程序侧重的方面很多,贴近需求,良好的用户体验,可维护性佳。现在的软件工程师,也许还是半个产品经理。

fhjr999
2011-08-08 17:37
1.DRY(拧干代码不要有水分) 不要有重复代码,很多概念实际就是为此存在,比如loops function和classes等等,如果有重复,进行抽象。

9.最少耦合,代码(代码块,函数,类,等等)的任何部分,应尽量减少对其他地区的代码的依赖关系。这是通过使用尽可能少的共享变量 。“低耦合往往是一个结构完善的计算机系统的标志和一个好的设计,高凝聚力相结合,实现更高的可读性和可维护性的总体目标。

这两条有那么一点点的矛盾,应该说,这两条都分别偏向了某个极端,而在实际情况当中,往往需要中庸。

我们来看一下这样一种情况,有两个分属不同功能的类,他们都需要调用一段同样功能的代码,那么我们可以有两种做法,一种做法是,在这两个类当中分别实现这一段代码,还一种做法就是我们将这段代码封装在别处,然后这两个类进行调用。这两种做法有什么不同呢?第一种做法,必然造成了代码的一定冗余,这违背了第1条编程原则。而第二种做法则通过那段封装了的代码变相的产生了耦合。这又违背了第9条原则,调用同一个函数,也是一种共享变量。

实际设计当中,如何平衡各方矛盾很重要,如果是我来选择的话,我会选择第一种做法,因为我做的大多是一些偏底层的设计,对于解耦比较看重一些,但是还是那句话,要平衡,这种冗余的量绝不能多,当重复代码数量较多时,还是需要另外封装。

dwq460299228
2011-10-05 16:10
你只要还写代码,也是程序员

cdc859
2011-10-18 01:06
这这样说“程序员”不合适吧。

colingo
2011-12-02 15:23
需要经常写代码,不然会忘记。

xiaocainiaok
2012-02-13 09:26
写的很好,给力~ 翻译

猜你喜欢