Готовитесь к рассмотрению кода в качестве разработчика?


10

Я ищу некоторые идеи здесь.

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

Мой вопрос

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

    • В настоящее время я практикую следующие методы

      • PPT для логического потока
      • Подробные комментарии.

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

Я думаю, что многие разработчики тоже переживают то, что я переживаю.


2
Только один: не делайте глупостей в своем коде.
BЈовић

1
ПОЦЕЛУЙ: если код прост, ваш мозг может справиться со всем этим.
Mouviciel

Когда вы проводите проверку кода в вашей компании, кто обычно ведет собрание? Вы или человек, который проверяет вашу работу? Я спрашиваю, потому что встреча по пересмотру кода в IMO - это не место, где можно потратить время на поиск фрагментов кода, даже если вы очень быстро разбираетесь в поиске.
ДХМ

@DXM Спасибо за ответ. Это мой ТЛ бы вел встречу.
Картик Сринивасан

@Kartik: K, эта часть хороша. Таким образом, основываясь на вашем вопросе, вы не спрашиваете, как написать и создать высококачественный код, готовый для проверки кода. Вместо этого ваша главная задача заключается в следующем: «Я продолжаю искать реализацию и процесс, и слишком много времени теряется». Можете ли вы уточнить это? почему вы делаете какой-либо поиск, если TL имеет код перед ним / ней и ведет собрание?
ДХМ

Ответы:


8

Таким образом, исходя из предоставленных подробностей OP, звучит вопрос: «Как мне узнать свой собственный код, чтобы, когда меня попросили найти X или объяснить Y, я мог быстро ответить».

Несколько предложений, которые я могу придумать:

  • При кодировании вам нужно время, чтобы выучить и понять свой собственный код. Это может быть то, что ваш TL пытается донести до вас не так много слов. Будучи TL для текущего проекта, я сделал много обзоров кода за последние 11 месяцев, и я заметил, что некоторые разработчики ищут «пример кода» в нашей собственной кодовой базе или где-то еще (Google и т. д.) и скопировать / вставить его. Лично я не могу этого вынести, потому что, хотя их код проходит простые модульные тесты, они не понимают, что он на самом деле делает, поэтому мы никогда не гарантируем, что его нет t некоторый граничный случай или ожидаемое условие отказа, которое может произойти.

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

  • Читайте и учитесь любить принцип СУХОЙ . Много раз то, что вы склонны копировать / вставлять, может быть помещено в общее место (отдельная функция, отдельный класс, отдельная библиотека ...)

  • Читайте и учитесь любить ТВЕРДЫЕ принципы, и пока вы это делаете, просмотрите KISS, который уже упоминал mouviciel. Все эти принципы ориентированы на создание очень сжатого, чистого и модульного кода. Если у вас есть большие классы и большие функции внутри них, то, очевидно, будет гораздо сложнее находить вещи, и вдобавок ко всему попытаться объяснить, что делает код. С другой стороны, если вы будете следовать (или хотя бы попытаться следовать) SRP и сделать каждый класс / функцию ответственной только за одну вещь, ваш код будет небольшим и очень читабельным.

  • Возьмите копию Чистого кода . Очень хорошая книга. В нем говорится о написании кода, который говорит само за себя и легко читается, поддерживается и расширяется. Если вы практикуете написание легко читаемого кода, у вас не должно возникнуть проблем с чтением собственного кода в обзорах кода. И это забавная часть, я попросил людей прочитать их собственный код или просто сказать мне, что представляют собой переменные, и они не смогли ответить, даже если они написали этот код (совершенно новые классы, а не устаревшие) только неделю назад , Хорошее именование имеет большое значение.

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

  • Если после всех вышеперечисленных пунктов у вас все еще есть проблемы? Вы новичок в команде и попросили поработать с большим количеством устаревшего кода? В этом случае может случиться так, что ваш TL будет A $$, и вы можете проявить инициативу, попросив его перед встречей пройти спокойно и не тратить время всех участников. Когда новые люди присоединяются к команде, TL нужно иметь достаточно терпения, потому что работа над новой платформой, новым продуктом, новыми людьми, новой средой требует большой концентрации от нового человека, и этот человек вначале упустит некоторые детали. Работает как Designed, и ваш TL должен просто принять это.

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


