Почему программирование — это сложно

Привет! Меня зовут Владислав Василенко, я сотрудничаю с компанией Dev.Pro в роли Software Engineer и считаю, что программирование — это сложно.

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

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

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

Чужой код

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

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

Проблема работы с чужим кодом чаще всего возникает из-за следующих причин:

• Слишком много/мало кода. Обычно в жизни встречаются две полярные ситуации: 100 методов против 10. Несмотря на количество методов, функционал работает исправно в обоих случаях, однако поддержка и возможность быстро понять суть функционала хромают в обоих случаях. Размазывание логики или же жесткая инкапсуляция ради уменьшения количества методов негативно сказывается на читабельности такого кода, что приводит к тому, что ваши коллеги тратят лишнее время на попытки понять весь этот функционал.
• Нейминг. Все мы когда-то читали или слышали про «Clean Code», но ваш коллега мог случайно упустить эти знания, поэтому среди его кода вы запросто можете увидеть что-то подобное, где название ни класса, ни метода не дают понять, что это и зачем нужно. А тратить время на то, чтобы разобраться в чужом коде, не хочется никому.

class DataRecords {
 public loadDataRecord(): void {
   // implementation of getting data from DB
 }
}

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

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

Приступ рефакторинга

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

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

• Новый человек. Часто новые люди приходят на проект со своими амбициями, багажом знаний и «best practices» — порой все это становится толчком к навязыванию их точки зрения и попытке переделать все на лучший лад.
• Непонимание командной работы. Эта причина применима по большей части для «ревнивцев». Программирование — чаще всего работа в команде, что подразумевает отсутствие подобных претензий на код, ведь в рамках одной команды рано или поздно кто-то добавит изменения в такие места.

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

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

Та самая опечатка

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

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

• Спешка. Все мы помним про дедлайны, а особенно про те, что «на вчера». Конечно, иногда бывают безвыходные ситуации, когда из-за спешки какая-то опечатка, вызывающая баг, оказывается в продакшене. А как я написал выше, такие ошибки могут проявляться случайно, поэтому даже у QA нет возможности ее заблаговременно выявить.
• Отсутствие сосредоточенности. Бывает так, что вы пишите код и решаете сделать себе чай. Пока закипает чайник, вы смотрите в окно, а вернувшись за рабочее место, уже не помните на чем остановились, поэтому просто продолжаете писать код. Иногда это не приводит ни к чему страшному, но возникают ситуации, когда после такого чая вы проводите несколько часов дебага.

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

Вместо выводов

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

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

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