Как я могу просмотреть свой собственный код? [закрыто]

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

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

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

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

Загляните на сайт Code Review Stack Exchange. Он предназначен для обмена кодом из проектов, над которыми вы работаете, для экспертной оценки :

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

Если вы ищете отзывы о конкретном рабочем фрагменте кода вашего проекта в следующих областях…

• Лучшие практики и использование шаблонов проектирования
• Проблемы с безопасностью
• Представление
• Корректность в непредвиденных случаях

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

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

Я настоятельно рекомендую мой подход.

ps он не шутит.

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

краткосрочный обзор (вскоре после написания кода)

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

Прежде чем я проверяю, я сравниваю то, что я изменил в своем коде, и переосмысливаю:

• имена переменных / методов / классов по-прежнему отражают то, для чего они используются?

долгосрочный обзор (6 месяцев после написания кода)

Я спрашиваю себя:

• я могу описать в одном предложении, что делает класс / метод / переменная?
• Насколько легко использовать класс изолированно (без других классов) или написать юнит-тест?

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

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

Говорят, что истинное владение предметом - это способность обучать его кому-то еще. С документацией вы пытаетесь научить кого-то другому свой код.

Преобразуйте эту технику отладки в технику проверки кода: http://en.wikipedia.org/wiki/Rubber_duck_debugging

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

В дополнение к полезным инструментам, упомянутым в других ответах, я думаю, что изменение вашего мышления полезно при проверке кода. Это глупо, но я говорю себе: «Я надеваю шляпу для проверки кода». Я делаю то же самое с QA.

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

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

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

Вот советы из моего нескольких лет опыта:

• Имейте грубый контрольный список под рукой. Это то, что вы хотите пометить во время чтения вашего кода.
• Возьмите ваш обзор кода в автономном режиме. Это может показаться расточительным, но возьмите распечатки, которые вы можете аннотировать и переворачивать назад или вперед, или цифровой эквивалент красиво выделенных PDF-файлов, синхронизированных с iPad, который затем переводится в автономный режим. Отойди от своего стола, чтобы все, что ты делаешь, проверяло твой код без отвлечения.
• Делайте это рано утром, а не до конца рабочего дня. Свежая пара глаз лучше. На самом деле, это может помочь отойти от кода за день до его повторного просмотра.

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

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

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

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

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

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

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

1. BDD означает сначала писать тест кода. Это гарантирует, что весь ваш код покрыт тестами.
2. BDD - это, по сути, TDD, но с немного другим фокусом и «языком». Это означает, что вы постоянно рефакторизируете свой код во время работы над ним и используете свои тесты, чтобы убедиться, что ваши усилия по рефакторингу продолжают гарантировать, что ваш код удовлетворяет спецификации вашего продукта.
3. Язык BDD рекомендует писать тесты в форме операторов, которые по существу кодируют требования как модульные тесты.

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

Реальная проблема для вас будет в том, сможете ли вы обнаружить потенциальные проблемы в вашем коде, которые будут указывать на необходимость рефакторинга. На рынке есть несколько инструментов для профилирования, которые могут помочь вам в этом, а также несколько других инструментов, связанных с показателями качества кода. Они часто могут рассказать вам о многих вещах, которые могут пропустить обзоры кода, и они необходимы при разработке проектов самостоятельно. В действительности, однако, ключом является опыт, и если вы привыкли быть беспощадными в своем рефакторинге, вы, вероятно, станете гораздо более критичны в отношении своего собственного кода. Если вы еще этого не сделали, я бы посоветовал почитать книгу Рефакторинга Мартина Фаулера в качестве отправной точки и найти хороший BDD API, который, по вашему мнению, будет работать для вас на любом языке, с которым вы решили работать.

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

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

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

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

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

Дайте ему 3 месяца, затем вернитесь и посмотрите на свой код. Я обещаю вам, если вы не можете найти что-то не так с этим (или вопрос, кто написал этот мусор!), Вы лучше, чем я!

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

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

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

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

Большинство людей склонны рассматривать свой код как своих собственных детей и кормить их эго, а не реальностью. Как и любые другие обзоры кода, просматривайте его, когда видите чужой код. Полностью забудь, что ты что-то написал. Просмотрите каждую строку кода. Контрольный список был бы полезен для того, чтобы быть эстетическим в рассмотрении собственного кода. Автоматизированные инструменты для проверки кода могут помочь в некоторой степени. Я использовал некоторые инструменты, такие как klocwork (коммерческое программное обеспечение). Это очень полезно, когда вы работаете в больших проектах, и несколько разработчиков работают над этим. Всегда сосредотачивайтесь на обнаружении дефектов, а не на исправлении.

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

Подумайте о том, чтобы провести инспекцию Фагана самостоятельно - вам придется адаптировать процесс, потому что вы сами, но вы должны быть в состоянии извлечь немало пользы из него. Хитрость заключается в том, чтобы найти правильный «набор правил» для оценки вашего кода как отдельного разработчика, а затем иметь дисциплину, чтобы каждый раз задавать эти вопросы в критическом, аналитическом, беспощадном настроении. Я подозреваю, что вы можете начать с мозгового штурма своих 4-5 важных вопросов, а затем развить их со временем. Некоторые люди против формальных инспекций, потому что они кажутся такими трудоемкими ... прежде чем вы решите, что они слишком дороги, имейте в виду все статистические доказательства того, что проведение инспекций должным образом фактически сокращает время проекта. Вот ссылка на Википедию, с которой вы можете начать дальнейшие исследования:

http://en.wikipedia.org/wiki/Software_inspection

Также было несколько книг, например, Google для «Процесса проверки программного обеспечения» Штрауса и Эбенау.

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

http://www.javaspecialists.eu/

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

На самом деле это еще не было включено в ответ (но было добавлено как комментарий к существующему ответу)

Просмотрите код после хорошего ночного сна, например, начните день с просмотра кода, который вы написали в предыдущий день.

Это, конечно, не даст вам коллективного опыта команды, но даст вам возможность пересмотреть код с новой точки зрения.

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

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