Тем, кто не имеет отношения к созданию ПО, труд разработчика может казаться довольно лёгким: ты востребован на рынке, платят прилично, компании стараются угодить приятными ништяками, и так далее. Всё это так, но если начистоту, то в работе программиста немало неприятных моментов. Мы собрали десять наиболее популярных вещей, которые чаще всего огорчают создателей ПО.
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 Peksen
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 входит что-то другое? Добро пожаловать в комменты :)
Комментарии (75)
trigun117
05.03.2018 20:14Про чужой код конечно правда, но даже свой через какое то время начинает колоть в глаза.
Akdmeh
05.03.2018 20:19От себя бы добавил:
Отсутствие интересных задач. Иногда везет, и ты разрабатываешь какой-то хитрый плагин или модуль, или оптимизируешь какое-то место в системе, что приводит к ускорению алгоритма в несколько раз.
Но когда доходит до: «сдвинь кнопочку на три пикселя вправо, добавьте то, добавьте это» — когда требуются чисто технические навыки без фактического размышления и оригинальности — подобные задачи просто выматывают за несколько часов.
SergioDeMaster
06.03.2018 09:54Это огорчение №0.
Если задача интересная — остальное уже не так напрягает.YemSalat
07.03.2018 03:46Есть еще смешанная ситуация — задача интересная, но надо работать с чужим кодом…
potan
05.03.2018 20:196. Мержиться — действительно самое неприятное в профессии…
DenimTornado
06.03.2018 01:26Что-то не так вы мержите… Что может быть неприятного?
Ckpyt
06.03.2018 07:06Слияние двух веток от одного ствола — это еще терпимо. Гораздо хуже, когда есть две главные ветки проекта. Скажем, 1.х и 2.х. И временами надо добавлять изменения из версии 2.x в 1.х или наоборот. Скажем, патчи безопасности. И это всегда боль и страдание.
Самое худшее в моей жизни это патч 3.х кодом из 8.х. За пять лет там ВООБЩЕ ВСЕ поменялось. И вместо мержа пришлось переписывать код с тем же фиксом.
Еще более страшный случай делал мой коллега — патч 2.х из 8.х. Там были разные системы управления кодом.zuev93
06.03.2018 09:42+1Тут, на мой взгляд, вопрос к вашему подходу (gitflow) и необходимости таких операций.
Почти всегда когда что-то получается через боль и страдание стоит задуматься — может быть я что-то делаю не так?
Skerrigan
07.03.2018 06:39Почти всегда когда что-то получается через боль и страдание стоит задуматься — может быть я что-то делаю не так?
Не автор, но no problem, let's go:
->патч 3.х
«Был молод и не опытен»/«технологическая эпоха была иной»
->из 8.х.
«уже все делается как надо»
может быть я что-то делаю не так?
Не смог продать клиенту v8 в силу различных причин?
Резюме — вовсе не обязательно, что человек делает что-то не так. Наоборот, пример, разбираемый выше, — это случай, когда даже древние системы пытаются патчить от текущих уязвимостей и/или ошибок.
F0iL
05.03.2018 20:21Ты тратишь дни в попытках понять, почему твой код не работает. И только для того, чтобы обнаружить, что всё дело в баге языка или фреймворка
Или стандартной библиотеки/компилятора, да.
Из того на что сам когда-то убил несколько часов, решительно не понимая, почему простейший код не работает как надо: gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
А если еще вспомнить описание прекрасной POSIX-функции cuserid() из manpages…
Sometimes it does not work at all, because some program messed up the utmp file. Often, it gives only the first 8 characters of the login name.
…
Nobody knows precisely what cuserid() does; avoid it in portable programs.
perfect_genius
05.03.2018 20:37У меня вчера впервые появился баг, на который потратил ЦЕЛЫЙ день, но в конце таки нашёл причину (банально неожиданные входные данные). Это было так убийственно для нервов, что чуть не переросло в нервный срыв.
В статье написано, что иногда причина бага ищется даже дольше О_о
У кого-то такое было?
old_bear
05.03.2018 21:21У всех, кто пренебрегает unit test-ами может легко и непринуждённо возникнуть баг вида «неожиданные входные данные». И без этих самых unit test-ов на его поиск может понадобиться и больше чем день.
P.S. Ник у вас хороший…
P.P.S. Есть намного более страшный сон программиста — когда надо делать мерж между двумя разными системами управления исходным кодом (и не спрашивайте меня, зачем компании понадобилось использовать две разных системы внутри одного проекта)OlvinKSA
06.03.2018 15:20У всех, кто пренебрегает unit test-ами может легко и непринуждённо возникнуть баг вида «неожиданные входные данные».
Это зависит не только от наличия юнит-тестов, но и от их качества. Да и не всё возможно покрыть автоматическими тестами, хотя таких случаев относительно мало.
И да: вряд ли невозможно покрыть тестами то, что должно проверять входные данные; здесь больше вопрос к качеству таких тестов.
0xd34df00d
07.03.2018 09:47Юнит-тестами или сильной статической типизацией.
alix_ginger
07.03.2018 18:29Всё-таки «юнит-тестами и сильной статической типизацией»
0xd34df00d
07.03.2018 19:05Опыт показывает, что при достаточно сильной статической типизации достаточно тестирования существенно более высокого уровня.
avatar256
05.03.2018 21:21День — это не страшно. Были у меня баги которые кочевали от одной версии игры к другой, и таким образом жили один — два года. А ведь много редко-воспроизводимых багов так ни когда и не будет найдено
Skerrigan
07.03.2018 06:47Худший баг — это баг в ПО, что отвечает за «качество и диагностику», т.е. ищет баги.
AlexanderS
05.03.2018 21:42Целый день — это ещё по-божески. Я пару раз искал проблемы пару недель! Пару недель, чтобы где-то просто в коде добавить буквально пару строк! Вот это был полный абзац — уволиться хотелось, я кажется даже во сне анализом занимался)
perfect_genius
05.03.2018 21:47Наверно, перепробовали всё, что можно? Локализовали-то хоть быстро?
AlexanderS
05.03.2018 22:59В вышеприведённом случае было несколько плат с FPGA, стыки — самописные интерфейсы. Внутри ПЛИСов — модули ЦОС с интерфейсами частично на IP ядрах (например, fifo там всякие с SPI или FSL), частично — самописные интерфейсы. Внутри одного ПЛИСа процессор на HDL (IP ядро), внутри которого программа крутится. Источник данных — в одном из ПЛИСов, выход по финалу — в Ethernet. И в этой системе, на приличных скоростях, прокачивается немаленький объём данных и где-то портится иногда один пакет. Испортиться может где угодно) Год всё работало нормально и уже считалось надёжным. Когда локализовал проблему, дальше уже как-то попроще — либо аналитически в код пятилетней давности втыкать (не всегда результативно), а параллельно, раз не знаешь почему, встраиваешь по маршруту данных внутрисхемный отладчик, набираешь статистику и потом сидишь и думаешь. Работа по сути идиотская, но её делать больше просто некому, т.к. исследователь должен понимать работу системы на низком уровне.
Как-то вылез косяк — непонятно почему пропадал ВЧ сигнал на выходе. После переинициализации всё заводилось, но осадочек оставался, тем более у нас не та техника, в которой допустимо оставлять косяки. Пока это было не критично — этим не занимались. На протяжении пары месяцев заметили, что это вроде бы обычно в первой половине дня происходит. Последовательность команд, приводившая к ситуации могла быть любой. Когда занялся вплотную — неделя убилась на ловлю глюка. Он мог в один день пару раз проявиться, а мог 3-4 дня не проявляться. Я уже в отладчик вывел почти все сигналы управления — хрен знает, что делать, но что-то делать надо. Хотел свалить всё на аппаратчиков — какого фига что-то происходит, если мы ничем не управляем! Но нашёл) Девайс с утра стоял и грелся. Грелся и грелся… Когда прогревался до определённой температуры, в процессоре срабатывал алгоритм динамической подстройки выходной мощности, программа в процессоре крутилась по кругу и если после срабатывания алгоритма передать определённую команду в «неудачное» время, то кратковременно выдавалась команда на отключение. Понятно почему и проявлялось это исключительно до обеда — если эта ситуация «проскальзывала», то потом всё работало вполне себе спокойно)
Как-то разбирались почему после отправки команды на волшебный адрес вешалась вся система. Вот вообще вся. И всё бы ничего, но по телеметрии всё работало без нареканий и хоть каких-то намёков. Тут вот ушло только два дня. Один день ушёл на осознание и офигевание «как такое может быть»? А второй — уже более спокойно я выяснял какой и где интерфейс подвис. По финалу дня оказалось что на низком уровне система работает — телеметрия не врёт. «Чё за хрень»? Решилось аналитически, опять же надо было очень хорошо понимать низкий уровень. Один девайс отправляет другому пакет. Второй девайс должен его передать дальше, но в нём была старая прошивка с нескорректированной маршрутизацией и он этот пакет в соотвествии со своей таблицей маршрутизации заворачивал на первый девайс, переставляя адреса абонентов. Первый девай получал пакет, ну что делать — раз пришло, надо обрабатывать, системе управления типа виднее и в соответствии со своей таблицей маршрутизации происходила передача в блок обработки, который идентифицировал, что пакет мол не мой, переставлял адреса абонентов в пакете и выдавал обратно. Опять пакет улетал второму устройству и так далее. В результате одна команда передачи данных запускала в систему пакет, который там летал по петле на сумашедших скоростях, не давая отбиться таймаутам в интерфейсах. Ситуация красивая в том плане, что, когда набралось понимание по низкому уровню пришлось реально головой подумать и пофантазировать, а во-вторых — это не баг и не косяк, это кто-то, возможно даже я, не обновил везде прошивку на актуальную, но соль ситуации такова, что уже всем было на это пофиг если это починилось )))
Я думаю у каждого разработчика есть таких случаев в кармане тележечка. А если уж с железом плотно работаешь — и того подавно.old_bear
06.03.2018 01:12А я дней 10 ждал, пока симуляция post-translate добежит до нужной точки, на которой сбой наблюдался. Причём симуляция полной модели нехилой такой системы из нескольких плат с парой десятков FPGA. Когда в итоге нашёл косяк в одной из прошивок (не моего авторства) с трудом сдержался от членовредительства, т.к. автор этой прошивки был убеждён, что проблема в моей части.
AlexanderS
06.03.2018 09:26Я так наоборот всегда радуюсь, когда нахожу не свой косяк. Идёшь к кому надо и радостно делегируешь проблему. Правда бывает, что к кому идти непонятно, а чуть позже следствие устанавливает, что человек уже уволился пару лет назад, никто ничего естественно не знает (в том числе не помнит и сам создатель проблемы) и теперь этот косяк — твоя проблема ;)
springimport
06.03.2018 16:57Я не разбираюсь в таких устройствах. С моей колокольни в идеале, наверное, было бы протестировать каждое устройство отдельно для всех случаев.
AlexanderS
06.03.2018 18:28Всё верно, каждый программный модуль должен моделироваться и в тесте, перебирая различные входные воздействия, должно становиться понятно, что он будет нормально работать. Проблема в том, что порой тесты получаются времязатратны, а порой чуть ли не сложнее самих этих модулей. А так же есть небольшой момент: когда вроде бы оттестированные модули собираешь в проект где-то что-то может вылезть — или в тесте такую ситуацию не догадались посмотреть, или изначально не продумали протокол стыковки, или теперь надо быстренько и качественно кое что изменить. Жизнь, в общем, она такая, да)
JoyceGraham
06.03.2018 09:42У меня в начале карьеры был баг, который я не мог исправить в течение наверно недель двух или трех. Причина была в том, что где-то в коде из-за вызова static_cast вместо dynamic_cast портилась память.
Самое смешное, что когда натыкаешься на такие баги, то через некоторое время поиска причины, то тебе начинает казаться, что причина во фреймворке, ос, драйверах, но не в твоем коде.springimport
06.03.2018 17:53Да, подтверждаю! Особенно когда начинаешь учиться. Кажется что ошибка будет скорее в самом Линуксе или Винде чем в своем коде.
Flying
06.03.2018 14:12Я в прошлом году потратил три дня на поиска проблемы которая проявлялась в том что сообщения между двумя частями в browser extension переставали приходить после примерно 2-3 сообщений. С учётом того что из-за особенностей платформы (Firefox WebExtensions который на тот момент ещё не зарелизился) единственным доступным мне способом отладки была запись в логи — это было "весело", к третьему дню я реально начал сомневаться — а не сошёл ли я, случаем, с ума?
В итоге причину я всё-таки нашёл и она, как и почти всегда в подобных случаях, была тривиальной, но неожиданной:
Для передачи сообщений между частями browser extension используется отсылка сообщений через порт. Для передачи / получения сообщений открывается порт и в обработчике события открытия порта на него вешается обработчик для получения сообщений. Всё было настроено и работало, но я не учёл что во внешней библиотеке, которую я использовал, открывался аналогичный порт, но позже чем мой порт (как раз я за время пока второй порт не открылся успевал передать те 2-3 сообщения которые проходили). В момент открытия порта мой обработчик события открытия порта вызывался, сохранял ссылку на новый порт и вешал на него свои обработчики. Но поскольку порт был уже другим — я начинал получать не свои сообщения, а сообщения внешней библиотеки которые мне были не нужны.
В общем всё решилось банальной проверкой корректности имени порта (1 условие), но нервов на эту строчку ушло очень много :) В коде приложения до сих пор стоит подробный комментарий с припиской: "Takes me 3 days of debugging to figure it out, valuable information :) "
geher
05.03.2018 21:27«Обнаружение трудновоспроизводимого или, что хуже всего, проявляющегося на интеграционном тесте бага, который случайно проходит или сбоит на одном и том же куске кода!!! Потом создаётся ощущение, что ты никогда не сможешь найти эти проклятые таинственные баги, прячущиеся где-то в коде. Фу!» Emmanuel Ngwane
Особенно весело бывает, когда причина сбоя обнаруживается на совсем другом куске кода, а не на том, на котором сбоит.
Sun-ami
05.03.2018 22:10Хуже всего, когда трудновоспроизводимый баг оказывается заложен в микросхеме от крупного производителя, а техподдержка не отвечает ничего более вразумительного чем «обычно эту микросхему используют вот так, и всё работает». Приходится долго танцевать с бубном или переделывать пол проекта.
AlexanderS
05.03.2018 23:19Да, налетал и на такое. Тут проблема больше в том, что на это думаешь и проверяешь далеко не в самую первую очередь)
Chudic
05.03.2018 22:32«Обнаруживать код, написанный кем-то, кто вообще не имел должной квалификации для его создания…» — лично для меня — самое неприятное и затратное по времени. Человек пишет код типа Вообще, если работали с западными заказчиками — там количество копи-пасты зашкаливает все разумные пределы!
pim_jewel
05.03.2018 22:33Необходимость переключаться с одной задачи на другую — более срочную. А потом через месяц, когда ты основательно «выпал из контекста», возвращаться к той недоделанной. И, конечно, потом это всё мёрджить!
jeamgrey
06.03.2018 09:42Это еще по божески.
Был пару лет назад случай. Прилетает задача, срочно бросай все и срочно делай. Делаю, реализую, передаю, а заказчик ушел в декрет. И как спустя еще неделю переписки выяснилось, никому кроме заказчика эта фича не была нужна.
Но что самое веселое. Месяца 3 назад, задача прилетает обратно, заказчик вышел из декрета.
Хорошо не потерял свои наработки еще за 2 года.
ferreto
05.03.2018 23:1811. Когда ты хочешь с кем-нибудь пообщаться, все вокруг заняты какой-то ерундой, но делают вид, что работают. А стоит тебе заняться задачей, от которой вот-вот закипит мозг, как все начинают лезть к тебе с дурацкими разговорами или болтать между собой о всякой ерунде…
wxzarm
06.03.2018 01:05Работа с чужим кодом вызывает большее раздражение, когда автор его не только не документирует, но и использует странный стиль, который не используется другими разработчиками. Тем более, когда код почти или полностью состоит из «костылей», которые вот-вот могут сломаться из-за перехода на что-то новое.
mrtime336
06.03.2018 01:05Был как-то один проект на чистом С, с неблокируемыми сокетами, с реализацией одного закрытого протокола методом реверс-инжиниринга и подглядыванием в «какую-то версию сервера, исходники которого получилось достать»… и так понравился чистый С..., ЛЮБОЙ баг — и он ругается Segmentation Fault… спасал только gdb и доста детальные логи…
но один из «мистических багов» искался недели 2-3, возникал где-то каждые 2-3 часа при 10 000 активных ТСР соединений, в одном их них… после бесконечных крешдампов, килограмов логов была обнаружена ошибка: в каком-то одном забитом месте вместо int надо было поставить unsigned int )))))
В этом жеж проекте было особенно весело находить баги и дыры в безопасности в самом протоколе, и в тех-жеж проектах которые мы «реверс-инжинирили»)))
AHAPX1CT
06.03.2018 01:05А как же прокрастинация у творческих личностей, в случаях когда попадается нудная задача?
untilx
06.03.2018 09:08Писать код в одно лицо, основываясь на коде огромного старого проекта (из-за нехватки времени 90% кода сохраняется, но в нём ещё нужно разобраться) без документации, при этом написанного на языке, который не знаешь. True story.
ZhanD
06.03.2018 09:42+1Нашел я как-то неуловимый тупой баг в легаси коде, который периодически появлялся у одного пользователя из десяти. Пофиксил, отправил на тест, так тестеры не смогли воспроизвести этот баг и закрыли проблему с комментами, что бага нет.
Interreto
06.03.2018 09:42- Работать с легаси где весь нейминг (переменные, класс, бд) и комментарии на голландском :)
lightman
06.03.2018 09:47+1Для меня самое большое мучение — это ежедневное восьмичасовое отсиживание. В обед обязательно пешком иду до столовой, затем гуляю по окрестностям, но всё равно заряда бодрости хватает лишь на на первые шесть часов. Последние два часа рабочего дня превращаются реально в пытку, ноги, спина устают сидеть в одной позе и как ты не пытаешься их поменять — не помогает.
При этом я заметил, что дома на выходном я могу провести за компьютером и 14 часов. Проанализировав свои действия, пришёл к выводу, что дома, не задумываясь об этом, регулярно встаю, могу просто ходить кругами, обдумывая код, могу лечь на пол (какой же это кайф — лежать на твёрдой поверхности) и смотреть в потолок, могу встать и приняться ритмично отбивать ритм барабанными палочками по тренировочному пэду, тоже при этом размышляя.
Это всё такие мелочи, копеечные, но обидно, что они отделяют продуктивную деятельность от непродуктивных мучений. И ни работодатель, никто об этом не знает, я мучаюсь просто зазря и конца этому не видно.
makdoc
06.03.2018 10:07Искренне сочувствую вам, у меня начальство к этому вопросу подошло с пониманием.
Daniil1979
06.03.2018 13:39Помогает регулярное наливание новой чашки чая — дойти до стола с чайником, наклониться, поднять чайник, держа чайник на весу, налить воду в чайник, наклониться, поставить чайник. Наклрниться за пакетиком чая, затем за сахаром. Держа на весу чашку с кипятком, дойти до своего стола и поставить чашку на блюдце, не пролив чай на стол. Если пролил — вернуться к общему столу, поднять рулон бумажных полотенец, оторвать, вернуться к своему столу. А если в чайнике нет воды — то надо сходить с ним до кулера. И так до 4-5 раз за рабочий день.
А на обед можно и в дальнее кафе сходить — 10 минут туда, 10 обратно.
А Вы — неподвижно сидеть! Просто не надо держать пиво в холодильнике у компа. :-)
poslannikD
06.03.2018 17:28Ну ничего себе жизнь довела, наклоны и шаги считаете :)
Daniil1979
07.03.2018 14:51Ну, просто хочется показать коллеге, что всё не так плохо и безнадёжно в плане физической активности.
pi-null-mezon
06.03.2018 15:20Прочитал Ваш коммент, как будто в зеркале своё отражение увидел )) Если на работодателя повлиять не получится, нужно менять работу
old_bear
06.03.2018 17:31И ни работодатель, никто об этом не знает, я мучаюсь просто зазря и конца этому не видно.
Так может вы культурно донесёте работодателю свою проблему? Сейчас же уже официально есть в ТК понятие «дистанционная работа», когда сотрудник делает всё то же самое, что и в офисе, только дома. И оформляется это, судя по тому что я читал в обзорах ТК, без особого головняка и для сотрудника и для предприятия.lightman
06.03.2018 18:29Не, у нас контора с довольно консервативными устоями, например лишь недавно отменили месячное ограничение интернет-трафика.
До отказа от «необходимости личного присутствия в офисе» мы дойдём ещё очень не скоро.
apodznoev
06.03.2018 09:51А как же, когда фича, на которую ушли недели-месяцы внезапно становится ненужной и её нужно переписать или вовсе выкинуть?
Причём порой ощущение, что чем тщательней и ответственней ты подходишь к её разработке, тем больше вероятность, что от неё скоропостижно избавятся, и наоборот — код написанный на коленке для галочки будет жить вечно.
Forxxx
06.03.2018 10:07+1Был интересный случай, когда бухгалтера попросили заменить лампочку в офисе ответив на мой вопросительный взгляд «Че, тыж программист!»
Chamie
06.03.2018 20:13Зато борьба с гиподинамией. Я когда устроился «ведущим программистом» в госконтору, а потом взял совместительство эникейщика (должность называлась «электроник», честно-честно), именно так к этому и относился.
tretyakovmax
06.03.2018 10:24Нужно изначально нормально писать код, чтобы потом не доходить до белого каления в поисках багов.
tretyakovmax
06.03.2018 10:28еще…
0. Отсутствие четкого ТЗ по задачам
Нужно «чё-то вот такое» сделатьexehoo
06.03.2018 12:01О, да! Боль всей жизни. Телепатия и ясновидение должны указываться в вакансии в качестве главного требования, сразу же после стрессоустойчивости.
AlexPu
06.03.2018 11:13>>9. Сидеть весь день
не претендую на звание доктора, да и проблема для меня не сильно актуальная (я из тех кто без проблем может просидеть/пролежать довольно продолжительное время — хотя это может меня временами раздражать, но проблемой не является). Но тем не менее:
— довольно давно выпускаются столы с поднимающимися столешницами, которые позволют работать в том числе и стоя — не думаю что составит больших трудов убедить офисное руководство обеспечить работников таким столами (да, они не дешевы но… закупают же по два-три монитора… причем далеко не самых дешевых)
— для многих ИТ специалистов не составит особых трудов убедить руководство несколько дней в неделю работать из дома (а у кого-то это изначально заложено в контракте — у меня например это именно так). А уж дома выбор положений тела для работы куда более широк — я например частенько работаю лежа или полулежа (на диване, а то и прямо на кровати — было пару раз когда мне просто лень было вылезать из нее утром), задрав ноги на стол, на лоджии (в теплое время года при сложенном остеклении), в библиотеке, в парке, даже на терассе гостиничного номера в Греции, на лежаке (да это не дом, но кого это колышет? И нет, я на пляже никогда не работал — на пляже это делать неудобно)
>>1. Работать с чужим кодом
Очень субъективно — меня например полностью устраивает такое лазание… особенно когда по результатам я предлагаю более эффективное решение или вытаскиваю на свет божий такой баг, который всех приводит в трепет, и который существовал зрен знает сколько («так воооот в чем дело-то было!!!») — почета и уважения в компании огребаешь столько, что потом вообше можешь заниматься чем хочешь… ну… только периодически надо повторять вау эффект
Peter1010
06.03.2018 13:10По факту только 2 3 и 6 и 9(и то в некоторых офисах эта проблема решена) пункты. Остальные просто нытьё.
Bedal
06.03.2018 18:21+1Самое тяжёлое — финальная доводка программы под живого пользователя. Всё уже сделано, всё работает, ничего интересного не осталось… а впереди ещё примерно столько же работы, сколько уже проделано. Именно этим работа прикладного программиста страшнее создания какого бы то ни было ядра, хоть чуть отделённого от живых людей. И никакое знание тонкостей организации памяти или методик поиска в небинарном дереве тут не поможет.
artyomtch
06.03.2018 19:161x. Догматические методологии «на все случаи жизни».
Которые выливаются в нечто типа «Мы не должны тратить много времени на брэйнсторм и планирование (Боже упаси, это Waterfall), но дайте нам четкий список того, что будет сделано к следующему релизу (или тоже самое с другого конца: „когда будет завершена эта фича?“).
vlreshet
07.03.2018 03:32Вникание в смежные области (читай: в бухгалтерию). Ты мечтал быть крутым программистом и писать крутые программы, а по факту уже битый час сидишь разглядывая формулы экселя, клепая под них формочку и обработчик, и осознавая где и какой баланс должен сойтись, от чего нужно брать процент, итд.
tretyakovmax
07.03.2018 09:49+1Это уже какие-то придирки. Вникание в области, в которых и работает ПО — это обязательное условие нормального понимания задачи. Не представляю как можно написать бухгалтерское ПО не вникая в бухгалтерию…
Другой вопрос, насколько глубоко нужно вникать. А «огорчение» — это когда вникать приходится самостоятельно, а не с помощью специалиста указанной области.vlreshet
07.03.2018 12:31А «огорчение» — это когда вникать приходится самостоятельно, а не с помощью специалиста указанной области.
Да, в общем то я это и имел ввиду.
guai
07.03.2018 13:20Хуже всего нечеткие задачи. Типа «ну там уже всё есть, посмотри, и сделай так же на другой системе». И начинаешь пытаться понять, какая идея стояла за этими костылями, чего хотели-то. Спросить не у кого, критерии нечеткие, кто этим будет пользоваться — тоже хз, а то бы хоть спросил, что им хочется видеть-то.
Flash_CSM
07.03.2018 19:21Картинка в топике. Показалось что палят по дискете 5,25", а может даже 8"… увы, а ведь было бы символично.
iPonic
Прям до слез…