Ошибки при написании кода

Научитесь выявлять их. Выработайте привычки избегать их.

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

От переводчика

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

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

1) Программирование без планирования
2) Чрезмерное планирование
3) Недооценивание важности качества кода
4) Хвататься за первое решение
5) Не отступать
6) Не гуглить
7) Не использовать инкапсуляцию
8) Планирование неизвестного
9) Использование неподходящих структур данных
10) Ухудшать код
11) Комментирование очевидных вещей
12) Не писать тесты
13) Думать, если что-то работает, то это правильно сделано
14) Не подвергать сомнению существующий код
15) Одержимость лучшими практиками
16) Одержимость производительностью
17) Не ориентироваться на конечного пользователя
18) Не подбирать правильные инструменты
19) Непонимание, что проблемы с кодом вызывают проблемы с данными
20) Изобретение колеса
21) Неправильное отношение к инспекции кода (code review)
22) Не использование систем контроля версий
23) Злоупотребление общим состоянием (shared state)
24) Неправильное отношение к ошибкам
25) Не отдыхать

1) Программирование без планирования

Качественный контент не создаётся “на коленке”, а требует основательной работы. Программный код – не исключение.

Хороший код должен проходить через следующие стадии:

Замысел. Исследование. Планирование. Написание. Проверка. Изменение.

Каждому из этих пунктов надо уделить достаточно усилий.

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

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

“Если ты зол, сосчитай до 10, прежде чем говорить. Если очень зол — то до 100”. (Томас Джефферсон)

Для нашего случая это можно перефразировать так:

“Когда проверяешь код, сосчитай до 10 прежде чем переписать 1 строчку. Если для этого кода нет тестов — то до 100”.

Программирование – это на 90% изучение существующего кода и его изменение посредством маленьких, легко тестируемых порций, вписывающихся в общую систему. Само написание кода это всего лишь 10% работы программиста.

Программирование – это не просто написание строк кода, а творчество, основанное на логике, которое надо развивать в себе.

2) Чрезмерное планирование

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

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

Линейное планирование всей программы “от А до Я” (водопадным методом) – не годится для большинства программных продуктов. Разработка подразумевает обратную связь и вы постоянно будете удалять и добавлять функционал, что никак нельзя учесть в «водопадном планировании». Планировать следует несколько следующих элементов. И каждый новый надо включать в план лишь после гибкой адаптации к реальности (Agile).

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

3) Недооценивание важности качества кода

Если при написании кода вы можете сосредоточиться только на одной вещи, то это должна быть читабельность. Непонятный нечитабельный код это не просто мусор, а мусор, не подлежащий переработке.

Смотрите на программу как на составные части, общающиеся посредством кода. Плохой код — это плохая коммуникация.

“Пишите свой код так, будто его будет сопровождать агрессивный психопат, знающий, где вы живете”. (Джон Вудс)

Важны даже “мелочи”. Если вы бессистемно используете заглавные буквы и отступы, то у вас нужно отобрать лицензию программиста.

tHIS is
  WAY MORE important
than
         you think

Не используйте длинные строки. Строку длиннее 80 символов очень трудно читать. Используйте специальные инструменты для приведения кода в порядок (ESLint, Prettier для js).

Следите за количеством строк в функциях и файлах. Разделяйте код на мелкие части, понятные и тестируемые. Функция больше 10 строк – слишком длинная.

Не используйте двойное отрицание. Не не не делайте так. Это очень не не плохо.

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

“В компьютерных науках есть только две по настоящему сложные вещи: инвалидация кэша и именование переменных”. (Фил Карлтон)

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

const monthsInYear = 12; 

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

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

“Измерять программирование строками кода, это то же самое, что измерять авиастроительство тоннажем произведенных самолетов”. (Билл Гейтс)

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

4) Хвататься за первое решение

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

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

“Есть два пути написания программы: 1) сделать её настолько простой, что в ней, очевидно, не будет недостатков; 2) сделать её настолько сложной, что в ней никакие недостатки не будут очевидными”. (Тони Хоар)

5) Не отступать

Другая частая ошибка новичков – не отступать. Даже когда они поняли, что выбранное решение не самое лучшее. Подход “не сдаваться” хорош во многих сферах, но не в программировании. Программистам полезно признавать ошибки раньше и чаще. Как только вы засомневались в решении – отбросьте его и переосмыслите проблему. Не важно, сколько вы уже вложили в этот путь. Системы контроля версий типа Git позволяют создавать ветки и экспериментировать с разными решениями, активно пользуйтесь этим.

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

6) Не гуглить

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

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

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

Не будьте креативным в понятиях Брета Виктора, который сказал:

“Думать, что ты знаешь, что делаешь – самая опасная мысль креативного человека”.

7) Не использовать инкапсуляцию

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

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

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

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

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

Стремитесь к тому, чтобы ваш код имел высокое зацепление и низкую связанность (High Cohesion and Low Coupling). Этот загадочный термин означает, что внутри класса должно быть максимально связей, а между классами – минимально зависимостей.

8) Планирование неизвестного

Когда вы пишете новую строчку кода, порой в голову лезут мысли: “а что если…” И вы начинаете фантазировать о разных новых фичах, которыми можно украсить программу. В большинстве случаев такие мысли вредны и не стоит на них ориентироваться.

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

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

“Рост ради роста — это идеология раковой клетки”. (Эдвард Эбби)

9) Использование неподходящих структур данных

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

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

Неуместно использованная структура данных это кричащее предупреждение: “код новичка!”. Вот несколько примеров.

Обычный массив или ассоциативный?

Самая распространённая ошибка – это использование обычных массивов вместо ассоциативных для хранения списка записей.

Обычный массив:

[{id: 1, title: "entry1"}, {id: 2, title:"entry2"}, .... ]

Ассоциативный массив:

{ 1: {id: 1, title: "entry1"}, 2: {id: 2, title:"entry2"}, ....}

Да, вы не ослышались, для хранения списка записей нужно использовать ассоциативные массивы. Под списком записей я подразумеваю такие записи, где присутствует идентификатор. Массивы оправданы для хранения скалярных величин и если планируется активное использование методов, вроде push, pop, shift, unshift, которые обращаются к записям не через ключ, а через порядок в списке.

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

Стек или рекурсия?

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

Но вместо рекурсии можно использовать такую структуру данных как стек. Помещайте вызовы функций в стек и затем извлекайте их, когда подойдёт очередь.

10) Ухудшать код

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

Вот несколько распространенных ошибок, приводящих к беспорядку в коде:

Дублирование

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

Не использование файла конфигурации

В файл конфигурации обязательно надо помещать те величины, которые:
могут меняться в зависимости от окружения
встречаются в разных местах кода
Каждый раз, когда вы вводите в код новую величину, спрашивайте себя: “может быть её поместить в файл конфигурации?” И ответ будет почти всегда “да”.

Лишние условные операторы и временные переменные

Любой if разветвляет логику вашей программы, поэтому их наличие должно быть сведено к минимуму, насколько это возможно без вреда для читабельности. Самое сложное – определить правильный уровень для изменений: будете вы расширять текущий код или вынесете его во внешнюю функцию и вызовете её?

Вот яркий пример ненужного if:

function isOdd(number) {
 if (number % 2 === 1) {
   return true;
 } else {
   return false;
 }
}

Его можно переписать без единого if:

function isOdd(number) {
 return (number % 2 === 1);
};

11) Комментирование очевидных вещей

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

Например, такой код:

// This function sums only odd numbers in an array
const sum = (val) => {
  return val.reduce((a, b) => {
    if (b % 2 === 1) { // If the current number is odd
      a+=b;            // Add current number to accumulator
    }
    return a;          // The accumulator
  }, 0);
};

Можно заменить таким:

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (isOdd(currentNumber)) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  }, 0);
};

Но иногда прояснить код можно только комментарием. В таком случае сосредоточьтесь на вопросе: “ЗАЧЕМ нужен этот код”, а не “ЧТО делает этот код”. Вот пример кода, где комментарии только засоряют код:

// create a variable and initialize it to 0
let sum = 0;
// Loop over array
array.forEach(
  // For each number in the array
  (number) => {
    // Add the current number to the sum variable
    sum += number;
  }
);

Не делайте так, если вы программист. А если вы работодатель таких программистов — увольте их прямо сейчас.

12) Не писать тесты

Если вы считаете себя экспертом в программировании, который не нуждается в написании тестов для своего кода, то вы – новичок.

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

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

Если можете, создавайте проверки даже прежде самого кода. Разработка через тестирование (test-driven development, TDD) создана не для прикола и хайпа. Она благотворно влияет на то, как вы продумываете, проектируете и реализуете программные элементы.

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

13) Думать, если что-то работает, то это правильно сделано

Взгляните на эту функцию, которая суммирует нечетные числа. Всё ли там правильно?

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (currentNumber % 2 === 1) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  });
};
 
 
console.assert(
  sumOddValues([1, 2, 3, 4, 5]) === 9
);

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

