10 ошибок начинающего разработчика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Высыпаться? Куда высыпаться?

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

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

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