開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《課程 cs-video-courses》
今日推薦英文原文:《3 Tips to Become a Better Code Reader》
開源日報第1008期:《課程 cs-video-courses》
今日推薦開源項目:《課程 cs-video-courses》傳送門:項目鏈接
推薦理由:該項目是一個非常全的計算機技術視頻課程與講座的清單,從演算法,操作系統到計算機金融和量子計算機。
今日推薦英文原文:《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/