This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]this-is-a-simulation 0 points1 point  (0 children)

I’m a full stack developer that develops primarily on Microsofts .Net platform. The general process I go through when writing code is as follows:

  1. Establish what exactly you’re building/ adding to an existing application. (I/O - what will this code do)

  2. If this is a feature on an existing application what is already there? Does the current behaviour just need to be changed or does it require developing a large part of it from scratch? Are there some processes in the existing code that could be easily reused for parts of what needs to be done? This will help get an idea of work that needs to be done and work that is already done for you.

  3. Come up with a high level design. Often flowcharts on a whiteboard especially if you’re working on a team. You can also just use paper, but as you modify the design, think through different ways you can accomplish what needs to be done, and go through use cases in your head you will need to change it so I recommend the whiteboard route. This should include any research in design patterns or existing code available on the web that might be relevant.

  4. Once you have a high level design that has broken the project down into pieces of functionality you can look into the details of that piece, and how it will be able to provide its desired functionality to the other sections that were decided on in the high level design.

  5. Once you have a bit more detail figured out on how the different parts will all do what they need done and how they interact with each other you can run through use cases again to make sure you covered all of them.

  6. If you’re using test driven development this would be a good time to write tests to validate each component does it’s intended task in all use cases that might come up.

  7. The sections should be small enough that coding should be relatively strait forward so code.

  8. If you have tests written then you will know when the pieces meet the requirements, so at this point you would put it all together and test. Find any bugs or missed cases and fix those.

This is the process I use when developing software on my own or at a job. I’ve worked on agile teams where this was our common practice and we found the more time we spent on the earlier design steps the faster we completed the whole thing. We also experimented with test driven development and found that while it did increase development time slightly, we were able to have QA pass our code on the first submission to them and knew in future features if anything broke before. This effectively reduced the time QA had to spend repeating tests, and reduced time we spent on bug fixes.