+1 за "не копировать и вставлять код, который вы не понимаете". Это невыносимо! Также +1 за «поговори со своим TL»
MarkJ

@DXM Ваша способность понимать тончайшие нюансы вопроса была очень профессиональной, не говоря уже о том, что ваш ответ очень информативен и описателен. Разум = взорван!
Картик Сринивасан

@DXM Из вашей ссылки «С другой стороны, если вы будете следовать (или хотя бы попытаться следовать) SRP и сделать каждый класс / функцию ответственной только за одну вещь, ваш код будет небольшим и очень читабельным». Можете ли вы дать мне знать, что означает * SRP ? * Я видел еще один интересный пост о ясности кода здесь .
Картик Сринивасан

1
@KarthikSreenivasan - В контексте используется его практика, где метод или класс отвечает за одну вещь. Например, метод, который складывает числа вместе, также не должен возвращать среднее значение. Простой поиск нашел это: en.wikipedia.org/wiki/Single_responsibility_principle
Ramhound

10

Практики меняются, но по моему опыту:

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

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

  • Код должен быть напечатан или отображен с номерами строк . Предпочтительно, номер должен продолжаться от одного файла до следующего. Гораздо проще обратиться к «строке 3502», чем к «строке 238 файла foo.c», а наличие номеров позволяет всем говорить о конкретных строках, не тратя время на поиск этих строк.

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

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

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

  • Помните, что это не личное. Трудно избежать ощущения (и действия) защиты во время обзора. Хорошо объяснить ваш код, если вы думаете, что его неправильно поняли, но больше всего постарайтесь просто послушать.


Я хотел бы добавить одну вещь: «линия 3502» будет большой красной меткой. Наличие очень длинных файлов, безусловно, плохо.
BЈовић

2
@VJo: Калеб предложил, чтобы номера строк продолжались в файлах, поэтому строка 3502 на самом деле является строкой 238 из foo.c.
Хайнци

Я не согласен с номером строки в файлах. Для меня это просто сбивает с толку и неловко. Если обнаружены какие-либо проблемы, они должны быть отслежены модулем (класс, файл, возможно, даже метод) в любом случае. Кроме того, во время проверки кода вам следует проверять не всю систему, а подсистему или даже пару классов или файлов, поэтому не должно быть слишком сложно отслеживать, где находятся изменения.
Томас Оуэнс

1
@ThomasOwens Номера строк предназначены исключительно для упрощения описания местоположения в проверенном коде во время проверки. Это быстрее и менее подвержено ошибкам, чем использование «file foo.c, строка 123», а OP специально просит потратить меньше времени на поиск кода. Согласитесь, что проблемы должны отслеживаться по файлам. IME, обзоры, как правило, охватывают группу классов, может быть, два больших или десяток маленьких. 3500+ строк - это слишком много, чтобы их можно было просмотреть за один раз. Я лишь пытался подчеркнуть, что числа переходят от одного файла к другому.
Калеб

Если вы организованы, это не должно иметь значения. Для меня, я чувствую, что это замедлит меня. Я принимал участие в обзорах кода и всегда распечатывал файлы, скреплял их по классам / файлам, а затем читал и комментировал их. Если кто-то хочет сказать мне, где искать, мне нужна пара имя файла / номер строки - это облегчит мне задачу, тем более что моя IDE печатает имя файла в верхнем / нижнем колонтитуле на каждой странице, и я печатаю номера строк для каждого файла.
Томас Оуэнс

3

Еще одна вещь, которую нужно добавить к другим ответам: чтобы упростить формальные проверки кода, проведите МНОГО неофициальных проверок кода! Например:

«Эй, Боб, могу я показать, как я реализовал функцию foo ()?» «Привет, Стив, можешь взглянуть на эту диаграмму классов и дать мне знать, что ты думаешь?» «Эй, Карен, можешь помочь мне обдумать эту проблему? Думаю, у меня есть хорошее решение, но я могу воспользоваться твоей помощью ...»

Сделайте это обычной привычкой. Когда вы вовлекаете своих коллег на ранних этапах процесса проектирования, вы:

  • Строить отношения
  • Получите новое понимание проблемы
  • Улучшите вашу способность объяснить проблему / решение под рукой
  • Экономьте время позже в официальных обзорах кода

+1 для построения команды и улучшить вашу способность объяснить проблему. Это действительно отличная идея!
Картик Сринивасан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.