One of the most frequent questions I get from people when I teaching them about web services, mashups and coding is “how do you get started”. Typically what they mean by this is how do I go about building something from start of finish. I have my own methodology for building things and goes something like this.
- Outline the what the thing I’m building is supposed to do. Basically this is what I’ve learned many development shops call “creating user stories”. User stories are basically stories how the user would use the tool being built. For most complex systems there is lots of them. For a simpler system there might be only one user story that might have sub-stories. Most of my projects have a single user story with substories.
- Once I have the user stories I map out (on paper) how the application is going to work including anything about what other systems it needs to interact with. I try to be very detailed with this including information like what information I need to send from my application to an external web service to get what I want back. If I’m dealing with a new web service this is where I do my research about the service and also if I need to find a new service to suit my needs then I do the research for that here. I’ll pinboard documentation for any new service I’m using and any examples I can find.
- Once I’ve mapped everything out on paper, I transfer this to what I refer to as pseudo-code which is basically the skeleton of my real code. In my case it is the real PHP code file that is going to be my application. It consists mostly of lots of comments about what’s supposed to be going on where in the code. I also will pull out pieces of code that repeat as part of this process and make them functions. The functions are typically empty except for comments about what they do. It isn’t uncommon for me to have to do more research in the pseudo-code phase. If I realize in writing my pseudo-code that I’m going to need to use cases in my code and I haven’t done that in a while. I’ll look that up and pinboard examples for later.
- Once I have my pseudo-code I usually start the real coding on the project filling in sections as I go. I use the stuff I’ve pinboarded to help me work faster.
I try very hard to work on the code in testable sections. This allows me to test as I go and make sure things are working the way they should before I get the whole thing written and get caught in a tangle of where the heck is my error. It also allows me to have stopping points when I need to stop for a break, meal or the end of the day. I like to make notes as I go within the code but also in my task list which I usually use to document the project. I almost always have a task list with subtasks so I can keep track of the fact that I wrote code to accommodate all the user stories. I like to check off functionality in my task list as I go.
If I’m working with a new service or function that I’m really not familiar with, I’ll open up a separate coding document to do some testing outside of my application. This allows me to understand how the new thing I’m learning works separately from the complexity of application.
- The last thing I do is test everything to make sure it works properly. I do this based on the user stories; pretending I’m a user working with the application. If something is broken I fix it.
- If the application is for learning/demonstration purposes, a new thing I’ve been doing is writing up a document about how the code works for others to learn from. This is can be the hardest part of the process if I’ve been lazy when I documented the code. It also is much worse to create this type of thing later because you have to go back and relearn your code.
My way of doing things is just one possible method a developer might use to build things. If you work as part of a team you have lots of tools at your disposal and the process is stricter because people can be working on the same code at the same time. In terms of tools, I use version control now. I don’t know what the heck I did without it and would go insane if I didn’t have it. I’ve also mentioned my testing setup before. All of these make the development process go more smoothly for me. Every developer and development shop has to work out their own practices but I thought it would be helpful to share mine since I frequently get asked about them.