Ошибки начинающего программиста

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

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

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

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

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

1) Программирование без планирования
2) Чрезмерное планирование
3) Недооценивание важности качества кода
4) Хвататься за первое решение
5) Не отступать
6) Не гуглить
7) Не использовать инкапсуляцию
Планирование неизвестного
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). Этот загадочный термин означает, что внутри класса должно быть максимально связей, а между классами – минимально зависимостей.

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

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

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

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

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

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) Не отдыхать

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

Введение

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

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

1. Не ограничивайтесь одним языком

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

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

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

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

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

2. Идите своим путем

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

Индийский предприниматель и эксперт в области технологий Навин Джайн считает: “Самая большая ошибка новичков  —  это сравнение себя с другими. У каждого человека свой уникальный путь, поэтому сосредоточьтесь на собственном прогрессе”. Аналогичным образом Стив Джобс советовал: “Вы должны во что-то верить  —  в свое чутье, судьбу, жизнь, карму, что угодно. Такой подход никогда не подводил меня и изменил всю мою жизнь”.

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

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

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

3. Чистота, комментарии, отступы!

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

Как отмечает индийский инженер-программист и предприниматель Гириш Матрубутам, “хорошо отформатированный код легче читать, легче понимать и легче поддерживать”. А основатель ОС Linux Линус Торвальдс, считающий, что “хороший код  —  это лучшая его документация”, советует: “Собираясь добавить комментарий, спросите себя: “Как я могу улучшить код, чтобы этот комментарий не был нужен?”.

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

Новички могут воспользоваться рекомендациями, которые включают в себя PEP 8: Style Guide for Python (Руководство по форматированию кода на Python) и Google Java Style Guide (Руководство Google по форматированию кода на Java). Кроме того, такие инструменты, как линтеры и редакторы кода, помогут выявить и исправить ошибки форматирования в коде.

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

4. Следуйте соглашению о присвоении имен

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

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

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

Такие ресурсы, как Google Style Guides, содержат подробные указания по соглашениям об именовании, а также другие рекомендации по форматированию и стилю различных языков программирования. Кроме того, редакторы кода и IDE часто имеют функции, которые могут автоматически предлагать и применять соглашения об именовании.

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

5. Освойте выбранный язык досконально

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

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

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

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

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

6. Не используйте несовместимые технологии

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

Индийский инженер-программист Шиванш Видж советует: “Придерживайтесь одного технологического стека, пока не освоите его. Не совмещайте разные технологии только потому, что они кажутся крутыми и модными”. А Джефф Этвуд предупреждает: “Идеального кода не бывает. Каждая строчка кода  —  это потенциальная ошибка”.

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

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

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

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

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

7. Проводите отладку целенаправленно

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

Как советует индийский технический специалист Ритеш Агарвал, “всегда старайтесь понять первопричину проблемы, а не просто устранять симптомы”. Инженер-программист и автор учебников Джон Сонмез отмечает, что “отлаживая код, вы похожи на детектива в криминальном фильме, в котором вы же являетесь и убийцей”.

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

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

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

8. Тестируйте код

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

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

Как советует индийский инженер-программист Шубхам Бхартия, “тестируйте код как можно чаще и старайтесь сломать его всеми возможными способами”. Разработчик программного обеспечения и автор учебных пособий Кент Бек отмечает: “Если вы не тестируете, вы не разрабатываете программное обеспечение, вы просто печатаете”.

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

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

9. Используйте контроль версий

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

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

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

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

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

10. Ставьте реалистичные цели

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

Индийский предприниматель и основатель корпорации Zoho Шридхар Вембу советует: “Будьте терпеливы и ставьте перед собой достижимые цели. Как Рим не за один день был построен, так и вы не сразу приобретете навыки программирования”.

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

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

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

11. Победите свой страх

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

Марк Цукерберг однажды заметил: “Самый большой риск  —  это не рисковать. В мире, который меняется очень быстро, единственная стратегия, которая гарантированно провалится,  —  это не рисковать”.

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

Одним из средств для преодоления страха перед программированием может стать книга Роба Конери “Справочник самозванца” (“The Imposter’s Handbook”). В ней содержатся практические советы и рекомендации для программистов всех уровней по преодолению страха и совершенствованию своих навыков. Не менее полезными ресурсами являются онлайн-сообщества программистов, такие как Stack Overflow и GitHub, где новички могут общаться с опытными программистами для получения поддержки и рекомендаций.

