Советы по сфокусированности во время обзоров кода

Question

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

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

Answer 1

• Если речь идет о запущенном коде, это не обзор кода.
• Если это более 1000 строк кода, это не обзор кода.
• Если требуется более 20 минут подготовки, это не обзор кода.
• Если сам обзор занимает больше часа, это не обзор кода.

Может быть, ваша компания должна зафиксировать процесс обзора кода ...

Answer 2

До сих пор я использую следующий

• Проверка моей электронной почты & RSS-каналы каждый так часто - однако при этом увеличивается, как рассматривается больше кода.
• кофе - пить больше и больше
• Переход к StackOverflow, чтобы ответить на вопросы или задать вопросы;)

Answer 3

Это действительно сложная проблема. Думаю, мой вопрос к вам будет следующим: что вы можете сделать, чтобы более вероятно, что первые 5000 строк кода, на которые вы смотрите, являются правильными, на которые нужно смотреть?

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

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

Answer 4

Стратегия должна заключаться в том, чтобы заставить их пройти через код, объясняя, что они видят. Цель состоит в том, чтобы: a) создать твердый, ремонтируемый, правильный код и b) учиться на этом. Вы будете удивлены, как много вы узнаете, просматривая код других. Да, идея считывания кода PAINFUL, но на практике это возможность для большого образовательного опыта, и это дает вам идеи о том, что следует искать в будущем.

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

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

И, конечно же, кофеин;)

Answer 5

ли определенное количество упражнений для каждого блока кода, который вы обзора (например, 20 приседания на тысячу строк кода, или что-то подобное). Вы можете добавить немного вещей, например, сделать 5 отжиманий для каждого бесполезного комментария, который вы видите, или 10 chinup для каждой повторяющейся функции, которую вы найдете. Физическая активность удерживает внимание ума, и, учитывая состояние большинства кодов в мире, вы будете серьезно разорваны в кратчайшие сроки.

Предупреждение: не рекомендуется для классического ASP. Сердечный приступ и инсульт были бы неизбежны.

Answer 6

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

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

Это сделает вас занятым и сконцентрированным на 100% занятым. И он также визуализирует ваш прогресс и подбадривает вас!

Answer 7

Я бы предпочел, чтобы у вас одновременно был обозреватель. Это улучшает скорость и эффективность.

Answer 8

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

Check this ebook on solid.

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

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

Answer 9

Можете ли вы сделать обзор сверху вниз? Просмотрите верхний уровень (основной метод?) И напишите комментарии к этому. Затем разверните один шаг на каждом уровне абстракции и прокомментируйте это. Иногда я тренируюсь по 14 уровням методов и полностью теряюсь, когда возвращаюсь. Может помочь ваш обзор.

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

Не то, чтобы я завидовал. Мне не нравится делать отзывы с разработчиками поблизости.

Что касается управления временем, попробуйте метод Помодоро. Это действительно помогает мне, когда я сталкиваюсь с сеансом кодирования марафона.

Answer 10

Я считаю, что лучший обзор кода, когда он протекает так:

1. Кодер говорит о каждом методе; один за раз. Основное внимание уделяется тому, как и почему он делает то, что он делает; а не на входе или выходе. Это может сделать его интересным, так как все в команде заинтересованы в коде.
2. Лидер команды служит исполнителем. Он заставляет всех, кто уходит, вернуться к точке.
3. Это сделано в традицию и выполняется DESPITE независимо (необходимо исправить незначительную ошибку prod, только кофе без кофеина в кастрюле для кофе, людям это не нравится и т. Д.). Затем люди попадают в ритм и поток, а проверка кода не постепенно прекращается из-за других действий.

Answer 11

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

Answer 12

Я обычно пройти через функцию, в то время, гуй вниз дБ/reporsitory слой.

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

Я буду придерживаться mindmap/wiki моего понимания системы. Сразу же после перерыва мышление становится легче воспринимать.

Я бы рассказал о своих выводах с другими товарищами по команде.

Answer 13

Я сомневаюсь, что любой человек мог извлечь что-либо значимое из чтения 5000 строк кода за день.

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

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

Идея не посмотреть каждую строку кода. Это работа менеджера разработчиков, или, возможно, QA. Идея в обзоре кода состоит прежде всего в том, чтобы дважды проверить мыслительные процессы, стоящие за кодом, включая архитектуру, поток и т. Д., А также посмотреть на аспекты качества: производительность, масштабируемость и безопасность.

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

Answer 14

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

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

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

В обзоре я задавать вопросы, которые направят меня на интересные/проблемные места в коде:

• Какие решения вы сделали при выборе конкретной реализации?
• Каковы преимущества конкретного решения, которое было принято?
• Какие шаблоны дизайна/принципы дизайна следует вашему коду?

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

Answer 15

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

Открытый экзамен на кодовую базу занимает ДЛИТЕЛЬНОЕ время и не имеет достаточных шансов быть эффективным, если ваше участие должно быть недолгим.

Существует довольно хороший подкаст по проблеме считывания кода на se-radio: link. Это интервью с Дейвом Томасом (автор «Прагматического программиста»). Я думаю, это относится к тому, что вы пытаетесь сделать.

Answer 16

Да в обзоре кода вам необходимо прочитать код. Но не только прямые линии 5K без цели или плана. Неудивительно, что вы не можете сосредоточиться.

Инструменты анализа, которые производят показатели, могут сфокусировать вас. Запустите инструменты анализа и отсортируйте результаты по их метрикам. Каждый инструмент покажет вам «топ-5 файлов или функцию» с проблемами по данному вопросу:

• длинных файлы
• длинных функции
• большого вентилятора в или веерных из
• сложность
• нарушение ворса

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

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

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

Answer 17

1. Outsource your own job.
2. играть портативный видеоигр в конференц-залах
3. Collect зарплата
4. Жизнь хороша