Блог

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

Есть ли еще кто-нибудь, у кого была проблема, когда они только начинали, из-за отсутствия какой-то детали, которая вызывает большие проблемы? Есть ли какие-либо привычки или поведение, которые помогли вам преодолеть это?

Вот список распространенных ошибок и/или предложений, как их избежать:

1. Опыт подсказывает, что лучший способ избежать ошибок-это то, что они уже случались с вами.
2. Просмотрите код других людей
3. Попросите других людей просмотреть ваш код
4. Используйте систему управления версиями, даже если вы единственный разработчик
5. Просмотрите все свои изменения, прежде чем выполнять фиксацию в системе управления версиями
6. Подумайте об использовании более современного языка, который затрудняет вам совершать ошибки
7. Подробно прокомментируйте свой код
8. Рефакторинг кода на ранней стадии и часто
9. Исправьте ошибки перед добавлением функций
10. Создавайте обширные тестовые примеры, потому что знание о ваших ошибках поможет вам быстрее избежать будущих.
11. Изучайте и используйте шаблоны проектирования.
12. Избегайте дублирования кода любой ценой, старайтесь никогда не копировать/вставлять блоки кода
13. Прочитайте о конкретных распространенных ошибках в используемом вами языке программирования

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

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

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

Это похоже на все остальное, что вы будете делать в жизни. От сжигания себя на фритюрнице в местном магазине быстрого питания до того, чтобы стать предпринимателем в своем 3-м стартапе.

Совершайте ошибки, учитесь на них и улучшайте себя — не игнорируйте их.

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

Я добавлю еще один голос за «практика делает совершенным» , но с небольшим одобрением:

совершенная практика делает совершенным — родственная поговорка гласит: «практика делает постоянным», поэтому, другими словами, убедитесь, что вы практикуете хорошие привычки кодирования, которые сокращают количество ошибок:

• модульное тестирование
• форматирование читаемого кода
• полезные имена переменных
• система управления версиями для истории изменений

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

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

Здравый смысл приходит из опыта.

Опыт приходит из-за неправильного суждения.

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

Вы делаете хорошее начало — признаете, что еще не все продумали. Никто из нас не знает.

Убедитесь, что вы понимаете домен — это сразу устранит некоторые ошибки. Знайте, что вы решаете, а затем приступайте к разработке решения.

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

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

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

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

Всегда придерживайтесь принципа «Все просто»!! У вас меньше шансов ошибиться, если вы будете все делать просто.

РВенди

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

Шаблоны — разрабатывайте или заимствуйте и ИСПОЛЬЗУЙТЕ шаблоны в своей работе. Некоторые примеры шаблонов: согласованное использование имен переменных, согласованное расположение приращения счетчиков, согласованное размещение отчетов об ошибках и т.д.

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

 void MyMethod(String some_input)
{
   if (some_input == null)
   {
      some_input = "";
   }
}
 

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

 void MyMethod(String some_input) {
  if (some_input == null) {
    some_input = "";
  }
}
 

Если где-то пропала скоба, ее поиск отнимает очень много времени!

Хорошо прокомментируйте.

Хорошо распределите свой код.

Имеют значимые имена переменных.

Как правило, БОЛЬШИЕ ошибки возникают из-за погружения в программное обеспечение и написания программного обеспечения до того, как вы подумаете об этом. У меня работают 2 программиста, и вот что я настаиваю, чтобы они сделали. Это имеет большое значение.

Нарисуйте экран, который вы разрабатываете, на бумаге и определите, как все работает, насколько это возможно, перед кодированием. Покажите это своему боссу/клиенту/кому-то еще. Объясни им это. Заставьте их критиковать это.

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

1. Наследование
2. Агрегация (например, этот сайт состоит из пользователей, пользователи делают несколько сообщений, сообщения могут иметь несколько комментариев от других пользователей)

Будет иметь огромное значение для того, чтобы вообще не думать об этом.

Сохраняйте свои функции небольшими — никогда не более, скажем, 30 строк, часто меньше. Это поможет вам структурировать свой код.

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

общедоступная строка getName(int CustID) {

         // Create local variables

        // Get the connection string from the config file

        // Create Try Catch Finally block

        // Create SQL parameters 

        .... etc

    }
 

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

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

1. Не бойтесь ошибок — это лучший способ узнать что-то новое
2. Это очень важно для еженедельного обзора кода — с профессионалом
3. код на дому — это поможет вам быстрее совершенствоваться
4. читайте код других — открытый исходный код-лучший способ узнать что-то новое

Мой единственный совет, который еще не был упомянут и который помогает мне регулярно, заключается в следующем: прежде чем я внесу какие-либо существенные изменения, будь то код или документация, я всегда сделаю 10-15-минутный перерыв, прежде чем фактически завершить изменение. Обычно перерыв позволит мне вернуться обновленным и, что более важно, не так сильно инвестированным в перемены, и большинство моих улучшений из — за этого становятся очевидными. Это обычно более полезно, когда вы единственный человек, работающий над чем-то, в противном случае вы можете просто получить экспертную оценку, которая, как правило, выше.

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

Мы все совершаем глупые ошибки, потому что мы люди.

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

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

Практика — чем больше кода вы напишете, тем больше опыта приобретете

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

Защитное кодирование — сведите к минимуму создание рискованного кода, избегайте влияния граничных условий

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

Мы все совершаем ошибки. Гении-это те, кто просто держит их на разделочной доске.

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

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

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

если фред==билл досометингтофред() еще досометингтобилл();

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

если (Фред==билл) {
 дозометингтобилла();
}
еще {
dosomethingtofred();
}

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

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

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

Я верю в простую вещь.

Код один раз, код правильный.

И чтобы получить это (в любом случае для меня), мне нужно полностью мысленно визуализировать проблему, прежде чем что-либо делать. Если я не совсем понимаю проблему, я очень не решаюсь продолжать.

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