今日推荐开源项目：《命名指南 naming-cheatsheet》
今日推荐英文原文：《3 Tips to Become a Better Code Reader》
今日推荐开源项目：《命名指南 naming-cheatsheet》传送门：项目链接
推荐理由：在团队中统一使用同一套命名规范是相当有必要的。这个项目介绍了命名时需要考虑的数个要点，比如使用 get 这样的统一前缀表示同一种行为，不与上下文中现存的名称重复防止混淆搜索结果等等，根据这些统一一套命名规范能够节省团队中所有人在读懂其他人代码上花费的时间。
今日推荐英文原文：《3 Tips to Become a Better Code Reader》作者：Živković Miloš
原文链接：https://medium.com/better-programming/3-tips-to-become-a-better-code-reader-c84fcb4cedc3
推荐理由：花时间读代码也是有需要的，毕竟读是为了更好的写，而读代码当然也与写代码一样不能蛮干
3 Tips to Become a Better Code Reader
Reading code is just as important as writing it. Here’s how to be a better reader
We’ve all been there: The wrong logic caused a critical bug. You could have prevented it during code review.Experienced developers know that reading code holds great value. It can reduce how much code you need to write and thus deliver reusable code.
With all that in mind, let’s proceed to the tips I’ve compiled for you.
1. Avoid Working With Code You Don’t Like
I’ve heard that reading open source code will improve my reading skills. I was checking out all the possible projects, but after a while, I got bored.You may be in the same spot. You can’t read all the code out there.
Be mindful of your time. Not every code you read improves your reading skills. I don’t understand assembly, so naturally, it will bore me.
Reading without context is a waste of time. Reading a code base that doesn’t suit you will lead to boredom. After you read the code without context, you will most likely leave a dummy comment.
Angular developers reading about open source calendar lib can improve their skills. Reading about changes in the Spring framework won’t if you don’t like it. Make yourself comfortable in the code base.
2. Always Understand What Is Going On
My first PR review consisted only of code review — checking for reusable code, whether the naming was correct, overengineering.I was wrong. You should always pay attention to the bigger picture.
Check the story first. What are the requirements, what are the acceptance criteria? Pay attention to what the business thinks and read through ticket comments.
Think through how would you do it. Does the logic in the PR do that? Then proceed. If not, leave a comment.
Don’t get that sinking feeling when doubting code quality. Critique the code crafted — not the developer. Always doubt code and don’t undervalue team members.
Look at these two comment examples and judge which one is better:
- “What did you do with this variable name?! Check Sonar for errors!”
- “This code is unconventional and can lead to a misunderstanding. Please change it to possible name, as that will do the job.”
Comprehend the logic, read the requirements first, and leave humane comments.
3. Spend As Much Time Reading As Writing
Reading code improves your writing as well. Take your time when reading your own code and extra time when reading other PRs.“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.” — Robert C. Martin, Clean Code: A Handbook of Agile Software CraftsmanshipDon’t only check the diff of the PR. Take a broader picture. Check the code for common logic in other places that can work here as well.
Get familiar with the context and then check the code. That will bring a new view of the code.
Developers spend most of their time reading code rather than writing.
Bonus: Talk With Your Team Members
Talking can shorten the read time. Have a call with a team member and go through the code together.This will serve as rubber duck programming where you’ll be the listener, unraveling some new ideas or a better approach to solving the problem.
Thanks for reading!
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
