The Mistakes I Made In My First Software Project
The only man who never makes a mistake is the man who never does anything.
- why to use
undefined is not a function
I want to talk about some of the most significant technical mistakes I made in this project.
A failure is not always a mistake, it may simply be the best one can do under the circumstances. The real mistake is to stop trying.
B. F. Skinner
It would have been a much better approach to use the MVC (Model-View-Controller) or some similar pattern to avoid the tight coupling of logic and view.
I added JSDoc to every method in the application even if the method already had a declarative name.
Reading recommendation: Don’t comment your code!
This was probably my biggest mistake: I used the window object for global state and stored dozens of properties there. A summary of possible problems using the window object for the global state:
- anyone can change the state at any time (it is mutable)
- bad readability of the code
- testing can be tricky
- many more...
Reading recommendation: Why is global state so evil
To avoid code duplication in every file, I created a generic class that was used in every view to make HTTP requests. This was a very, very, very stupid decision and led to a large and unmaintainable hell of code.
Each method in this backend handler class consisted of a large switch-case statement to determine which view class made the call. As multiple views could trigger a request simultaneously, we also implemented a simple queue mechanism, making it more complex and unmaintainable.
It would have been a much better approach to handle the request in each of the views (ideally in each controller but as mentioned above I did not implement such an abstraction).
I wrote a lot of unit tests for the application, but in the end, they did not catch major bugs. I also did not write regression bugs after fixing a bug, so sometimes, I had to fix the same issue again. Additionally, coupling the view and business logic together in one class made it very hard to test as many dependencies had to be mocked.
Reading recommendation: How to know what to test
I finished the app on time and within budget, but the problems occurred after leaving the project. Of course, there were bugs, but the customer only provided a little budget to fix them. So my company assigned the tasks to working students or apprentices who just used quick dirty hacks to fix the bug. As you can imagine, this did not improve the already bad code base I left there.
Additionally, the app had to be rolled out in more regions with special business requirements. As the app was not scalable and flexible, this became quite a problem for the following developers of the project.
As you can maybe imagine it is not easy for me as a developer (or in general as a person) to talk publicly about my mistakes. But I think it is important for my personal development and I also want to take you the fear to talk about the mistakes you made. Also, you should not be afraid of making mistakes in your first software project, this can happen and you will learn a lot from them.
Asking questions is one of the most important things you can do if you are new to a programming language or project. If you don't ask questions when necessary, you may get into trouble, as happened to me. Especially if it is about defining a software architecture for a business application, you should ask a senior developer for advice. Get help from experienced developers as early and often as you can. If you are the only developer in the team, try establishing a code review process with a more experienced developer.