A code review is a helpful tool for teams to improve code quality. Yet, there are many other benefits to reviewing code. Not to mention the reduced development cost when catching bugs early in the development lifecycle, sharing knowledge, and improving the team's estimation skills.

This blog post will explain what a code review is, why you should implement code reviews, how you can prepare for one, and how to give actionable feedback. In the last section of this article, you can find a code review checklist to use when implementing a code review process in your developer workflow.

First, let's understand what a code review is?

What is a Code Review?

A code review aims to improve the quality of the code that you want to add to your codebase. A code review refers to a systematic approach to reviewing other programmers' code for mistakes and many other quality metrics. Additionally, a code review checks if all requirements have been implemented correctly.

In most developer teams, a developer will submit a Pull Request (PR) to add code to a codebase. One or multiple team members will be assigned to review the code, check if the code meets the quality standards, and adds the necessary documentation.

However, a code review is more than just a quality check. By assigning multiple developers to a PR, you are exposing them to new code. To complete a code review, reviewers have to understand the context and scope of the PR. Therefore, code reviews are a great tool to reduce technical debt.

Moreover, a code review can be a valuable learning moment for developers. It's a great opportunity to get feedback about your code and coding style.

Why should you do code reviews?

There are many clear benefits and reasons why your team should do code reviews.

Some of these benefits have already been addressed above. It provides an excellent opportunity for developers to improve their coding skills and get valuable feedback. Also, it's a great tool to share knowledge among different team members actively.

You can prevent a «single point of knowledge failure.» It means that multiple people have experience or knowledge about a specific part of the codebase.

It can, for instance, be useful when a particular developer is on holiday (or sick), and you need someone to review code that targets this developer's area of expertise.

A less obvious ROI metric of code reviews is reducing development costs by catching bugs early. A code review can help you find bugs that might slip undetected through testing or automated code review tools.

And lastly, code reviews help you to improve your estimation skills. Atlassian provides a good explanation.

Estimation is a team exercise, and the team makes better estimates as product knowledge is spread across the team. As new features are added to the existing code, the original developer can provide good feedback and estimation.

So, how do you prepare for a code review?

Preparing for a code review

Before starting a code review, make sure you have all information you need to start the review. You don't want to be blocked halfway through your review because you don't have access to the information you need to complete the process.

Also, make sure you understand the context and scope of the PR. This will make it easier to review code and check its requirements. I always suggest developers try out the code and use the debugger to gain a deeper understanding of how the code works.

How to give specific and actionable feedback?

Firstly, make sure to create a friendly atmosphere. Code reviews aren't a tool to criticise your colleagues. On the other hand, you want to create a supportive environment.

The best way to do this is to provide friendly suggestions, explain your reasoning, and give tips on improving the code. You don't want to tell the PR owner that this code is not good. Make sure to include reasoning and give tips or even snippets of code to improve the PR. The PR owner will appreciate this feedback, and it's a great chance to learn something new.

Tip: Ask questions rather than making statements. If you do this, you force the PR owner to think about their code and find a better solution themselves. In other words, you create an actionable learning opportunity for the PR owner. However, don't forget to add sufficient feedback for the PR owner to understand your question.

Code review checklist

A checklist helps you to create a structured approach to code reviews. Also, they remind you of all the quality checks you need to perform to approve code into the codebase.

You can include many specific items into your code review checklist. Here's an overview of must-have items you should always look out for.

1. Verify feature requirements ✔️

Once you have absorbed the context of the PR, it's time to verify the requirements. You want to make sure that the PR covers all requirements as described by the feature ticket.

If something is missing or incorrectly implemented, you should stop the code review and ask the developer to complete the PR.

You don't want to waste time reviewing the rest of the code while it might still change.

2. Code readability ????

Once you have verified the requirements, it's time to take a look at the readability. The main question you should ask yourself: «Is the code self-explanatory?» If you find a function that is not readable, suggest breaking up the code or reorganising it to improve the readability for other developers.

3. Coding Style ????

Most development teams prefer defining a coding style guide. You can use this style guide to review the code. Again, using the same coding style will improve code readability.

4. Clear naming ????

Verify if function and variables are descriptive. To improve readability, you should understand what a module or class does by just looking at the function names and variables. Many developers use this approach to understand the scope and context of a new PR quickly. Therefore, developers must use clear naming.

5. Code duplication ????

Make sure to check for code duplication. Newer team members sometimes don't know which functions or libraries already exist. Therefore, they might create their own library while this functionality already exists. To keep your codebase clean, check for code duplication.