Проблема 1

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

TypeError: Cannot read property 'reduce' of undefined.

И это признак плохого кода по двум главным причинам:
Пользователи вашей функции не должны сталкиваться с деталями её реализации.
Сообщение об ошибке не информативно.

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

TypeError: Cannot execute function for empty list.

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

Проблема 2

Нет валидации. Что если в функцию передадут вместо массива строку, число или объект? Вот что произойдет:

sumOddValues(42);
TypeError: array.reduce is not a function

Подвох в этой ситуации в том, что array.reduce — это как раз функция. Но так как вы назвали аргумент функции array (массив), то что бы вы не передали ей (в данном примере это 42), будет названо массивом внутри функции. На самом деле ошибка говорит о том, что 42.reduce — это не функция. Не лучше ли сделать вывод ошибки в виде:

ОшибкаТипа: 42 - это не массив, чувак. 

Проблемы 1 и 2 описывают стандартные исключения, которые легко предусмотреть. Но бывают и менее очевидные исключения, с которыми надо быть внимательнее. Например, что произойдёт, если в массиве будут отрицательные числа?

sumOddValues([1, 2, 3, 4, 5, -13]) // => still 9

Следует ли программе воспринимать -13 как нечётное число? Или игнорировать? Или выдать ошибку? Может следует переименовать функцию в “сумма положительных нечётных чисел”? Вы легко выберете нужный вам вариант. Но самое интересное здесь то, что если вы не пишите тесты, документирующие работу вашей функции, то те, кто будут их сопровождать, даже не смогут понять, баг ли это или преднамеренное допущение.

“Это не баг. Это задуманный функционал” — удобная отмазка тех, кто не пишет тестов.

Проблема 3

Не все валидные случаи правильно работают. Забудьте разные каверзные исключения. Эта функция неправильно работает и с вполне обыденным набором переменных.

sumOddValues([2, 1, 3, 4, 5]) // => 11

В данном примере 2 попадёт в сумму, хотя не должна. Это произойдёт потому, что в функцию reduce не передано initialValue, и поэтому в качестве исходного значения будет взят первый элемент массива. Поэтому важно написать тест и для такого случая. Если такого нет, то это ещё один признак кода новичка.

14) Не подвергать сомнению существующий код

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

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

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

Новичкам можно посоветовать такое правило: любой недокументированный код, который вы не понимаете — возможно, плохой. Изучайте его. Спрашивайте о нём. Пользуйтесь командой git blame, выдающей автора каждой строки кода.

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

15) Одержимость лучшими практиками

Термин “лучшие практики” вредный, он ограничивает вас в исследовании, «ведь уже есть лучшая практика».

“Лучших практик” не бывает. Бывают хорошие практики на сегодняшний день и для этого языка программирования.

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

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

16) Одержимость производительностью

“Преждевременная оптимизация – это корень всех зол в программировании (или почти всех)”. Дональд Кнут, 1974

Хотя программирование существенно изменилось со времен Дональда Кнута, его совет актуален и в наши дни.

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

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

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

17) Не ориентироваться на конечного пользователя

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

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

18) Не подбирать правильные инструменты

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

Ориентироваться на популярность инструмента, а не пригодность для конкретной задачи – признак новичка.

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

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

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

19) Непонимание, что проблемы с кодом вызывают проблемы с данными

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

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

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

Как защитить себя от такого? Можно использовать несколько уровней валидации: на фронтенде, бекенде, при передаче и в базе данных (БД). Как минимум, используйте встроенные ограничения в БД.

Хорошо знайте все типы ограничений в БД и используйте их все при создании новых столбцов и таблиц.

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

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

CHECK проверяет произвольное выражение, например, для процентов нужно проверять вхождение в интервал от 0 до 100.

PRIMARY KEY подразумевает одновременно уникальность и не пустое значение. Каждая таблица базы данных должна иметь такое поле для идентификации записей.

FOREIGN KEY говорит о том, что величины этого столбца содержатся в другой таблице.

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

20) Изобретение колеса

В программировании зачастую полезно переизобретать колёса. Это довольно гибкая и стремительно меняющаяся сфера знаний. Никакая команда не может угнаться за всеми обновлениями и новыми требованиями.

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

Иногда бывает сложно выбрать нужное колесо из-за многообразия. Проводите исследование. Пробуйте перед покупкой. Большинство “программных колёс” бесплатны и с открытым кодом. По возможности используйте заготовки с открытым исходным кодом (open source), их легко отлаживать, улучшать, заменять и поддерживать.

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

