Python – Don’t be afraid of the dark
You may have an enormous ball of mud written in Perl but there are many benefits to introducing a new language like Python or Go:
- The communities are vibrant
- It’s easier to hire someone
- They can do everything Perl can do
Documentation – Have some
- Do not strip the comments from the code. That reminds me of WWII UK when signposts were removed to confuse the enemy.
- Have documentation for each sub saying what the inputs are, the outputs and if you have a god object, what the side effects are.
- Have documentation, preferably in POD in the code that reflects precisely what the code does. You can do lots with this. And test it.
Don’t have an overly complicated branching strategy
- Don’t have a main branch that isn’t main/master.
- Have a branch for each story.
- Have branches for releases.
- Do gitflow, it’s simple.
Jumphosts – They’re a PITA
- Don’t be SO paranoid about security
- Are you so locked down you have to ssh through a jumphost? And the jumphost won’t do ssh forwarding?
- That breaks so much: no sshfs, no remote editing in your chainsaw of choice.
- For bonus points, the dev machine can’t see the git repo. Please. I don’t like coding with a paper bag on my head.
CI on commit – Do it automatically
- Once you have tests, run the CI pipeline when the code gets committed.
- Preferably deploy (CD) that branch to the/a dev machine.
- It exercises your deployment process. Remove a speed bump.
- Deploy to dev and scheduled to test. It’s a computer: automate it.
- Make friends with Docker. It makes life SO simple. Having laptops able to see the database is a BIG WIN.
- Keep your dev database up to date.
No tests – a classic
- Write your code so it’s testable. Don’t do everything through a God object. Have subs that have defined inputs and outputs.
- When using Test::Perl::Critic::Progressive (or equivalent) to make sure your code isn’t getting worse, you’ll probably need to copy t/.perlcritic-history into and out of the artefact store between each run.
- Can your CI machine see a test database? If not, you’re entering mocking hell.
- Tests provide code examples. This is good.
- Put the tests on a pre-commit git hook. Remember to chmod +x it.
- Graph the progress if you can.