6. Tests ✅

You should always check that the implemented tests cover all coding paths. Make sure to flag any missing tests to the PR owner.

7. Documentation ✍️

And lastly, a developer should update the documentation when adding a new feature to the codebase. However, don't forget to check the quality of the documentation.

How to improve codebase communication?

A significant amount of code review time is spent reading and understanding code. The best way to improve your codebase communication is to add code issues using the Stepsize extension. You can create, view, and prioritise your issues and make sure all members of the team have access to this valuable code context.

Conclusion

Code reviews are a handy tool for developer teams.

Keep in mind that code reviews are for everyone in your team. Some companies mistake code reviews for a way to provide junior team members feedback from senior team members. The opposite is also true. Any developer in your team can learn, improve, and share knowledge.

P.S. Check out our latest industry report on How Codebase Health Impacts Engineering Hiring and Retention where we gathered insights from 200+ Engineers ????

Код-ревью — как сделать правильно

Я оцениваю качество кода студентов в Яндекс.Практикуме на курсе «Мидл фронтенд-разработчик» и участвую во внутреннем код-ревью Яндекса. Мне кажется, что заложить принципы грамотного код-ревью — важная часть обучения. Благодаря этим навыкам студенты, с одной стороны, учатся писать хороший код быстрее, а с другой — делают в нём меньше ошибок.

Принципы хорошего код-ревью

Код-ревью — часть процесса разработки. В учебных проектах — это проверка написанного кода наставником, в рабочих проектах — коллегами. Они смотрят, насколько код подходит под стандарты, заданные в команде, выполняется ли поставленная задача и можно ли сделать реализацию лучше.

https://www.youtube.com/watch?v=bt5ZP6uKQAk\u0026pp=ygU60JrQsNC6INC_0YDQvtCy0LXRgdGC0Lgg0LrQvtC0LdGA0LXQstGM0Y46INGH0LXQui3Qu9C40YHRgg%3D%3D

Чтобы сделать код-ревью полезным, всем участникам процесса нужно соблюдать несколько правил. Я расскажу о 7 принципах хорошего код-ревью.

Уважайте друг друга

Даже если вам кажется, что фраза «Я сегодня вышел на улицу, наступил в мокрый снег, и ощущения от этого были гораздо лучше, чем от вашего кода» очень смешная, и человек на неё не обидится, не стоит её использовать.

Это можно сказать иначе: «Я думаю, в этом месте можно было бы сделать вот так». Будьте доброжелательны и помните, что вы оцениваете не человека, а его код.

Это может казаться мелочью, но это база, из которой складывается здоровая атмосфера в команде и эффективная работа.

Полезные фразы «Я бы попытался сделать вот так…», «мне кажется, будет хорошей идеей попробовать вот это…», «в нашей команде мы как-то делали похожий проект и там мы решили эту задачу вот так…», «решение выглядит нелогичным, ты можешь попробовать применить вот такой подход, думаю, тебе это точно поможет».

Будьте объективны

Избегайте комментариев, которые состоят только из ваших субъективных оценок. Обязательно ссылайтесь на источники, документацию, материалы, которые помогут разработчику быстрее решить проблему.

Если вы столкнулись с тем, что человек написал код не так, как это принято на проекте, отправьте ему ссылку на код коллеги. И помните: аргументацию стоит писать уважительно — без подтекста «Как ты можешь этого не знать?»

Полезные фразы «Обычно такие вещи мы делаем немного иначе [ссылка на документацию], «вот ссылка на проект наших коллег — они очень здорово решили похожую задачу, думаю, мы можем перенять их опыт».

Пример из реального код-ревью:

import React, {FC, memo} from «react»; import {Link} from «react-router-dom»; export const Footer: FC = memo(() => { return (
);
});
На данный момент этот блок не поддерживается, но мы не забыли о нём!Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

Не давайте готовое решение

Этот принцип особенно важен в учебных проектах. Задача ревьюера-наставника — подтолкнуть человека в правильную сторону, подсказать, как ещё можно подступиться к задаче, какие инструменты можно использовать.

Полезные фразы «Вот хороший пример, как была решена почти такая же задача. Попробуй ознакомиться с альтернативным решением».

Больше общайтесь с командой

Некоторые моменты проще объяснить во время созвона или личной встречи. Не стоит считать такую коммуникацию тратой времени. На самом деле, отдача от такого созвона или встречи намного больше, чем кажется. Команда, которая умеет эффективно общаться — лучшая команда.