21) Неправильное отношение к инспекции кода (code review)

Один из признаков новичков, это восприятие инспекций кода как критицизма. Они не любят их, не ценят и даже боятся.

Это в корне неправильное отношение надо как можно быстрее изменить. Смотрите на каждую инспекцию кода как на ценную возможность обучения. Любите и цените их. Учитесь посредством них. И благодарите делающих замечания.

Надо принять тот факт, что программист – это вечный ученик, а инспекция кода – это одна из форм обучения.

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

22) Не использование систем контроля версий (Git)

Новички склонны недооценивать пользу хорошей системы контроля версий/кода, вроде Git.

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

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

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

Ещё одно предназначение системы контроля версий – понятность предназначения той или иной вещи. Допустим, вы столкнулись с функцией и вам надо понять её назначение и устройство. Вы можете найти коммит, в котором она появилась, и перед вами возникнет контекст её создания, что прольёт свет на всё остальное, связанное с ней.

Система контроля версий может даже помочь обнаружить баг, а именно, ту строку кода, с добавления которой программа дала сбой. В Гите есть бинарный поиск bisect, обнаруживающий коммит, внёсший баг.

Систему контроля можно использовать в разных целях, даже до того, как изменения кода превратились в официальные коммиты:

• отслеживание изменений (staging changes)
• выборочный патч (patching selectively)
• сброс (resetting)
• прятание (stashing)
• перезапись истории (amending)
• применение (applying)
• просмотр изменений (diffing)
• отмена коммитов (reversing)

Изучите все эти возможности, поймите, используйте и цените их. Чем меньше возможностей Git вы знаете, тем больше вы новичок.

23) Злоупотребление общим состоянием (shared state)

И снова это не про сравнение парадигмы функционального программирования с остальными.

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

Большая проблема общего состояния начинается тогда, когда несколько ресурсов меняют его в рамках одной итерации цикла событий (в событийно ориентированных средах). Возникает состояние гонки (Race conditions). И новички склонны решать эту проблему посредством таймера, особенно при блокировке данных. Это большой красный флаг. Избегайте этого. Ни в коем случае нельзя писать такой код или принимать его.

24) Неправильное отношение к ошибкам

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

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

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

25) Не отдыхать

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

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

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

Работа с необъявленными переменными

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

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

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

Инициализация переменных без начального значения

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

Приведем пример такого кода:

[code]int num1, num2;
int sum = num1 + num2;
cout << «Введите два числа для суммирования: «;
cin >> num1;
cin >> num2;
cout << «Сумма = » << sum;[/code]

В результате его исполнения вы можете ввести, например, числа 2 и 5, а в качестве результата получить 2384.

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

Необъявленные функции

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

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

Переполнение типа

Иногда бывает, что код выглядит логично, а программа вылетает по ошибке из-за проблем с выделением объемов памяти для того или иного типа переменной.

Приведем пример на C++:

[code]A = B + C;
char* G = new char[A];[/code]

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

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

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

Переполнение буфера

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

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

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

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

Ошибки в оценке границ массива

Бытует мнение, что такую ошибку можно допустить только в C или C++. На самом деле, обращение к несуществующему элементу массива возможно в Python, Java и многих других языках. Суть проблемы заключается в том, что программист по причине невнимательности или из-за ошибки в расчетах обращается к элементу массива с несуществующим номером.

Самый просто пример:

1. Вы определили массив из 10 элементов.
2. Нумерация в массиве начинается с нуля, т.е. существуют номера с 0 до 9.
3. Вы забываете об этой особенности массива и обращаетесь к элементу с индексом 10.

При этом программа обращается к неиспользуемой области памяти, присваивает это случайное значение элементу с индексом 10. Результат обработки «мусорной» информации, само собой, непредсказуем.

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

«Забытые» ограничения ресурсов

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

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

Аккуратно относитесь к ограничителям массивов, проверяйте базы данные при слиянии, а при прямом обращении к ОЗУ обязательно указывайте граничные значения.

Обращение к освобожденной памяти

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

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

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

Инъекции SQL и команд ОС

Эти два типа инъекций на самом деле являются хакерскими атаками, которые оканчиваются доступом злоумышленника либо к базам данных (SQL), либо к root-доступу на компьютере пользователя.

