I don't know how to describe it well, so let me just start and you get an impression of what I mean.
When I start writing a program or a script I asks myself, what it should do and what is necessary for it. Then I gather my material of frameworks or new things I would like to test out. My next step is to open up my text editor and lay out the basic function and classes I might need. From these classes and function I pick the one which is most important. For example I need to scrap some website, so I write the scrapping function first, because without it everything else would be useless. I debug these function till they work and go to the next higher function. At the end I write the interaction with the user.
Do you have other approaches like writing the whole script in one go and then start to debug it and if so, why do you do it this way? Does a design pattern like Model-View-Controller interfere or forces you to write your code in a specific style?
I'm excited for your answers!
Top comments (3)
I tried writing a reply 3 times. They were all different. It's a dissapointing answer maybe but really...
It depends
Following Udi Dahan's advice you should insert a pause after saying that and put on your thinking face :)
From my experience it is good to have a clear requirements before you start to write anything. So I usually think about what is needed, write it down somewhere, on paper or in notepad. I work with that until I have a nice point of view of what I need to create. Sometimes it is not necessary, because ticket or my own assumptions are clear enough to start coding. But I do not start with writing production code.
After I get all requirements, I start to write unit test for general classes. On this level I can clarify my dependencies, mock it and test general purposes objects. While writing tests, I am working on high-level production code with injected mocked dependencies. Next, I am getting deeper to more detailed classes. I implement them with the same way.
And this is how I work with all the code. I move from general to specific. Always test first, then work on production code. This approach is called
test-driven development. It pays of in a long term projects. For some proof of concept application, or the small ones it is not necessary to follow this way. But I use it as a habit.Refering to MVC, it is also possible to use TDD. Starting from testing controllers, then going deeper to services, models. Views are a little bit different topic and I do not have much experience with testing it. From my point of view it is enough to run an app and go through all the paths.
I hope you will find it helpful.
Bob's answer is spot-on: It depends. But, in general, I follow the basics of TDD.
The first thing I do is hard-code the result I want to see, and then build a test to make sure that it works. So, for example, if I'm building a process that will use JS/AJAX to display today's weather for my location on a web page, I start by hard-coding the HTML on the page, and building a test that checks to make sure that the HTML is there.
From there, I write the JavaScript that populates the weather display. Again, still hard-coded. The original test still should pass.
Then, I'll write the AJAX call to retrieve the weather from a third party weather information service. I'll hard-code the location. The original test still must pass, and I'll write new unit tests as needed.
Next, I'll write the code to retrieve the current location, but I'll hard-code the return value. Original test still passes.
Then, I'll update the location code to remove the hard-coded location and have it determine my current location dynamically. As before, I'll write unit tests for this as needed.
At this point, I've built out the code to find my location, pass it to the weather service's API, retrieve the current weather for that location, and display it. All my tests pass, and I have a working solution for the original task.
Next, I start expanding the testing.
I live near Los Angeles, California, USA, but my code should work anywhere in the world. I write a test to make sure that my code still works if I travel to Helsinki, Finland, or Lima, Peru.
I'll look for potential points of failure, and make sure that my code will break gracefully if, for instance, the AJAX calls fail, or if the AJAX call returns the HTML for "500 Server Error" instead of the JSON I'm expecting.
When I'm done, I have a reasonable stack of automated tests, and code that I can be confident works as needed.
I find that coding goes pretty smoothly when I work like this, and I do less re-thinking, because I'm continually starting from code that works (in a loose sense), rather than trying to build separate components and then cobble them together.
If I'm working with existing components, I follow a similar pattern, but I make sure that the first things I soft-code use those components, since I don't want to make incorrect assumptions and have to rethink everything later. I start with the things I cannot change, and build around them.
I hope that's illuminating!