День 1329. #CodeReview
Допрашиваем Незнакомый Код. Начало
Читаемый код — это хорошо, но не весь код будет читаемым. Популярное утверждение о коде, что его читают в десять раз чаще, чем пишут. Точных цифр нет, но скорее реальное соотношение ближе к 100:1. И чем больше срок службы продукта, тем оно выше. Книги и пособия обычно фокусируются на написании кода, но чтение кода — это отдельный навык.
Новичкам часто кажется, что, если не тратить большую часть времени на добавление нового кода в проект, они не работают продуктивно. На самом деле, первые 80-95% времени должны быть потрачены на чтение кода и других форм документации. Иногда это даже 100%: в процессе изучения кода вы можете узнать, что эта функция уже существует, просто о ней забыли или это принесёт больше вреда, чем пользы.
Рассмотрим наиболее практичные тактики чтения кода и полезные инструменты, которые нужно иметь и сочетать их в зависимости от ситуации.
1. Изучите IDE и установите полезные плагины
Ваша IDE — бесценный инструмент для понимания кода. Однако стоит потратить время, чтобы найти полезные плагины, которые облегчат чтение и понимание кода. Ищите следующие функции:
- Подсветку синтаксиса: ключевые слова, имена классов/методов/полей/переменных,… скобки.
- Автоформатирование
- Статический анализ
- Контекстная навигация: позволит быстро перейти к определению, просмотреть реализации и просмотреть использования класса или метода.
- Рефакторинг: автоматизирует частые рефакторинги, такие как извлечение логики в метод, изменение параметров метода или переименование переменной.
- Подсказки по коду: тип, параметры, документация о классе/методе/поле, при наведении курсора.
- Средство запуска тестов.
- Отладчик.
- Интеграция с системой контроля версий: помимо очевидного, предоставляет информацию об авторе и дате последнего редактирования каждой строки кода.
Вы можете (а иногда, возможно, придётся) читать код без этих инструментов. Но они упрощают проверку ваших предположений и сбор контекста, и вы с большей вероятностью будете принимать правильные решения и меньше гадать.
2. Прочитайте код как минимум дважды
Одного прочтения почти никогда не бывает достаточно, чтобы полностью понять, что делает фрагмент кода. Дважды - это самый минимум.
При первом чтении постарайтесь получить общую картину, просматривая и создавая схему в уме (или на бумаге). Ваша цель — общее представление о том, что делает код. Если под рукой есть резиновая уточка, - самое время поговорить с ней. Объясните общую цель кода. Если какие-то части будет сложно объяснить, это привлечёт к ним внимание.
Второе чтение больше касается деталей. Убедитесь, что вы понимаете каждую строку или хотя бы имеете теорию об этом. Обратите особое внимание на внешние эффекты. Какие методы вызываются? Обновляется ли общее состояние? Какие значения возвращаются? Потратьте время на изучение каждого метода, чтобы понять всю логику, даже если она находится за пределами изучаемого кода. Перейдите к другим методам, посмотрите документацию библиотечных методов, проверьте, что значит каждый фрагмент, вызывающий сомнения. Когда вы закончите, у вас будут теории о возможном поведении, пограничных случаях и условиях отказа в коде. Могут быть части, которые вы не понимаете, но они почти всегда следуют простым правилам, которые можно нагуглить или узнать у товарища по команде.
Третье прочтение полезно, если код содержит сложную логику. Выберите простые значения для любых параметров или переменных и представьте, что они проходят через код сверху вниз. Просчитайте результаты каждой строки.
На самом деле, каждое чтение может включать в себя несколько проходов и несколько походов в Google и на Stack Overflow. Совершенно нормально читать кусок кода десять или более раз, прежде чем вы действительно его поймёте. Может помочь длительный перерыв после первых нескольких прочтений, особенно если вы имеете дело с новыми для вас понятиями.
Продолжение следует…
Источник: https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
Допрашиваем Незнакомый Код. Начало
Читаемый код — это хорошо, но не весь код будет читаемым. Популярное утверждение о коде, что его читают в десять раз чаще, чем пишут. Точных цифр нет, но скорее реальное соотношение ближе к 100:1. И чем больше срок службы продукта, тем оно выше. Книги и пособия обычно фокусируются на написании кода, но чтение кода — это отдельный навык.
Новичкам часто кажется, что, если не тратить большую часть времени на добавление нового кода в проект, они не работают продуктивно. На самом деле, первые 80-95% времени должны быть потрачены на чтение кода и других форм документации. Иногда это даже 100%: в процессе изучения кода вы можете узнать, что эта функция уже существует, просто о ней забыли или это принесёт больше вреда, чем пользы.
Рассмотрим наиболее практичные тактики чтения кода и полезные инструменты, которые нужно иметь и сочетать их в зависимости от ситуации.
1. Изучите IDE и установите полезные плагины
Ваша IDE — бесценный инструмент для понимания кода. Однако стоит потратить время, чтобы найти полезные плагины, которые облегчат чтение и понимание кода. Ищите следующие функции:
- Подсветку синтаксиса: ключевые слова, имена классов/методов/полей/переменных,… скобки.
- Автоформатирование
- Статический анализ
- Контекстная навигация: позволит быстро перейти к определению, просмотреть реализации и просмотреть использования класса или метода.
- Рефакторинг: автоматизирует частые рефакторинги, такие как извлечение логики в метод, изменение параметров метода или переименование переменной.
- Подсказки по коду: тип, параметры, документация о классе/методе/поле, при наведении курсора.
- Средство запуска тестов.
- Отладчик.
- Интеграция с системой контроля версий: помимо очевидного, предоставляет информацию об авторе и дате последнего редактирования каждой строки кода.
Вы можете (а иногда, возможно, придётся) читать код без этих инструментов. Но они упрощают проверку ваших предположений и сбор контекста, и вы с большей вероятностью будете принимать правильные решения и меньше гадать.
2. Прочитайте код как минимум дважды
Одного прочтения почти никогда не бывает достаточно, чтобы полностью понять, что делает фрагмент кода. Дважды - это самый минимум.
При первом чтении постарайтесь получить общую картину, просматривая и создавая схему в уме (или на бумаге). Ваша цель — общее представление о том, что делает код. Если под рукой есть резиновая уточка, - самое время поговорить с ней. Объясните общую цель кода. Если какие-то части будет сложно объяснить, это привлечёт к ним внимание.
Второе чтение больше касается деталей. Убедитесь, что вы понимаете каждую строку или хотя бы имеете теорию об этом. Обратите особое внимание на внешние эффекты. Какие методы вызываются? Обновляется ли общее состояние? Какие значения возвращаются? Потратьте время на изучение каждого метода, чтобы понять всю логику, даже если она находится за пределами изучаемого кода. Перейдите к другим методам, посмотрите документацию библиотечных методов, проверьте, что значит каждый фрагмент, вызывающий сомнения. Когда вы закончите, у вас будут теории о возможном поведении, пограничных случаях и условиях отказа в коде. Могут быть части, которые вы не понимаете, но они почти всегда следуют простым правилам, которые можно нагуглить или узнать у товарища по команде.
Третье прочтение полезно, если код содержит сложную логику. Выберите простые значения для любых параметров или переменных и представьте, что они проходят через код сверху вниз. Просчитайте результаты каждой строки.
На самом деле, каждое чтение может включать в себя несколько проходов и несколько походов в Google и на Stack Overflow. Совершенно нормально читать кусок кода десять или более раз, прежде чем вы действительно его поймёте. Может помочь длительный перерыв после первых нескольких прочтений, особенно если вы имеете дело с новыми для вас понятиями.
Продолжение следует…
Источник: https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
👍9
День 1330. #CodeReview
Допрашиваем Незнакомый Код. Продолжение
Начало
3. Рефакторинг имён локальных переменных и методов
Иногда часть кода настолько расплывчата или вводит в заблуждение, что её трудно осмыслить. Один практически безрисковый способ — переименовать локальные переменные и приватные методы, чтобы более точно описать, что они делают. Эти изменения не повлияют ни на что за пределами файла, с которым вы работаете, и не вызовут ошибок, если вы будете осторожны, чтобы избежать конфликтов имен. Если возможно, используйте инструменты рефакторинга IDE, а не поиск и замену текста.
Возможно, стоит внести и другие улучшения (например, предложенные статическим анализатором кода), но даже переименование нескольких плохо названных идентификаторов поможет понять код, не меняя его логики и не задумываясь обо всех его частях одновременно. Сами решайте, фиксировать ли эти изменения. Улучшение читабельности кода будет приносить пользу всей команде снова и снова, даже если оно не добавляет и не изменяет функциональность.
4. Посмотрите, как используется код
Большая часть кода используется другим кодом. Понимание ситуации, в которой код используется, может быть ценным контекстом для выяснения того, что он делает.
В идеале IDE покажет все места, где используется метод. Если такой функции нет, можно попробовать переименовать метод во что-нибудь нелепое. Ошибки компиляции сообщат, где использовался метод. Не забудьте изменить имя обратно. Если ваш язык интерпретируемый, придётся использовать текстовый поиск по имени метода и копаться в результатах.
5. Поищите похожий код
Иногда код трудно понять, даже если все идентификаторы правильно названы и варианты использования знакомы. Иногда для конкретной операции нет идиомы. В худшем случае рассматриваемый код либо уникален для кодовой базы, либо нет очевидной фразы, которую вы могли бы погуглить, чтобы узнать больше.
Хорошая новость в том, что по-настоящему уникальный код встречается редко в долгоживущих кодовых базах, особенно на уровне одного выражения или строки кода. Если вы потратите несколько минут на поиск похожего кода в проекте, вы можете найти что-то, что поможет разгадать загадку.
Полнотекстовый поиск — самая простая версия. Если вы хотите сузить результаты, поищите с помощью регулярного выражения. Также стоит потратить время на изучение некоторых продвинутых методов. Многие программисты предпочитают инструменты командной строки Unix, такие как grep и awk, или, в Windows, рукописные сценарии PowerShell.
Цель в том, чтобы сузить поиск до нескольких файлов, которые, скорее всего, будут отражать изучаемый вами процесс. Это позволит взглянуть на код с другой стороны и, возможно, лучше его понять.
6. Запустите модульные тесты
В идеальном мире тесты — всё, что вам нужно, чтобы понять поведение любого участка кода. Большинство кодовых баз не соответствуют этому идеалу. Тем не менее, рекомендуется проверить наличие тестов, выполняющих код, который вы изучаете. По крайней мере, они будут описывать входные и выходные данные.
Если тестов нет или они недостаточно полны, это вторая возможность внести некоторые положительные изменения. Напишите тест или два, чтобы ответить на вопросы, которые у вас остались о коде. Вы можете зафиксировать их, повысив стабильность кодовой базы и сделав её более самодокументируемой для всех, кто с ней сталкивается. И не нужно беспокоиться о том, что добавление теста как-то нарушит существующую функциональность.
Для написания тестов требуется время, но они гораздо более эффективны, чем прогон кода в воображении. Они являются фактическим доказательством того, что код работает определённым образом. И если вам в итоге потребуется изменить код, тесты дадут вам уверенность, что вы его не сломаете.
Окончание следует …
Источник: https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
Допрашиваем Незнакомый Код. Продолжение
Начало
3. Рефакторинг имён локальных переменных и методов
Иногда часть кода настолько расплывчата или вводит в заблуждение, что её трудно осмыслить. Один практически безрисковый способ — переименовать локальные переменные и приватные методы, чтобы более точно описать, что они делают. Эти изменения не повлияют ни на что за пределами файла, с которым вы работаете, и не вызовут ошибок, если вы будете осторожны, чтобы избежать конфликтов имен. Если возможно, используйте инструменты рефакторинга IDE, а не поиск и замену текста.
Возможно, стоит внести и другие улучшения (например, предложенные статическим анализатором кода), но даже переименование нескольких плохо названных идентификаторов поможет понять код, не меняя его логики и не задумываясь обо всех его частях одновременно. Сами решайте, фиксировать ли эти изменения. Улучшение читабельности кода будет приносить пользу всей команде снова и снова, даже если оно не добавляет и не изменяет функциональность.
4. Посмотрите, как используется код
Большая часть кода используется другим кодом. Понимание ситуации, в которой код используется, может быть ценным контекстом для выяснения того, что он делает.
В идеале IDE покажет все места, где используется метод. Если такой функции нет, можно попробовать переименовать метод во что-нибудь нелепое. Ошибки компиляции сообщат, где использовался метод. Не забудьте изменить имя обратно. Если ваш язык интерпретируемый, придётся использовать текстовый поиск по имени метода и копаться в результатах.
5. Поищите похожий код
Иногда код трудно понять, даже если все идентификаторы правильно названы и варианты использования знакомы. Иногда для конкретной операции нет идиомы. В худшем случае рассматриваемый код либо уникален для кодовой базы, либо нет очевидной фразы, которую вы могли бы погуглить, чтобы узнать больше.
Хорошая новость в том, что по-настоящему уникальный код встречается редко в долгоживущих кодовых базах, особенно на уровне одного выражения или строки кода. Если вы потратите несколько минут на поиск похожего кода в проекте, вы можете найти что-то, что поможет разгадать загадку.
Полнотекстовый поиск — самая простая версия. Если вы хотите сузить результаты, поищите с помощью регулярного выражения. Также стоит потратить время на изучение некоторых продвинутых методов. Многие программисты предпочитают инструменты командной строки Unix, такие как grep и awk, или, в Windows, рукописные сценарии PowerShell.
Цель в том, чтобы сузить поиск до нескольких файлов, которые, скорее всего, будут отражать изучаемый вами процесс. Это позволит взглянуть на код с другой стороны и, возможно, лучше его понять.
6. Запустите модульные тесты
В идеальном мире тесты — всё, что вам нужно, чтобы понять поведение любого участка кода. Большинство кодовых баз не соответствуют этому идеалу. Тем не менее, рекомендуется проверить наличие тестов, выполняющих код, который вы изучаете. По крайней мере, они будут описывать входные и выходные данные.
Если тестов нет или они недостаточно полны, это вторая возможность внести некоторые положительные изменения. Напишите тест или два, чтобы ответить на вопросы, которые у вас остались о коде. Вы можете зафиксировать их, повысив стабильность кодовой базы и сделав её более самодокументируемой для всех, кто с ней сталкивается. И не нужно беспокоиться о том, что добавление теста как-то нарушит существующую функциональность.
Для написания тестов требуется время, но они гораздо более эффективны, чем прогон кода в воображении. Они являются фактическим доказательством того, что код работает определённым образом. И если вам в итоге потребуется изменить код, тесты дадут вам уверенность, что вы его не сломаете.
Окончание следует …
Источник: https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
👍3
День 1331. #CodeReview
Допрашиваем Незнакомый Код. Окончание
Начало
Продолжение
7. Используйте отладчик
Выполните код по шагам в отладчике. Если вы знаете, какие действия пользователя запускают код, установите точку останова в начале кода, запустите программу в обычном режиме, взаимодействуя с ее интерфейсом, чтобы запустить код. Это дольше, чем запустить отладку в тесте, но так вы используете более реалистичные данные, которые могут помочь вам заметить такие вещи, как нулевые ссылки и пограничные случаи.
Отладка может быть менее полезной для кода, который выполняется десятки или сотни раз, например, для вложенных циклов. В этом случае вы можете добавить переменные, которые собирают данные на каждой итерации, чтобы просмотреть их позже. Многие IDE также позволяют устанавливать условные точки останова, чтобы можно было приостановить выполнение итерации, отвечающей определенным требованиям.
8. Поиск в базе знаний
Если ваша команда использует базу знаний, такую как Stack Overflow for Teams, Confluence или GitHub-вики, вы уже должны иметь довольно хорошее представление о том, какие термины или понятия можно использовать для поиска соответствующей документации. Имейте в виду, что документация не должна быть вашим единственным источником правды. Она начинает устаревать в момент публикации, и единственное, на что вы можете полностью положиться, чтобы узнать, как ведёт себя часть кода, — это сам код. Тем не менее, даже устаревшая документация может дать достаточно исходной информации и контекста, чтобы помочь вам избежать ошибочных выводов.
Документация может объяснить скорее не «как», а «почему» код работает так, а не иначе. Иногда вы понимаете, что делает фрагмент кода, но что-то в нем кажется неправильным. Прежде чем изменить его, вы должны приложить все усилия, чтобы понять, чем руководствовался первоначальный программист.
9. Используйте аннотацию контроля версий (git blame)
Последний способ собрать контекст — отследить исходного автора, коммит и тикет, связанный с этим кодом.
В любой системе контроля версий есть инструмент, который раскрывает автора и коммит для любой строки кода в кодовой базе. В Git это команда git blame. Так вы сможете найти исходный запрос, который включал код, и возможно, ссылку на исходный тикет, в котором содержится описание функции или ошибки. Возможно, придется просмотреть историю изменений файла, чтобы найти коммит, в котором было сделано нужное изменение.
Так вы сможете найти автора, рецензентов пул-реквеста, всех, кто комментировал тикет или ещё каким-либо образом имел отношение к изменению. Если вы до сих пор не поговорили с коллегами о возникшем у вас затруднении, теперь самое время.
Итого
Контекст и понимание, которые вы получили в ходе этих шагов, вероятно, будут ценны в будущем. Прежде чем двигаться дальше, рассмотрите возможность рефакторинга кода для ясности, создайте новую документацию или даже просто отправьте email с вашими выводами. Каждый раз, когда вы инвестируете в это, вы будете получать дивиденды, поскольку вы и ваша команда будете взаимодействовать с кодом в будущем.
Способность эффективно читать код — это секретное оружие, которое ускорит прохождение вами технического собеседования и сделает вас незаменимым членом любой команды. Программисты, умеющие писать код, ценны, но программисты, умеющие читать код, возможно, ещё более ценны. Когда в продакшене есть ошибка или нужно срочно создать фичу, первым и самым важным шагом является понимание. Умение читать код поможет вам в этом.
Источник: https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
Допрашиваем Незнакомый Код. Окончание
Начало
Продолжение
7. Используйте отладчик
Выполните код по шагам в отладчике. Если вы знаете, какие действия пользователя запускают код, установите точку останова в начале кода, запустите программу в обычном режиме, взаимодействуя с ее интерфейсом, чтобы запустить код. Это дольше, чем запустить отладку в тесте, но так вы используете более реалистичные данные, которые могут помочь вам заметить такие вещи, как нулевые ссылки и пограничные случаи.
Отладка может быть менее полезной для кода, который выполняется десятки или сотни раз, например, для вложенных циклов. В этом случае вы можете добавить переменные, которые собирают данные на каждой итерации, чтобы просмотреть их позже. Многие IDE также позволяют устанавливать условные точки останова, чтобы можно было приостановить выполнение итерации, отвечающей определенным требованиям.
8. Поиск в базе знаний
Если ваша команда использует базу знаний, такую как Stack Overflow for Teams, Confluence или GitHub-вики, вы уже должны иметь довольно хорошее представление о том, какие термины или понятия можно использовать для поиска соответствующей документации. Имейте в виду, что документация не должна быть вашим единственным источником правды. Она начинает устаревать в момент публикации, и единственное, на что вы можете полностью положиться, чтобы узнать, как ведёт себя часть кода, — это сам код. Тем не менее, даже устаревшая документация может дать достаточно исходной информации и контекста, чтобы помочь вам избежать ошибочных выводов.
Документация может объяснить скорее не «как», а «почему» код работает так, а не иначе. Иногда вы понимаете, что делает фрагмент кода, но что-то в нем кажется неправильным. Прежде чем изменить его, вы должны приложить все усилия, чтобы понять, чем руководствовался первоначальный программист.
9. Используйте аннотацию контроля версий (git blame)
Последний способ собрать контекст — отследить исходного автора, коммит и тикет, связанный с этим кодом.
В любой системе контроля версий есть инструмент, который раскрывает автора и коммит для любой строки кода в кодовой базе. В Git это команда git blame. Так вы сможете найти исходный запрос, который включал код, и возможно, ссылку на исходный тикет, в котором содержится описание функции или ошибки. Возможно, придется просмотреть историю изменений файла, чтобы найти коммит, в котором было сделано нужное изменение.
Так вы сможете найти автора, рецензентов пул-реквеста, всех, кто комментировал тикет или ещё каким-либо образом имел отношение к изменению. Если вы до сих пор не поговорили с коллегами о возникшем у вас затруднении, теперь самое время.
Итого
Контекст и понимание, которые вы получили в ходе этих шагов, вероятно, будут ценны в будущем. Прежде чем двигаться дальше, рассмотрите возможность рефакторинга кода для ясности, создайте новую документацию или даже просто отправьте email с вашими выводами. Каждый раз, когда вы инвестируете в это, вы будете получать дивиденды, поскольку вы и ваша команда будете взаимодействовать с кодом в будущем.
Способность эффективно читать код — это секретное оружие, которое ускорит прохождение вами технического собеседования и сделает вас незаменимым членом любой команды. Программисты, умеющие писать код, ценны, но программисты, умеющие читать код, возможно, ещё более ценны. Когда в продакшене есть ошибка или нужно срочно создать фичу, первым и самым важным шагом является понимание. Умение читать код поможет вам в этом.
Источник: https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
👍10
День 1465. #CodeReview
Как Оптимизировать Обзоры Кода
Обзоры кода требуют значительных временных затрат, и важно понять, как инженеры могут извлечь из них максимальную пользу. Процесс проверки кода (с помощью некоторой автоматизации) может быть идеальной возможностью для членов команд развить навыки асинхронного общения и внести вклад в обмен знаниями в команде.
Доверьтесь асинхронной связи
Пандемия положила начало периоду самоизоляции, и многие из нас теперь работают из дома. Благодаря этому эффективная асинхронная связь стала первостепенной задачей. В дополнение к email и мессенджерам, проверка пулл-реквестов является вариантом асинхронного общения. У асинхронного общения есть свои преимущества:
- Люди из разных часовых поясов могут чувствовать себя вовлеченными.
- Удобно для людей с разным знанием языка (человеческого, а не языка программирования).
- Обеспечивает гибкость для людей с разными графиками.
Разработка надёжной стратегии асинхронной коммуникации, особенно в отношении обзоров кода, требует двух вещей: доверия и стандартов. Не имея возможности наблюдать за выражением лица и интонацией голоса собеседника, остаётся доверять его благим намерениям при получении отзывов.
А стандарты код-ревью помогут уменьшить трения, связанные с двусмысленностью. Например, разъяснение того, какой отзыв является придиркой, а какой отзыв фактически блокирует слияние, помогает прояснить ожидания для всех, кто участвует в процессе проверки. Этих проблем можно избежать, выделив время всей командой для определения стандартов.
Ещё есть документация. Очень сложно подготовить хорошую документацию для проектов, особенно если нет специального технического писателя. Обратите внимание на пассивную документацию: способы обмена информацией без активного участия, т.е. все виды артефактов, которые команды создают, когда они исследуют, проектируют и создают продукт публично. Пассивная документация включает письменный диалог для исследования ошибки или описания пулл-реквестов. Да, «пассивные документы» сложнее искать, если у них нет специального оглавления или маркировки, но они обеспечивают удобный формат для обмена знаниями.
Позвольте автоматизации оптимизировать процессы
Иногда требуется машина, чтобы помочь людям не мешать друг другу, когда дело касается совместной работы. Создание GitHub Actions и подобных ему сервисов позволило легко внедрять автоматические проверки в процесс обзора кода. Но здесь возникает и большая ответственность. Какие проверки целесообразно автоматизировать? Стратегия может быть примерно такая:
1. Меньше значит больше. Из-за множества проверок любому, кто занимается код-ревью, может быть очень сложно отличить, что важно, а что нет. Автоматизация при консервативном применении может помочь сфокусироваться на важных вещах. Но излишняя автоматизация проверки может сбивать с толку и демотивировать в принятии решений.
2. Автоматизация как второй мозг. Автоматизация должна помогать там, где человеческое внимание может подвести. Автоматизируйте проверки качества кода, что облегчит жизнь разработчикам, дав им возможность сосредоточиться на проверках на более высоких уровнях, а также на обмене знаниями.
3. Автоматизация должна расширять возможности людей. Эффективная автоматизация должна позволять людям полностью владеть определёнными функциями. Например, автоматическое перемещение пулл-реквеста в ишью, при получении отзыва, пометка его и назначение его исполнителю даст команде больше понимания того, кто владеет какими функциональными областями. Вместо того, чтобы отправлять задачу в общую кучу невыполненной работы, автоматизация поможет поддерживать действенность обратной связи.
Итого
Хотя проверка кода часто считается утомительной, она может стать благодатной почвой для роста эмпатии, более активного общения и лучшего обмена знаниями внутри команд. А даже небольшая автоматизация может иметь большое значение.
Источник: https://github.com/readme/guides/code-review-optimization
Как Оптимизировать Обзоры Кода
Обзоры кода требуют значительных временных затрат, и важно понять, как инженеры могут извлечь из них максимальную пользу. Процесс проверки кода (с помощью некоторой автоматизации) может быть идеальной возможностью для членов команд развить навыки асинхронного общения и внести вклад в обмен знаниями в команде.
Доверьтесь асинхронной связи
Пандемия положила начало периоду самоизоляции, и многие из нас теперь работают из дома. Благодаря этому эффективная асинхронная связь стала первостепенной задачей. В дополнение к email и мессенджерам, проверка пулл-реквестов является вариантом асинхронного общения. У асинхронного общения есть свои преимущества:
- Люди из разных часовых поясов могут чувствовать себя вовлеченными.
- Удобно для людей с разным знанием языка (человеческого, а не языка программирования).
- Обеспечивает гибкость для людей с разными графиками.
Разработка надёжной стратегии асинхронной коммуникации, особенно в отношении обзоров кода, требует двух вещей: доверия и стандартов. Не имея возможности наблюдать за выражением лица и интонацией голоса собеседника, остаётся доверять его благим намерениям при получении отзывов.
А стандарты код-ревью помогут уменьшить трения, связанные с двусмысленностью. Например, разъяснение того, какой отзыв является придиркой, а какой отзыв фактически блокирует слияние, помогает прояснить ожидания для всех, кто участвует в процессе проверки. Этих проблем можно избежать, выделив время всей командой для определения стандартов.
Ещё есть документация. Очень сложно подготовить хорошую документацию для проектов, особенно если нет специального технического писателя. Обратите внимание на пассивную документацию: способы обмена информацией без активного участия, т.е. все виды артефактов, которые команды создают, когда они исследуют, проектируют и создают продукт публично. Пассивная документация включает письменный диалог для исследования ошибки или описания пулл-реквестов. Да, «пассивные документы» сложнее искать, если у них нет специального оглавления или маркировки, но они обеспечивают удобный формат для обмена знаниями.
Позвольте автоматизации оптимизировать процессы
Иногда требуется машина, чтобы помочь людям не мешать друг другу, когда дело касается совместной работы. Создание GitHub Actions и подобных ему сервисов позволило легко внедрять автоматические проверки в процесс обзора кода. Но здесь возникает и большая ответственность. Какие проверки целесообразно автоматизировать? Стратегия может быть примерно такая:
1. Меньше значит больше. Из-за множества проверок любому, кто занимается код-ревью, может быть очень сложно отличить, что важно, а что нет. Автоматизация при консервативном применении может помочь сфокусироваться на важных вещах. Но излишняя автоматизация проверки может сбивать с толку и демотивировать в принятии решений.
2. Автоматизация как второй мозг. Автоматизация должна помогать там, где человеческое внимание может подвести. Автоматизируйте проверки качества кода, что облегчит жизнь разработчикам, дав им возможность сосредоточиться на проверках на более высоких уровнях, а также на обмене знаниями.
3. Автоматизация должна расширять возможности людей. Эффективная автоматизация должна позволять людям полностью владеть определёнными функциями. Например, автоматическое перемещение пулл-реквеста в ишью, при получении отзыва, пометка его и назначение его исполнителю даст команде больше понимания того, кто владеет какими функциональными областями. Вместо того, чтобы отправлять задачу в общую кучу невыполненной работы, автоматизация поможет поддерживать действенность обратной связи.
Итого
Хотя проверка кода часто считается утомительной, она может стать благодатной почвой для роста эмпатии, более активного общения и лучшего обмена знаниями внутри команд. А даже небольшая автоматизация может иметь большое значение.
Источник: https://github.com/readme/guides/code-review-optimization
👍7