Причины SQL-инъекций – низкий уровень защиты сайта. Чаще всего, их проводят через отправку сообщений от пользователей (форма обратной связи, добавление записи на форум, обращение в чат и т.д.). Если «дыра» в безопасности не закрыта, злоумышленник отправляет через эти формы вредоносный код, сервер начинает его исполнять. И хакер получает доступ ко всем базам данных.

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

Рискованные алгоритмы

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

С первым случаем все понятно. Защита данных – не та область, где стоит полагаться только на свои, довольно скромные возможности. Пример второго случая – использование алгоритма хэштегирования SHA-1. Если вы воспользуетесь поиском, то очень быстро узнаете, что этот алгоритм уже устарел, в нем найдено множество уязвимостей, под которые написан не один вирус. А потому лучше пользоваться SHA-2 или SHA-3.

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

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

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

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

 

Распространенные типы ошибок в программе и в программировании у новичков

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

 

Программирование без четкого плана

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

• идея;

• исследование идеи;

• планирование;

• кодинг;

• проверка кода;

• внесение изменений после проверки.

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

 

Излишнее планирование

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

В общем, к планированию нужно подходить со всей ответственностью, но и с осторожностью.

 

Недооценка важности качества кодинга

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

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

 

Любая проблема решается первым решением

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

 

Никогда не отступлю

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

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

 

Не пользоваться Гуглом

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

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

С другой стороны, распространенная проблема Гугла и новичка — это бездумное копирование кода. Многие новички копируют его, даже не пытаясь понять, для чего он нужен.

 

Фантазии и работа

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

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

 

Ухудшение кода

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

Всегда нужно делать «порядок» в том месте, где планируете работать.

 

Излишнее комментирование

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

 

Зачем писать тесты

Если программист задает такой вопрос, то, скорее всего, он новичок. Отличительная черта многих новичков — не писать тесты.

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

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

 

Если код работает, то он правильный

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

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

 

«Лучшая практика»

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

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

 

Преждевременная оптимизация

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

 

Ориентация на пользователя

Многие молодые программисты, прежде чем что-то добавить в свою разработку, думают в первую очередь о себе: чтобы это было просто и легко. А нужно смотреть на свою разработку глазами конечного пользователя. Нужно ли ему то, что вы хотите добавить? А будет ли ему удобно пользоваться именно таким функционалом?

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

 

Отношение к ошибкам

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

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

 

Отсутствие отдыха

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

 

Заключение

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

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

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

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

3. Недооценка загруженности. Оценка рабочей нагрузки — одна из самых сложных задач при разработке программного обеспечения. Как часто вы слышали “Я мог бы легко реализовать эту функцию в одном спринте”? Скорее всего все не так просто, и предполагаемое решение не сработает. Когда дело доходит до оценок, убедитесь, что вы учитываете время и на такие вещи, как тестирование, а не только на разработчика.

4. Написание очевидных комментариев. Мы все видели подобные комментарии раньше. Они ничего не объясняют, но сосредотачиваются на том, что делает код (например, комментарий типа «цикл по продуктам», когда есть цикл foreach). Когда бы вы ни оказались в такой ситуации, не пишите комментарий, посвященный тому, что делает код. Вместо этого сосредоточьтесь на том, зачем этот код написан.

5. Закомменченные блоки кода. Мы все видели целые закомментированные блоки кода, содержащие несколько функций. Никто не знает, почему этот блок кода все еще существует и актуален ли он. Причина, по которой никто не удаляет этот блок кода, состоит в том, что все предполагают, что он может понадобиться кому-то другому. Просто удалите закомментированный блок кода. Если окажется, что код по-прежнему нужен, он будет в системе контроля версий.

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

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

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

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

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

11. Плохие сообщения при коммите. Мы, наверное, все это уже совершали раньше. «Исправлена ​​ошибка» или «WIP» — не очень хорошие сообщения в коммите. Важно писать правильные сообщения, и вы должны найти время для этого. Хорошее сообщение содержит полезную информацию о том, что изменилось и почему. Когда дела идут плохо, история изменений — отличный ресурс, чтобы быстро узнать, где именно что-то пошло не так.

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

13. Слишком много всего происходит в одной функции. Нужно позволить своим функциям делать одно и только одно. Не позволяйте функции извлекать, обрабатывать и выводить данные. Разделите все эти обязанности на разные функции. Одна для получения данных, одна для обработки и еще одна для вывода. Сосредоточение функции на одной задаче — вот что делает ее более надежной.

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

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

Источник

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.

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

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

1. Повторяющийся код

Не повторяйте себя — это один из основных принципов программирования. что вы встретите, как вы узнаете. Это часто сокращается до СУХОГО, и код, который написан с использованием этого принципа, называется СУХОЙ код.

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

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

2. Неверные имена переменных

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

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

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

let rate = 0.1; 

Все, что мы действительно знаем об этой переменной, это то, что это показатель. Какой тариф?

Код будет работать просто отлично, но сложно сказать, что здесь происходит.

  let interestRate = 0.1; 

Programming… Where counting starts from 0 not 1. If you are not in programming and you will be pointing this a mistake made by a programmer then be ready to see a sarcastic angry young man look of a programmer throwing a paper or stone at yourself. Programming is one of the funniest (We have already given example), hardest (If you don’t enjoy coding) and easiest (If you love to play with code) thing to do in the world. A semicolon, a bracket, a loop and a lot of small and big things matter a lot in coding and you might have definitely experienced your silly mistakes especially in the initial phase-in programming.
Mistakes are part of coding and every programmer makes tonnes of mistakes especially as a beginner but that’s how they grow and become a good developer. We are going to discuss some most common mistakes that programmers make during the initial phase of coding but these are not limited. It’s good to be aware of these mistakes and not to do the same while learning to code…

1. Learning Too Many Programming Languages, Frameworks, and Technology

This is one of the common mistakes that most of beginners make when they start learning to code. They think that it’s impressive to have Java, C++, Python and a lot of more language, frameworks or technology to showcase to someone or to mention in the resume but that’s actually foolishness not the sign of intelligence if you don’t have command or in-depth knowledge in any one of them.
Learning Java for 15 days and switching to Ruby just because java is tough or there is another reason then you will eventually end up with lots of confusion. It’s good to have knowledge of multiple languages but we highly recommend you to focus on a single language, in the beginning. Once you are experienced you won’t face difficulty in switching to another language. If you do this mistake then after a couple of years you will realize you aren’t master in any single language.

2. Comparison, Self Doubt, And Fear

It’s human nature to compare ourselves with others all the time, that’s the case in programming as well. You see a talented programmer who is good at solving the problems and making things work too fast, you start doubting and questioning your capability which is not good. Some people are good at picking up the concept very easily and some people take time but slow learning is completely ok if you take interest in coding.
Programming might be scary for you sometimes and beginners go through the phase when a voice in the head always say ‘I am not smart enough to solve the problem‘, ‘I have a wrong type of brain’ and a lot of things make them feel insecure and make them realize that they are not capable enough to code. When you have self-doubt on yourself always remember that you need to face it with courage and you need to be fearless. Programming is the field of taking the challenge and helping others by solving their problems but before that do yourself a favor and help yourself first.
Ask yourself…What can I do to become a better programmer? What are the areas I should improve on?. Identify your strength be thankful for it, identify your weakness and work on that by taking help from others, watching tutorials or joining a programming community.

3. Writing Messy Code And Ignoring Code Quality

An experienced programmer can easily spot a beginner looking at their code format. Some of the mistakes that beginners make in formatting code are

• No proper indentation in code
• Inconsistent use of new lines and white space or putting everything in a single line
• Writing function that is too big or putting everything in a single line, function or file.
• Bad variables and functions name(Ex. name of variable or function AbshdhhDdhjdjdXyshdb doesn’t make any sense). They use small case and large case variable names randomly.
• Not commenting or over commenting the code

The above points are not limited, there are a lot of other mistakes that beginners make while writing the code. As a beginner, it’s good and exciting that your code is running and giving the desired output but what if you handover this messy code to someone else and he/she needs to maintain or continue it, it will become annoying for that person. He/she would face difficulty in understanding your code, loops or conditionals in it. Programming is not about just writing code and making it work, your code should be clean, readable and maintainable as well so always try to write well-structured code.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-Martin Golding

4. Writing Code Without Plan

A lot of beginners in excitement skip the thinking, research, and planning stages of a project and start writing code right away. They do not understand the problem requirements, limitations and do not think about all the case scenarios (what’s the input and what should be the output etc). It can create a big issue and later you may regret it. We highly recommend every beginner that just like before saying anything to someone you should think so you don’t regret later, you should also think and research before you start writing code. In programming, developers spend only 10% of the time writing code. Rest of the time they think, plan, research and discuss the complete project.
A beginner should go with the flow in a sequence of Think, Research, Plan, Write, Validate and Modify so they should follow some basic things before writing the code to avoid any issue or disaster at the production level.

