Skip to main content

Agile Design


How can you design the software which is built in tiny increments?

How can you ensure that the software has a good structure which is flexible, maintainable and reusable?

ARE'NT YOU GOING TO MISS THE BIG PICTURE?

Not really! In an agile team, the big picture evolves along with the software.

How? With each iteration, the team improves the design of the system so that it is as good as it can be for the system as it is now. They focus on the current structure of the system, making it as good as it can be.

How do we know if the design of software is good?

Avoiding these following symptoms of poor design (design smells) should be a way.

1. Rigidity - The design is hard to change.
2. Fragility - The design is easy to break.
3. Immobility - The design is hard to reuse.
4. Viscosity - It is hard to do the right thing.
5. Needless Complexity - Overdesign
6. Needless Repetition - Mouse abuse
7. Opacity - Disorganized expression

These symptoms are similar in nature to code smells, but they are at a higher level. They are smells that pervade the overall structure of the software rather than a small section of code.

How to avoid design smells?

The principles of object-oriented design that help developers eliminate design smells and build the best designs for the current set of features.

1. SRP -  The Single Responsibility Principle
2. OCP - The Open-Closed Principle
3. LSP - The Liskov Substitution Principle
4. DIP - The Dependency Inversion Principle
5. ISP - The Interface Segregation Principle

These principles are not the product of a single mind, but they represent the integration of the thoughts and writings of a large number of software developers and researchers.

Agile teams apply principles to remove smells. They don't apply principles when there are no smells.

Often, a design smell is caused by the violation of one or more of the principles.

Principles are not a perfume to be liberally scattered all over the system. Overconformance to the principles leads to the design smell of Needless Complexity.


Reference:
Image result for agile software development book


Robert C.Martin, Agile Software Development, Principles, Patterns, and Practices; Section 2, Agile Design.

Comments

Popular posts from this blog

BIRT - Fix the size of an image

I use a dynamic image as a logo my report in pdf. At the beginning, I use table to align the logo in left or right. I meet a problem with some images with a large width or height. My customer requires that the logo should be displayed in original size. These following steps solves my problem: 1. Use Grid instead of Table 2. Set Grid "Height" is 100%  and "Width" is blank 3. Set "Fit to container" for images are "true". Download the the template here .

The HelloWorld example of JSF 2.2 with Myfaces

I just did by myself create a very simple app "HelloWorld" of JSF 2.2 with a concrete implementation Myfaces that we can use it later on for our further JSF trying out. I attached the source code link at the end part. Just follow these steps below: 1. Create a Maven project in Eclipse (Kepler) with a simple Java web application archetype "maven-archetype-webapp". Maven should be the best choice for managing the dependencies , so far. JSF is a web framework that is the reason why I chose the mentioned archetype for my example. 2. Import dependencies for JSF implementation - Myfaces (v2.2.10) into file pom.xml . The following code that is easy to find from  http://mvnrepository.com/  with key words "myfaces". <dependency> <groupId>org.apache.myfaces.core</groupId> <artifactId>myfaces-api</artifactId> <version>2.2.10</version> </dependency> <dependency> <groupId>org.apache.myfaces.core<...

Avoiding Time-Wasting Pitfalls in Agile Estimation

If you do Scrum at work, you might be very familiar to the estimation in Planning 1 . My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated. I give you some advice from my experience: Estimation is estimation, not measure. When you read some requirements, you see some risks but you actually don't know how complicated it will be.  Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement. The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you do...

Why Functional Programming Matter

What issues do we concern when implementing and maintaining systems? One of the most concern is debugging during maintenance: "this code crashed because it observed some unexpected value." Then, it turns out that the ideas of  no side effects  and  immutability , which functional programming promotes, can help. Shared mutable data is the root cause Shared mutable data are read and updated by more than one of the methods. Share mutable data structures make it harder to track changes in different parts of your program. An immutable object is an object that can't change its state after it's instantiated so it can't be affected by the actions of a function. It would be a dream to maintain because we wouldn't have any bad surprises about some object somewhere that unexpectedly modifies a data structure. A new thinking: Declarative programming There are two ways thinking about implementing a system by writing a program. - Imperative programming: has...

When we don't see the sun, we see other stars

What are your motivations for creativity? - I want to make a change. - It makes me happy! It is a need of my mind. How to be creative for a thing? There are two steps: - See the thing as every people see it - Think about a new different thing from it How to think about a new different thing? There are two ways: - Forget all things you have already known. - A whack on the side of your head. ;) This was what I have learned from the following great book: source: Amazon.com Well! A physical whack on the side of your head is needed sometimes but the meaning behind is that you need to break these 9 following locks on your mind. Remove them! The lock #1: "The correct answer" We all learn from schools that there is only one correct answer to a question. For example, a proposition is only true or false in Algebra. In reality, there are always some answers to a question basing on a point of view. For example, number 6 becomes number 9 if you look it ...