October 31, 2026 at 12:00 am
Comments posted to this topic are about the item PostgreSQL 19 Is Late
October 31, 2026 at 7:34 pm
The 1st time I used linting and formatting on a legacy project it found a lot of violations, many couldn't be fixed automatically. SQLFluff found stuff that would have caused hard to find bugs.
Sourcery and SonarQube found a similar volume of violations.
Switching on strict mode for Terraform/Terragrunt, again, generated many entries in violation reports.
Fixing these issues took time. Then we noticed something strange. We had absorbed the lessons these tools taught us. Even though we hadn't reached the point where we could switch on all these checks in our CICD pipeline we were generating fewer violations.
Eventually we were able to switch the checks on and implement standard pre-commit hooks so violations simply wouldn't merge into the main branch of the codebase.
Then came security scanning which revealed still more to do.
To get autopatching working safely we had to refactoring our code to support unit and integration tests.
It was a huge amount of work to get the point where changes could be made and we'd know that if the tests passed, we had a product that functioned as expected.
I've used Claude Code to critique a code base. This feels like Groundhog day, but at least we know what we are up against. Looking back I think of the old Irish joke about giving directions to a stranger "Well I wouldn't start from here"!
If you do get to the point where you have a robust automated quality gate, defend it like it's your 1st born. Fight against slackening quality. There will always be those who argue that getting stuff out of the door us what matters. Not if it comes back through the door as rework it isn't.
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply