用什么代碼可以改變鍵盤(pán)

by John Cobb

約翰·科布(John Cobb)

為什么我改變了對(duì)代碼質(zhì)量的看法 (Why I changed the way I think about Code Quality)

What do you think about when you think about code quality?

當(dāng)您考慮代碼質(zhì)量時(shí)，您會(huì)怎么看？

Is it consistency? Enforcing a set of standards and best practices on your code through linter rules and formatters? How about ensuring your code has tests that run automatically during your build process? What about pull requests and code reviews — protecting your master branch from direct commits and having peers review your code?

是否一致？ 通過(guò)linter規(guī)則和格式化程序?qū)Υa執(zhí)行一套標(biāo)準(zhǔn)和最佳實(shí)踐？ 如何確保您的代碼具有在構(gòu)建過(guò)程中自動(dòng)運(yùn)行的測(cè)試？ 拉取請(qǐng)求和代碼審查又如何—保護(hù)您的master分支免受直接提交并讓同級(jí)審查您的代碼？

They’re some of the things that come to mind for me. Automated processes and manual checks. Smart and efficient. Yet, while they’re all useful, they really only address half of the problem.

這些是我想到的一些東西。 自動(dòng)化流程和手動(dòng)檢查。 聰明高效。 然而，盡管它們都很有用，但實(shí)際上只能解決一半的問(wèn)題。

我們不能使一切自動(dòng)化 (We can’t automate everything)

Automation is crucial for maintaining code quality. Static analysis of your syntax with a linter and automated testing should be mandatory. But I can write code that passes all the automated processes without any guarantee to its actual quality.

自動(dòng)化對(duì)于保持代碼質(zhì)量至關(guān)重要。 必須使用lint對(duì)語(yǔ)法進(jìn)行靜態(tài)分析并進(jìn)行自動(dòng)測(cè)試。 但是我可以編寫(xiě)通過(guò)所有自動(dòng)化過(guò)程的代碼，而不能保證其實(shí)際質(zhì)量。

Does the code follow established patterns? Does it use existing modules, or does it duplicate code? Is everything named sensibly? Is the code in the right place in the codebase? Will this change have wider, unintended, implications? Does this code actually address/solve what it intends to? Does it even work?

代碼是否遵循既定模式？ 它使用現(xiàn)有模塊還是重復(fù)代碼？ 一切都被合理地命名了嗎？ 代碼是否在代碼庫(kù)中的正確位置？ 這種變化會(huì)產(chǎn)生更廣泛的，意想不到的影響嗎？ 此代碼是否實(shí)際解決/解決了預(yù)期的問(wèn)題？ 它甚至工作 ？

Automated processes can’t answer those questions for you (yet). If you (or another human being) aren’t asking these questions of your code, then you’re probably not shipping quality code. That’s why we have code reviews.

自動(dòng)化流程無(wú)法為您回答這些問(wèn)題(至今)。 如果您(或其他人)沒(méi)有問(wèn)代碼的這些問(wèn)題，那么您可能沒(méi)有在交付質(zhì)量代碼。 這就是為什么我們要進(jìn)行代碼審查。

良好的代碼審查不僅僅應(yīng)包含代碼 (A good code review should be about more than the code)

Of course a code review should be about the code (it’s right there in the name after all). But it should also be about the broader questions posed above, and also about the end product.

當(dāng)然，代碼審查應(yīng)該是關(guān)于代碼的(畢竟它就在名稱(chēng)中)。 但這還應(yīng)與上面提出的更廣泛的問(wèn)題以及最終產(chǎn)品有關(guān)。

I’ve noticed a tendency for developers to treat code reviews as perfunctory. A rudimentary check of the modified code. A comment on any obvious mistakes (or just picking a nit or two to look busy).

我注意到開(kāi)發(fā)人員傾向于將代碼審查視作敷衍。 對(duì)修改后的代碼的初步檢查。 對(duì)任何明顯的錯(cuò)誤發(fā)表評(píng)論(或者只是挑一兩個(gè)尼特，讓他們看起來(lái)很忙)。

Five minutes, job done. Looks good to me.

五分鐘，工作完成。 對(duì)我來(lái)說(shuō)看起來(lái)不錯(cuò) 。

But, code that doesn’t address the requirements of the task is not quality code. Code that produces console errors or visual bugs in the device/browser is not quality code. Neither of those things can be picked up in a perfunctory code review. You can’t adequately review code unless you actually run it.

但是，不能滿(mǎn)足任務(wù)要求的代碼不是質(zhì)量代碼。 在設(shè)備/瀏覽器中產(chǎn)生控制臺(tái)錯(cuò)誤或視覺(jué)錯(cuò)誤的代碼不是質(zhì)量代碼。 這些功能都無(wú)法在敷??衍的代碼審查中找到。 除非您實(shí)際運(yùn)行代碼，否則您將無(wú)法充分審查代碼。