Полезные фразы «Если хочешь, можем созвониться, пообщаться голосом. Я буду рад подробно всё объяснить».

Учитесь в процессе код-ревью

В Pull Request для обсуждения изменений в коде могут прийти большие профессионалы с полярными мнениями. Если это случилось, не переживайте, наоборот, приготовьтесь узнать много нового.

Однажды я делал задачу, связанную с браузерами, и в Pull Request пришли несколько опытных разработчиков. Они начали горячо обсуждать, как лучше хранить данные и какие решения для этого использовать.

Внимательно прочитав и проанализировав их обсуждение, я узнал много нового и в итоге сделал задачу гораздо лучше, чем ожидал. Поэтому относитесь к код-ревью как к мощному инструменту для обучения.

Как влюбить в себя своего код-ревьюера: правила подготовки к code review

Несите ответственность за код

Правильное отношение к код-ревью — считать, что вы несёте такую же ответственность за будущую корректную работу кода, как и его автор. Ведь от ваших комментариев зависит, насколько качественно человек выполнит свою работу.

Внимательно относитесь к новичкам

Если вам предстоит разобрать на код-ревью работу новичка, значит, нужно подойти к этому ещё ответственнее, чем обычно. От первой полученной обратной связи зависит, как человек будет работать в дальнейшем, а возможно, останется ли он вообще с вами. Чем ответственнее вы и ваши коллеги относятся к код-ревью, тем быстрее растут новички как профессионалы.

Как код-ревью делают в Яндексе

В дополнение к базовым принципам хорошего код-ревью, в Яндексе мы придерживаемся ещё трёх правил.

Проверяем код на уровне логики и решений

Во многих командах для автоматизированной проверки используются статические анализаторы кода — линтеры. Когда пунктуация и стиль кода проверяется автоматически, гораздо проще сфокусироваться на высокоуровневых вещах — насколько логично человек мыслит и насколько эффективные решения он принимает. Разработчики в Яндексе не жалеют времени и сил на полное погружение в код коллег.

Не жалеем времени на код-ревью

В Яндексе есть внутренний инструмент, который называется «ревьюшница». Это робот, который отправляет автоматизированные приглашения людям посмотреть код коллег, когда наступает время код-ревью.

Принцип их отправления простой — пишем определённую команду в интерфейсе гитхаба, робот проверяет, кто имеет максимальную экспертизу в таком виде кода и присылает приглашения этим людям. Получается, чем больше кода писать, тем больше нужно ревьюить.

В день это занимает около двух часов. Я никогда не жалею времени на это.

Не заливаем код, который не прошёл ревью

Во многих командах Яндекса эта вещь ограничена программно — новый код нельзя влить, пока он не получит определённое количество аппрувов (одобрений) от коллег. Это правило позволяет использовать в работе только качественный код.

Чек-лист хорошего код-ревью

Чек-лист поможет сделать ревью полезным, а коммуникацию — эффективной.

• Вы доброжелательны по отношению к коллегам в х? Воздержитесь от шуток, которые могут обидеть.
• Ваши сообщения содержат не только критику, но и конкретные предложения?
• Каждый ваш комментарий подкреплён ссылками на документацию и примерами из кода?
• Если вы делаете код-ревью в учебном проекте, не даёте готовое решение, а лишь подталкиваете человека в нужную сторону?
• Не жалеете сил на обратную связь? Если чувствуете, что нужно дополнительно созвониться или написать в мессенджере, сделайте это.
• Во время код-ревью думаете не только о соблюдении синтаксиса, но и пытаетесь понять, как именно мыслит человек при решении задач?
• Понимаете, что написанный код нельзя считать готовым, пока его не посмотрит кто-то ещё?

Если ваш ответ на большинство этих вопросов утвердительный, можно быть уверенным — код-ревью пройдёт успешно и станет для всех его участников хорошим инструментом для профессионального роста.

Код-ревью: полное руководство о том, как проводить код-ревью

Если вы планируете стать разработчиком программного обеспечения, вы будете не только создавать программное обеспечение, но и будете вынуждены просматривать код своих коллег.

Код-ревью — это необходимый шаг для улучшения качества кода и, как следствие, качества создаваемого вами программного обеспечения.

У этого также есть другие преимущества, такие как снижение затрат на разработку и обнаружение ошибок на ранних этапах процесса. Это также возможность учиться, делиться и совершенствовать свои навыки.

