每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；微博：https://weibo.com/openingsource；電報群 https://t.me/OpeningSourceOrg

今日推薦開源項目：《這是什麼？是代碼 Code Surfer》傳送門：GitHub鏈接

推薦理由：一個 React 組件，能夠幫助你突出你的代碼，如果你有一大堆代碼要說明，為什麼要把它們丟在編輯器里，然後用你的滑鼠去划出重要的那部分？試試這個吧，這可比滑鼠划過去簡單而管用得多。

今日推薦英文原文：《Passing Code Reviews Fast》作者：Jackie Tung

原文鏈接：https://medium.com/@jackie.tung/passing-code-reviews-fast-b58148ab3395

推薦理由：讓別人在審查你的代碼的時候花費更少的時間，這其中有一條是在任何時候都很適用的——線下對話，這可比線上對話有效率得多（至少你們不會再發表情包了）

Passing Code Reviews Fast

Coming from being a code monkey on Wall Street trading desks, I recall the culture shock during code reviews in my first job in Silicon Valley. Why are we nitpicking indentation and variable names? Who gives a sh*t about being Pythonic? Unit tests? Pfft! Is a LGTM from me, to me not enough?

Four years later, I』m fully adjusted. I get that having code reviews probably is a sensible idea. This article won』t debate the merits of code review culture, nor recommend tooling of any kind. Instead, I will focus on human aspects to sustainably getting to 「ship it!「 as fast as possible.

Ask Nicely

Specific reviewers usually have no obligation to look at your code at all. Even if they do look, timeframes are not guaranteed.

In short, each code review performed is a favor granted by the reviewer. So ask nicely. For example:

Never take eventual code acceptance for granted. It』s disrespectful to diligent reviewers. Blind accepts by indifferent reviewers defeats the whole purpose of code review.
Correctly frame urgent requests as your own fault for not planning ahead, not the fault of reviewers being slow. It』s up to you to address all feedback as fast as you can.

Digest Feedback

Accepting feedback often means extra work. This leads to a reflex to resist actionable feedback — I have seen it in myself and others. This typically manifests as grasping at weak technical arguments to avoid making changes.

In the extreme, this can lead to people not wanting to review your code at all. It is a losing proposition: They cannot accept code without reasonable fixes; but you have a reputation for being unwilling to listen.

Take a step back, fight the inertia, and be open to feedback. It might be good for you.

Talk Offline

Text-only communication is terrible at expressing tone and emotions. It is common for review feedback messages to be taken the wrong way.

Once an issue escalates beyond the purely objective (e.g. A is better than B, because 1+1=2), just walk over and have a real conversation. Communication bandwidth is much better face-to-face for most people anyway.

Trolls

On the off-chance that you think you are being trolled — that nothing you ever code seems good enough — what are you to do? First you should establish that the reviewer is indeed being unreasonable. What if your code really is crap? While the reviewer』s attitude is uncalled for, perhaps you need to improve your coding skills also.

You need a second opinion. Lay out the evidence for your manager or peer. They can let you know whether it』s you or them.

What doesn』t kill you makes you stronger — So relax: getting trolled in code reviews from time to time probably just makes you a better professional software engineer.

Perfect is the Enemy of Good

There is always a smarter way, or an extra abstraction that makes the code more generic, scalable, extensible, or harder-to-read, etc. Some reviewers enjoy pointing this out.

But code needs to be shipped to provide value today. What』s the best way to handle this? Perfection is seldom required and never budgeted for. Perhaps polishing this specific piece of code to handle 1000x load is not an efficient use of your development time.

Here is one reasonable way to handle this:

Thank the reviewer for the great feedback.
Explain the immediate value provided by the baseline code change.
Add a TODO documenting the suggested improvement as an inline comment.
Add a task to your team』s project management system (cc. the reviewer).
Allow management to prioritize this accordingly.

Obviously, spamming this strategy to deflect every suggestion won』t make you popular. When appropriately used however, this is graceful way to break an impasse for all parties. The reviewer feels like his smart idea is acknowledged (and credited in the TODO); you get to ship; users get value now. Win, win, win!

Preemptive Strike

Perhaps you made a conscious coding decision to take certain shortcuts rather than reach for perfection. Write a comment right then and there! Explain the justifications and preemptively add a TODO. This saves time during code review, and lets reviewers (and maintainers) know that you were thoughtful and deliberate about your code.

The Follow-Up Change

Suppose you agree with a suggestion for a big improvement, but it involves lots of additional code. Should you do it right now? If the baseline code is functional and correct, it might not be a good idea. Other reviewers might have already spent time reviewing and are satisfied with the baseline code. In your subconscious rush to rewrite the algorithm and inject more code, what』s to say that no new bugs are introduced? If there is no obvious harm done to push the code as is, then just do so.

But you must make a follow-up change. This is similar to the TODO prioritization strategy earlier, except that you work on the improvement immediately after the baseline code passes review and is pushed to trunk.

Make sure you follow through though, or your reputation goes to sh*t.

Code Surfer

2018年10月5日：開源日報第211期