今日推荐开源项目：《管理学 managers-playbook》
今日推荐英文原文：《A Junior Developer Explains Code Reviews》
今日推荐开源项目：《管理学 managers-playbook》传送门：GitHub链接
推荐理由：随着经验值的积累，队员精英化成为队长是迟早的事，这个项目是一系列在管理方面需要注意的事项列表，尤其是在沟通方面，高效的沟通技巧能够更快的让团队得到所需信息，即使不处在管理层面上，有些技巧也能活用于与同事们的日常沟通中。
今日推荐英文原文：《A Junior Developer Explains Code Reviews》作者：Max Albert
原文链接：https://medium.com/better-programming/a-junior-developer-explains-code-reviews-dd47693b347e
推荐理由：读同事们的代码能够带来的好处
A Junior Developer Explains Code Reviews
Spread influence, provide value, and become a well-rounded dev by improving your code review
There’s so much more to software development than writing code. Many developers totally underestimate the importance of reviewing code.It’s a shame because reviewing your coworkers’ code is a mission-critical responsibility. In fact, if your goal is to spread influence, provide value to the team, and become a well-rounded developer, then code reviews may be more impactful than the code you write yourself.
Code Reviews Increase Influence
No matter the company involved, when I ask my friends about tech promotions, I notice a common theme: influence. That is to say, developers become great candidates for a promotion when they gather enough influence.The idea of influence is somewhat malleable. If I were to offer my definition, I would say it is dependent on three things:
- How often are you weighing in on technical decisions for the team?
- How often are your peers asking you for help?
- How much of the production codebase have you touched?
Rather than being siloed into a niche section of the codebase, reviews allow you to weigh in on the big picture. The more of the business logic you understand, the more of a resource you can be for the team.
Code reviews allow developers to make technical decisions horizontally as well as vertically.
Writing code may earn you some credibility, but it’ll be specific and niche. Reviewing code is how to spread your knowledge far and wide.
Code Reviews Add Value to the Team
Reviews improve algorithm efficiency. Furthermore, they reduce the likelihood of dumb mistakes getting promoted to production. Reviews can standardize the coding style. They even scrutinize the business logic. The list goes on and on.There’s a myriad of reasons why companies are invested in code reviews.
When I write an article, I have many different editors review my writing before I publish. That’s because I am only human. I have many biases and will produce mistakes no matter how much I review on my own.
My articles that receive the most editing are more thoughtful and perform the best. For similar reasons, it’s imperative that when we write code, we have editors to check our work.
Code Reviews Are a Learning Opportunity
Code reviews also afford the developer a great opportunity to learn new things.Last month, I was roped into reviewing some React code that my coworker wrote. Though I do have some React experience, I usually program in Rx-Java. React was outside of my wheelhouse, to say the least.
After reviewing a few more React tasks, I was given the privilege of landing some React code myself. It was easy to do since I knew the codebase surrounding my task from the code reviews!
This is an extreme example, but it highlights my point very well. Code reviews are a great opportunity to get outside your comfort zone. They can teach you new avenues for accomplishing tasks.
To recap, these are the top three reasons why code reviews are tremendously important:
- Influence
- Value
- Learning
Tip #1: Leave Compliments on Your Coworkers’ Code
Code reviews aren’t only for critiques anymore. It’s important to compliment your coworkers’ code.And no, compliments on code reviews are not only a nicety to your colleagues — though that is a great benefit.
Code compliments are a great way to spread your influence!
Echoing a coworker’s technical decision by stating, “I understand why the team is implementing this code in this way” makes you a resource that your team can lean on — not only the author of the code. It shows a mastery of understanding and camaraderie.
Here is what I look for when I compliment code:
- Readability — If my coworker made complex business logic easy to digest, I give them a shoutout: “Hey, this is really clean. I understood this very easily. Bravo!”
- Algorithm design — If my coworker implemented technical logic in a fast and memory-efficient solution, I will acknowledge it: “Loved how you designed this algorithm!”
- Improvement — If I notice my coworker made a mistake at first but then revised it, I will compliment them and offer my support of the new design: “I like this implementation a lot more! Well done in finding an alternative solution!”
Plus, if I can’t find any legitimate critiques of a developer’s code, I will not feel pressured to make up a phony critique to feel like I’m contributing. This happens often in the development world — and it’s hugely counterproductive.
Tip #2: Understand Your Team’s Objective With Code Reviews
Some teams have strict technical requirements. Thus they need developers to nitpick each other’s algorithms.Other teams don’t have such harsh technical requirements but demanding business requirements. These developers need to focus their attention on the business logic.
Some teams have neither! Developers can instead focus on writing clean code that is future-minded.
Finally, some organizations strive to cover all three scenarios. They understand it’s expensive but feel that it’s worth it in the long run.
Whatever the case is, it’s important as a junior developer to find out the goal of code reviews for the team.
You’d be surprised by what those objectives can be. I remember the first time I found a slight optimization in a senior developer’s code.
I brought the optimization to their attention in a code review. They told me, “Yes, I thought of that as well. But the truth is, the optimization is very slight and the code is so much more readable in the current form. Since readability is our highest priority and the application has no speed requirements, I believe it’s best to leave as is. Do you agree?”
Of course, this is an extreme example, but it’s an important one. Spending development time tracing your peers’ technical implementation is expensive and possibly not worthwhile to your team.
Tip #3: Ask Questions About Your Peers’ Code
There is no shame in writing a comment like, “Hey, I would love to approve this code, but I’m having trouble understanding this section. Could you please come over and explain it to me?”These types of comments provide three great pieces of information to a team.
For starters, these types of comments let the author know that there is a readability issue. If their peers don’t understand the implementation, that is never good. It may be bearable, but it’s not ideal.
Also, these comments can actually speed up a team’s productivity. Spending ten minutes of a developer’s time to get a teammate unstuck is usually a great trade.
In conclusion, this is a great learning opportunity for the reviewer. Often, the reviewer learns a new “trick” and it becomes common practice across the codebase. These types of interactions produce smart developers.
Code reviews are an art form. Developers often lean on their peers to review their code and are elated when they find colleagues who are exceptional at it.
During my first internship as a full-stack web developer, I was hesitant to raise my first pull request: “I’m not sure if my code is optimized enough. I want to take some more time to clean it up."
My colleague replied, “Just raise the PR and don’t sweat it! The other developers are great resources to help find those optimizations!”
From then on, I was much more comfortable pushing code and thankful to have a great support system of teammates.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