12. Соблюдайте единый стиль регистра

Следование единому стилю регистра облегчает читаемость и сопровождаемость кода. К сожалению, несоблюдением этого правила грешат многие новички. Смешение различных стилей регистра (например, camelCase, PascalCase, snake_case) может привести к путанице и затруднить идентификацию переменных, функций и классов.

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

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

13. Пишите полезные комментарии

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

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

При комментировании кода рекомендуется следовать принципу KISS (Keep It Simple, Stupid  —  делай проще, тупица). Как сказал Стив Макконнелл, “хороший код  —  это его лучшая документация”, поэтому пишите код, который не требует пояснений и даже минимальных комментариев. Простой и лаконичный комментарий может сэкономить много времени и усилий на понимание кода.

Ресурсы, которые помогут усовершенствовать навыки комментирования,  —  это “Чистый код: Руководство по созданию гибкого программного обеспечения” Роберта К. Мартина и “Искусство создания читаемого кода” Дастина Босвелла и Тревора Фушера. В этих книгах содержатся практические советы по написанию удобочитаемого и сопровождаемого кода. Следование стандартам и практикам написания кода, таким как Javadoc и Doxygen, также поможет в написании полезных комментариев.

14. Делайте резервные копии своих работ

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

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

Начните регулярно создавать резервные копии своих работ. Можно использовать облачные решения для хранения данных, такие как Google Drive, Dropbox и OneDrive, которые предлагают бесплатное пространство для хранения файлов. Кроме того, можно применять программное обеспечение для контроля версий, например Git, чтобы отслеживать изменения, вносимые в код, и вести историю собственных проектов. Таким образом, вы обеспечите безопасность и доступность своих работ.

15. Никогда не переставайте учиться

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

Саймон Синек, американский писатель и мотивационный оратор, как-то заметил: “Единственный настоящий тест на лидерство  —  это то, насколько эффективно вы функционируете в условиях кризиса”. В контексте программирования это означает, что истинный личностный рост и лидерство проистекают из преодоления трудностей и готовности извлекать из них уроки. Индийский предприниматель Навин Джайн советует: “Никогда не переставайте учиться, потому что жизнь никогда не перестает учить”.

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

16. Освоение условного синтаксиса

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

Индийский технический предприниматель и инженер-программист Нитин Каматх советует: “Работая с условными операторами, потратьте время на то, чтобы понять синтаксис и логику, лежащую в их основе. Убедитесь, что четко понимаете, что вы проверяете и что хотите сделать, если условие истинно или ложно”.

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

17. Планируйте работу перед написанием кода

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

Здесь снова уместно вспомнить справедливое замечание Стива Макконнелла: “Хороший код  —  это его лучшая документация. Когда вы собираетесь добавить комментарий, спросите себя: “Как я могу улучшить код, чтобы этот комментарий не был нужен?”.

Эксперты советуют при планировании работы излагать требования проекта, ожидаемые результаты и стратегии реализации. Том Каргилл обращает внимание на то, что “на первые 90% кода приходится первые 90% времени разработки; оставшиеся 10% кода составляют остальные 90% времени разработки”.

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

Такие ресурсы, как “Чистый код: Руководство по созданию гибкого программного обеспечения” Роберта К. Мартина и “Завершенный код: Практическое руководство по созданию программного обеспечения” Стива Макконнелла, дадут вам больше информации о подготовке к написанию кода и других эффективных практиках разработки ПО.

18. Без практики не будет прогресса в обучении

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

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

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

Заключение

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

Читайте также:

• 11 шагов на пути к работе дата-сайентиста
• Худший враг программиста — долгосрочная актуальность
• Как повысить мотивацию с помощью поведенческой психологии

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи Sheriff Babu: Stop 18 Programming Mistakes!!!

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

1. Да зачем мне этот английский?
2. Консервация проблем
3. Гуглить — это долго: быстрее дёрнуть тимлида
4. Тесты? Не, не слышал
5. А давайте комментировать всё!
6. Забивать на ревью и рефакторинг
7. Минимум времени на общение с заказчиком
8. Git — просто странное слово
9. Игнорировать новые инструменты
10. Высыпаться? Куда высыпаться?

