Ниже предлагается полушуточная типология программистов, которые работают в больших корпорациях, банках и т.д. с самописными и с вендорскими системами, что в целом иронично называют bloody enterprise. Кстати, переводить эту идиому следует не "кровавый" энтерпрайз, что не имеет никакого смысла, а "проклятый" энтерпрайз - горы кода, написанного на разных языках, под разное системное ПО, на разных БД, куча различного оборудования. Внедрять, поддерживать и развивать системы в больших корпорациях сложно, именно из-за огромного количества взаимосвязей и разнородностей систем. Спасает этих разработчиков только то, что в корпоративном мире, в большинстве случаев, толерантность к ошибкам высокая и большинство ошибок сходят с рук (при условии быстрого исправления).
Первый тип - быстрые программисты. С такими сталкиваешься редко. Это эрудированные и увлеченные люди, обычно занимающие высокое положение в иерархии разработчиков (тим лиды или что-то около). Основная особенность - высокая скорость написания кода и способность быстро осваивать новые технологии. Думаю, для корпоративной среды это ценные сотрудники (высокая производительность, без оглядки на качество, приветствуется). Качество кода у таких программистов не всегда высокое, чаще наоборот. Иногда код сложный. Один раз я просматривал код за одним из таких специалистов и он меня поразил одной особенностью. Это был код высококлассного спеца, но выглядел он как набросок - широкими мазками была сформирована структура, но вот детали были иногда просто не реализованы. Обычно код таких программистов приходится допиливать и доводить до приемлемого качества, но главное преимущество остается: код очень быстро появляется и сразу в больших объемах. Работая с таким кодом, чаще всего находишься в растерянности от широты мысли и количества творческих идей автора.
Второй тип - педанты. Код этих программистов пишется со средней скоростью, обычно он качественный в плане надежности и отсутствия ошибок, но часто бывает перегружен количеством рассмотренных кейсов, проверок и т.д. Код также сложный - со сложными для понимания структурами и алгоритмами, от него нет чувства легкости, он тяжелый и очень трудно воспринимается при чтении. Один раз я сталкивался с кодом квалифицированного педанта, который практиковал очень длинные строки - по несколько сотен символов: вызовы методов с большим количеством параметров, каждый из которых сам был вызовом других методов или конструкторов. Править такой код чрезвычайно сложно (трудно понимать для чего сделаны те или иные вещи), а главное страшно - всегда есть опасность что-то зацепить и все сломать.
Третий тип - расслабленные. Часто это начинающие программисты, или программисты, которые еще не погрузились в тему или не хотят (не могут) погружаться. Эти программисты производят тип кода, который часто вызывает удивление при чтении (WTF). В нем много странных решений, много ошибок использования API, структурных проблем. Плюс в том, что кода обычно немного и он не очень сложен для понимания. Проще всего бывает его переписать сразу или по кускам. В таком коде могут быть ненужные проверки, которые были вставлены по непониманию или по перестраховке. Править код таких программистов иногда даже приятно - повышаешь самооценку, чувствуешь себя умнее автора.
Четвертый тип - догматисты. Код таких программистов четко следует какому-то стилю (догме, правилам), причем сами правила часто совершенно удивительны - например в Java это может быть избыточное обязательное использование final, где нужно и где не нужно. Их код при чтении вызывает раздражение именно своим стилем оформления, который почему-то часто не соответствует общепринятым стандартам. Такой догматизм мало что дает заказчику, но часто очень бесит коллег по команде.
Пятый тип - скупые программисты. Чаще всего пишут медленнее всех, но код качественный, чаще всего не вызывающий проблем при сопровождении и содержащий малое количество ошибок. Кода мало (как раз для выполнения поставленной задачи), он не блещет какими-то идеями и абстракцями, часто очень упрощенный, можно сказать, написанный "в лоб". Это хороший вариант для задач, где нужно точечно поправить какой-то небольшой кусок, причем максимально подстраховаться от регресса. В корпоративном мире такие программисты чаще всего недооцениваются, поскольку работают медленно.
Шестой тип - технологисты. Код изобилует примерами применения технологий к месту и нет. Особенно тяжелые случаи наблюдались в мире J2EE, когда ими создается куча прослоек и абстракций, чаще всего в случаях, где вообще не предполагается получить от них пользу для бизнеса. Если такие программисты занимают ведущие позиции в команде, то их подход может привести к краху весь проект. Я участвовал в таком начинании, где код сразу писался под все доступные на тот момент реализации EJB, с дико сложными решениями для учета всех различий. Также в этом проекте зачем-то сразу писался свой Look-N-Feel для Java, что очень затратно, а смысла имеет крайне мало. В Java8 код таких программистов перегружен использованием Stream API и прочих нововведений.
Седьмой тип - программисты начальники или программисты-заказчики. Совершенно безобидны, если пишут и сопровождают свой код сами. Я слышал про трейдеров в каком-то банке, которые понаписали себе кода на Haskell (в других местах на R) и самостоятельно решали все возникающие проблемы. Головная боль начинается, если такой код передается вдруг на сопровождение профессиональным программистам. Чаще всего, такой код проще переписать заново, что обычно не очень приветствуется авторами (там уже все написано, только нужно немного поправить и все). Такой код также случается у начинающих программистов, которые вдруг написали много кода, который ушел в продакшен, а сами они перешли в другое подразделение или вообще в бизнес. Переписать много кода сразу сложно, а поддерживать его, а, главное, следовать исходной архитектуре, очень сложно, а иногда просто неприятно.
Комментарии (38)
Ant80
14.06.2022 10:33+2тут напрашивается исследование. оценить хотя бы пару сотен, а лучше тысячу корпоративных программистов по параметрам скорость, читаемость кода, количество ошибок, сложность решаемых задач, опыт работы итд, потом кластеризовать и уже потом рассуждать с уверенностью :))
knigarnya Автор
15.06.2022 08:41мой экспромт имел другую (полушуточную) цель - показать антипаттерны, с которыми я столкнулся на своем опыте) заметьте, что почти все типы имеют недостатки, что очевидно не покрывает всю выборку
GooG2e
15.06.2022 09:40+3Так иногда все эти параметры прям дико зависят от управления и процессов в компании.
Условно один программист работал в компании, где постановки тщательно обдумывались, обсуждались и т.д. прежде чем отдаваться в разработку - у такого разработчика и код будет чаще писаться быстро с минимумом ошибок, ненужных абстракций, проверок и т.д. (в большинстве, но не всегда). А есть другой программист - в его компании постановки делалис на тяп-ляп, ни с кем никогда не согласовывались, после решения задачи по десять раз переделывались, в процессе постоянно всплывали проблемы - такой программист хошь не хошь, а начнёт везде перестраховываться, чтобы иметь возможность потом достаточно быстро ввести самые параноидальные изменения.
Поэтому я бы сказал, что на то каким становится программист очень сильно влияет компания. Да, думаю после 10-20 лет стажа может быть уже достаточно тяжело изменить стиль, но раньше всё вполне себе решают процессы и организация в компании.
kwolfy
14.06.2022 10:41+16Еще забыли один тип программистов - эффективные гавнокодеры. Решающие все задачи в лоб с максимальным копи-пастом вместо постройки архитектуры. Отличаются тем, что дают бизнесу максимально быстро продукт плохого качества с технической точки зрения и терпимого внешне. Такие сотрудники ценятся по своему, часто собирают вокруг себя похожих и объединяются в гавнокод-команды.
MyraJKee
14.06.2022 14:10+3Работал в такой недавно. Это боль. Особенно когда на позиции тимлида такой. Принцип - работает, не трожь. Один знает как работает эта куча мусора.
GooG2e
15.06.2022 09:47+1а когда вся компания такая - это же тихий ужас
Приходишь, пытаешься это разгрести, довести необходимую бюррократию до конца, а в ответ - у нас на это нет ресурсов...
zloddey
15.06.2022 13:25Ха, потому он и тимлид. Сие "тайное знание" есть его конкурентное преимущество перед неофитами. А если они стремятся всё прибрать, то лишат его этого преимущества. Поэтому, конечно, будет сопротивляться переделкам до последнего.
IntActment
17.06.2022 04:09Кстати, в японских аутсорс-компаниях это скорее правило, чем исключение. Тут есть такое явление - "заказчик - бог и всегда прав". Все это пришло из сферы услуг и проникло повсюду. И местные тимлиды вместе со стажем впитывают в себя то, как надо угодить "букве заказа", а не ее "духу". Тут принято все решать "в лоб". Попробуй убедить тимлида, что даже в мире эмбеддед стоит использовать ассерты вместо игнорирования тысяч варнингов; если используется магический указатель в неизвестность - выделите ему хотя бы именованную константу; что клиническая боязнь mallocа - не оправдание для отсутствия архитектуры и т.д. А потом когда этот зоопарк заказчик требует прогнать через статический анализатор, тимлид требует с тебя составить кучу экселек, составленных по стандартам крупных корпораций с максимально переусложненной бюрократической частью, где должно быть пересказано текстом где, почему исправлен каждый из нескольких тысяч варнингов, как, кем исправлен, кем и когда проведено ревью этих исправлений, чтобы в глазах заказчика выглядеть солидной фирмой. И вишенка на торте - для чистоты отчета "на всякий случай" удалить из проекта и с файловой системы все неиспользуемые файлы (сиди парси логи линкера о неиспользуемых символах, составляй списки файлов и пиши утилиту удаления всех этих файлов "на время прогона анализатора", так как в будущем это нужно будет повторять снова).Уже половина успеха, если вообще разрешили для автоматизации этого процесса такую утилиту написать, а не "полировать тарелки" руками. И все это уже тимлид пообещал заказчикам сделать до завтра... Простите, наболело.
ilyastuit
14.06.2022 14:22А какая у автора экспертиза?) В профиле вижу участие в 1С-Битрикс
knigarnya Автор
14.06.2022 14:25У меня стандартная для корпоративного мира экспертиза - Java/Oracle/Linux, немного MS SQL. 1С интересовался лет 10 назад, когда была идея поизучать что-то помимо Java, но это было давно и неправда)
dim_s
14.06.2022 21:20Про первый тип, почему детали не реализуются подробно, потому что заранее написанный код никому не нужен и в перспективе может стать ненужным куском кода. Не нужно писать код, который скоро не уйдет в продакшен или в прототип хотя бы.
dyadyaSerezha
14.06.2022 22:54+6Ну допустим, их 7 типов. Или 3. Или 18. Какой полезный практический смысл имеет такая "классификация"? По-моему, никакого.
knigarnya Автор
15.06.2022 08:51+1Смысл простой - показать антипаттерны поведения программистов в корпоративной разработке. А вообще, для меня хороший корпоративный программист этот тот, у кого:
Код соответствует стандартному Java стилю, код не имеет необычных идиом
Код простой для восприятия, для чтения, пускай неэффективный (лучше код будет работать медленнее на 10-20%, чем нечитабельнее на 50%
Код имеет структуру и хорошие абстракции, позволяющие его развивать в дальнейшем
Код максимально лаконичный, без излишнего использования технологий и учета кейсов, которые не случаются на практике
Код не валится при первой же проблеме или хотя бы валится с логированием
SpiderEkb
15.06.2022 08:53+4горы кода, написанного на разных языках, под разное системное ПО, на разных БД, куча различного оборудования
Естественно. А как Вы себе это представляете? Ну вот у нас - есть ядро АБС, работающее на серверах IBM Power9 (Power E980, 120 процессорных ядер Power9, RAM 12Тб, 400Тб на SSD, OS IBM i 7.4):
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессовОдна только процедура закрытия дня (EOD - End Of Day) в которой выполняется
обслуживание всех без исключения сделок и бизнес сущностей чего стоит - в ней производится более 500 миллионов изменений в БД, при этом eё длительность составляет около 4 часов.Но это только ядро. Вокруг него еще несколько десятков (кто-то оценивал - порядка 60-ти) различных "внешних систем", которые "общаются" с ядром (через очереди, ESB шину...) и получают от него информацию. Или предоставляют информацию для ядра.
Естественно, что все это разнесено в пространстве. И каждая система развивается в соответствии со своей бизнес-логикой и поддерживается своей командой, которая использует тот стек, который будет наиболее эффективен для выполнения их задач. Стыковка идет на уровне транспортов и протоколов обмена.
Внедрять, поддерживать и развивать системы в больших корпорациях сложно, именно из-за огромного количества взаимосвязей и разнородностей систем.
Именно так. Посему кроме всех прочих тестов есть еще интеграционный. Даже в рамках ядра, где, как сказано выше, 150+ разных программных комплексов и 27тыс. программных объектов, можно "внедрится" так, что порушится что-то соседнее. Или не порушится, но замедлится (что в определенных ситуациях становится катастрофой).
Спасает этих разработчиков только то, что в корпоративном мире, в большинстве случаев, толерантность к ошибкам высокая и большинство ошибок сходят с рук (при условии быстрого исправления).
Мягко говоря, неправда. Час простоя АБС (только ядра) может стоить банку до 24 миллионов рублей прямых финансовых потерь при кратковременной недоступности. Это не учитывая репутационных потерь, которые могут привести к прекращению банковской деятельности в целом.
Посему тесты многоуровневые. Кодревью, автотесты, компонентное тестирование (на соответствие FSD), бизнес-тесты на соответствие BRD, нагрузочное тестирование, интеграционное тестирование (последние два теста проводятся на отдельном prelive сервере - копии промсреды с полным объемом данных).
Эффективность кода поставлена во краю угла. Есть список "нефункциональных требований" - рекомендаций и ограничений по использованию тех или иных инструментов именно с точки зрения эффективности использования ресурсов (в первую очередь это касается ресурсов CPU и работы с таблицами, особенно большими и наиболее интенсивно используемыми).
И да, код порой бывает сложный и нетривиальный. Когда замороченная бизнес-логика начинает реализовываться с предельной эффективностью. Там все идет в ход - создание витрин, кеширование данных предыдущих вызовов и т.д. и т.п. Решения "в лоб" тут не проходят в 90% случаев по причине малой эффективности и несоответствия "нефункциональным требованиям". Ну разве что это какая-то совсем примитивная типовая задачка без особой логики.
Так что во всей этой классификации не увидел никого, кто мог бы у нас прижиться.
Ivan22
15.06.2022 12:39без обид, но вы динозавры, вопрос только в скорости вымирания
DrPass
15.06.2022 12:49+5На самом деле ваш собеседник только что описал ИТ-инфраструктуру практически любой крупной компании :) Да, они все не вечные, но и любая из молодых компаний с эффективно спроектированной инфраструктурой станет абсолютно такой же через какой-то не слишком продолжительный период роста бизнеса.
SpiderEkb
16.06.2022 10:20Да, Вы абсолютно правы.
любая из молодых компаний с эффективно спроектированной инфраструктурой станет абсолютно такой же через какой-то не слишком продолжительный период роста бизнеса
Тут ключевое слово "с эффективно спроектированной инфраструктурой". Причем, изначально эффективно спроектированной. Такой, которая поддерживает и, главное, выдерживает масштабирование в достаточно широких пределах.
У нас за последний год количество клиентов увеличилось на 25% (это данные не из официального отчета, а просто прирост количества активных записей в основной таблице клиентов - то, с чем мы, собственно, работаем). Порядок величины - несколько десятков миллионов активных записей.
Из того, с чем пришлось сталкиваться лично - после известных событий был период, когда к нам мигрировало очень много клиентов из других банков. И вот возникла проблема - был один процесс, который автоматизировал загрузку проводок из одной из внешних систем. Обычный объем был порядка 100 000 проводок в сутки что занимало минут 10. А тут речь пошла о 5 000 000 в сутки... Пришлось несколько модифицировать процесс (в основном в плане распараллеливания загрузки на несколько потоков). В результате через неделю уже была готова новая версия, которая грузила 5 000 000 примерно за 35 минут. Да, больше чем было в три раза, но заказчика такой результат устроил и по нагрузке на сервер тоже уложились в допустимые пределы. При необходимости (исключительно настройками) можно увеличить количество потоков, время сократится, но ценой увеличения нагрузки.
Да, много задач "на оптимизацию". Но все это локально - отдельные процессы, модули которые демонстрируют неоптимальность при возросшей нагрузке. Какие-то процессы периодически выносятся на внешние системы.
Но в целом система достаточно стабильна и масштабируема.
вы динозавры, вопрос только в скорости вымирания
Ну это уже много лет слышу. И не только в отношении нас, но в принципе в отношении IBM i. И не только у нас, но во всем мире. Однако, система живет, развивается и вымирать не думает.
На эту тему написано очень много. Вот первое что попалось:
Worrying about the future of IBMi? Here are some facts!
Why Should You Not Worry About the Future of IBM iSeries Systems?
What Will The Future of IBM i Look Like?
anton_pi
15.06.2022 14:44Интересно посмотреть на трейдеров, которые сами выучили хаскель и написали себе в помощь скрипты — какая-то фантастика. Можно подробности?
knigarnya Автор
15.06.2022 14:52Никакой фантастики, но, конечно, не все трейдеры в финансах/банках такие. Но многие, а особенно так называемые кванты, имеют базу в виде высшего математического или физического образования или даже PhD/к.ф-м.н и для них записать свои выкладки на удобном языке (R/Python) довольно адекватная задача, другое дело, что код у них чаще всего получается не промышленного качества, а из серии "сел и написал". Насчет Haskell - это было в западном банке и меня тоже в свое время удивило, но вот там такие люди встречаются. Почему именно Haskell не знаю, но задача была расчетная, это точно.
AnthonyMikh
15.06.2022 23:13+1В Java8 код таких программистов перегружен использованием Stream API и прочих нововведений.
Как будто что-то плохое, ей-богу.
pirt
16.06.2022 09:24+1Забыли восьмой тип - халявщики. В крупной компании всегда есть шанс затеряться где-то в недрах и создавать видимость работы. Главное - правильно отчитываться перед менеджером. Код обычно ужасен и попадает в прод только после ревью/перелопачивания более грамотным коллегой. Слава богу, его обычно мало. Особенно распространен в Германии, где договор плюс профсоюз почти не оставляют шансов компании уволить такого "специалиста" в одностороннем порядке.
knigarnya Автор
16.06.2022 11:23Да, у этого типа есть некоторая корреляция с "Расслабленными" (тип 3) - тут разница в мотивации, либо человек хочет, но просто еще не умеет, либо он сознательно халявит. Еще бывает вариант когда программист настолько занят своими личными делами, что просто не может полностью погрузиться в задачу и делает поверхностные решения, на которые нужно меньше ресурсов головного мозга)
Hamlet_dat
16.06.2022 11:20Автор относится к третьему типу писателей на Хабре.
Их тексты сами по себе не несут никакой полезной информации, но позволяют комментариям захватить внимание читателей настолько, что не только смысл, но и сам факт существования статьи в ходе чтения становится сомнительным.
knigarnya Автор
16.06.2022 11:21"Типы писателей" на Хабре - хорошая тема для статьи! Какие другие 2? Или их больше в вашей типологии?
Graf54r
Ага-ага, метод длинною в жизнь, и куча переменных и нужно понять будут эту переменную переиспользовать или можно выбросить ее из гловы т.к. ее вот тут задали, а дальше только из нее читают. Так что добавлять final ко всем переменным которые не мутабельные(т.е. мы из них дальше будем только читать) это очень удобно для чтения кода.
knigarnya Автор
Я имел ввиду выражения такого плана и подобные им:
catch (final SomeExceptionType e)но от вашего примера уже даже на словах тошно)
KvanTTT
Это удобно для полей, но для переменных слишком избыточная запись, обычно локальные переменные имеют небольшой срок жизни.
Maccimo
Методы «длиною в жизнь» не нужны. А если вдруг такой попадётся, то find usages есть сейчас в любой IDE.
Zer0Sum
Мне рассказывали, что в некоторых крупных компаниях использование final является даже обязательным требованием, и я сам их всегда ставлю даже в своих набросках кода, в качестве привычки. Не думал, что это может кого-то раздражать. Но теперь задумаюсь.
Если мне понятно объяснят, что это бессмысленное раздувание кода, которое раздражает других людей, я перестану так делать.
К сожалению, я не помню подробностей, но использование final вроде приносит некую пользу с точки зрения использования памяти.
В Rust, например, все переменные по-умолчанию "final", а он считается очень безопасным и производительным языком (не только поэтому, конечно).
Я подумал, что и в Java буду делать все свои переменные final "по-умолчанию", только вручную. Чтобы было как в Расте. Или всегда использовать Optional там, где есть шанс вернуть null (что в Расте тоже вшито в язык изначально).
Может я и зря так решил, теперь вот сомневаюсь как лучше.
knigarnya Автор
Польза есть, безусловно, и в каждом конкретном случае использование final можно обосновать, например, final в catch защищает от переприсваивания exception внутри блока catch. Проблема в том, что это, очевидно, не общепринятая практика (например, в исходниках JDK этого нет), а также в том, что это перегружает код и делает его менее читабельным. В корпорациях работа программиста на 80% состоит из чтения кода, поэтому любой необязательный момент, который ухудшает читабельность, нужно избегать.
И да, действительно, я тоже сталкивался с тем, что это является обязательным, но я такую практику не поддерживаю и считаю ее вредной.
SimSonic
Лучше настроить IDE чтобы мутабельные переменные красились ярко-красно.
Neikist
В котлине конечно разделение идет по var/val, потому там ничего не загромождается, просто везде val по умолчанию пишем. Но вот дарт уже больше похож на java, и когда на нем пишу всегда использую final. Ибо реально защищает от ошибок по невнимательности.
martin_wanderer
Как знакомо и как больно. Ну к счастью та же IDEA уже года два как подчеркивает все мутабельные переменные. А вот повсеместная простановка final не спасает, потому что про НЕ помеченную переменную ты все равно не знаешь, это потому, что она мутабельная или ее просто забыли пометить. Мне кажется, всё-таки в первую очередь стоит бороться с "методами длиною в жизнь". Да и сама мутабельнось в типичном бизнес-коде редко оправдана.