I try to always rewrite complicated code. As an example, another dev who left the team had written a program in Elixir that nobody knew or understood. I rewrote it in python (with his help, since I still had contact with him over chat). After that, everyone in the team could understand the code and we could make changes very easily to it and document it.
Another program he wrote in python was kind of complicated and we would have bugs in it that we didn’t know how to fix. So I rewrote it with a completely different architecture with focus on simplicity. And again, now everyone could just read the code and understand it.
I think many devs are writing code that is not simple to understand for others. Then rewriting it can be worth it to avoid the pain of trying to fix bugs in complicated code.
That’s only the first stage. Once you get tired enough you start writing code that not even you can understand the next morning, but which you’re loathe to change because “it just works”.
Yeah I’ve had that experience too. But sometimes I write a lot of hackish code to get it to work, and then after spend time rewriting it so it’s easy to understand. But it depends on mood. Sometimes I don’t change it because it’s complicated and it would be too much thinking required to make it better. :)
I stepped out of webdev like 5 years ago. Now every time I try to get back into things to work on an open source project or whatever I just give up because I do not understand things.
Everything seems to be based on React which is some kind of magic templating library that does everything? And also dynamically updates thing in response to changes and talks to the server?
I much prefer the days of just using vanilla js to manipulate a DOM and talk to a well defined API.
The thing is, they look like too much for a simple app with near none interactive elements.
But once app starts growing, concepts like reusable components, reactivity and state management become such an important tool.
Imagine tracking shopping cart’s total value. With these frameworks it’s just one store containing total value, exposing the value as reactive state. Once the value changes, all components using directly or indirectly that value update immediately. In vanilla you would have to keep track of every instance where that value is used manually.
Additionally, if you decide keeping total value of cart in frontend is stupid (because it is), you just modify your store to provide only readonly value, and create setters that require you to pass item or item id. Then that setter would hit up backend keeping your cart’s total value, add an item, and backend would return new total, which would now be set as that store’s new total value.
These frameworks are kind of SOLID principles applied to chaotic world of user interfaces.
That second article is hilarious. It’s trying to point out that the first article is over complicating things then doing the same thing except the author thinks it’s not complicated what they’re saying when it’s actually insane.
I let my stand-in scrummy drive the TFS board this morning. In adding a PBI to the sprint he typed the iteration manually (a pretty long path name), rather than clicking the context menu and selecting “current iteration”
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.