05-23-2013, 08:12 PM
Base code skeleton
Finally, after almost a week of planning, I feel that have done my homework, did the research on what is needed, and prepared myself thoroughly for the actual coding. So let's start writing some code. I like to start my code as a skeleton - put together the main parts, make a high-level picture of what needs to be done. First, write the toplevel functions, they won't do anything yet, but make the code organized; also this allows for some last-minute thoughts about the architecture to surface. Then, go deeper, fill in the functions, make them call lower-level functions; for the time being, those will do nothing, return a dummy value etc.
For example, for the very start, we don't need the storage to actually do anything, we'll have the big access functions, such as AddArea() and GetAreasNearToCoords(), but they will not be interfacing with the DB, AddArea won't do anything except for maybe logging the request, and GetAreasNearToCoords() will return one dummy area. This is to simplify testing of the code that will make use of the storage. This way we'll have a working skeleton done quite fast and can delve into the details later on.
Finally, after almost a week of planning, I feel that have done my homework, did the research on what is needed, and prepared myself thoroughly for the actual coding. So let's start writing some code. I like to start my code as a skeleton - put together the main parts, make a high-level picture of what needs to be done. First, write the toplevel functions, they won't do anything yet, but make the code organized; also this allows for some last-minute thoughts about the architecture to surface. Then, go deeper, fill in the functions, make them call lower-level functions; for the time being, those will do nothing, return a dummy value etc.
For example, for the very start, we don't need the storage to actually do anything, we'll have the big access functions, such as AddArea() and GetAreasNearToCoords(), but they will not be interfacing with the DB, AddArea won't do anything except for maybe logging the request, and GetAreasNearToCoords() will return one dummy area. This is to simplify testing of the code that will make use of the storage. This way we'll have a working skeleton done quite fast and can delve into the details later on.