4 ms·
I always find it fun to read through these kinds of stories, particularly when we all know we've been there, are going to be there at some point, or are sitting
by emeraldd 13y ago
I always find it fun to read through these kinds of stories, particularly when we all know we've been there, are going to be there at some point, or are sitting there right now. For instance, myself and two other co-workers were working on a project several years back that involved passing around an array of values. I was building out a Swing based UI layer and infrastructure to wrap their logic and database access layer. At some point, something broke in the backend and I tracked the issue down to a block of code that was taking an array of values and constraining it to have no duplicates. The problem being that our dataset could easily have and should have duplicates. I fixed the issue with the comment "This imposed set semantics on something that is not a set."
Granted, I could have written the comment a little better, i.e. more context as to why set semantics were an issue. My co-workers later told me they found my change and spent 3 hours or so trying to figure out if I was right or not, eventually concluding I was. Of course, I was just down the hall and neither I or them thought to go ask the other about why things had changed or if it was a valid change in the first place. A little communication could saved a large amount of time ... Ah well, live and learn.
- wting 13y agoI made this same mistake refactoring a function to not process duplicates that the original dev caught in code review. I argue that assumptions (intentionally re-processing duplicates) should be explicitly communicated through comments, unit tests, or assertions. In the article, author states that existing unit tests checked that two digit zip codes were invalid. The question remains how a refactor that fails unit tests was pushed to master.