• Understand the problem requirements and limitation.
• Do some research and experiment to find out which data structure is good to solve the problem. Pick up the best one.
• Design the program and make a rough working draft.
• Pick up the right data structure for your problem.
• Think and note down all the corner cases for testing.
• Break the problems into solvable pieces.

5. Thinking You Know It All

It’s really an exciting and amazing feeling for beginners when their code starts running without any bug. Afterall they put so much effort into learning to code and finally they have successfully written a program that actually works. You enjoy coding, your confidence grows and maybe you also start teaching stuff to others. It’s actually pleasurable feeling that you have learned a lot of stuff but what if we say to explore some more complex projects made by top-notch programmers on Github or just take a look at your own code you have written a couple of months back. You will understand that it still needs some modification and your code can be refactored as well. This happens with the experienced programmer as well.
Always remember programming is a marathon where there is no end line. Every day new technology, frameworks and a lot of things are coming out in the world, so there is no end of learning the coding stuff. Do not underestimate your ability but do not overestimate your ability as well. Keep your feet on the ground, explore more complex stuff in programming and keep learning. If you will hang out with some great experienced programmer you will find they don’t carry ‘I know everything attitude’ with themselves, they keep learning and they keep exploring the things even after spending years in programming.

6. No Backup For Work

This is one of the blunder mistakes any programmer can make especially as a beginner. Think about a situation when you have put so much effort in making a project and after two weeks you find that the disk crashed in your system where all your files were saved, you have also lost your work. In development, there is no one who is going to listen that you have lost X-amount of work just because your system or a part of the system got crashed. You can’t give any excuse in this case and that’s the reason every beginner or programmer should have this habit to keep backup of their work at regular intervals.
Learn to use source control (SVN or Git), Github or you can also take the help of Dropbox which is a cloud service to save your work in no time.

7. Laziness in Doing Practice

There is no point to read thousand of lines of code if you don’t get your hands dirty in programming. There is a huge difference between reading the coding stuff theoretically and doing things practically. Practicing the actual code should never be neglected in programming. It’s easy to read some lines of code or watch some videos for learning then telling your brain that you understood everything but once you will start writing the code you will find that you are making a lot of silly and big mistakes.
In the beginning, you will be a missing semicolon, braces and you will face difficulty in writing a loop as well but to get rid of all these things all you just need to do is to try your hands on code, keep practicing it, catching some errors, debugging those errors and then finding out how all the small pieces come together.

Programming is a skill acquired by practice and example rather than from books.
-Alan Turing

Programming… Where counting starts from 0 not 1. If you are not in programming and you will be pointing this a mistake made by a programmer then be ready to see a sarcastic angry young man look of a programmer throwing a paper or stone at yourself. Programming is one of the funniest (We have already given example), hardest (If you don’t enjoy coding) and easiest (If you love to play with code) thing to do in the world. A semicolon, a bracket, a loop and a lot of small and big things matter a lot in coding and you might have definitely experienced your silly mistakes especially in the initial phase-in programming.
Mistakes are part of coding and every programmer makes tonnes of mistakes especially as a beginner but that’s how they grow and become a good developer. We are going to discuss some most common mistakes that programmers make during the initial phase of coding but these are not limited. It’s good to be aware of these mistakes and not to do the same while learning to code…

1. Learning Too Many Programming Languages, Frameworks, and Technology

This is one of the common mistakes that most of beginners make when they start learning to code. They think that it’s impressive to have Java, C++, Python and a lot of more language, frameworks or technology to showcase to someone or to mention in the resume but that’s actually foolishness not the sign of intelligence if you don’t have command or in-depth knowledge in any one of them.
Learning Java for 15 days and switching to Ruby just because java is tough or there is another reason then you will eventually end up with lots of confusion. It’s good to have knowledge of multiple languages but we highly recommend you to focus on a single language, in the beginning. Once you are experienced you won’t face difficulty in switching to another language. If you do this mistake then after a couple of years you will realize you aren’t master in any single language.

2. Comparison, Self Doubt, And Fear

It’s human nature to compare ourselves with others all the time, that’s the case in programming as well. You see a talented programmer who is good at solving the problems and making things work too fast, you start doubting and questioning your capability which is not good. Some people are good at picking up the concept very easily and some people take time but slow learning is completely ok if you take interest in coding.
Programming might be scary for you sometimes and beginners go through the phase when a voice in the head always say ‘I am not smart enough to solve the problem‘, ‘I have a wrong type of brain’ and a lot of things make them feel insecure and make them realize that they are not capable enough to code. When you have self-doubt on yourself always remember that you need to face it with courage and you need to be fearless. Programming is the field of taking the challenge and helping others by solving their problems but before that do yourself a favor and help yourself first.
Ask yourself…What can I do to become a better programmer? What are the areas I should improve on?. Identify your strength be thankful for it, identify your weakness and work on that by taking help from others, watching tutorials or joining a programming community.