Что такое проверка кода?

Проверка кода — это акт сознательной проверки фрагментов кода на наличие ошибок и багов. В конце концов, программирование — это человеческая деятельность, и поэтому в нём могут быть ошибки Проверка кода может выполняться инструментами/программным обеспечением проверки кода и людьми.

Когда разработчик-человек проводит проверку кода, важно, чтобы человек, который проверяет и тестирует код, не был тем же человеком, который изначально написал код. Поэтому вас, как разработчика, могут попросить просмотреть коды, написанные вашими коллегами.

Вот почему важно, чтобы вы знали, как работает процесс проверки кода.

https://www.youtube.com/watch?v=bt5ZP6uKQAk\u0026pp=YAHIAQE%3D

Чтобы упростить процесс проверки кода, разработчики часто используют контрольный список проверки кода: список вещей, которые они хотят проверить в процессе. Наличие контрольного списка проверки кода помогает рецензенту кода не контролировать какой-либо аспект и проверять любые детали.

Важность проверки кода

Так ли важен код-ревью? Можем ли мы использовать программное обеспечение для проверки кода, которое сделает всю работу за нас? Инструменты проверки кода могут быть очень полезными, но, как и в любом другом деле, люди всегда могут заметить то, что не замечают машины. Кроме того, возможность посмотреть на работу коллеги дает вам возможность улучшить свои навыки и научиться новым приемам. С другой стороны, когда у вас есть обзор кода от коллеги, вы можете получить ценные отзывы и советы по улучшению.

Код-ревью всегда улучшает окончательные результаты: в общем, это шанс улучшить ваш код и, следовательно, качество программного обеспечения или приложения, которое вы создаете.

Как мы уже упоминали, проверка кода помогает выявлять ошибки на ранних этапах процесса разработки: это может сократить время и затраты на сам процесс разработки. Как мы видим, недостатков у код-ревью нет.

Пришло время обсудить, как это сделать.

Одна из основных причин, по которой вы хотите научиться запускать процесс проверки кода, заключается в том, что вы можете получать за это деньги. Код-рквью редко бывает бесплатным: если у вас есть друг-программист, который также работает над проектом, вы можете стать ревьюером его кода.

Это единственное обстоятельство, при котором вы можете рассчитывать на бесплатную проверку своего кода: в любом другом случае вам нужно будет нанять коллегу-разработчика (фрилансера или добавить одного члена в команду разработчиков). Код-ревью — это возможность трудоустройства для вас!

Как провести код-ревью

Подготовьтесь к проверке кода

Прежде чем приступить к просмотру кода, убедитесь, что у вас есть вся информация, необходимая для завершения процесса. Если вы начнете проверять обзор, не зная контекста, над каким приложением или программой работает разработчик, какие у него есть основные сомнения и каковы их приоритеты, это сделает вашу работу неэффективной, и вы рискуете застрять в середине.

Чтобы не останавливаться на полпути, обязательно спросите обо всем заранее:

• Какое программное обеспечение создается
• Какова цель
• Каков контекст
• Каковы приоритеты автора (эстетика? исполнение?)

Кроме того, перед началом процесса проверки кода вы можете запустить тест , чтобы получить более глубокое представление о том, как работает код, и получить первое общее представление о возможных ошибках.

Контрольный список проверки кода

Фактический процесс проверки кода начинается сейчас. Как мы уже упоминали, все разработчики, проводящие проверки кода, используют контрольные списки, чтобы убедиться, что они проверяют и тестируют все аспекты, которые необходимо проверить и протестировать.

Отладка

Номер 1 в вашем контрольном списке проверки кода всегда отладка. Как мы видели, есть много причин, по которым вы хотите провести проверку кода, но, безусловно, вашим приоритетом является отладка и устранение всех проблем.

Ошибки могут быть вызваны ошибками в написании переменных, параметрами в неправильном порядке и другими простыми ошибками; авторы кода обычно не могут их обнаружить, потому что они устали и потому что они просматривали этот код снова и снова (по той же причине автор текста не должен проверять опечатки!) .

Итак, самое первое, что вы хотите вычеркнуть из своего контрольного списка проверки кода, — это отладка (вы также можете использовать программные инструменты отладки на этом этапе, убедитесь, что вы также просмотрели код своими глазами; это также возможность ознакомиться со всем кодом и составить общее первое впечатление).

Безопасность

