Тем, кто не имеет отношения к созданию ПО, труд разработчика может казаться довольно лёгким: ты востребован на рынке, платят прилично, компании стараются угодить приятными ништяками, и так далее. Всё это так, но если начистоту, то в работе программиста немало неприятных моментов. Мы собрали десять наиболее популярных вещей, которые чаще всего огорчают создателей ПО.
10. Железо
Конечно, программам необходимо оборудование, чтобы они могли выполняться. И как бы некоторые разработчики ни старались игнорировать роль железа, рано или поздно при создании и отладке ПО они неизбежно столкнутся с характерными для оборудования проблемами. Поэтому новичкам рекомендуют всегда изучать особенности железа и систем, на которых будет исполняться их код, чтобы потом появлялось меньше затруднений.
«Каждый программист, который хотя бы раз отлаживал странное падение на сервере базы данных или пытался понять, почему RAID-накопители работают некорректно, знает, какая это боль — аппаратные проблемы». Steve Borthwick
«Программисты ненавидят железо, потому что они не могут всегда всё на него сваливать!» Anonymous
9. Сидеть весь день
Пока у вас не появится рабочий стол с беговой дорожкой, разработка ПО никогда не будет походить на разновидность аэробной нагрузки. Большинство программистов тратят долгие часы, сидя на заднице, стуча по клавиатуре и пристально глядя в экран(-ы). Спустя какое-то время длительное сидение может стать весьма некомфортным. А если вам даже нельзя пересесть в другое место, чтобы поменять антураж, то это порой быстро вгоняет в тоску.
«Сижу целый день на стуле и пялюсь в экран. Это началось некоторое время назад… сначала спина, потом шея, глаза устали и словно горят, болит голова… ногам нет покоя… Пытался компенсировать это фитнесом, тайцзицюанем, йогой, цигуном, ездил на работу на велосипеде — и всё равно не могу больше сидеть по восемь и более часов. Проводить целый день в офисе… смотреть, как солнце проходит по небу, не отрываясь от этого чёртового стула, пока жизнь проходит мимо». Markus Toman
8. Отладка
Даже самый лучший, тщательно написанный код не обходится без багов. Естественно, разработчики вынуждены регулярно тратить время на поиск и исправление дефектов — и в своём коде, и в чужом. Одни баги находятся и лечатся легко, а другие могут доводить до белого каления своей неуловимостью, заставляя тратить многие часы и сомневаться в устойчивости своей психики.
«Обнаружение трудновоспроизводимого или, что хуже всего, проявляющегося на интеграционном тесте бага, который случайно проходит или сбоит на одном и том же куске кода!!! Потом создаётся ощущение, что ты никогда не сможешь найти эти проклятые таинственные баги, прячущиеся где-то в коде. Фу!» Emmanuel Ngwane
«Мы пишем настолько большие программы (иногда и маленькие тоже), что при отладке углубляемся в такие дебри и забываем о том, что собой представляет сам баг». Ayush Bhatnagar
«Отладка, особенно когда работаешь над большими проектами из тысяч строк. Многие гики наподобие меня предпочитают при отладке выводить изображение через проектор, чтобы глазам было легче». Isaac Perez
7. Плохая документация
Работа с чужим кодом иногда раздражает, но не так сильно, если он хорошо задокументирован. К сожалению, так бывает не всегда. Если нет комментариев в коде или нормально написанного объяснения, как всё работает, приходится тратить гораздо больше времени на отладку, расширение или интегрирование приложения. А это не лучшим образом влияет на самочувствие программистов.
«Больше всего раздражает, когда тебя нанимают разбираться с плохо задокументированным ПО. Это затрудняет жизнь тем, кто принимает работу над проектом. Нехватка комментариев и плохая семантика, особенно когда после предыдущего программиста осталась куча багов и ошибок». Angel Angeles III
«Разбирательство в незадокументированном и неоткомментированном коде, который написал какой-то идиот». Abhishek Chauhan
«Я, как и большинство программистов, трачу больше времени на сопровождение плохо задокументированного кода, чем на написание нового». Walt Karas
6. Слияние кода
Системы управления исходным кодом вроде Git или Subversion — это прекрасные инструменты, позволяющие многим программистам одновременно работать над одной кодовой базой, не толкаясь локтями. Но в конце концов изменения нужно коммитить в репозиторий, и здесь могут возникать конфликты, если, скажем, два разработчика изменили один файл или подпрограмму. Иногда такие конфликты решаются просто, иногда — не очень.
«Я не люблю слияния, потому что я хочу поменять код так, мой коллега хочет сделать это иначе — и как же нам быть? Я всегда стараюсь находить способы объединить оба решения, но если возникает реальный конфликт, то слияние становится очень неприятным занятием». Jessica Su
«Конфликт слияния ✽абсолютное зло✽». Koustuv Sinha
5. Нереалистичные ожидания
Разработчики ПО — люди далеко не глупые. Но именно по этой причине всевозможные начальники, менеджеры проектов и продажники часто проявляют нереалистичные, завышенные ожидания относительно того, что программист или команда программистов могут создать к определённой дате, и поэтому планируют слишком многое. В результате разработчики со временем выгорают на работе и в целом не чувствуют от неё удовольствия.
«Самое неприятное — объяснять людям, что ты не волшебник, что у твоих знаний есть границы, что именно можно реализовать с помощью имеющихся инструментов в рамках отведённого времени, причём стараться донести всё это людям, которые никогда не занимались программированием и не горят желанием это делать». Mark Miller
«Ваш босс очень много ожидает от вас и ваших коллег, но времени и ресурсов недостаточно даже для того, чтобы хотя бы приблизиться к ожидаемым результатам». Kevin Sekin
«Менеджеры проектов и бизнес-аналитики обещают клиентам достать Луну с неба, а программисты должны это сделать во что бы то ни стало». Ratnakar Sadasyula
«Люблю, когда кто-то просит сделать что-то тривиальное, а потом небрежно так подкидывает требование, для реализации которого компьютерной науке нужно развиваться ещё лет двадцать». Vladislav Zorov
4. Другие люди ломают мой код
Код, написанный любым разработчиком, так или иначе должен взаимодействовать с кодом других программистов. Неважно, будут ли это части одного приложения, сторонние библиотеки, инструменты или вообще другое приложение. Наш код не существует изолированно. В результате кто-то может из-за спешки, недопонимания или безалаберности поломать чужой код, что становится причиной недовольства, ссор, стресса и зачастую ругательств.
«Худшее, что у меня было, это когда я писал программу вместе с человеком, который безо всяких уведомлений менял библиотеку, на которую мы оба ссылались. В результате мои вызовы подпрограммы теряли переменные или добавляли их. Либо, что ещё хуже, падал код библиотеки, к которому у меня не было доступа». Sheri Fresonke Harper
«Когда часть твоего кода перестаёт работать, потому что кто-то изменил свою часть кода. Часто их функции начинают требовать больше аргументов, чем раньше. Иногда функции вообще пропадают или переносятся в другой файл». Jessica Su
«Необходимость постоянно возвращаться и переделывать код, который ты написал пару дней назад и который только что „сломался“ (не в первый раз) из-за изменений, внесённых в общую систему безо всяких обсуждений кем-то, кто даже не протестировал или забил на то, что тесты не проходят. И в результате тебе же заявляют, что твой код „не работает“». Simon Hayes
3. Люди не понимают, чем я занимаюсь
Несмотря на рост популярности профессии программиста и повсеместной распространённости программного обеспечения, многие неайтишники всё ещё не понимают, чем на самом деле занимаются разработчики. Для них мы просто «технари», и они не видят особой разницы между, например, разработчиками ПО и оборудования. Постоянное непонимание и неуместные представления, особенно среди твоей семьи и друзей, могут выводить программиста из себя.
«Среди людей, не имеющих отношение к IT, распространено ошибочное представление, что раз программисты работают на компьютерах, то должны уметь чинить их. Это примерно то же, что если ты ездишь на машине, то должен уметь перебирать коробку передач». Steve Borthwick
«Да, я зарабатываю на жизнь написанием кода. Нет, я не могу помочь решить проблему с принтером, или открыванием приложенного к письму файла, или не загружающимся компьютером. По крайней мере — пока вы не угостите меня обедом или пивом, тогда, возможно, я смогу помочь». Phil Johnson
«Объяснять людям, что у меня нет в каждом углу по магазину, устанавливающему на их компьютеры пиратское ПО». Anbalagan Jeyabalachandran
«Семья и друзья думают, что я могу дистанционно починить всё связанное с компьютерами. Как железо, так и программы. Они не понимают. В результате тебе приходится выслушивать их язвительные комментарии вроде „что ты за программист, если даже не можешь починить DVD-дисковод на моём ноутбуке“». Jazib Babar
«Лишь 1—2 % людей знают, чем я на самом деле занимаюсь». Yasin Pekşen
2. Нехватка времени
Как и в большинстве других сфер деятельности, создание хорошего ПО занимает время. К сожалению, как и повсюду, руководство и/или клиенты обычно не желают ждать достаточно долго, чтобы можно было правильно реализовать идеальное решение. В результате разработчиков очень часто подгоняют, чтобы они сделали побыстрее. Это приводит к использованию неприглядных хаков, к техническому долгу, плохой документации. В свою очередь, описанные последствия становятся причиной головной боли при последующих доработках и сопровождении, особенно для программистов, которым приходится иметь дело с уже готовым кодом.
«Я хочу всё делать хорошо, но из-за давления приходится делать поспешно. Иногда это оправдано, но не покидает ощущение, что современная культура программирования ушла в этом направлении слишком далеко». Tikhon Jelvis
«Худшее для меня — торопливо писать неряшливый код и знать, что я мог бы сделать его гораздо элегантнее. Постоянно давит нехватка времени...» Gene Sewell
«… Когда многое из того, что ты делаешь, даже отдалённо не напоминает хорошие методики программирования, и лишь потому, что скорость важнее качества, тебе приходится делать то, о чём просят». Jose Palala
«… Всегда не хватает времени и денег для создания правильного решения, но зато их всегда достаточно для того, чтобы потом исправлять на коленке, снова и снова». Romi Awasthy
1. Работать с чужим кодом
Рано или поздно разработчикам ПО приходится иметь дело с кодом, написанным кем-то другим. Будь это легаси-код, унаследованный от предшественника на работе, или сторонний API, или код, написанный консультантом, — вам не удастся полностью избежать необходимости исправлять, расширять и/или интегрировать чью-то программу. И это часто заставляет разработчиков рвать на голове волосы.
«… Хуже всего — лазить по чужому коду, разбираться в нём, отлаживать, настраивать. И совсем мрак, когда написавший его человек уже уволился и никак тебе не поможет». Ratnakar Sadasyula
«Пытаться расшифровать тысячи строк недокументированного кода». Simon Zhu
«Бывали случаи, когда мне приходилось разбираться с УЖАСНЫМ кодом, написанным консультантами». Joe Samson
«Другая проблема, которая может очень сильно расстраивать, это сторонние API. Иногда ты на них сильно полагаешься, а потом замечаешь проблему, или нужна какая-то функциональность, но API не даёт возможности решить это самостоятельно, так что приходится обращаться к автору и надеяться на лучшее». Kevin Sekin
«Баги языка и фреймворка. Ты тратишь дни в попытках понять, почему твой код не работает. И только для того, чтобы обнаружить, что всё дело в баге языка или фреймворка». John Paul Alcala
«Обнаруживать код, написанный кем-то, кто вообще не имел должной квалификации для его создания…» Nani Tatiana Isobel
Возможно, в ваш топ-10 входит что-то другое? Добро пожаловать в комменты :)
Автор: Barrayar