1. Да зачем мне этот английский?

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

try:
    1 / 0
except:
    print("You cannot divide by zero!")

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

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

Решились подтянуть английский? Держите нашу подборку бесплатных материалов и книг по английскому языку:

2. Консервация проблем

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

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

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

В обоих случаях поможет следующий подход:

1. Перед выполнением таска всегда составляйте план решения: так, обращаясь с вопросом, вы заочно продемонстрируете человеку, что готовились, а не просто сидели, сложа руки.
2. Пробегитесь по документации, потыкайте поиск и Stack Overflow.
3. Не помогло? Тогда как можно скорее просите более опытного коллегу о помощи. Чем дольше тянете, тем больше вопросов к вашему тайм-менеджменту.

3. Гуглить — это долго: быстрее дёрнуть тимлида

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

Держите мастер-класс для программиста «Как правильно гуглить»:

4. Тесты? Не, не слышал

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

Освойте методологию разработки TDD (test-driven development) — разработка через тестирование, которая основывается на повторении коротких циклов: написание теста, покрывающего изменения, а затем написание самого кода, который это реализовывает. Хотя TDD подходит не любому проекту, понимание и практика лишними не будут.

5. А давайте комментировать всё!

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

Пример так себе названий:

// Эта функция суммирует только нечётные числа в массиве
const sum = (val) => {
  return val.reduce((a, b) => {
    if (b % 2 === 1) { // Если текущее число нечётное,
      a+=b;            // добавляем это число
    }
    return a;          // Возвращаем результат
  }, 0);
};

И вот что будет, если называть переменные нормально:

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

6. Забивать на ревью и рефакторинг

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

Код должен быть вычищен от:

• дублей;
• временных переменных;
• лишних условий;
• избыточных комментариев.

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

7. Минимум времени на общение с заказчиком

Как же раздражает, когда менеджер проекта просит во всех подробностях расписать план действий по таску, правда? Ведь клиент тратит ваше драгоценное время: достаточно ответить «Yes, of course», и с места в карьер. Правильно?

А вот и нет: это очередная ошибка начинающего разработчика. Ненужные, на первый взгляд, детали сэкономят вам время в ближайшем будущем. Неверно интерпретированный таск заставит вас написать код, который после придётся переделывать. Расписывать заказчику вопросы и план действий — обязательное условие, даже если очень лень, даже если заказчика самого раздражает такая дотошность. Важно докопаться до истины и понять, что вы оба on the same page, а не каждый сам по себе.

8. Git — просто странное слово

Блокнот — вполне подходящая система контроля версий (VCS), пока вы учитесь. Но выход на профессиональный уровень, даже если это Trainee, потребует от вас умения работать в команде. И вот здесь начинается самое интересное.

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

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

9. Игнорировать новые инструменты

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

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

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

1. Не оставляйте всё на пятницу и выходные.
2. Не игнорируйте болезни и берите больничный, даже если«просто простуда».
3. Не отодвигайте отпуск, если чувствуете, что знатно устали.
4. ВЫСЫПАЙТЕСЬ!

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

Эти ошибки могут стоить Вам позиции джуна. Что за ошибки и как их избежать?

1 Слишком много вопросов

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

2 Вопросов слишком мало

Некоторые вопросы невозможно решить самостоятельно, например, касаемо логики конкретного проекта. Лучше спросить, чем сидеть полдня за минутной задачей. Если Вы 1,5-2 часа просидели над задачей и всё ещё находитесь в тупике – точно задавайте вопрос. Старайтесь подходить к тимлиду или другому коллеге сразу со списком того, что у Вас не получилось, что сэкономить и его/её, и Ваше время.

3 Не проговаривать риски

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

4 Неосознанность

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

5 Не сделана домашняя работа

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

6 Зацикленность на технологиях, а не на проекте

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

7 Нет понимания бизнес-логики

Как код попадает на продакшн / тестируется / деплоится. Бизнес процессы позволяют увидеть big picture и посмотреть на проект со стороны заказчика. Так Вы будете более осознанным, эффективным и незаменимым сотрудником..

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

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