A Clean Code: Episode 1 (Remake)
Important note(s) to myself as a Developer
"Adding manpower to a late software project makes it later" Fredrick P. Brooks Jr.
As shown in the above images, new manpower will introduces many unpredictable things as well, as previous rotten/bad code was left for them to do bugfixes and new features. Meanwhile the trusted developer, working on a redesign.
A decision to redesign a late software projects was a nightmare:
- Requirement Docs exist in the old code (makes it harder to catchup, as the projects grows overtime)
- Customer will unhappy (As new redesigned system might unable to do most of the old system does)
The danger of renaming or fixing a bug that widely used by client or customer-developer in our Library/Software Projects. In Android, sometimes library developer will notify the breaking changes happened to avoid consumer/customer of that library experiences this issue. Or the Android Library Developer will make it backward compatible in a stable manner, after a few releases it before removing/breaking it.
This what Kotlin, Gradle (or AGP) did for at least 2 major/minor releases before deprecating it or even removing it!
Inseparable code (unpredictable, we also never knows how to reuse the components) makes it us wants to rewrite the code instead of reusing it.
Duplication is an alternative to avoid reusing the wrong abstraction in purpose. Anonymous (been get this phrases somewhere, but not sure if it from uncle bob or someone else though cmiiw)
Who writes the smell code? We. We are the writer. We need to go fast. Customer didn't care if sits down to talks about the right things to do. Tight deadlines. Managers Anger. Etc
Adding that "TODO" for later might means we were not go back to fix/clean it later, as a tight schedules and new features always coming up!
Avoid try to rush writing code. It'll slows us down in the long term. Take our times to think and design carefully, before adding this features. Discuss this with the teams, how to make it better, especially when we dealing with legacy codes. That also occurred for the new features we tries to write. A 1-2 Duplication might be better until we know how to test the important pieces of codes, so we can reusable that component/method later.
The extracting method to be testable will helps us a lot to avoid breaking changes in the production codes, meanwhile we try to migrate/refactor that pieces of code.
Good code is written by someone who cares about the system/products. It'll takes times to be patient and wants to tells other developer what piece of code tells to them. As we care for it, we also wants to be empathy with other devs
"how to write code that others will think is pretty much what they expected." Uncle Bob
We need to leave our code better than we previously write. This is happened when occurred in that pieces of code. But carefully breaking the changes.
That's most of a painful and best practices mentioned (not all) by any means, related to my use case atm.
Thanks Robert Martin