Типичные ошибки начинающих программистов

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

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

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

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

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

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

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

Источник

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

Первая ошибка начинающего программиста заключается в отсутствии плана

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

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

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

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

Начинающий программист недооценивает кодстайл

При написании кода важно учитывать его читабельность. Новички пренебрегают пробелами, полноценными и понятными именами переменных, предпочитая не обращать на эти вещи внимания и называть первую переменную “a”, вторую – “b” и т. д. Никогда не недооценивайте важность чистоты кода. В интернете есть множество статей, посвящённых кодстайлу для каждого из ЯП. Наши материалы по общим рекомендациям:

10 принципов хорошего программного кода, который устроит всех
6 простых советов по написанию чистого кода

“Всегда думайте, будто парень, который будет поддерживать ваш код, – это жестокий психопат, который знает, где вы живёте.” – Джон Вудс.

Выбирает первое попавшееся решение

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

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

Как сказал Энтони Ричард Хоар, существует два принципа написания ПО:

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

Не может бросить код незаконченным

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

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

Пятая ошибка начинающего программиста в том, что он не гуглит

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

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

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

Шестая ошибка начинающего программиста – он использует не подходящие структуры данных

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

Вот два небольших примера:

Использование списков (массивов) вместо хешей (объектов) для управления записями.

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

Неприменение стеков.

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

“Недорефакторинг”

Обычно под словом “рефакторинг” подразумевается улучшение кода для более ясного понимания и оптимизации. Однако не все новички умеют улучшать читабельность своего кода.

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

Пишет комментарии об очевидных вещах

Есть один способ избежать комментариев и сделать код более понятным – заменять комментарии на очевидно заданные элементы.

Вместо следующего кода:

// 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 even
      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;
  }
);

Девятая ошибка начинающего программиста – отсутствие тестов

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

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

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

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

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

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

Начинающие разработчики не ставят себя на место пользователя

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

То, чем заставляют заниматься в школах/ВУЗах, – изобретение колеса

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

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

Отторжение code review

Один из признаков начинающего программиста – восприятие code review как осуждение, критику. Он недоволен этой критикой, не ценит её или даже боится. Это в корне неправильное отношение к ревью. Если вы так себя чувствуйте, убедительно рекомендуем пересмотреть и изменить своё отношение. Смотрите на каждое ревью как на обучение, возможность узнать что-то новое. Самое главное, благодарите своих рецензентов, когда они вас чему-то учат. Большинство из них поделится с вами опытом, который, возможно, упростит вашу деятельность и положительно скажется на продуктивности.

Оригинал

Источник

https://gbcdn.mrgcdn.ru/uploads/post/2139/og_image/866e65cb285465ef3c663de8eb923817.png

Источник: м/ф «Симпсоны»

У каждого из нас имеется собственный компьютер на углеродной основе — головной мозг. Мощный, продуктивный и чрезвычайно сложный. Но, увы, подверженный сбоям и ошибкам. Баги заметили ещё в античности, а древние римляне запротоколировали их в краткой и ёмкой формуле: «Человеку свойственно ошибаться».

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

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

Самоуверенность или чрезмерные сомнения в себе

Эти проблемы — две стороны одной медали, поэтому мы объединили их.

«Я уже знаю всё, что нужно!» — типичная ошибка самоуверенного юнца. Первые шаги оказались успешными, первая программа запустилась без ошибок (почти) — ура, я стал мастером! Многие из нас проходят эту стадию, и всем приходится рано или поздно убедиться: это не так. Никто из разработчиков, каким бы опытным он ни был, не знает всё, что может ему когда-либо понадобиться. Быть программистом — значит постоянно учиться, открывать для себя новые приёмы и возможности, заниматься исследованиями и экспериментировать. А порой даже мучительно вспоминать: «Чёрт возьми, я ведь уже делал что-то подобное, но не помню, как именно!»

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

Эта проблема известна с 1999 года как эффект Даннинга — Крюгера. В 2000 году исследование авторов было отмечено Шнобелевской премией по психологии.

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

Изобретение велосипеда

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

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

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

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

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

Плохой стиль программирования и оформления кода

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

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

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

Распространённая формула оценки кода — «What The F*ck’s»/minite — количество сомнительных мест в коде, которые можно за минуту отследить на код-ревью. Чем меньше это значение, тем лучше.

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

Чрезмерное комментирование

