软件设计的指导方针与原则 (from Prefactoring)

前段时间读完了〈Prefactoring, Extreme Abstraction, Extreme Separation, Extreme Readability>感触比较多。其实无论你采用哪种过程,最后的目标都是一样。也许大家对相同的方法使用不同的名字,但原理都是相同的。Prefactoring首先是一种态度,然后才是相关的方针和原则。所以,态度决定一切也是有一定道理的。此书非常经典,但也不必逐字逐句阅读,所以摘出其精华部分与大家分享。

Don't Reinvent the Wheel
用已有方案解决问题而不是重新创造一个新方案.

Think About the Big Picture
系统的任何决策都要与大方向保持一致.

Document Your Assumptions and Your Decisions
团队要不断自省,确保你的假设与决定都是正确的。

Don't Repeat Yourself (DRY)
每一段代码都是唯一的,清楚的,表达的意思都是明确的。

Plan Globally, Develop Locally
每次的迭代都跟你的计划保持一致.

Splitters Can Be Lumped More Easily Than Lumpers Can Be Split
合并远比拆分简单.

Clump Data So That There Is Less to Think About
数据聚合减少了我们需要关注的概念的数量。

When You're Abstract, Be Abstract All the Way
尽可能抽象.

Strings Are More Than Just a String
把String也看作是简单类型,尽量使用抽象类型不是String。其实不能一概而论,如果需要就用抽象类型,但不应该全部都用.

Never Let a Constant Slip into Code
避免Magic number.

To Text or Not to Text
在程序内部不应该用Text,程序之间要用Text.程序内部尽可能使用类型,而不是简单的文本。

If It Has Collection Operations, Make It a Collection
集合分离了对象的使用和存储,并隐藏了聚合操作的实现细节。

Don't Change What It Is
想一个新术语,而不是为当前的术语添加新意思。

Adapt a Prefactoring Attitude
在出现之前就要消除重复.

Don't Overclassify
通过行为而不是数据区分不同的类。

Place Methods in Classes Based on What They Need
如果一个方法不需要实例变量,它不应该是类的成员。反过来,如果一个方法需要的都是实例变量,那它一定是成员方法。

Honor the Class Maxims
低耦合,高内聚.

Do a Little Job Well and You May Be Called Upon Often
只执行特定任务的方法和类最可能被重用.

Separate Policy from Implementation
分离策略与实现能够使实现更易阅读与维护。

Separate Concerns to Make Smaller Concerns
把重多的职责分到不同的方法和类中,以使每个方法或类更专注.

Test or Production; That Is the Question
注意分离测试代码与产品代码。

Build Flexibility for Testing
一开始就要计划让你的设计更容易测试。

Decouple with Associations
中介类可解耦相关联的类.

Split Interfaces
把一个接口分成几个接口,以使客户端可以访问不同的接口.参考[url=http://samuelray.iteye.com/blog/194073]SIP[/url].
Do a Little and Pass the Buck

用代理来增加功能,稍后再实现它。

Business Rules Are a Business unto Themselves
保持业务规则相互独立.

A Rose by Any Other Name Is Not a Rose
为每一个概念定义一个唯一的清晰的名字。

Prototypes Are Worth a Thousand Words
界面或图片要比任何语言都更有说服力.

Communicate with Your Code
你的代码可以清楚告诉你它的想法.

Explicitness Beats Implicitness
直率要强过含蓄.

Declaration over Execution
声明风格的程序不用改动代码就可以提供很好的适应性.

Use the Same Layout to Get the Same Layout
用模板或脚本提供一致性.

The Easiest Code to Debug Is That Which Is Not Written
永远不要实现已经存在的功能.

Use the Client's Language
在你的代码中使用客户的语言.这一点不是太赞同,不过它一样也在一定的环境中有效。

Create Interface Contracts
设计定义良好的接口,然后执行这些接口的合约。

Validate, Validate, Validate
验证接口的输入参数.

Test the Interface, Not the Implementation
用接口的合约开发功能测试,不必去关注实现.

Adopt and Adapt
创建你想要的接口,然后让实现去适应它。

Don't Let the Cold Air In
被暴露的接口一定要验证输入参数的合法性.

Decide on a Strategy to Deal with Deviations and Errors
在你的系统中定义什么是偏差,什么是错误.

Report Meaningful User Messages
错误信息的报告应该考虑如何提供给用户更多有用的信息,而不是告诉用户这个错误到底是什么意思.

Never Be Silent
错误不应该被隐藏.

Consider Failure an Expectation, Not an Exception
计划好操作在发生错误时如何响应.

Don't Speed Until You Know Where You Are Going
在提高运行速度之前要先保证系统运行正确。

The Spreadsheet Conundrum
清楚自己在做行列方法的决定.

Consistency Is Simplicity
一致性常常会导致简单,使你的代码更易于理解和维护.

If It Can't Be Tested, Don't Require It
任何功能需求,不管正式还是非正式的,都要有相应的测试。如果需求无法测试,你就不知道它是不是被满足。

Plan for Testing
预先考虑测试会导致更好的设计。

Figure Out How to Migrate Before You Migrate
考虑移植路径会帮助你发现设计中的另外需要考虑的事情。

Know Who It Is
为每个对象建立唯一索引.

Perform a Retrospective After Each Release
检查你的设计及方法,会对你下个版本有帮助.

Nothing Is Perfect
在有限的时间和资源内选择比较好的方案而不是最好的.

See What Condition Your Condition Is In
用基于状态的分析方法来检查对象行为.通过状态图,我们可以发现更多的对象行为或职责.

Get Something Working
首要任务就是让软件工作起来,然后才是重构,精化.

Plan Your Logging Strategy
在设计阶段就要考虑在哪里以及如何写日志。

More Is Sometimes Less
有些已经完成的模块提供了大量的特性,你只需要其中一部分的话,就用适配器让这些模块为你所用.

Be Ready to Import and Export
通过定义良好的格式,可以在系统之外使用系统的数据。

Avoid Premature Generalization
在决定通用化方案之前要先解决特定问题.

If You Forget Security, You're Not Secure
安全问题不应该最后才考虑,整个开发过程都要考虑.

Consider Privacy
设计系统时要考虑个人隐私问题。

Avoid Premature Inheritance
继承会花费你更多的时间和精力.

Think Interfaces, Not Inheritance
接口使类的关系更和谐流畅。

Overloading Functions Can Become Overloading
唯一的名字更具有自我描述性.

When in Doubt, Indirect
无论是方法还是数据,间接都可以提供更好的适应性.
阅读更多
个人分类: 技术
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