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

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

173 голоса | спросил Max Yankov 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

19 ответов


91

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
54

Взгляните на Обзор кода . Это для совместного использования кода из проектов, над которыми вы работаете, для экспертной оценки :

  

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

     

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
26

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

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

пс Он не шутит.

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
22

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

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

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

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

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

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

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

  • Можно ли описать в одном смысле, что делает класс /метод /переменная?
  • Насколько легко использовать класс отдельно (вне других классов) или написать unittest для?
ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
18

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
15

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
13

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
9

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

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

  • Имейте грубый контрольный список. Это те вещи, которые вы хотите отметить, когда читаете свой код.
  • Просмотрите свой код в автономном режиме. Это может показаться расточительным, но сделайте распечатки, которые вы можете аннотировать и перевернуть назад или вперед, или цифровой эквивалент хорошо выделенных pdf-файлов, синхронизированных с iPad, который затем отключается. Уходите от своего стола, так что все, что вы делаете, - это обзор вашего отвлекающего кода.
  • Сделайте это рано утром, а не в конце рабочего дня. Свежая пара глаз лучше. Фактически, это могло бы помочь уйти от кода за день, прежде чем пересматривать его заново.

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
8

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

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
7

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

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

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
5

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
5

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
5

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
5

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
4

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
3

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
3

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

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

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

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

http://www.javaspecialists.eu/

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
0

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18
0

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

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

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

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

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

ответил Stig Hemmer 18 +03002016-10-18T13:54:18+03:00312016bEurope/MoscowTue, 18 Oct 2016 13:54:18 +0300 2016, 13:54:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132