After daily written the code, if you have the habit of Code Review?
That code review Code Review, which aims to find the development of neglected Bug, in order to greatly improve the quality of the code can also help developers more familiar with the project. Unfortunately, many industry developers are not accustomed to regular code review. So for programmers, Review whether it is a necessary job?
作者 | Gergely Orosz
Translator | meniscus, Zebian | Tu Min
Exhibition | CSDN (ID: CSDNnews)
The following is the translation:
Ten years, I used to work as a code reviews. Many of the benefits of code review: Read the code changes from other people's point of view, as well as knowledge-sharing tools and automation improvements. If you do not have code review, then I strongly recommend you follow Jeff Atwood share in 2006, this recommendation (https://twitter.com/codinghorror).
Many people and organizations to share best practices for code reviews, code reviews and good sense. SmartBear team, engineering team and guide Palantir engineer Philipp Hauer sharing are good reading material. The following are my personal views on good code review, and how to do better. The background paper is technical environment of my work, where I now include Uber, and before Microsoft's Skype and Skyscanner.
Areas covered by code review
Good code reviewers will look at changing the code itself , and whether these changes for existing code. They will carefully study the title and description, and "reason" to change the code. They will also check the correctness of the code, test coverage, functionality changes and make sure to follow the programming guidelines and best practices. At the same time, they also point out significant areas for improvement, for example, it is difficult to understand the code, ambiguous name, comment out the code, the code untested or untreated edge cases. Finally, they also note that if the submission contains too many code changes, it is recommended to change the code should remain a single purpose, and code changes break down into several parts of the target more focused.
Better code reviewers will look at the code change from the perspective of the overall system , and checks whether these changes easy to maintain. They may ask the need for code changes or impact on other parts of the system caused. They will study abstract and adaptability to existing software architecture introduced in the code. Moreover, they also observe maintainability, such as whether a complex logic can be simplified, the structure of the test, repeat, and other possible improvements. Engineer Joel Kemp in this article (https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36), will review the code is divided into two levels: preliminary examination and comprehensive review.
Tone review
Tone code reviews can greatly affect the morale within the team. Harsh comments may lead to poor working conditions. Self-righteous language may make people feel hostile, causing heated debate. At the same time, professional and positive mood can develop a more inclusive environment. People in these environments can accept constructive feedback, and code review will lead to a healthy and lively discussion.
Good code review personnel will Ask open-ended questions, rather than publish strong or opinionated statements. They will provide an alternative to other solutions. These reviewers will think they may have missed some of the content, so they will first ask for clarification, rather than ask for corrections.
Better code review personnel compassionate. They know that people write code spent a lot of time and effort to respond to these changes. The code review staff not good publicity. They will be strong appreciation of the good solutions and comprehensive positive action.
Approve the request to change
Good code reviewers will not approve the code changes when there are open-ended questions. However, they will clearly indicate which question or comment does not cause obstruction or unimportant, usually such audit opinion is referred to as "critical." Approve the change only in case they change very clear (for example, marked "very good in my opinion."). When you need to follow up, they will definitely use the same code review tool, or follow the team to communicate habits.
更优秀的代码审查人员在面临需要回答某些问题或解决重要问题之前，也不会批准代码更改。这种审核在原则上是坚定的，但在实践上却是灵活的：有时，写代码的人会在后续代码变更中单独解决审核指摘的问题。有些更改比较紧急，所以审查人员会尽快地推动审查。
从代码审查到彼此交谈
良好的代码审查人员会尽可能地留下评论和问题。如果经过修改后仍然有残留问题，他们也会记录下来。如果来回的评论过多，那么审核人员会舍弃过于耗时的工具，而选择面对面交谈。
更优秀的代码审查人员在第一次审核完毕，但有很多评论和问题时，会主动联系写代码的人。他们知道与其在评论中来回反复，还不如面对面的交谈，因为这种方式可以节省大量的时间，还可以省却不少误解和麻烦。很多针对代码的评论表明，审查双方往往会存在一些误解。彼此的交谈更容易消除误解。
吹毛求疵
如前所述，良好的代码审查人员会清楚地表明哪些评论不重要，或有点挑剔。这方面的审查问题包括变量声明按字母顺序排列、测试结构遵循某个结构或括号位于同一行或下一行。
通常，良好的代码审查人员不会有太多的挑剔。鸡蛋里挑骨头会打击人的积极性，而且也会让大家丧失对重要问题的关注。
更优秀的代码审查人员明白太多的挑剔意味着缺乏工具或缺乏标准。经常遇到这些问题的审核人员会考虑在代码审查流程之外解决这个问题。例如，大多数常见的挑剔都可以通过自动linting来解决。如果无法通过工具解决，则应该由团队协商采用某些标准来解决，然后继续跟进这个问题，甚至可以自动化。
零基础如何开始学Python？14年开发经验大神分享
新加入代码审查的人
良好的代码审查人员会一视同仁，采用相同的质量标准和方法，无论他们的职位，级别以及加入公司的长短。根据上述内容，通常代码审查人员都会很和善，只在有必要的时候请求变更，并在收到许多意见时与他们进行交谈。
更优秀的代码审查人员更加注重给新加入的人留下一个好印象。审查人员明白新来的人可能不了解所有的编程指南，而且也可能不熟悉代码的某些部分。所以，他们会进一步努力解释替代方案，或建议他们阅读编程指南。他们还会使用非常积极的语气，鼓励写代码的人刚开始提交的代码变更。
跨办公室及跨时区审查
如果写代码的人和审查人员不在同一个地点时，代码审查会变得更困难。当审核人员位于不同的时区时，这种难度就会更高。多年来，我力争公平地审查所有代码，无论是美国、亚洲还是欧洲团队所提交的代码。
良好的代码审查人员会尽可能地考虑时区差异。审查人员都会努力在双方都办公的时间内审查代码。如果遇到很多评论的情况，则会选择直接聊天或进行视频通话。
更优秀的代码审查人员在反复遇到时区问题时，就会努力寻找代码审查框架之外的系统解决方案。假设某个欧洲的团队经常更改某项服务，而代码审查则由美国负责这项服务的人来进行。系统级的问题是，这些变化如此频繁发生的原因是什么？随着时间的推移，变化的频率相同还是下降了？假设代码变更是在正确的代码库中完成的，且频率没有下降，那么是否应该打破这种跨部门的依赖性？解决这些问题往往不简单，可能涉及重构，或者创建新的服务/接口，或改进工具。解除这种依赖关系会让两个团队都更加轻松，更有效地推动工作。
组织的支持
公司及其工程组织如何看待代码审查是影响代码审查的重要因素。如果组织认为代码审查无关紧要或微不足道，就不会在这方面投入太多。在这样的文化中，在某些情况下，开发人员将不得不放弃代码审查。倡导实施更好的代码审查的工程师可能会感到孤立，而且也无法获得获得上述支持，最终放弃。如果组织认为代码审查是工程中的关键部分，那么他们就会为工程师提供更好的工作环境。
拥有良好代码审查的组织会确保所有工程师都参与代码审查流程，包括那些单独在某个项目上工作的人员。他们鼓励提高质量标准。这些团队会积极地讨论从团队和组织层面开展代码审查。通常，这些公司都有工程师发起和编写的大型代码库的代码审查指南。这样的组织中，理解代码审查会占用工程师的很多时间。许多这样的公司在招聘开发人员时，也会将代码审查作为一项重要的工作能力，并希望高级工程师花费更多的时间来审查其他人的代码。
拥有更好的代码审查的组织会建立硬性规则：没有经过代码审查的代码不能投入到生产中，就像没有经过自动化测试的业务逻辑更改不能进入生产环境一样。这些组织明白，削减这样的成本根本不值得，相反他们拥有在紧急情况下，加快审查团队和组织代码审查的流程。这些组织会投资提高开发人员的工作效率，其中包括更有效的代码审查和工具改进。这些公司的高管通常都是软件工程师，你不需要说服他们有关代码审查和其他工程最佳实践的好处。相反，他们支持团队利用更好的工具，或更有效的代码审查流程。
当写代码的人感受到恶意的评论时，他们可以说出来并全力支持解决问题。高级工程师和管理人员认为不达标的代码评审与劣质的代码或不健全的功能同等严重。工程师和工程经理都感觉有责任改进代码审查的开展方式。
原文：https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/
作者：Gergely Orosz，软件工程师，主要从事移动、Web和后台开发。
This article CSDN translation, please indicate the source of the source.
CSDN 5G salon coming!
June 29, Wei Qing, Microsoft (China) chief technology officer, director of the School of Information and Communication Engineering multimedia technology research center of Beijing University of Posts and Telecommunications / Sun Songlin doctoral tutor, senior research director Xiao Jiang Jinshan Yun AIoT Division, Ericsson China R & D senior experts in the multi-antenna Zhuhuai Song, director of Ericsson China R & D systems engineer Liu Yang and other top industry leader, senior technology experts come together to discuss 5G great potential in the Internet of things.
Fanger Wei code scan, make an appointment immediately live!
Thermal paper recommended
☞ write code is not strict, I do not deserve to be a programmer?
☞ programmers is how off single? | Programmer something to say
☞ 5G era, Microsoft has gone a step of chess!
☞ rolling Bert? What "Tu list" of XLnet mean for NLP tasks
☞ vomiting blood summary! 100 Interview Questions Python Collection (on)
☞ 17-year-old programmer tell you 7 important lessons about programming!
☞ "is! Internet since there is no BAT!"
Click to read the original, live appointments.
Your point of each "look", I seriously as a favorite