Do you get cold feet when it's time to implement code changes? What are your go-to strategies for overcoming fear of code changes and improving development practices?
Follow the DEVteam for more discussions and online camaraderie!
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (10)
Prevention is better than cure β do not create code that you will be scared to change π Meaning avoiding complex frameworks, fancy monorepos, microfrontends, and tools with millions of dependencies. But if you have some already and itβs too lateβ¦ just a good testing suite and a team of responsible peers for code reviews and QA.
A good way to start changing complex code with confidence is with tests. We start with the results of the previous code and test your final code with the same values. If you have the same results(Or better) with your new code everything will be fine.
I have succeeded with this technique where others fail a lot of times. Trust me, is a good advice(In this situation).
Two words: Regression tests!
Depends on the project,
Current environment has 200+ projects with a code lifespan of 1month to 20 years old.
Some projects I have no compunction about changing code, running the tests and booting the results up to pre-prod and alerting the testers.
Others... review, review, review, establish first if the existing code matches the expected starting point, make the changes, test TEST TEST, review, TEST, regression, TEST, pre-prod with Prod's data (The end-users/testers don't have good test cases from well known data, just This is prod, and I know it when i see it style correctness)...
Mostly it comes down to the age of the software, my own familiarity with it, the documentation state (existing: y/n; updated: y/n; correct: y/n; complete y/n;) the consequences of defects: critical vs. mundane, and the recover-ability in case of defects.
Our end-users are the 'business' to our 'IT' so we treat them as internal clients and partners while having the organizational trappings of a software for hire shop.
Good times? Β―_(γ)_/Β―
It depends. A well-maintained and architected codebase will make it a lot easier that is for sure. If you have good test coverage for the critical paths, this removes even more of the fear. Breaking down the requirements into the smallest possible tasks, using feature flags, and a staging environment that mirrors production distill the fear even more.
If it is truly scary to make changes, then it sounds like there is a need to tackle some technical debt, improve documentation and testing, and avoid single points of failure in terms of knowledge about the system.
I watched the following video a week or so ago and it was support interesting approach to taking back control over a codebase that has a lot of technical debt.
In addition to all of the other great tips here: at some point you just have to start making tiny steps. Figure out the obvious steps, but also where the biggest unknowns and risks are, then start chipping away at one one small part of the problem.
Change is a practice. You only get better at change by practicing. If the problem service is deployed every 6 months, find a way to make it 3, then 1, then weekly, then CD. The less frequently it's deployed the more likely people are to be scared because they just don't know what's going to happen.
Tests.
Avoid Frameworks whenever I can and stick to vanilla Javascript. ECMASCRIPT has wonderful features, just follow tried and true design patterns.
Code changes means new requirements or fixes. These are part of a software life cycle. The first step to clear your "fear" is to know clearly what these changes are. The rest is "implementation".
Go for it!
If I've a afraid of... I'm keep going through the darkness 'cause the other side rewards it amazing and awesome!
We don't let you give up!