Комментирование — это полезно и важно! Иногда (особенно работая с чужим кодом) вы будете остро нуждаться в подсказке: что делает этот кусок программы, зачем здесь цикл, для чего нужна эта переменная?

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

К примеру:

int_Count += 1 // увеличиваем счетчик на 1

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

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

Плохие имена

Когда вы читаете чужой код, имена классов, функций и переменных могут оказаться настоящей катастрофой. Что, например, делает функция f_rs645()? (И не пробуйте, ни за что не угадаете, пока не откроете код функции и не начнёте читать.) А если таких названий много?

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

Таких проблем можно избежать, если давать объектам «говорящие» названия. Чем более внятное и содержательное имя, тем проще будущим поколениям программистов оценить ваш шедевр.

Правда, иногда в результате такого подхода рождаются неудобоваримые имена в духе AbstractSingletonProxyFactoryBean — настоящий Эйяфьядлайекюдль в IT. Но если бы создатели Java решили сократить имя этого класса до аббревиатуры «aspfb», было бы куда сложнее разобраться, что же это за класс и для чего он нужен.

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

Важнейшие общепринятые принципы именования объектов:

использовать осмысленные имена;
использовать CamelCase;
соблюдать регистр имени, даже если язык к нему нечувствителен;
использовать префиксы для имён переменных разных типов или разного назначения (например, для переменных типа integer использовать префикс int_).

Отсутствие «защиты от дурака»

Мы можем работать над программой, которой будут пользоваться доктора наук, но не стоит чересчур полагаться на их регалии и звания. Если в программе предусмотрено поле с подписью «Введите число от 1 до 10» — не поленитесь, проверьте, что ввёл туда пользователь. Как показывает практика, там могут оказаться и значения из неправильного диапазона, и вообще ничего (если пользователь пропустил строку ввода). А иногда даже слово прописью: «десять».

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

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

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

Работа над кодом без общего плана

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

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

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

Чересчур большие функции

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

Ваша функция определённо слишком велика, если:

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

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

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

Вместо этого создадим подфункции:

функцию, предлагающую пользователю выбрать файл (возвращающую дескриптор открытого файла);
функцию, считывающую матрицу в массив;
функцию для подсчёта арифметического среднего для заданной строки или столбца массива;
функцию для формирования графика.

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

Использование глобальных переменных не по назначению

Глобальные переменные удобны: достаточно один раз определить их в начале программы — и можно использовать в любом месте кода. До тех пор, пока не обнаружите, что одна из них содержит очевидно некорректное значение. И тогда придётся потратить полдня и кучу нервов, чтобы наконец выяснить, что значение изменилось после вызова какой-то функции, где она почему-то тоже используется (вот так неожиданность!).

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

Выбор первого попавшегося решения

Перед вами поставили задачу. «О, я знаю, как это сделать!» — говорите вы и немедленно приступаете к выполнению.

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

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

Пренебрежение отладчиком

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

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

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

«Бэкапы для слабаков!» (на самом деле нет)

Фраз вроде «Я потерял целый день работы из-за сбоя!» вообще не должно быть в словаре программиста. Придумано множество средств, которые помогают автоматически сохранять бэкапы, выполнять резервное копирование и осуществлять контроль версий. Компьютер завис и пропали наработки? Следовало настроить автосохранение. Сгорел винчестер? Нужно было сохранять данные на сервере или в облаке.

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

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

Google It First!

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

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

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

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

Все мы когда-то только начинали программировать и делали ошибки. Напоследок несколько конструктивных советов:

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

И всё у вас получится!

Источник

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

Розовые очки

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

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

Нереальные/неконтролируемые цели

Цель «Стать программистом» — очень большая и серьезная. Типичный «слон». А значит, есть его надо по кусочкам. Эту цель не взять с наскока. Будут дни, когда вы будете впадать в депрессию из-за того, что результатов нет, вы весь день промучились с какой-нибудь задачкой, которую так и не получилось решить. Рассылаете свое резюме джуниор-программиста, а в ответ тишина. В такие моменты очень легко потерять мотивацию, разочароваться, сменить направление деятельности.

Чтобы поддерживать себя в мотивированном состоянии и плодотворно учиться, стоит ставить себе контролируемые цели. Например, учиться программировать каждый день минимум по 2 часа (этого мало, если вы хотите получить быстрый результат, но это гораздо лучше чем три дня по 8 часов, а потом забросить на 2 недели). Можно разбить эти 2 часа на 4 «помидорки» по полчаса в течение дня. (гуглите «техника Помодоро») Еще лучше — если вы распишете, что конкретно будете делать, например заниматься на Хекслете, или по какой-то конкретной книге. В этом случае, если вам удастся придерживаться этого графика, вы 100% будете двигаться вперед.

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