Во время проверки кода разработчики также проверяют безопасность кода, так что это номер два в вашем контрольном списке проверки кода. На этом этапе вы можете запустить тесты для проверки нескольких уязвимостей: некоторые плагины делают это автоматически, вы можете использовать несколько.

https://www.youtube.com/watch?v=bt5ZP6uKQAk\u0026t=73s

Попробуйте no-code платформу AppMaster

AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле

Начать бесплатно

Читаемость кода

Когда вы проверяете удобочитаемость кода, вы анализируете, является ли код ясным и лаконичным, а также соблюдаются ли все языковые и проектные соглашения.

Если над кодом работала команда разработчиков, вы также хотите проверить и убедиться, что все члены команды соблюдают одни и те же правила и соглашения.

Если у вас сложилось впечатление, что код в беспорядке, вы можете предложить разбить его и реорганизовать, чтобы улучшить читабельность.

Дублирование кода

Вы можете считать этот пункт четвертым в своем контрольном списке проверки кода. Важность контрольного списка проверки кода заключается в том, что он заставляет вас делать одну вещь за раз. Это может показаться неважным, но на самом деле это заставляет вас просматривать код, сосредотачиваясь на одном аспекте за раз: это самый эффективный метод для проведения внимательной проверки.

Наименование

Как мы уже упоминали, когда мы проводим проверку кода, мы ищем не только ошибки, но и способы улучшения кода. На этом этапе контрольного списка проверки кода вы можете просмотреть переменные, константы, поля классов, имена свойств (и т. д.) и найти возможности улучшить их, сделав их более описательными.

Тесты

Автоматизированные тесты — это фрагменты кода, поэтому их также необходимо просматривать. Таким образом, на этом этапе контрольного списка проверки кода вы хотите проверить:

• есть или нет тестов в коде
• качество этих тестов
• читабельность тестов
• именование в тестах

Документация

Прежде всего, если проект поставляется с какой-либо документацией, вы также должны проверить и просмотреть документацию. Если изменения, которые вы вносите в код, включают добавление новой функции, убедитесь, что вы обновили документацию, а затем просмотрите свои обновления.

Возможность улучшения

Пока вы просматриваете код, у вас могут появиться идеи о дополнительных функциях, аспектах, которые могут повысить производительность или безопасность, или в целом улучшить код. В своем контрольном списке проверки кода вы не только проверяете, что там есть, но также даете советы о том, как улучшить проект в целом или отдельные его аспекты.

На этом этапе вы должны спросить себя, есть ли способы улучшить проект, чтобы вы могли либо внести изменения самостоятельно, либо сообщить автору кода о замеченных вами возможностях.

Отслеживать изменения

Вы должны отслеживать изменения, которые вы вносите в код, на протяжении всего процесса проверки. Важно, чтобы, когда вы предоставляли свой отзыв автору кода (см. следующий абзац), вы могли показать изменения и объяснить их.

Оставить свой отзыв

В конце процесса проверки кода вы можете поделиться своим мнением с автором кода. Контрольный список проверки кода также поможет вам в этом. Вы можете просмотреть каждую точку и каждый тест, чтобы показать, что работает, а что нужно исправить.

В процессе обзора вы, возможно, также заметили, что существуют способы получения тех же результатов более эффективно или просто. Вы можете предоставить такую информацию коллеге, который вас нанял (или попросил об услуге): это будет дополнительным преимуществом в вашей работе в качестве проверяющего кода.

Если вы внесли изменения в код во время проверки, убедитесь, что вы не только проинформировали автора (или авторов) кода, но и что вы также можете объяснить, почему и как вы внесли эти изменения.

Нужен ли обзор кода для no-code разработки?

Как вы, конечно, уже знаете, вы не пишете код напрямую, когда создаете приложение на платформе no-code.

Если вы используете первоклассные инструменты no-code, такие как AppMaster — наиболее рекомендуемая платформа no-code на рынке — исходный код генерируется автоматически.

Означает ли это, что этот код не нуждается в проверке кода, потому что он был создан не человеком, а машиной, которая не делает ошибок?

Одним из огромных преимуществ платформы AppMaster является то, что платформа сразу генерирует чистый и красивый код, в котором нет места код-ревью.

Почему? Потому что и в open-source проектах, и в AppMaster все блоки и элементы уже проверены миллион раз, и платформа не допускает некорректного кода.

То есть зачастую ревью используется именно для улучшения качества кода, чтобы более профессиональные разработчики проверяли созданный код и тем самым избегали проблем с производительностью и ошибками.

