4 ms·
Document, document, document. Everywhere, repetitively, clearly, and more than you think you need to. Don't leave landmines for the next poor sap to step on. I
by solardev 2y ago
Document, document, document. Everywhere, repetitively, clearly, and more than you think you need to. Don't leave landmines for the next poor sap to step on.
I try to cross-reference my code with any relevant tickets/Jira issues/Confluence pages, leaving a bunch of comments like "// Works around backend checkout API off-by-one bug that can't be changed right now... see #BE-1234". And the Jira ticket itself will link back to the commit and mention a specific line if possible. But those things are ephemeral. Licenses changes, middle managers change, companies change.
The code is the only thing I write that might still be read years after I leave. Even if the Jira instance itself is gone, someone might still be able to search for "BE-1234" in their Slack or email history or whatever and maybe figure out the gist of what the original rationale was, or at least know that it was some sort of off-by-one bug that they need to further investigate. If it's not in a comment next to the code, it's not real institutional memory, just some other abandoned document in the graveyard.
I assume every line of code I write will be obsolete and rewritten within 2-3 years anyway (such is web dev life). The code itself doesn't really even matter (it's just a mishmash of JS fashion trends over the years), but the comments are the only things really illuminating the business need that caused the code in the first place, especially the weird idiosyncrasies and exceptions.
Any new programmer to the team can (hopefully) read the comment and figure out what they need to code, but if they just look at the code without any accompanying English description, they will often try to reverse engineer it, get the obvious parts, but totally miss the deliberate exceptions.
Writing specific tests for any non-obvious behavior really helps too, especially when a function or component behaves as expected for 95% of use cases but deliberately changes its behavior for some 5% of edge cases (like needing to support grandfathered data from another pipeline or whatever).