Месье знает толк в извращениях

[catodon]

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

Именно вышеприведенная цитата приходит в голову вашему покорному слуге при просмотре сообществ вроде "The Daily WTF". Ибо хоть кодить мне надо редко, но координация проектов подразумевает необходимость заглядывать в чужой код и разбираться в технических решениях. Ну и вообще за годы работы в IT пришлось повидать то, чего лучше бы я не видел. Тут будет много технического мата, непосвещенным под кат лучше не ходить.

Построение моделей данных. Почему-то это не преподается отдельным предметом у ВУЗ-ах, а надо бы. Когда серьезный дядя презентирует предложение "универсальной" модели из 3-4 классов, содержащих по 250-300 полей (только полей, не методов) каждый, это смешно. Серьезная фирма генерит около тысячи классов экселевским макросом из экселевских же таблиц и при этом они вообще не имеют структуры наследования, потому что руководитель отдела искренне считает это ненужным баловством. Это уже не смешно: привет разработчикам, которым когда-нибудь понадобится общее свойство или метод для всего этого зоопарка. Некий разработчик пытается впихнуть в релациональную базу объектно-ориентированную модель без изменений. Добавляет взаимные циркулярные ссылки, получает stack overflow при сериализации. Хотя бывает и наоборот: програмер познакомился в релациональными базами и теперь строит модели данных только этим квадратно-гнездовым методом, даже там, где оно не нужно. Причем как раз с данными из баз происходят всякие весёлые вещи. Например: для выборки записей грузим всю таблицу в память целиком и выбираем там, а ненужное выбрасываем. Не так уж редко встречается, кстати. Запрос с параметрами? Нет, не слышали. Бывают еще любители все данные пихать в один большой BLOB. Впрочем, для них сейчас распространены базы NoSQL, с которыми они могут удовлетворять свои извращённые наклонности.

Интерфейсы. Что можно напортачить при передаче простого объекта по REST/JSON в Java? Такого, где только пара полей примитивных типов? Например, можно задать тип поля, не как int, а как Integer, так что оно неожиданно может иметь значение null. В особо запущенных случаях оба варианта встречаются о одном и том же интерфейсе. Правда, численные поля еще избежали незавидной участи Булевских. Этих бедолаг вообще имеют и в хвост и в гриву, определяя их как boolean (true, false), Boolean (true, false, null), int (ноль, не ноль) или Integer (ноль, не ноль, null pointer exception). Правда, попадаются и совсем продвинутые товарищи, считающие такой подход "ванильным" и определяющие логические переменные сразу как String. Изящность этого решения заключается в том, что тут не только возможет вариант null, но еще надо угадать, какое текстовое представление выбрал прогер: "true"/"false", "t"/"f", "yes"/"no", "y"/"n" или "ja"/"nein". Хотя я видел даже особо хитрый комбо-вариант для истинных ценителей: "0"/"1" (да, именно строкой, а не цифрой).

А еще есть такая вещь, как design patterns. Полезная штука, если применять её с умом. С умом, ага. Иначе получается как со стеклянным дильдо из поговорки про дурака. У меня когда-то в команде был человек, который очень любил design patterns. Настолько, что нашел свой отдельный pattern для взаимодействия 90% классов в проекте. Для каждого из них. Не только нашел, но и имплементировал, трудоголик хренов. В результате ни один вызов метода между классами (даже самый тривиальный) не шел иначе как через прокладку из 2-3 интерфейсов. Если повезет. Иначе больше. К сожалению, я не успел вовремя остановить этот процесс. Студента, который потом дорабытывал проект, мне было искрене жаль. Впрочем, то, что нас не убивает, делает нас сильнее.

Еще встречается мой "любимый" тип программиста. Я называю таких "техно-фриками" или "декораторами". Они пишут программы, основаные на самых передовых технологиях, украшенные красивыми интерфейсами для мониторинга, управления и т. д. Куча всего красивого генерируется автоматически, логи пишутся аспектно-ориентированно и показываются в консоли разными цветами. В коде все что можно заменено лямбдами и стримами, а сам код компактен и краток. Все GUI "любовны и прельстивы" и радуют заказчика. Проблема только в том, что под этой замечательной оберткой находится рудиментано и/или криво реализованная бизнес-логика. То есть в итоге продукт красив, но не работает. Ну да, разбираться с требованиями к продукту - это же скучно и никак не связано с новейшими разработками. Да и времени у них на это обычно уже не остаётся после имплементации всех свистоперделок. В худшем случае базовые требования оказываются несовместимы с какой-то особенно передовой технологией и все приходится переделывать, чтобы было хоть и менее красиво, но делало то, что от него требуется. Стараюсь "декораторов" вовремя распознавать и по возможности подсыпать цианистого калия в кофе держать подальше от наших проектов.



Костыли - это классика. Когда-то давно один разработчик писал некий интерфейс. При этом он умудрился запихать заведомо опциональный параметр в середину URI как path-переменную. Когда это заметили, интерфейс уже вовсю использовался несколькими клиентскими системами, которые пришлось бы релизить заново. Посему после долгого обсуждения был сделан костыль: если параметр не нужен, мы пихаем туда строчное значение "void". Да, некрасиво, но работает. Прошла пара лет, система разрасталась, возникали новые интерфейсы. И вот архитектор, к своему удивлению, обнаруживает сервисы, коротые реализованы совсем по-другому и поддерживают опциональные значения, но дружно продолжают требовать этот самый идиотский "void" при отсутствии параметра, потом выкидывая это значение в мусор. То есть прогеры раз за разом перенимали все как есть и ни один не потрудился разобраться, зачем оно там. Есть еще soft-вариант костылей: когда применение метода интерфейса меняется, а название остается, ибо метод записан в API и используется другими сервисами. В результате на вызов "getEyeColor()" надо выдавать цвет шнурков на правом ботинке (в первой, давно забытой версии шнурки как раз к цвету глаз и подбирались, а потом еще появилась мода на разные шнурки справа и слева), причем из документации это не ясно.



Еще есть старые проекты. Иногда системный ландшафт построен на 5-6 технологиях из разных эпох, а в центре находится написанная на C++ (в лучшем случае) или на Фортране (в особо запущенном) 25 лет назад ядро. Это ядро подперто десятками костылей, которые иногда подпирают даже не само ядро, а другие костыли. Как оно точно работает уже никто не помнит, а переписать его тоже проблематично, потому что для этого сначало надо разобраться, как оно точно работает (см. выше). И вообще специалистов по древней версии C++ или Фортрану еще пойди найди. Самое эффективное в данной ситуации - облить все бензином и поджечь построить заново весь ландшафт. Однако он уже настолько разросся, что у фирмы не хватит на это ресурсов, тогда уже можно сразу заявлять о банкротстве. Хотя, если ядро в своё время разрабатывалось добротно, то система может работать долгие годы без серьёзных проблем, пусть и запутываясь все больше и больше. То есть каждая следующая доработка будет требовать все больших усилий и большего времени. А также все новых и новых новых костылей и внешних слоев. Которые тоже потихоньку устаревают. Особенно интересный момент наступает, когда надо что-то делать с частями, в которых не было предусмотрено четкого разделения фронтенда и бэкенда. А такое раньше встречалось нередко. В результате мы имеем, к примеру фронтенд, сделанный через жо JSF, который работает исключительно на древней версии "Апача" (со всеми тогдашними дырами и глюками), посему перейти на новый Wildfly без полной переделки не получается.

Ну и немного веселухи напоследок. Имеется система, симулирующая развитие по времени сложного процесса. Обычно такие системы работают либо с фиксированным шагом по времени либо прыгая на разную "темпоральную дистанцию" от события к событию. Изначально система была настроена на фиксированный шаг и отлично работала несколько лет. Потом ее запустили в другом режиме. Она проработала какое-то время без сбоев, но в определенный момент начала наглухо зависать. Расчёты уходят в бесконечный цикл и привет. Причем какие-то расчёты работают, а какие-то нет: определить, что именно влияет на ошибку, не получается. Разработчики начинают копаться в коде. Копаются долго, пока кто-то не натыкается на строчку, округляющую шаг по времени в секундах до второго знака после запятой. Без внятных причин. Без комментариев и документации. То есть как только у нас возникает шаг, например, в 3 ms, он внутри тихо превращается в ноль, система начинает снова считать с того же места и так до бесконечности. Разработчик, писавший это, тоже уже давно ушел.

Возможно, кто-нибудь возразит, что такая проблема решается тестами. Да, кое-что решается, но "100% покрытие тестами" процесса еще ни разу не означает, что все серьёзные проблемы будут найдены. В вышеописанном случае, например, никакие тесты не помогли, потому что тестировать шаг именно между 1 и 10 ms никто не додумался. Кроме техники тут надо учитывать еще и психологию. Именно требованое руководства (или системы деполймента) покрывать всё тестами рождает у разработчиков тенденцию массово писать бессмысленные тесты для примитивных методов вместо вдумчивого и целенаправленного тестирования действительно критических мест. И это в итоге увеличивает количество незамеченных ошибок. Мой совет: если вам на потенциальной новой работе начинают рассказывать про test-driven development, то fly you fools!!! тихо и незаметно уходите, и не возвращайтесь туда больше. С этого места можно было бы написать много чего о разных дурацких заносах в организации проектов (например, повальное увлечение модными методами без понимания их свойств и контекста), но это уже совсем другая тема...

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

Comments

[yajohn]

Я сейчас в проекте, где софт писали инженера. Это адѣ.
Самопальная среда исполнения скриптов, со своим редактором и дебагером. С глобальными переменными, арифметикой указателей намертво срощеными с ГУИ. Скрипты версионируются копипейстом и ссылаются друг на друга. Данные в реляционной ДБ, доступ частично прямой, частично через веб сервисы. Все это запускается специальным ланчером, который в зависимости от адреса машины откуда стартует скрипт (да, все в сети) выбирает ту или иную версию среды исполнения (сиречь сетевую папку с EXE и конфигами). Конфиги по ходу - стрые добрые ini, но для считывания КАЖДОГО значения файл (сетевой, напомню) открывается, читается и снова закрывается. Ах да, чуть не забыл, в БД что-то около сотни тысяч таблиц, в некоторых десятки миллионов записей. Кое что даже нормализовано, но как-то странновато. Запросы выполняющиеся более нескольких часов - повседневность.
И вишенка на торте - все это работает. Не спрашивай.

[catodon]

Чур меня, чур! А представляешь, как весело будет, когда проектировавшие все это уйдут на другие места или на пенсию? А документации, наверное, горы? Ну как горы... горки. Горочки. Холмик. Кротовый, если быть точным. Один. Где-то точно был, надо поискать.

[yajohn]

> представляешь, как весело будет, когда проектировавшие все это уйдут
Конечно представляю. Уже ушли.

А с документацией... Есть кое что и похуже полностью отсутствующей документации: неактуальная документация.

[catodon]

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

[ukurainajin]

Якщо відкинути лінощі та патології, то недбалість дуже часто вимагають і заохочують до неї. Хто не чув про «зроби, як простіше (розумій: швидше)»?! Чудово, коли девелопер опанував високий рівень магії і примудряється попри тиск прогнозувати на кілька кроків наперед.

Я теж можу розповісти купу кумедних анекдотів, через особисту зустріч з якими я припиняю висловлюватися стримано і культурно. :)
Спало на думку, що цей текст можна переписати алегоріями, без професійної специфики. Вийшла би збірка філософських притч. «Шлях Просвітленого Розробника» не бажаєте написати? ;)

[catodon]

недбалість дуже часто вимагають і заохочують до неї

Бывает, но это прошедший день. Сегодня все работает немного по-другому. Фишка тут в том, что количество маразма определяется не столько стилем руководства, сколько уровнем команды. При любом раскладе разработчик будет делать так, как он привык и умеет, а не так, как от него требуют "сверху".

Вийшла би збірка філософських притч. «Шлях Просвітленого Розробника» не бажаєте написати? ;)

Не имеет смысла :-) Во-первых, этого добра уже много. Во-вторых, я сам не девелопер уже много лет как. Хотя еще могу к этому вернуться при необходимости.

[ukurainajin]

Я там просто відчув якісь невловиму мораль загального характеру про людську природу. Безвідносно до розробки :)

[catodon]

Нет тут никакой морали! Это совершенно аморальный пост!

[juan_gandhi]

Аплодисменты. Как это я вас раньше не читал?