I’ve been involved with software design and analysis for many years now and I still learn something new each day. Over the years I’ve come across many confused and at times overwhelmed newbies struggling to understand and produce decent designs, this blog is an effort to share some learning with them
1) Take a plunge
Designing is like swimming, you can’t just read stuff and be good at it! You have to jump in water and practice to be a good swimmer. Similar is case with design, don’t just get stuck at reading books get working on it, practice and you will get better at it. Once you know your way around things you read will make more sense.
2) Work full cycle
Try to take up different roles in software life cycle if possible work as a requirement analyst, tester, developer, production support analyst. Each of these roles will give you a different perspective and will make you a better designer.
3) Understand the functional domain of problem
The functional domain provides all the essential clues required for building a good design, it is important to understand the domain before working on the design. Understandably all information may not be readily available but make a conscious effort to gather knowns.
4) Work your way Top down
Work in layers, start with domain, build a layer of high level abstractions below it and keep moving in this direction building lower layers to the lowest level. Try to focus on current layer and its interactions with the one below it.
5) Encapsulate what varies
The golden rule for a good design is ‘encapsulate what varies’ i.e. try to segregate things that change from those which do not change. Initially try to follow this simple rule only and save yourself from being overwhelmed trying to follow all design rules and principals.
6) Do not over engineer
At the outset it might seem that lot of things can vary and you need to segregate everything! Fight this urge, your domain would give you a good idea about things that can change, look at the probability of each kind of change, and segregate the ones that have high probability of change.
7) Let patterns show the way
When you have identified a segregation point, look at the interactions between stable and varying components. Try to figure out and use a design pattern which would provide similar kind of segregation.
8) Design to interfaces
The stable components should always be designed to interact with the interfaces of varying components rather that the implementations, remember they were encapsulated out because they can change, designing to interfaces provides flexibility required for change.