浅谈程序设计

一段代码能正常Run,没有BUG,这就代表这段代码没有问题，是一段良好的代码了吗？没有BUG,能运行,这不代表这段代码是一个好代码.

或者说评价一个代码的好坏,其指标或者说原则应该是多元的,不仅仅是能Run,并且没有BUG.而评价一个代码最重要的是,代码能否适应将来的需要,即对代码的维护.

代码能Run,不是说Run一次两次能用就好了,你要考虑的是它一年以后,两年以后,五年以后.甚至十年二十年以后, 这个代码还可能有其他人或者你自己要继续做下去.需求如果有了变更,要进一步发展下去,这个时候你拿之前写的代码怎么办.

你的代码还能不能在今后起作用； 让今后做维护的,无论是其他人还是你自己,能够比较容易的在这个代码的基础上做事情.这才是我们考察代码良好的一个重要原则。 就是说这个代码适不适合扩展,也就是常说的可扩展性.在程序中存在相似甚至相同的代码块，这是非常低级的代码质量问题。

代码复制所带来的问题就是:如果需要去修改一个副本,那么就必须得同时修改所有其他的副本.否则就存在不一致的问题.这大大增加了维护程序的工作量,而且很容易存在错误和危险.

比如对于维护程序的人来说,程序员看到一个副本被修改好了,就以为其他所有要修改的地方都已经修改好了.因为没有任何迹象表明还有一份一样的副本代码存在, 所以很容易导致遗漏还没被修改的地方.

消除代码复制的两个基本手段————函数与父类。

你的程序设计优不优秀.就需要定义一些评价设计的术语:两个重要的核心术语————耦合与聚合.

耦合指的是类与类之间的联系.程序设计的目标是一系列通过定义明确的接口通信来协同工作的类.耦合度反映了这些类联系的紧密度. 我们要努力来降低耦合度,或者叫做松耦合.因为耦合度决定了程序修改的难易程度.在一个紧耦合的结构中,对一个类的修改也会导致对其他一些类的修改. 这是我们要努力去避免的,否则,一点小小的改变就可能使整个应用程序发生改变.另外要想找到所需要修改的地方，并一一修改却是即困难又费时的事情.

另一方面,在一个松耦合的系统中,常常可以修改一个类,但同时不会修改其他类,而且整个程序还可以正常工作.

聚合与程序中一个单独的单元(可以说是test)所承担的任务的数量和种类相对应有关,它是针对类或方法(函数)这样大小的程序单元而言的理想情况下, 一个代码单元应该负责一个聚合任务(也就是说，一个任务可以被看作是一个逻辑单元(logic unit)).一个方法应该实现一个逻辑操作,而一个类应该代表一定类型的实体.

聚合的重点是重用:如果一个方法或者类是只负责一件定义明确的事情,那么就很有可能在另外不同的上下文环境中使用.

遵循这点的好处是，当程序某部分的代码需要改变时，在某个代码单元中很可能会找到所有需要改变的相关代码段。