В AppMaster такого нет, потому что весь код написан профессионально. Его тестирует и улучшает огромное количество людей, и каждый раз, когда мы находим варианты улучшения, эти варианты сразу же применяются ко всем приложениям, которые генерируются платформой. Так что используйте AppMaster, не тратьте деньги и не увеличивайте стоимость программного продукта.

Вывод

Процесс проверки кода — это возможность роста как для автора кода, так и для человека, которого попросили его проверить. Это также возможность улучшить качество вашего проекта. Нет причин избегать этого. В этой статье о проверке кода мы также рассказали, как инструменты no-code могут ускорить разработку и творческий процесс, а также снизить затраты на программирование.

Как провести код-ревью: чек-лист : Backend Developer — Python — Golang — Software Engineer

Galina Iaroshenko

iOS-developer, ИТ-переводчица, пишу статьи и гайды. В данной статье мы рассмотрим 7 практических советов, следуя которым можно значительно повысить качество проверки кода.

Данная статья является переводом. Ссылка на оригинал.

Полный контрольный список проверки кода

В код-ревью много тонкостей и нюансов, поэтому так важно, чтобы рецензенты применяли структурированный и тщательный подход. Использование нашего чек-листа гарантирует, что ничего не будет упущено.

1. Проверьте требования к функциям

Требования к функциям (код-ревью)

Каждый обзор начинается с основного вопроса: «Выполняет ли этот код то, что нужно конечному пользователю?». Разработчики, работающие над проектом, не пишут код в вакууме. Их программа должна надежно выполнять функции, ожидаемые пользователем. Если ваш разработчик пропустил этот шаг, отложите проверку до тех пор, пока код не предложит полный набор функций.

Чтобы проверить требования к функциям, спросите себя:

• Есть ли недостающая функциональность?
• Есть ли плохо реализованные функции?
• Могут ли они добавить какие-либо связанные функции, которые пожелает пользователь?

2. Оцените удобочитаемость

Оцените удобочитаемость (код-ревью)

Чтобы проверить требования к функциям, спросите себя:

• Может ли код поместиться на экране ноутбука (14 дюймов) или на экране настольного компьютера (22-24 дюйма)?
• Говорит ли код сам за себя и передает ли его цель?
• Насколько ясен и лаконичен код?
• Есть ли в коде непонятные выражения?
• Можете ли вы различить роль конкретных функций, методов или классов?
• Разбил ли разработчик код на простые для понимания блоки?

Статья по теме ???????? 3 принципа написания чистого кода на Python

3. Проверка сопровождаемости

• Проверка сопровождаемости (код-ревью)
• Со временем вам, возможно, придется расширить или изменить свой код, поэтому обеспечение простоты его обслуживания и изменения избавит вас от головной боли.
• Задайте себе эти вопросы, чтобы оценить сопровождаемость кода:

• Легко ли тестировать и отлаживать код?
• Можете ли вы настроить код для быстрого изменения значений данных?
• Код привязан к другой системе или устаревшей программе?
• Полагается ли код на функции или технологии, от которых вы хотите отказаться?

4. Проверьте наличие уязвимостей в системе безопасности

Проверьте наличие уязвимостей в системе безопасности (код-ревью)

В коде могут быть уязвимости, которые ваш разработчик мог не заметить из-за банального недосыпа. Чтобы избежать уязвимостей в системе безопасности, задайте следующие вопросы:

• Используются ли в коде устаревшие инструменты или инструменты с известными проблемами безопасности?
• Если бы вы хотели украсть данные или получить доступ к системе, какими уязвимостями вы бы воспользовались?
• Используется ли код аутентификации и авторизации для обеспечения безопасности?
• Проверяется ли ввод пользователя?
• Надежно ли код хранит пользовательские данные?
• Защищает ли код P2 или другие данные, связанные с GDPR?

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека тестировщика» Интересно, перейти к каналу

5. Учитывайте скорость и производительность

Учитывайте скорость и производительность (код-ревью)

Ваши проблемы не заканчиваются на обеспечении безопасности. Пользователь по-прежнему ожидает надежной работы. Рецензенты кода также должны сопоставлять потребление ресурсов программой с ее скоростью.

Задайте себе несколько вопросов, чтобы оценить скорость и производительность:

• Содержит ли код неэффективные конкатенации строк, ведение журнала или присвоения объектов?
• Можете ли вы увидеть повторяющийся код, который вам не нужен?
• Будет ли программа негативно влиять на производительность системы в целом?
• Использует ли код плохо оптимизированные ресурсы или несколько запросов API?

