This week's lesson is not really technical in nature, but remains significant nonetheless in my growth as a professional Software Developer. I am on the final stretch of development before the Order Processor I've been building is ready to go into production, but unfortunately due to an oversight of mine the majority of this work week was spent refactoring a significant portion of its code base instead of cleaning up and making any final "production-ready" adjustments.
For starters, my company does not follow any kind of rigorous development standards (which I am slowly working to change). We don't currently do TDD, Unit Tests, Agile, Waterfall, or even regular code reviews. Ouch. But, again, I am making steps to change this.
When I was tasked with the Order Processor application, I was not given much information on how it will be used and was simply sent to compare legacy code and "improve on it." That's fine for most of what I needed, but led to what bit me this week: I did not yet have the experience necessary to know how valuable the input of your customer is. Regardless of whether they are a paying customer, your sales team, the manager who takes care of the orders, or another entity, they are the one who knows how the application is used everyday.
If I had followed an Agile-ish principle at project inception, I would have asked my "customer" for information on the project (e.g.: how it is run day-to-day) and hopefully would have been told that it sits on a server constantly scanning every five seconds for a new order at a status of 0 and will also handle orders coming in at later statuses by picking up where they would have left off. Unfortunately, not knowing this, I built my application under the assumption that the processor would only be run one time when a new order was placed and only handles orders in a linear fashion (status 0 to finish, no picking up in between).
This week was spent gently teasing apart my code base, extracting each portion that must be handled at each processing status and ensuring that it still runs as expected. Because an order may come in at any status, I could no longer use the values I set in variables at the beginning of processing - I also had to tease apart my data and leverage the database tables where I was originally using these getters and setters. Thirdly, I introduced a simple timer that runs the application every five seconds to check for any unprocessed orders and handles them accordingly.
Overall, although it was an annoying week, it was paramount to my personal development and has taught me a lesson that will stick with me forever. After this Order Processor has gone into production and I've been assigned a new task, I'll be much better equipped to ask the right questions before I've written thousands of lines of code.
Top comments (1)
This was the most important lesson I learned when I began my programming career 5 years ago.