The only man who never makes a mistake is the man who never does anything.Theodore Roosevelt
- why to use
undefined is not a function
I want to talk about some of the biggest 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 problem using the window object for 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 which 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 be able to determine which view class made the call. As multiple views could trigger a request at the same time we also implemented a simple queue mechanism which made 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 which occurred. I also did not write regression bugs after I fixed a bug so that 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 a lot of dependencies had to be mocked.
Reading recommendation: How to know what to test
I finished the app in time and budget but the problems raised after I left the project. Of course, there were bugs but the customer did only provide 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 image, this did not improve the already bad code base I left there.
Additionally, the app had to be rolled out in more regions which all had special business requirements. As the app was not scalable and flexible at all, this became quite a problem for the next 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 you need to, you may get into troubles as it 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 to establish a code review process with a more experienced developer.Cover Image by mohamed Hassan from Pixabay
Du hast einen Fehler in diesem Artikel gefunden? Du möchtest gerne etwas klarstellen, aktualisieren oder hinzufügen?
Alle meine Artikel können auf Github editiert werden. Jeder Fix ist willkommen, egal wie klein er sein mag!Ändern auf Github
Senior Frontend Developer (Freelancer) aus München mit Fokus auf Vue.js☕️Kauf mir einen Kaffee