6. Проверьте наличие соответствующей документации

Проверьте наличие соответствующей документации (код-ревью)

Хорошая документация объясняет, что делает кодовая база и как вы можете ее использовать. Однако даже отличный код может нуждаться в некоторой внешней документации для простоты использования.

Чтобы убедиться, что документация соответствует требованиям, спросите:

• Объясняет ли документация назначение кода?
• Обучает ли документация пользователя тому, как использовать код?
• Требуют ли какие-либо новые функции или изменения кода дополнительную документацию?
• Ясна ли документация и хорошо ли она написана?

7. Проверьте соглашения об именовании

Проверьте соглашения об именовании (код-ревью)

Четкие соглашения об именовании облегчают чтение и понимание кода. Когда программисты выбирают произвольные или неоптимальные имена, даже отличные программы становятся трудными для понимания другими.

Вы можете проверить соглашения об именовании, спросив:

• Вы просматривали имена переменных, констант, полей классов, свойств и методов?
• Названия простые и разборчивые?
• Соответствуют ли имена принятым в вашей компании правилам именования?
• Передают ли имена, что такое функция или переменная?
• Объясняют ли названия контекст или объем всей кодовой базы?

Какова цель код-ревью?

Какова цель код-ревью?

Наиболее очевидным преимуществом проверок кода является гарантия того, что плохой код не попадет в производство. Тем не менее есть много других преимуществ, таких как обмен знаниями, повышение безопасности и содействие командной работе. Менеджеры, проводящие проверки кода, также помогают организациям добиться большей стандартизации.

Обеспечение качества кода

К тому времени, когда вы закончите программировать, вы, вероятно, устанете смотреть на одни и те же строки кода. На этом этапе трудно оставаться объективным, и вы рискуете пропустить ошибки.

Вот когда свежий взгляд со стороны помогает: это дает вам уверенность в том, что кто-то другой обнаружит проблемы в коде, пока вы готовите столь необходимый кофе (или чай).

Делитесь знаниями и улучшайте командную работу

Обзоры кода дают как рецензенту, так и автору кода возможность учиться. Например:

• Человек, который рецензирует код, изучает исходный код и стиль.
• Авторы кода могут извлечь уроки из любых отзывов и получить возможность применить свои уроки на практике.

Благодаря этому процессу, авторы кода и рецензенты могут проводить мозговой штурм, обсуждать цели и разрабатывать рабочие процессы.

Улучшить безопасность

Безопасные проверки кода помогают выявлять уязвимости и недостатки безопасности в ручном или автоматизированном процессе. Нарушения безопасности могут привести к:

• Дефектам поздней стадии разработки.
• Плохому общему качеству кода.
• Ухудшению сопровождаемости с течением времени.
• Более высокому техническому долгу.
• Краже информации о пользователях.

Заблаговременное предотвращение проблем с безопасностью экономит время и репутацию вашего бизнеса. Дополнительные несколько минут, потраченные на проверку безопасности, с лихвой окупят себя.

Сокращение затрат на разработку

Проверка кода выявляет незначительные проблемы, которые могут перерасти в серьезные проблемы. Раннее исправление ошибок может сэкономить затраты на разработку и помочь рецензенту выявить проблемы, на которые следует обратить внимание. Когда это выгодно и познавательно, вы (буквально) не можете позволить себе пропустить ревью.

На что не стоит обращать внимание при код-ревью

Есть лучшие способы провести время, чем проверять каждую деталь на код-ревью. Некоторые области имеют приоритет над другими, особенно когда вы хотите оптимизировать свой процесс проверки. Имея это в виду, вы можете не сосредотачиваться на:

• Ручном тестировании. Включите автоматизацию в проверку кода, чтобы сэкономить время. Благодаря автоматизации, вы можете сосредоточиться на задачах, с которыми не может справиться ИИ. Просто не забудьте перепроверить автоматизированную работу, чтобы избежать проблем с автоматизацией.
• Эстетике. Несмотря на то что удобочитаемость имеет значение, вам не нужно быть перфекционистом и отшлифовывать каждую строчку кода.
• Личных предпочтениях. стандартизируйте код в соответствии с предпочтениями вашего бизнеса или команды, а не вашими. Соблюдение руководств внутри компании делает код каждого разработчика узнаваемым для других членов команды.

Как улучшить процесс код-ревью

