Don’t Repeat Yourself (DRY, also known as Single Point of Truth) is a process philosophy aimed at reducing duplication, particularly in computing. The philosophy emphasizes that information should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency. DRY is a core principle of Andy Hunt and Dave Thomas’s book The Pragmatic Programmer. They apply it quite broadly to include “database schemas, test plans, the build system, even documentation.” When the DRY principle is applied successfully, a modification of any single element of a system does not change other logically-unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

The DRY code philosophy is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” This philosophy is also prevalent in model-driven architectures, in which software artifacts are derived from a central object model expressed in a form such as UML. DRY code is created by data transformation, which allows the software developer to avoid copy and paste operations. DRY code usually makes large software systems easier to maintain, as long as the data transformation are easy to create and maintain. Tools such as XDoclet and XSLT are examples of DRY coding techniques. Examples of systems that require duplicate information are Enterprise Java Beans, which requires duplication not just in Java code but also in configuration files. Examples of systems that attempt to reduce duplicate information include the Ruby on Rails application development environment.

Data transformation skills are not taught in most junior-level software engineering courses. Current computer science curricula tend to be heavily weighted toward procedural skills such as Java, C++, or C#. The use of DRY code becomes increasingly important as developers create applications that use multi-tier architectures. The model-view-controller architectural pattern also challenges software developers to use data transformations. Developments in some language features, such as Java annotations, may allow additional metadata to be stored within object class definitions and accessed at run time, allowing features such as automatic view generation directly from models.

Reference: http://en.wikipedia.org/wiki/Don’t_repeat_yourself

Related Posts

• DAO层单元测试
• Elegant Software
• Single Sign On
• Code Quality Checklist

这种DAO测试诚然就是集成单元测试，其实就是对于Web Action测试，我也曾经一度认为应该mock service来测试，但是现在我已经不这样做了，而是真正初始化webwork的容器注入真正的service对象来测试了。因为Action是没有业务逻辑的，测试Action的目标是看xwork.xml有没有配对，拦截器运用是否正确的，这一mock，直接把action对象当做POJO来测试，你只能测试action传了什么参数，其他什么都没有去测，但是action传入什么参数，那是OGNL自动完成的，用不着你多此一举了。

从这个角度来说，只有对util类的测试才是真正的单元测试，其他都是集成测试，但我不觉得这样做有什么不对。特别是我看过ruby on rails的测试框架以后更加坚定了这种做法。rails的unit test，functional test，integration test都是集成测试。

测试的策略和你用什么编程语言无关。单元测试也不是为了划清界限才产生的，单元测试为了保证软件的质量，这一点不要想歪了。不管是Java还是 Ruby，敏捷软件开发有一个理念，所有的人拥有所有的代码，不管代码是不是你经手的，你都有责任去维护它的质量。单元测试不是为了推卸责任。

rails和Java在单元测试这一点上没有什么区别，本版前面有一个关于mock适用场合的讨论，这里不展开谈，只说结论：mock仅仅适用于测试环境无法重现的部分，例如信用卡支付网关，web容器请求和响应对象等等，mock不应该被滥用。

单元测试的范畴并不单单指隔离所有依赖对象进行单个对象的测试，否则任何对象的测试都必须引入mock，否则单元测试就无法完成的。怎么做单元测试要看你的测试目标，如果偏离了测试的目标，一昧追求纯粹意义上的隔离性，测试根本就是做无用功。

This article is from another website which I forget. so sorry here.

Related Posts

• DRY Your Code
• Elegant Software
• Single Sign On
• Code Quality Checklist

Factors affecting the elegance of software

Here’s a short list of some of the factors that I think are important. Obviously, this is not an exhaustive list, and all comments are my opinion, and not definitive.

Does it work?

I’d be hard-pushed to call software “elegant” if it didn’t work

Is it easy to understand?

Lots of the following factors can really be summarised by this one: if I can’t understand the code, it’s not elegant.

Is it efficient?

A bubble sort is just not elegant, because there’s lots of much more efficient algorithms. If a cunning algorithmic trick can drastically reduce the runtime, using that trick contributes to making the code elegant, especially if it is still easy to understand.

Short functions

Long functions make the code hard to follow. If I can’t see the whole function on one screen in my editor, it’s too long. Ideally, a function should be really short, less than 5 lines.

Good naming

Short functions are all very well, but if functions are called foo, abc, or wrt_lng_dt, it can still be hard to understand the code. Of course, this applies to classes just as much as functions.

Clear division of responsibility

It is important that it is clear which function or class is responsible for any given aspect of the design. Not only that, but a class or function should not have too many responsibilities — by the Single Responsibility Principle a class or function should have just one responsibility.

High cohesion

Cohesion is a measure of how closely related the data items and functions in a class or module are to each other. This is tightly tied in to division of responsibility — if a function is responsible for calculating primes and managing network connections, then it has low cohesion, and a poor division of responsibility.

Low coupling

