Of all the productivity tools available to UI/UX developers today, few are as ubiquitous and effective as the humble checklist.
In “The Checklist Manifesto”, Atul Gawande explains that simple checklists can transform the way we work. In his book, Gawande was trying to find a way that doctors, surgeons, and nurses could deliver better, more consistent outcomes when working in an operating room - a literal life-or-death situation.
“We have accumulated stupendous know-how,” Gawande writes in his book. “We have put it in the hands of some of the most highly trained, highly skilled, and hardworking people in our society. And, with it, they have indeed accomplished extraordinary things. Nonetheless, that know-how is often unmanageable.”
Although software development isn’t exactly a life-or-death endeavor, we can apply the same lessons by using the power of checklists to prioritize effectively when collaborating.
When a software developer on a team wants to contribute code they’ve worked on back into the main project, they need to do a ‘pull request’ or ‘merge request’. It’s the main way developers contribute to software projects, but sometimes getting pull requests approved can be agonizingly slow.
Before this code can be added to the project, other team members will do a code review. This means checking for bugs, issues and suggesting improvements.
Generally speaking, code reviews are great. They radically improve code quality, increase developer productivity and prevent bugs from ever reaching customers.
But without a good process, code reviews can be, in a word…painful.
Code review checklists help ensure productive code reviews. A code review checklist prevents simple mistakes, verifies work has been done and helps improve developer performance.
Start with the basics. Is the pull request you are looking at actually ready for review? To determine this, here are some key principles that should apply to all code reviews:
If these conditions are not met, return the code to the contributor to be improved or separated into different pull requests.
This might seem initially harsh or counter-productive, but over several weeks your team’s outputs and productivity will improve.
Set some basic styling rules for your team and ensure these are followed. Consistent code styling is essential to ensure future developers can understand code easily and work productively.
Some basic rules:
To save time, you could check these rules are followed with an automatic code linter. Prettier is a good example for JavaScript projects.
Again, if these standards are not met, stop checking the code and return it to the contributor for review.
Set security standards for your project and check these are being followed religiously. The rules to be checked will vary depending on your project and organization, but some best practices are:
If you identify security issues in a code review process, stop and speak to the contributor. It might be a sign of a more serious issue in the project or a lack of training, both of which will need follow on interventions.
Is the project as performant as it could be, or are these obvious optimizations that might improve performance?
For example:
There are a myriad of tools that can help you optimize the web performance of your project. Good places to start are Chrome Lighthouse (also called PageSpeed Insights) and DebugBear for frontend projects.
Tests automatically check that code does what it should, making them a key part of the code review process.
Jest is a good option if you’re looking into automated unit testing. For automated end-to-end tests, check out Cypress and Reflect.
However, always remember that not all tests are bullet-proof and shouldn’t be relied on completely, as the next checklist item proves…
It seems simple enough, but we’ve all made this assumption before.
If you are on an agile sprint team, the code should always be checked against the acceptance criteria provided by your Product Manager or Product Owner. If acceptance criteria are not met, ask the contributing developer why.
Another common issue is that code works locally but not in production. All code being reviewed should be deployed to a staging environment that is consistent with your production environment. This prevents environment specific issues.
Before you send your code review feedback or sit down for a meeting, check that your comments will help your team to improve rather than be seen as criticism.
Code reviews are one of the most regularly occurring interactions you have with the rest of your team. Take the time to ensure you’ve framed code review feedback in a positive way, so that you’re contributing to a positive, collaborative code review culture over time.
It can help to reframe critical feedback as constructive statements. For example, if the code is missing test coverage, suggest “could more test coverage benefit us here?” to test and challenge the understanding of your team members.
Your checklist is only good if it’s up to date. That’s why it’s important to continually review your checklist and ensure it meets your needs.
Your code review needs will change over time as new team members join or your project gains new requirements. For example, if you added new tooling to your CI process, this should be included.
Checklists are just one of the many tools UI/UX developers use to keep productive. Let us know how your team stays productive by sharing with us in the comments below.
Originally published on dzone.com
#agile #collaboration #devtools #staging #codereview #cd ci tools