When is the last time you did a code review?
“Criticism, like rain, should be gentle enough to nourish a man’s growth without destroying his roots.” — Frank A. Clark
E ver tried to use StackOverflow to just get feedback on your code, then your post gets deleted because it does not meet community standards? Then you head over to Reddit, then no one really follows subreddits of giving feedback for code reviews. I’ve personally had code I’ve written and wanted to show it off, but to who? For our Software Product Development course at Make School, Jeremy James and I decided to create a platform for a community of proud software developers where they can share their working functional code to get meaningful feedback on.
Good, better, best. Never let it rest.’Til your good is better, and your better is best. — St. Jerome
We soon realized that this platform can benefit more than just seasoned engineers to boast or brag about their craftsmanship but also a place where beginners can showcase their work and get constructive criticism on improving their code.
I realized that code review is essential for every software engineer starting or senior, and sadly, it seems code reviewing is a practice that’s foreign to many students, freelancers, and agencies. So let’s start by looking through Wikipedia on how they define “code review”:
Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.
In short; code review is the process of reviewing some code in order to make sure it works, and in order to improve it where possible. There are various ways to perform code reviews. However, in a world where so much code lives on GitHub, code reviewing often goes hand-in-hand with what we call a “pull request”. Problem with this is that it is hard to promote your code to the Github community and get eyes on it. Our solution is our platform is specifically for the community for code reviewing.
So why does this even matter?
Limits risks
Considered the most important reason of all. Having someone double-checking your work never hurts, and limits the risk of unnoticed mistakes. It is easy to get tunnel vision when being in the zone.
It dramatically improves code quality
This is not about standards and/ or code linting, this is about making your code more efficient. It can be from a better design pattern, a way to reduce complexity, suggestion for a smarter solution, or maybe improve on better
Big O performance.
Win-Win-Scenario!
Everyone can learn and get better. The code submitter is likely to receive feedback on their work, making them aware of possible problems and areas for improvement. The reviewers could well learn new things by reading through the code and figure out solutions applicable to their own work.
So as you can see getting code reviews cannot just be beneficial to the person that is asking for it but it can also be a way for developers to practice on reading other developers’ code and giving useful feedback to improve their code.
Working through the pains
During this iteration of our course, we learned the foundational skills of successful engineering teams, in pairs. Together we build a web app using “lean product development” methodology, the industry standard for engineering team collaboration. We learned how to program in an Agile Methodology (i.e. SCRUM, Sprint Planning, pair programming), a process to ensure that our app meets user needs and technical specifications.
Using tools such as Trello for product management really helped us stay on track on what needs to get done and trim out the “nice-to-have” for the “need-to-have”. Doing so helped pave the road for our for Minimal Viable Product (“MVP”) to be put into production.
Agenda for meetings
Define done (shipped, finished the code, completed wireframes)
Be able to demo the finished task
Talk about what went well last week and what went poorly
Acknowledge the other and give shoutouts
Plan for future improvements
Think of the next task and goal to work on
Sprint Planning — A meeting to determine what will happen in the next sprint based on what needs to get done and the teams capacity to work.
Sprint Retrospective — A meeting in the time between a sprint and the next sprint planning where the team assesses the previous sprint.
Considering what went well and what didn’t and then making a plan for improving what didn’t go as well as expected in future sprints or ensuring that the well-done actions are able to be repeated.
Doing sprint plannings and retrospectives helps teams coordinate efforts to achieve a larger goal and also improve the methods to achieve a larger goal. As a team, Jeremy James (Perzival1312) and I, stated at various points in time that certain things needed to get done and then we set about doing them.
We never really had any challenges that I would consider to be worthwhile mentioning. It was an easy-going time where we wrote code and collaborated.
In-person Feedback!
Pair programming became helpful for us, similar to that of giving remote code feedback which is what we are aiming for her with our web app. By far, pair programming encourages faster learning and up-skilling while maintaining fewer coding mistakes.
Wrapping Things Up
Having a regular and efficient code reviewing process is essential to maintain high-quality code standards, grow as a team and share knowledge between developers.
Asking for a code review is not a mark of weakness. There’s nothing embarrassing about asking for help, and certainly not in the form of a code review. Accept all feedback given to you.
Find what works for you. Reviewing code should be a large part of the code shipping process, so you should tailor it to your team. Make it the way you want so that it’s helpful and positive for everybody.
Thank you for following along this far, towards our journey on developing a helpful tool for code reviews. A thank you to Perzival1312 for making this a fun project. Stay tuned for part two where we will be talking about User Testing, User Interviews, User Journey, design, and what to expect in the future.
Again, all feedback is accepted. 😃 Don’t forget to drop some claps! 👏👏👏
Thanks to Rinni Swift and Sarin Swift for the contribution.