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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// 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 как осуждение, критику. Он недоволен этой критикой, не ценит её или даже боится. Это в корне неправильное отношение к ревью. Если вы так себя чувствуйте, убедительно рекомендуем пересмотреть и изменить своё отношение. Смотрите на каждое ревью как на обучение, возможность узнать что-то новое. Самое главное, благодарите своих рецензентов, когда они вас чему-то учат. Большинство из них поделится с вами опытом, который, возможно, упростит вашу деятельность и положительно скажется на продуктивности.

Оригинал

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

1. Комплекс «я сам»

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

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

2. Программирование без планирования

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

В крупных фирмах, в качестве примера возьмем «Росатом» (о работе в котором в сфере IT можно прочитать на Cybersport.ru), так не будет — в госкорпорации умеют ставить четкие задачи. Хотя «Росатом» включает в себя множество компаний (более 300), все они имеют конкретную цель или целостный проект в реализации, над которым работают на результат, а не ради написания кода.

3. Туннельное развитие в неподходящей сфере

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

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

4. Игнорирование иностранных языков

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

5. Написание кода на количество, а не качество

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

В хороших IT-компаниях практически невозможно услышать фразу: «Посмотри, как много кода я написал». Таким грешат только новички. Отказывайтесь от измерения длины кода раз и навсегда.

6. Невнимательное изучение технического задания

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

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

7. Отсутствие pet-проектов

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

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

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

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

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

9. «Комплекс бога»

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

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

10. Зацикленность на работе

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

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