今日推薦開源項目:《命名指南 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/