Ох, как же тяжело быть программистом

23 марта, 2015

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

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

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

Как бы ты не старался, тебе потом будет стыдно за этот код и даже будет хотеться переписать.

Чёрт побери, и ведь правда! Всем программистам стыдно.
Смотришь на свой код трёхмесячной давности и думаешь: «Блин, ну как я так мог кодить?»

Как же с этим жить? Но вот на одной конференции я узнал спасение:

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

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

И вот я переколбасил код думая что я сделал «рефакторинг», ну ничего что без тестов, но работать должно. И вместо написания своего CSV парсера нашёл в интернете и подключил к проэкту какой-то чужой, который ещё и Excel файлы шарит парсить, и в БД сразу записывать и кофе варить и ракеты запускать.
Я удалил не 200 а 400 строк! Йуху! Какой же я крутой 🙂

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

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

А ты хрен его знает даже что отвечать — там такой код уже непонятный, всё в костылях, писался десятью индусами и те уже поувольнялись.
— Ну за два-четыре дня. Наверное.
— Отлично! Два дня, так и скажу заказчику.
И убежал.

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

А были бы тесты, открыл бы их и почитал бы как спецификацию. Но их нет. И ты понимаешь что

Любой код без автотестов сразу становится legacy: никому непонятный, хрупкий и почти неизменяемый, и все уже через неделю забудут что он делает и как. И совершенно неважно, насколько хорошо он написан, объектно-ориентирован или инкапсулирован. С помощью тестов мы можем быстро и под полным контролем изменить поведение нашего кода. А без них мы на самом деле не знаем, становится ли наш код лучше или хуже
© Майкл Физерс, Эффективная работа с унаследованным кодом

Посидел, поглядел в монитор час.
Нет, всё равно непонятно. Как оно, блин, вообще работает? Я убил бы того кто это писал, вот бы узнать где он живёт… и бензопилой… или лучше в кислоте его…
Пойду кофе заварю.
Вернулся, посидел ещё часик.
Скучно. О! Новый имейл.
Потом ещё часик.
А что там в твитере пишут?
Потом ещё часик.
Зайду-ка я на хабру, может чё интересного почитать.
…ещё часик.
Так, ладно. Нифига не понятно, пора домой.

Следующий день проходит примерно также. И вот заходит к тебе проджект менеджер, а у тебя на весь монитор башорг:
— Нушотам, сделал?
— Та я это… там непонятно..
— Блин, ты же обещал за два дня сделать! А ты башорг читаешь!
— Ну… за два-четыре…
— Да продажи уже начнутся через два дня! Короче у тебя дедлайн до завтра. Иначе уволю нафиг, бездельника.

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

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

И всё? Вот это вот я три дня ковырялся чтобы одну строчку исправить? Блин, я программист а кода даже как-то и не пишу. И новая истина которая открылась тебе гласит:

Большую часть времени программист читает код, а не пишет.

Блин, это совсем не романтично 😦

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

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

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

А ошибка оказывается происходит когда пользователи цену указывают с центами. И вдруг ты понимаешь — а ведь в США десятичный разделитель не запятая, а точка! И ты вбивал $5,50 и у тебя работало, а американцы вбивают $5.50 и получают ошибку. Но ты об этом ну вообще даже не мог подумать, и отдал не до конца протестированный код и который ну просто обязательно и завалился. Это было неизбежно, потому что есть Закон Мерфи который гласит:

Если что-то сделано так что может поломаться, оно обязательно поломается

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

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

Но время идёт, потихоньку ты учишься делать рефакторинг правильно и быстро, средствами IDE, покрывая тестами, в заранее выпрошенное у заказчика время.
Но работа тебя постепенно перестаёт переть. Это уже совсем не тот драйв который ты испытывал когда писал Змейку на втором курсе.
Какое-то унылое ковыряние в XML конфигах, баг фиксинг, чтение документации, разговоры с коллегами.
А при этом прогресс не стоит на месте, и вот выходит новая версия библиотеки, где добавился новый функционал а старый будет удалён. И тебе нужно посидеть попробовать её, прочесть книжку, попробовать пописать код. Но это не в рабочее время, естественно.

Нужно бежать за прогрессом чтобы оставаться на месте

Как быть? После работы дома ещё начинаешь себе pet project, так, чисто для души.
Жена недовольна — муж приходит с работы и снова за компьютер и в наушники. Сначала бесится, а потом рожает тебе ребёнка чтобы ей скучно не было. Теперь дома детские визги вообще не посидеть кодить — и начинаешь засиживаться на работе до одиннадцати.
А что делать? Как-то же обучатся нужно.
И постепенно твоя производительность снижается и устанавливается на определённом уровне, и тебе открылась следующая истина:

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

Но вот случается чудо, и заказчику нужно написать новое приложение. У вас есть возможность написать проект самим с ноля! Не какого-то старого монстра фиксить костылями, а начать с чистого листа.
Тут вы сразу же восторженно рисуете UML диаграммы, схему БД и выбираете стект технологий: что там сейчас самое модное? MongoDB, AngularJS, Scala? Ну и конечно же сразу нужно всё писать для Cloud! А теперь попробуем со всем этим взлететь…

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

This is what programming is really like. http://t.co/jNgPZjpqmy—
Braindead McabrAdams (@rit) December 30, 2014

Как это не прискорбно, но следующее открытие:

Начали в стиле «Хай-тек». Закончили в стиле «Нехай так».
© Dmitriy Efimenko

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

Именно поэтому, вообщем-то, хороших программистов не так много. И именно поэтому им платят относительно неплохо (а на самом деле ещё и сильно недоплачивают).

Но однажды ты почувствуешь спокойствие и Силу Джедая. Как к этому прийти обязательно посмотри этот коротенький и чудный рассказа Андрея Солнцева:

UPD Похожая статья В поисках идеального программиста

---

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

Written by stokito Рубрика: Начинающим программистам, Programming