I propose that a good code review should involve at minimum:

我建議良好的代碼審查至少應(yīng)涉及：

• Pulling down the branch to a local environment.
  將分支拉到本地環(huán)境。
• Building the project (and checking that the linter and tests all pass).
  構(gòu)建項(xiàng)目(并檢查短毛絨和測(cè)試是否全部通過(guò))。
• Checking that the code runs error free in the target browsers/devices.
  檢查代碼是否在目標(biāo)瀏覽器/設(shè)備中無(wú)錯(cuò)誤運(yùn)行。
• Checking that the completed work matches the requirements of the task.
  檢查完成的工作是否符合任務(wù)要求。

If there are any issues with any of those steps the pull request should be rejected. Do not pass Go. Do not collect $200. Do not merge to master.

如果這些步驟中的任何步驟有任何問(wèn)題，則應(yīng)拒絕請(qǐng)求請(qǐng)求。 不要通過(guò)圍棋。 不要收取200美元。 不要合并到母版。

Reviewers should also use the code review as an opportunity to ask questions. If you don’t understand the code, then you shouldn’t approve the pull request. Don’t assume that the author knows more than you do — if it doesn’t make sense to you, ask for clarification.

審閱者還應(yīng)將代碼審閱作為提問(wèn)的機(jī)會(huì)。 如果您不理解代碼，則不應(yīng)批準(zhǔn)請(qǐng)求請(qǐng)求。 不要以為作者比你了解更多—如果這對(duì)你沒(méi)有意義，請(qǐng)澄清。

The reviewer has equal responsibility with the author for the quality of the code. This is a mindset that is essential for maintaining code quality.

審閱者與作者對(duì)代碼質(zhì)量負(fù)有同等責(zé)任。 這是保持代碼質(zhì)量必不可少的一種心態(tài)。

Comprehensive code reviews go a long way to helping ensure code quality. But there are steps you can take before you even open a pull request. Small things you can do that will help enhance the quality of your code, and reduce the effort required to review it.

全面的代碼審查對(duì)確保代碼質(zhì)量大有幫助。 但是，您甚至可以在打開(kāi)拉取請(qǐng)求之前執(zhí)行一些步驟。 您可以做的小事情將有助于提高代碼的質(zhì)量，并減少檢查代碼所需的工作。

仔細(xì)檢查您自己的作品是否完整 (Double check your own work for completeness)

I have an annoying habit. When I finish writing the last lines of code for a task, I mentally check the task off as complete.

我有個(gè)煩人的習(xí)慣。 當(dāng)我完成任務(wù)的最后幾行代碼編寫(xiě)時(shí)，我會(huì)在腦海中檢查任務(wù)是否完成 。

If I were to listen to that impatient voice in my head, I’d submit my pull request right then. But that code would likely contain many, or all, of the following:

如果我想聽(tīng)聽(tīng)我腦子里那急躁的聲音，那我馬上就要提交我的請(qǐng)求。 但是該代碼可能包含許多或全部以下內(nèi)容：

• Missed requirements.
  錯(cuò)過(guò)的要求。
• Missing test cases.
  缺少測(cè)試用例。
• Superfluous, unused or draft code.
  多余的，未使用的或草稿的代碼。
• Not enough code comments.
  代碼注釋不足。
• Visual bugs in some browsers/devices.
  某些瀏覽器/設(shè)備中的視覺(jué)錯(cuò)誤。

If any of those things are true about your code, then your code is not complete. If any of those things end up in the master branch, then you have degraded the quality of the codebase.

如果您的代碼中有任何上述情況，則您的代碼不完整。 如果這些事情中的任何一個(gè)最終出現(xiàn)在master分支中，則說(shuō)明代碼庫(kù)的質(zhì)量下降了。

The main point here is this: code quality starts with the code author. You shouldn’t rely on automated tasks, a code review, quality assurance or user acceptance testing to catch your mistakes.

這里的重點(diǎn)是：代碼質(zhì)量始于代碼作者。 您不應(yīng)該依靠自動(dòng)化任務(wù)，代碼審查，質(zhì)量保證或用戶(hù)驗(yàn)收測(cè)試來(lái)發(fā)現(xiàn)錯(cuò)誤。

Double checking work for completeness is an essential first step toward code quality. It’s the easiest step to take, but also the easiest one to ignore.

進(jìn)行雙重檢查以確保完整性是邁向代碼質(zhì)量必不可少的第一步。 這是最簡(jiǎn)單的步驟，也是最容易忽略的步驟。

You should only open up a pull request when you are certain your code is complete.

僅在確定代碼完成后才應(yīng)打開(kāi)拉取請(qǐng)求。

對(duì)分支機(jī)構(gòu)進(jìn)行自我審查 (Perform a self review of your branch)

I’m always surprised at how many issues — or opportunities to refine a solution — I can find in my own code. Issues and opportunities that only become visible to me when I step back and view my changes in isolation.