Classes and modules should not have have unnecessary dependencies between them. If a change to the internals of one class or function requires a change to apparently unrelated code elsewhere, there is too much coupling. This is also related to the division of responsibility, and excessive coupling can be a sign that too many classes, modules or functions share a single responsibility.

Appropriate use of OO and other techniques

It is not always appropriate to encapsulate something in a class — sometimes a simple function will suffice, and sometimes other techniques are more appropriate. This is also related to the division of responsibilities, but it goes beyond that — is this code structure the most appropriate for handling this particular responsibility? Language idioms come into play here: is it more appropriate to use STL-style std::sort on an iterator interface, or does it make more sense to provide a sort member function? Can the algorithm be expressed in a functional way, or is an imperative style more appropriate?

Minimal code

Code should be short and to-the-point. Overly-long code can be the consequence of doing things at too low a level, and doing byte-shuffling rather than using a high-level sort algorithm. It can also be the consequence of too many levels of indirection — if a function does nothing except call one other function, it’s getting in the way. Sometimes this can be at odds with good naming — a well-named function with a clear responsibility just happens to be able to delegate to a generic function, for example — but there’s obviously a trade-off. Minimal code is also related to duplication — if two blocks of code do the same thing, one of them should be eliminated.

One thing that is not present in the above list is comments in the code. In my view, the presence of comments in the code implies that the code is not sufficiently clear. Yes, well-written comments can make it easier to understand a given block of code, but they should in general be unnecessary: truly elegant code can be understood without comments. Of course, you might need to understand what it is that the code is trying to accomplish before it makes complete sense, particularly if the code is using advanced algorithms, and comments can help with that (e.g. by providing a reference to the algorithm), but my general view is that comments are a sign of less-than-perfect code.

Reference:

http://www.justsoftwaresolutions.co.uk/design/elegance-in-software.html

Related Posts

• DRY Your Code
• DAO层单元测试
• Single Sign On
• Code Quality Checklist

Web Single sign on works strictly with applications accessed with a web browser. The request to access a web resource is intercepted either by a component in the web server, or by the application itself. Unauthenticated users are diverted to an authenticaton service and returned only after a successful authentication.

Shared Authentication Schemes which are not Single Sign-On

Single sign on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign on. For example, an environment where users are prompted to log in to their desktop, then log in to their email using the same credentials, is not single sign on. Shared authentication schemes like OpenID, which require additional sign-on for each web site, are also not single sign on.

Reference:

http://en.wikipedia.org/wiki/Single_sign-on
http://www.cnblogs.com/guodapeng/archive/2008/11/19/1336583.html
http://www.ibm.com/developerworks/web/library/wa-singlesign/
http://www.josso.org/confluence/display/JOSSO1/JOSSO+-+Java+Open+Single+Sign-On+Project+Home
http://www.360doc.com/content/061004/13/73_222129.html
http://aspalliance.com/1545_Understanding_Single_SignOn_in_ASPNET_20
http://ginge.javaeye.com/blog/225778

Related Posts

• DRY Your Code
• DAO层单元测试
• Elegant Software
• Code Quality Checklist

1. Every fixed defect on a deployed product has tests added to prevent regression.
The worst thing you can do in this business is to have the same problem twice. Prevent it – our clients and users will usually understand if a bug happens the first time.Not ever, if it happesns agian.

2. Every design choice should yield the most simplistic design possible for the need of users at the current time. No guesses for future functionality were disigned into the application.

3. This paradigm is just as much for Project Manager as it is for Developers – but both types of people on a project have a responsibility to ensure that this is followed. Although Chapter 4 of Getting Real explains it better than I ever could – to sum it up. If you make guesses, rather than designing to facts, invariably, some of those guesses will be wrong. Some might be right , but any designing and development aht are for wrong guesses make things more complex, harder to fix, and harder to improve.
Instead, code to what you know is true, launch early, watch users, and iterate quickly. That’s on of the major benefits of hosted software (web apps) over distributed software (desktop apps) – so use it to its full advantage.

4. All logic duplicated between two or more modules/classes has been turned into a gemified module.

5. All functionality used in two or more models has been turned into a library/module.

6. Code has been aggressively DRYed during development. Make helpers. Make modules. Just keep doing it.

7. All model and variable names are bothe immediately obvious ( to a new developer) and as short as possible without using abbreviations. Naming is hard. Particularly for developers who are immersed in an application – what’s obvious to you when you’ve loaded the entire context of the application into your brain, will not be obvious to you later or to a new set of eyes. Don’t ruin this immense strength! If you can’t think of an ingenious, clear, and short name immediately, finish coding your method, and then try to unload the entire context you have while deep in coding. Put a TODO in and rename your variable or method name at the end of the day.

The hope is that every item on the checklist is so obvious to the more experienced Java developer, that it’s not worth mentioning – but that to new developers, the items on the list are non-obvious, and require some explanation. So here goes:

I certify that all of the above is true for my project.
[Printed Name] Signature

This is extended from http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist

I think these items are not only for Ruby on Rails but also work for other development, like Java, ASP.NET

Related Posts

• DRY Your Code
• DAO层单元测试
• Elegant Software
• Single Sign On