3. Writing Messy Code And Ignoring Code Quality

An experienced programmer can easily spot a beginner looking at their code format. Some of the mistakes that beginners make in formatting code are

• No proper indentation in code
• Inconsistent use of new lines and white space or putting everything in a single line
• Writing function that is too big or putting everything in a single line, function or file.
• Bad variables and functions name(Ex. name of variable or function AbshdhhDdhjdjdXyshdb doesn’t make any sense). They use small case and large case variable names randomly.
• Not commenting or over commenting the code

The above points are not limited, there are a lot of other mistakes that beginners make while writing the code. As a beginner, it’s good and exciting that your code is running and giving the desired output but what if you handover this messy code to someone else and he/she needs to maintain or continue it, it will become annoying for that person. He/she would face difficulty in understanding your code, loops or conditionals in it. Programming is not about just writing code and making it work, your code should be clean, readable and maintainable as well so always try to write well-structured code.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-Martin Golding

4. Writing Code Without Plan

A lot of beginners in excitement skip the thinking, research, and planning stages of a project and start writing code right away. They do not understand the problem requirements, limitations and do not think about all the case scenarios (what’s the input and what should be the output etc). It can create a big issue and later you may regret it. We highly recommend every beginner that just like before saying anything to someone you should think so you don’t regret later, you should also think and research before you start writing code. In programming, developers spend only 10% of the time writing code. Rest of the time they think, plan, research and discuss the complete project.
A beginner should go with the flow in a sequence of Think, Research, Plan, Write, Validate and Modify so they should follow some basic things before writing the code to avoid any issue or disaster at the production level.

• Understand the problem requirements and limitation.
• Do some research and experiment to find out which data structure is good to solve the problem. Pick up the best one.
• Design the program and make a rough working draft.
• Pick up the right data structure for your problem.
• Think and note down all the corner cases for testing.
• Break the problems into solvable pieces.

5. Thinking You Know It All

It’s really an exciting and amazing feeling for beginners when their code starts running without any bug. Afterall they put so much effort into learning to code and finally they have successfully written a program that actually works. You enjoy coding, your confidence grows and maybe you also start teaching stuff to others. It’s actually pleasurable feeling that you have learned a lot of stuff but what if we say to explore some more complex projects made by top-notch programmers on Github or just take a look at your own code you have written a couple of months back. You will understand that it still needs some modification and your code can be refactored as well. This happens with the experienced programmer as well.
Always remember programming is a marathon where there is no end line. Every day new technology, frameworks and a lot of things are coming out in the world, so there is no end of learning the coding stuff. Do not underestimate your ability but do not overestimate your ability as well. Keep your feet on the ground, explore more complex stuff in programming and keep learning. If you will hang out with some great experienced programmer you will find they don’t carry ‘I know everything attitude’ with themselves, they keep learning and they keep exploring the things even after spending years in programming.

6. No Backup For Work

This is one of the blunder mistakes any programmer can make especially as a beginner. Think about a situation when you have put so much effort in making a project and after two weeks you find that the disk crashed in your system where all your files were saved, you have also lost your work. In development, there is no one who is going to listen that you have lost X-amount of work just because your system or a part of the system got crashed. You can’t give any excuse in this case and that’s the reason every beginner or programmer should have this habit to keep backup of their work at regular intervals.
Learn to use source control (SVN or Git), Github or you can also take the help of Dropbox which is a cloud service to save your work in no time.

7. Laziness in Doing Practice

There is no point to read thousand of lines of code if you don’t get your hands dirty in programming. There is a huge difference between reading the coding stuff theoretically and doing things practically. Practicing the actual code should never be neglected in programming. It’s easy to read some lines of code or watch some videos for learning then telling your brain that you understood everything but once you will start writing the code you will find that you are making a lot of silly and big mistakes.
In the beginning, you will be a missing semicolon, braces and you will face difficulty in writing a loop as well but to get rid of all these things all you just need to do is to try your hands on code, keep practicing it, catching some errors, debugging those errors and then finding out how all the small pieces come together.

Programming is a skill acquired by practice and example rather than from books.
-Alan Turing