What is This?
That's a good question. We will be looking at the different parts of Software Design, and how they affect our code. The reason I have decided to create a tutorial on this, is because it is good to understand how you write your code. It can also help you in the future, as you can think about the Design Philosophies, and which will best suit your style.
I may say/do something differently to how you would. If I do, don't start hounding me in the comments, instead, explain how you would do it, someone may find it useful in their ventures.
What is a Design Pattern?
It's best to follow a Pattern when writing code. As humans, we are susceptible to flowing them anyway, so you should find the one that is best for you, before you fall into a trap that can be hard to escape from. But what do I mean by a Design Pattern?
Well, this is how you structure your code. It defines what get placed where, what gets done, and how it is done. You may prefer to get User Events first, then Process those events, and finally Show the results to the user. Or maybe you Show the user Controls, then Process what to do. Your Pattern may not even include Events, but instead implement Objects.
This is all down to how you write your code. The more comfortable you are when writing your code, the easier it is for others to understand how it works. We all remember our beginner code, it was messy, but we slowly learned techniques that made us structure the code differently. It's time to combine those techniques into a Design Pattern that is comfortable for you.
Finding Your Own Design Pattern
There are many Design Patterns out there already, and many that you could find for yourself. You just need to find the one that is most:
- Easiest to understand,
- Clearest to read,
- and Comfortable to implement
for you. For each of us, this will be a different one. You want to make sure that it is something that you feel that you could really benefit from using. You don't want to use a certain Design Pattern because it is what most people use, you want to use it because it help you to understand and develop your code.
After Identifying Your Design Pattern
You will find yourself reusing this Design Pattern from project to project. By using a Design Pattern that you understand, the code that you write will become clearer for everyone, including you. You will even find yourself enjoying creating your code even more. It doesn't only speed up development times, but it also allows your to spend more time solving the real problems in your code.
Why Project Planning is Important
When you get an idea that you know you want to see through to the end. You should plan it out first. It doesn't matter how big or small you think the project is. You may think "Well, it's only a small program. No need to put the effort into planning it out." That's where most of the best projects die. People, either out of laziness or straight arrogance, don't plan out what they are going to do, and how the will do it.
You'll find that you don't start a project with the words "Where do I start?" Because you would have planned this out, you'd know what you need to do first. You also won't get to a stage where you begin "bodging" your way through the project.
Whenever you think of an idea that you want to put in the project, write it down, and leave it for a day. When you wake up and read the note for that feature you wanted to add, you may decide that it doesn't fit with what you are doing. You also won't end up frustratingly adding it in and ruining the hard work you have done.
That's another thing to consider. When you start feeling tired of the project, put it on the back burner. Let your ideas simmer around, and work on some other stuff. You may even just stop and read a book for a hour or two. When you feel like you want to work on the project, then work on it. There's no point spending four hours on the project, to get annoyed and delete it in two minutes because you had had enough of the project for the day.
How to Plan Your Project
Just like with the Design Patterns, you will all have different ways of planning your project. Some may create a Todo list, which will link to a diagram of the program in action. Others may create Flow Charts, and some will write up Software Specifications. It all depends on who you are, and how you like to do it.
If you try to do it in a way that is uncomfortable for you, you will end up creating something that even you will have trouble following. So think about how you prefer to Plan your Projects.
Make sure, that when you plan, you add ideas to the plan, and plan those out before adding them fully. You can end up creating major problems because you decide that you wanted an idea in there now. So don't rush, make sure that it all fits together like puzzle pieces.
You Make the Choices
There are quite a few Design Concepts to cover. These will all be retailed to the Design Choices that you chose. They will also depend on your Project Plans, but most importantly, your Design Pattern.
When you work alone, or even in a team, you will have to make your own choices. Does ii fit in with the rest? Should we design it this way, or that way? Be ready to change and make choices, you never know when you will have too. Some of these choices will determine how the code is formed, which will in turn change the layout of the project.
Bellow are some of the biggest Design Choices you may make with your projects.
This is one of the most common choices to have to think about. Do you want your code to be split up into "snippets"? Or should it just be made to work by itself. Both come with positives and negatives that you will have to weigh, and they may weigh differently depending what you are doing.
Being able to Maintain your code is important, especially with long term projects. You may have to make the choice to make it more Maintainable so that it is easier to fix in the future. This is another important decision that you will face when creating your project.
You will want a program that works, but to do this, you may have to add in extra checks, safety for user input, and other measures to make sure that everything keeps on working. However, this is one of those times where you are more so making choices based on time.
Once again, if you are making a long term project, you are going to want it to be Scalable. If it wan;t, then you would have to rewrite much of the program each time you changed it. You will have to decide if it is worth it to separate parts of the code, and make other bits more abstract.
Do you require your project to be more abstract? This becomes much more apparent when you look at how modular your code has to be. You may not even use any extra data, as it all will come from the user in the
Do want to refactor you projects code, to try and make it more efficient and easy to understand? This can be time consuming, so knowing how much time you have to do this is very important, along with doing this in the first place.
Balancing Your Project
This can be hard to do. In an ideal world, you would have everything done to the best of its ability. But this is the real world, nothing can be perfect. So instead, we compromise on some things. Doing this is a choice we have to make, otherwise we would end up devoting the rest of our life to fixing each and every problem.
Overview and TL;DR
When you write your code, you should follow a structure that is relevant to you. Whether that be:
- Input > Processing > Feedback,
- Show > Events > Processing,
- or another one that you have made/found best works for you.
This will make it:
- Quicker to develop your code,
- Easier for you to focus on real problems,
- and Easier for others to read and understand.
You then also have to make decisions about what you are going to focus on. Are you going to make it:
- Modular, so that it is easier to edit and add to later on down the line?
- Maintainable, so that you can easier fix problems that may show up in the code?
- Reliable, so that you don't have to worry about the possibilities of things breaking?
- Scalable, so that you can easier add new functionality to the code?
- Abstract, so that is is easier to reuse code later on in other projects?
- Refined, so that the code is as efficient as possible at doing its task(s)?
Allocating time to each of these will allow you to have a highly functional bit of code. However, you don't have the time to do each of these perfectly, so you will have to choose what is more important to do. This ability to do this well will come with time, so don't beat yourself up over it.
Don't forget to plan your project, even if it a little Todo list with a bit of writing saying how it links to the other parts. It will allow you to add new ideas, and remove old ones that you don't think are good for your project.
Also, don't start adding new ideas that you get straight to the project, no matter how tempting it is, you will end up ruining your hard work. Instead, write it down in your Todo list, and have a read through it before you start your project again. You may then decide that this is not the project for that idea, and remove it. Just give yourself time to think, before you add it in.
You should also stop working on the project when you get tired of it for the day. Again, you might ruin the hard work you put in.There's no point ruining a project that you have worked on for the last month to create, because you got frustrated over it one day. Only work on the project when you feel motivated to, not because to feel you have to.
This has been interesting to write, as I has opened my eyes to how I do things. I hope that you found it just as interesting to think about. Share in the comment how you do your work, it may inspire others think about how they do theirs, and what they can change.
Hope you have a great day!
If you have any suggestions for tutorials, leave them in the comments and I'll be sure to have a look. If you like one in the comments, then give it an up vote to show that you want to see it. It makes my life so much more easier. Thanks in advance!