Теперь, когда вы знаете, на что обращать внимание при проверке кода, вы можете отточить этот процесс. Мы изложили несколько советов по улучшению процесса проверки кода:

1. Примите руководство по стилю: разрешите споры о стиле, приняв руководство по стилю кода для всей организации. Он должен не только определять поверхностные элементы, такие как правила пробелов или соглашения об именах, но также и то, как использовать возможности любого языка программирования.
2. Рассматривайте код-ревью как высокоприоритетную задачу: установите внутренние рекомендации о том, как быстро код должен проверяться.
3. Стремитесь к действенной обратной связи и наводящим вопросам: вместо того, чтобы комментировать код, спросите автора, почему он отформатировал код определенным образом или какие намерения стояли за решением. Здесь вы стремитесь к диалогу.
4. Замените «вы» на «мы». Когда вы говорите о проблеме, отформатируйте свой ответ так: «Нам нравится делать X, потому что Y». Избегайте комментариев вроде: «Здесь вы не следовали нашим рекомендациям по стилю». Напоминание разработчикам о том, что вы все работаете в одной команде, поддерживает моральный дух.
5. Опирайтесь на принципы, а не на мнения: стремитесь к объективной обратной связи, основанной на принципах кодирования. Это также обеспечивает культуру обучения для автора, чтобы лучше понять «почему» для определенной части обратной связи.
6. Сосредоточьтесь на аспектах, которые принесут наибольшую пользу: не сосредотачивайтесь на каждой возможности улучшить код во время проверки. Совершенство — это здорово, но, учитывая время и масштаб проекта, сосредоточьтесь на областях, которые окажут наибольшее влияние.

Часто задаваемые вопросы по код-ревью

У вас все еще есть несколько вопросов о правилах проверки кода или о том, на что обращать внимание при проверке кода? Нет проблем, у нас есть ответы.

В чем разница между код-ревью и проверкой кода?

Для проверки кода используют программное обеспечение для анализа исходного кода.

Некоторые организации используют средства проверки кода во время разработки, чтобы ускорить процесс проверки и снизить вероятность человеческой ошибки.

Это программное обеспечение использует статический анализ для проверки исходного кода на наличие ошибок, логических ошибок, стиля, документации и синтаксиса.

Какие инструменты упрощают проверку кода?

1. Инструменты статического анализа кода. Статический анализ сканирует исходный код синтаксического анализа на наличие ошибок и проблем с безопасностью. Использование одного из них перед обзором может помочь вам сконцентрироваться на более сложных проблемах.
2. Подключаемые модули для исправлений.

   Подключаемые модули для форматирования, отладки и рекомендаций могут помочь во время проверки. Во время проверки эти подключаемые модули указывают на проблемы, которые вы могли пропустить.

3. Трекеры комментариев для проверки кода.

   Приложения для совместной проверки и инструменты отслеживания комментариев показывают, кто взаимодействовал с кодом и вносил в него изменения.

Какие показатели я должен иметь в виду?

Команды должны выбрать метрики или контрольные показатели разработки программного обеспечения, чтобы отслеживать эффективность проверок кода и их влияние на качество кода. Метрики также дают командам объективные показатели для структурирования проверок кода.

Следующие четыре показателя являются хорошей отправной точкой для включения в процесс обзора:

1. Время реакции: этот показатель помогает организовать совместную работу над проектами с несколькими разработчиками. Просто запишите, сколько времени требуется рецензенту, чтобы ответить на адресованный ему комментарий. Более короткое время реакции обычно означает более сплоченную команду.
2. Непроверенные PR: руководители обращаются к непроверенным PR, чтобы увидеть, как долго код ожидает экспертной оценки после его отправки. Более короткие сроки указывают на эффективный конвейер, в котором проверки кода происходят по расписанию.
3. Тщательно проверенные PR: этот показатель измеряет глубину каждого обзора кода.
4. Повторяющиеся PR: вы можете увидеть, как часто проверки кода приводят к исправлению ошибок или улучшению качества с помощью повторяющихся PR. Большое количество повторяющихся PR означает, что ваши проверки кода приводят к измеримым улучшениям.

Сколько строк кода я должен просматривать?

Для достижения наилучших результатов просматривайте не более 400 строк кода за раз. Чуть больше, и вы рискуете пропустить ошибки, логические ошибки и другие дефекты. Еще лучше, если вы можете ограничить себя 200 строками кода за раз, то вы добьетесь наибольшего успеха.