Ways of developing applications
One of the challenges that lone developers like me face is that the entire design process rests with oneself. It often feels like the old "Jack of all trades, master of none" scenario - you can do all of it, just not very well.
I believe that the process one settles into is often driven by ones personality and the elements of the programming discipline that one finds motivational. This can be a blessing or a curse, depending on where your strengths and weaknesses take you. I for one tend to rush, I like to solve programming problems, but I also gain a deep sense of satisfaction from seeing my programs run correctly. I am good at chaining processes together in my head so that I can quickly see how to get from A to B when I want to effect a behaviour in my program. So what tends to happen is that I think to myself "Oh I can solve that" and then proceed to batter out the first solution I think of and move on.
This is not really the recommended way to develop software; for one thing it can lead to very buggy code since by taking the first solution, I find that I have rarely put sufficient thought into all the use cases and scenarios that my method/class/application has to deal with. If anything new comes along, the program either falls over or cannot be adapted easily to cope with the new scenario. Worse, I also tend to find, particularly when I am in unfamiliar territory, that the code also suffers from naivety and additional complexity created from the fog of confusion and annoyance that results from having to strain every intellectual sinew to concurrently develop and learn a new technology at the same time.
So how can this be changed? The answer is to have a strategy that suits your individual style. From the above synopsis I know that I need to slow down and to apply more of my intellect to devising ways to organise and test my code rather than just firing it out.
When I look at the activity of developers whom I admire, people such as Joshua Bloch, or BalusC, two things always stand out. Firstly, that they have taken the time to really understand their tools, and secondly they have developed a set of habits which ensure that they write good code. If you take BalusC as an example, simply reading through his responses on StackOverflow you can tell that he has a very deep and clear understanding of how JSF works, and also that he has developed clear guidelines of his own that he consistently applies to his work. I have no doubt that this extends from the simple conventions that he uses to the way that he imagines the objects and data that he works with. The same can be said of Joshua Bloch, in fact he explicitly says so in his book Effective Java. Studying the work of people like these can only be of benefit to your work, simply because they have huge experience and no matter how good a developer you are you cannot have all the answers.
So anyway, back to my own development strategy. I have decided that I will break the process down into the following stages:
I believe that the process one settles into is often driven by ones personality and the elements of the programming discipline that one finds motivational. This can be a blessing or a curse, depending on where your strengths and weaknesses take you. I for one tend to rush, I like to solve programming problems, but I also gain a deep sense of satisfaction from seeing my programs run correctly. I am good at chaining processes together in my head so that I can quickly see how to get from A to B when I want to effect a behaviour in my program. So what tends to happen is that I think to myself "Oh I can solve that" and then proceed to batter out the first solution I think of and move on.
This is not really the recommended way to develop software; for one thing it can lead to very buggy code since by taking the first solution, I find that I have rarely put sufficient thought into all the use cases and scenarios that my method/class/application has to deal with. If anything new comes along, the program either falls over or cannot be adapted easily to cope with the new scenario. Worse, I also tend to find, particularly when I am in unfamiliar territory, that the code also suffers from naivety and additional complexity created from the fog of confusion and annoyance that results from having to strain every intellectual sinew to concurrently develop and learn a new technology at the same time.
So how can this be changed? The answer is to have a strategy that suits your individual style. From the above synopsis I know that I need to slow down and to apply more of my intellect to devising ways to organise and test my code rather than just firing it out.
When I look at the activity of developers whom I admire, people such as Joshua Bloch, or BalusC, two things always stand out. Firstly, that they have taken the time to really understand their tools, and secondly they have developed a set of habits which ensure that they write good code. If you take BalusC as an example, simply reading through his responses on StackOverflow you can tell that he has a very deep and clear understanding of how JSF works, and also that he has developed clear guidelines of his own that he consistently applies to his work. I have no doubt that this extends from the simple conventions that he uses to the way that he imagines the objects and data that he works with. The same can be said of Joshua Bloch, in fact he explicitly says so in his book Effective Java. Studying the work of people like these can only be of benefit to your work, simply because they have huge experience and no matter how good a developer you are you cannot have all the answers.
So anyway, back to my own development strategy. I have decided that I will break the process down into the following stages:
- Define the problem as clearly as possible. In my case this means trying to look at the problem from as many different angles as possible and trying to think of the more subtle, interesting problems that may occur within the domain that the code will work in.
- Work out how the program will flow. This will give me the opportunity to test my ideas in my head and also gain an idea of which objects will be required and what their interfaces must contain.
- Create the program files and write the headline documentation for each class/interface. This will allow me to think about what the class actually represents, what scenarios it is designed to cope with, and what its responsibilities to the application will be.
- Start the Test-Driven-Design process with the first call that the application will make. I like TDD since it creates a momentum of its own. Each working test gives you confidence that the program is working, and pushes you on to work out the next step.
- For each method, try to break it. Think about the scenarios and parameters that you expect, and then see what will happen if you try scenarios that you do not expect. By doing this, you will uncover flaws in your code and get the opportunity to correct them before they produce subtle and unexpected behaviour later on. Before you move on to testing a different method, the method you are currently working on should check its parameters to ensure that they are what is expected and throw an exception if they are not (either a development-stage exception such as Java's assert() statement or a production exception such as an IlegalStateException - whichever is appropriate).
- Use the program! Try it out. If you can, get other people to try it out. See if they can break it.
Anyway, that's what I intend to do to become a better developer. I think that it will exploit my impetuous nature and allow me to enjoy those elements of programming that I need to pay more attention to.
Comments
Post a Comment