开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《命名指南 naming-cheatsheet》
今日推荐英文原文:《3 Tips to Become a Better Code Reader》
开源日报第1013期:《命名指南 naming-cheatsheet》
今日推荐开源项目:《命名指南 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.”
Commenting on code won’t only fix broken code. Reciprocity kicks in and you’ll get comments on your code. This will improve both your code reading and writing.

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 Craftsmanship
Don’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/