我總是在自己的代碼中發(fā)現(xiàn)有多少問(wèn)題或改進(jìn)解決方案的機(jī)會(huì)，總是感到驚訝。 當(dāng)我退后一步，孤立地查看我的更改時(shí)，問(wèn)題和機(jī)會(huì)才對(duì)我可見(jiàn)。

You can review your work and apply your own feedback before assigning a team member to review your work. You can also use this opportunity to leave comments on the pull request to clarify anything for the reviewer.

您可以在分配團(tuán)隊(duì)成員來(lái)審查您的工作之前，先審查您的工作并應(yīng)用您自己的反饋。 您還可以利用此機(jī)會(huì)在請(qǐng)求請(qǐng)求中留下評(píng)論，以使審閱者澄清任何事情。

Taking time to ensure your work is complete, to correct obvious mistakes, or assess your solution, will enhance the quality of your code. It also reduces the effort required to review it.

花一些時(shí)間來(lái)確保您的工作完成，糾正明顯的錯(cuò)誤或評(píng)估您的解決方案，將會(huì)提高代碼的質(zhì)量。 它還減少了審核所需的工作。

It might also save you some embarrassment. I know it has for me.

這也可能使您免于尷尬。 我知道它適合我。

確保代碼質(zhì)量應(yīng)該是每個(gè)開(kāi)發(fā)任務(wù)的內(nèi)在要求 (Ensuring code quality should be an inherent requirement of every development task)

You may be thinking that this approach adds time to the length of a task. And you’re right, it does. But that isn’t a bad thing.

您可能會(huì)認(rèn)為這種方法會(huì)增加任務(wù)時(shí)間。 你是對(duì)的，的確如此。 但這不是一件壞事。

Efficiency is important, but laziness and apathy is harmful. Apathy leads to a bloated, inconsistent code base. Laziness creates a growing backlog of bad technical debt. We can’t be passive and maintain code quality. It requires time and effort.

效率固然重要，但懶惰和冷漠是有害的。 冷漠會(huì)導(dǎo)致a腫的，不一致的代碼庫(kù)。 懶惰導(dǎo)致不良技術(shù)債務(wù)積壓的情況越來(lái)越多。 我們不能被動(dòng)地保持代碼質(zhì)量。 這需要時(shí)間和精力。

Changing the culture around code quality can be hard. Project managers and product owners generally aren’t concerned about code quality — they have their own concerns. Requesting extra time for code quality processes can sometime fall on deaf ears. However, maintaining code quality shouldn’t be thought of as something extra — it should be an inherent requirement of every task.

改變圍繞代碼質(zhì)量的文化可能很難。 項(xiàng)目經(jīng)理和產(chǎn)品所有者通常不關(guān)心代碼質(zhì)量-他們有自己的問(wèn)題。 為代碼質(zhì)量過(guò)程請(qǐng)求額外的時(shí)間有時(shí)會(huì)置若de聞。 但是，不應(yīng)將保持代碼質(zhì)量視為額外的工作—它應(yīng)該是每個(gè)任務(wù)的固有要求。

As developers, if we don’t change the way we think about code quality, we can’t expect anyone else to.

作為開(kāi)發(fā)人員，如果我們不改變我們對(duì)代碼質(zhì)量的方式，我們不能指望別人。

Nothing I’ve talked about here is particularly groundbreaking, nor is it prescriptive. Not every team, workplace, or project is the same, and some of the above may not be applicable to you.

我在這里談?wù)摰臎](méi)有什么特別開(kāi)創(chuàng)性的，也不是規(guī)定性的。 并非每個(gè)團(tuán)隊(duì)，工作場(chǎng)所或項(xiàng)目都是相同的，并且上述某些內(nèi)容可能不適用于您。

I do believe there is often a gap between the way developers think about code quality, and the actual actions taken to address it. If you’ve found that too, then hopefully there is something you can take away from this article — or perhaps you’ve already taken a different approach to addressing it. I’d love to hear your suggestions in the comments.

我確實(shí)相信開(kāi)發(fā)人員對(duì)代碼質(zhì)量的思考方式與為解決該問(wèn)題而采取的實(shí)際措施之間通常存在差距。 如果您也發(fā)現(xiàn)了這一點(diǎn)，那么希望本文可以對(duì)您有所幫助–也許您已經(jīng)采用了另一種方法來(lái)解決它。 我很想聽(tīng)聽(tīng)您在評(píng)論中的建議。

Thanks for reading!

謝謝閱讀！

翻譯自: https://www.freecodecamp.org/news/why-i-changed-the-way-i-think-about-code-quality-88c5d8d57e68/

用什么代碼可以改變鍵盤(pán)

總結(jié)

以上是生活随笔為你收集整理的用什么代码可以改变键盘_为什么我改变了对代码质量的看法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。