Читайте также
Стать программистом можно и после 35 лет: история успеха студента Хекслета.

Зубрежка функций

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

Типа: Ой, Руби классный. Ой нет, Руби умирает, вот Питон супер, его рекомендовали в какой-то статье которую я краем глаза читал. А пхп так вообще ужас, да и к тому же полумертв. О, так джависты оказывается получают в 5 раз больше других программистов, мне срочно нужна Java! И так далее. Эти попытки разобраться какой язык лучше занимают уйму времени и плодят сотни новых вопросов на тостерах.

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

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

Дети Ютуба

Где брать эти знания? Кроме очевидного -Youtube, Coursera, Stepic, Openedu, курсы Хекслета, стоит начать активно читать книги (бумажные или электронные — разницы нет). Видеокурсы все больше движутся в направлении развлечений, народ хочет зрелищ. (и хлеба в виде больших зарплат). А скучать никто не хочет. Под видео часто можно видеть отзывы типа “Скучно! Монотонно!”. Людей приучают развлекаться, и они постепенно привыкают. А ведь обучение по книге гораздо более эффективно, потому что информация в книге сконцентрирована, а в видео наоборот, размазана, чтобы было подольше да повеселее.

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

Что именно читать? Смотрите здесь, в книжной подборке Хекслета.

А вот отдельная статья про то, как выбирать и эффективно читать технические книги.

Перфекционизм

Некоторые хотят выучить все идеально, даже и не приступая к реальным проектам. Чтобы не дай бог где-то не ошибиться, не показать себя глупым. Грубо говоря, хотят стать senior программистом, еще перед трудоустройством. Им всегда кажется, что они знают мало, нужно еще, еще, еще. Еще чуть-чуть подготовиться, тогда можно и сходить на собеседование. Наверняка, это явление исследовано вдоль и поперек всякими мощными психологами. Мне кажется, здесь основной страх один — показаться плохим(неумелым) перед какими-то людьми, мнение которых для тебя важно.

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

Ладно это все общая болтовня, а вот конкретный совет. Если вы уже хотя бы несколько месяцев занимаетесь программированием, начинайте составлять резюме, читайте статью про алгоритм поиска работы и вперед!:)

Спасибо за то, что дочитали до конца и удачи во всех начинаниях!

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

Источник

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

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

1. Выбор платформы и языка программирования

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

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

Еще один более трудоемкий способ – это ходить на собеседования. Там вы не только сможете понять, нужны ли вы вообще хоть кому-нибудь с тем объемом знаний и навыков, которыми вы обладаете на данный момент. А еще вы поймете, какие требования есть у работодателей.

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

2. Слишком много сомнений

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

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

3. Слишком высокое самомнение

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

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

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

4. Не знать английский

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

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

5. Слишком много комментариев

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

Но вот что вам не стоит делать, так это оставлять комментарии вроде этого: “score += 5; // добавляет 5”. Это очевидно, и нет нужды еще раз писать об этом в комментарии. Конечно, комментировать каждую линию – это отличное упражнение для вашей первой программы. Но это не то, к чему вы должны привыкать.

6. Не доучиваться до конца

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

7. Учить один язык за другим

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

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

8. Пренебрегать дебаггерами

Если вы работаете с такими языками как Java, C# или ActionScript3, то вам стоит пользоваться дебаггером. Он не только облегчит вашу работу, но и обнаружит то, что вы можете не заметить.

9. Не делать бэкапы своей работы

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

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

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

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

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

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

Читайте также: 9 полезнейших сайтов для изучения программирования

Читайте также: Уроки по JavaScript для начинающих

Читайте также: 16 полезных уроков по CSS3 для начинающих

Источник

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

Совершенный код, Программирование, GTD, Проектирование и рефакторинг

Рекомендация: подборка платных и бесплатных курсов создания сайтов — https://katalog-kursov.ru/

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

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

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

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

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

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

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

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

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

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

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

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

tHIS is
  WAY MORE important
than
         you think

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

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

const monthsInYear = 12;

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

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

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

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

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

6) Не гуглить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот яркий пример ненужного 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) Не писать тесты

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.

Проблема 2

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

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

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

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

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

Проблема 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С какими ещё ошибками Вы встречались?

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

Источник