Hacker News Reader

Just file a new bugtracker ticket or whatever that says "Clean up foo.js, it does Bad Thing A and Bad Thing B"?

There are processes for sustaining code architecture reviews and paying back tech debt, but if you're in a team that's merging obviously terrible code you might not be large enough to want that kind of structure.

View on HN

I've probably over-exaggerated a bit how "terrible" our merged code is but anyway, my point is that at the "review" phase the code is still "imaginary". We think that it'll work, but it hasn't been integrated with anything yet, it hasn't been battle-tested or, often, even used. Obviously, we find a lot of issues after the merge and filing tickets allows us only "not to forget to fix them". I feel like there should be a standard practice aimed at preventing those issues from RE-occurring.

Reply on news.ycombinator.com