Факты о Java-архитекторах
Java-архитектор обычно бывает одержим какой-то архитектурной идеей, которую пытается реализовать в первом попавшемся проекте. Идея обычно обладает следующими признаками: она решает несуществующую проблему, по ходу создавая намного более серьезные проблемы, и затрудняет написание тривиального кода (*). Другие участники проекта, в котором Java-архитектор пытается реализовать свою идею, обычно бывают против, но соглашаются, чтобы его не обидеть. Как только Java-архитектор увольняется, эту архитектурную идею обычно долго и нудно выкорчевывают из проекта. Какие-то ее останки остаются догнивать в самых затхлых местах кодовой базы, пугая случайно заглянувших туда джуниоров.Хмм... Столько букаф... А вот .NET архитектор просто над всеми смеётся и пишет ControllableQuery.
Хмм... Столько букаф... А вот .NET архитектор просто над всеми смеётся и пишет ControllableQuery.Ты не понял мой тонкий юмор. Перечитай примечание.
А ведь такие упоротые — это реальность.
Надо еще что-то про спецификации написать.
Перед тем как приступить к кодингу любой задачи, настоящий архитектор пишет Спецификацию. Это многостраничный документ, большую часть места которого занимают таблички с описанием полей всевозможных функций, таблиц бд, и пр. Типичный пример строчки в таких таблицах - user_id: идентификатор пользователя.
Информацию о том, как должна работать реализуемая фича, и детали реализации архитектор обсуждает с пользователями и своими самыми опытными программистами.
Собрав первоначальные требования и драфт реализации, архитектор удаляется на неделю в свою пещеру мыслителя для недельного молчаливого обдумывания.
Выбравшись из пещеры архитектор обнаруживает, что за неделю его обдумывания у пользователей и коллег появились новые идеи. Тяжело вздыхая, архитектор берет еще один недельный таймаут на переписывание Спецификации. Так продолжается, пока архитектору не надоедает, и в ответ на очередное замечательное предложение изменить чуть-чуть архитектуру чтобы получить двукратный прирост производительности одновременно уменьшив стоимость разработки, он хлопает рукой по столу, говорит баста, производительность нашей системы и так уже на уровне, продукт находится в финальной стадии проектирования - ничего менять не будем!
Понурившиеся коллеги разбредаются по своим местам, и начинают грызть свежеполученный талмуд Спецификации.
PS Любые совпадения с реальными персонажами и событиями случайны.
Перед тем как приступить к кодингу любой задачи, настоящий архитектор пишет Спецификацию. Это многостраничный документ, большую часть места которого занимают таблички с описанием полей всевозможных функций, таблиц бд, и пр. Типичный пример строчки в таких таблицах - user_id: идентификатор пользователя.
Информацию о том, как должна работать реализуемая фича, и детали реализации архитектор обсуждает с пользователями и своими самыми опытными программистами.
Собрав первоначальные требования и драфт реализации, архитектор удаляется на неделю в свою пещеру мыслителя для недельного молчаливого обдумывания.
Выбравшись из пещеры архитектор обнаруживает, что за неделю его обдумывания у пользователей и коллег появились новые идеи. Тяжело вздыхая, архитектор берет еще один недельный таймаут на переписывание Спецификации. Так продолжается, пока архитектору не надоедает, и в ответ на очередное замечательное предложение изменить чуть-чуть архитектуру чтобы получить двукратный прирост производительности одновременно уменьшив стоимость разработки, он хлопает рукой по столу, говорит баста, производительность нашей системы и так уже на уровне, продукт находится в финальной стадии проектирования - ничего менять не будем!
Понурившиеся коллеги разбредаются по своим местам, и начинают грызть свежеполученный талмуд Спецификации.
PS Любые совпадения с реальными персонажами и событиями случайны.
А ведь такие упоротые — это реальность.ps
ничего личного. Просто мне не нравится ситуация, когда люди пытаются себя бить в грудь и кричать: "мы уж точно не такие", отказываясь замечать бревно в собственном глазу.
pps
любой сильный программист тащит в проект и реализовывает идеи от которых шарахаются все остальные. И как только уходит родоначальник идеи, то все остальные начинают потихоньку вытравлять эту идею из проекта.
любой сильный программист тащит в проект и реализовывает идеи от которых шарахаются все остальные. И как только уходит родоначальник идеи, то все остальные начинают потихоньку вытравлять эту идею из проекта.если идея говно.
если же нет, то смотрят, проникаются и сами фигачат такое же.
А вот .NET архитектор просто над всеми смеётся и пишет ControllableQuery.(С) Приписывается B_A_H_C_O_H-у по мнению .
8)Из-за пристрастия к переусложненным Java-веб-фреймворкам, Java-архитектор обычно не в состоянии за разумное время сделать несложный веб-интерфейс. При этом он считает, что разработка веб-интерфейсов - простая задача для низкоквалифицированных программистов (в просторечии "быдлокодеров"). Данное противоречие каким-то образом не вызывает у Java-архитектора острого когнитивного диссонанса (в просторечии "баттхерта" и лишь изредка манифестируется в форме иррациональной злобы и презрения к разработчикам, использующим язык программирования PHP, которых Java-архитектор высокомерно называет "похапистами", а сам язык PHP - "говнопохапе".
В некоторых случаях архитектурная идея (см. пункт 7) Java-архитектора лежит в области создания революционного веб-фреймворка, который должен положить конец всем сложностям веб-разработки. Автор данного текста был знаком с Java-архитектором, который разрабатывал свой набор патчей к одному широкоизвестному Java-веб-фреймворку. По мнению вышеупомянутого Java-архитектора, основной проблемой данного веб-фреймворка был недостаточно продуманный жизненный цикл HTTP запроса. Эту проблему должен был решить набор патчей, который к уже имевшимся в этом веб-фреймворке шести стадиям обработки HTTP-запроса добавлял еще две.
В некоторых случаях архитектурная идея (см. пункт 7) Java-архитектора лежит в области создания революционного веб-фреймворка, который должен положить конец всем сложностям веб-разработки. Автор данного текста был знаком с Java-архитектором, который разрабатывал свой набор патчей к одному широкоизвестному Java-веб-фреймворку. По мнению вышеупомянутого Java-архитектора, основной проблемой данного веб-фреймворка был недостаточно продуманный жизненный цикл HTTP запроса. Эту проблему должен был решить набор патчей, который к уже имевшимся в этом веб-фреймворке шести стадиям обработки HTTP-запроса добавлял еще две.
если же нет, то смотрят, проникаются и сами фигачат такое же.Да, именно так. Я на прошлой неделе болел и отсутствовал четыре дня. Прихожу в пятницу, мне говорят, мы тут Controllable Query еще в один проект прикрутили. Вовремя я заболел, иначе было бы не так приятно, а так получилось, что полностью без меня перенесли и используют.
Прихожу в пятницу, мне говорят, мы тут от твоего Controllable Queryеще в один проект прикрутилисовсем с ума посходили.
Вовремя я заболел, иначебыло бы не так приятно, а так получилось, что полностью без меня перенесли и используютнечего было бы соврать на форумлокале, чтобы потешить себя любимого.
Закончив это наставление, Будда сказал:
— В то время Controllable Query был Будда Андропов, Java — Алла Пугачева, озером был омут мирских страстей, водка была по пять-двадцать, косяком было мое учение, а паровозом был я сам.
— В то время Controllable Query был Будда Андропов, Java — Алла Пугачева, озером был омут мирских страстей, водка была по пять-двадцать, косяком было мое учение, а паровозом был я сам.
совсем с ума посходилиТы так пишешь, будто-то бы сам полгода назад (да и сейчас наверное) не занимался изобретением велосипеда.
Поскольку в посте часто упоминается реляционные базы и SQL. При этом в черном свете упомянуты кардинально противоположные проекты для работы с базой Hibernate и Controllable Query, то закономерный вопрос. Как автор поста работает с реляционной базой данных из языка общего назначения? Использует string-based call level interface? использует смешанные подходы? или что-то еще?
Поскольку в посте часто упоминается реляционные базы и SQL. При этом в черном свете упомянуты кардинально противоположные проекты для работы с базой Hibernate и Controllable Query, то закономерный вопрос. Как автор поста работает с реляционной базой данных из языка общего назначения? Использует string-based call level interface? использует смешанные подходы? или что-то еще?
Я считаю наиболее удобным, когда язык общего назначения вызывает хранимые процедуры на PL/SQL. Hibernate тоже можно использовать, если следить за lazy loading и N+1 select, и не ставить себе задачу все сделать через hibernate.
Я считаю наиболее удобным, когда язык общего назначения вызывает хранимые процедуры на PL/SQL.Вопросы остались. Какой способ используется для вызова хранимых процедур на PL/SQL из языка общего назначения? Как реализуются сценарии, когда требуется dynamic SQL?
Оставить комментарий
luna89
1)Настоящий Java-архитектор не знает ничего кроме Java. Разрабатывая много лет JavaEE приложения, Java-архитектор может не владеть элементарными сведениями об используемой СУБД, или наоборот, владеть сведениями самими дикими и фантастическими, непонятно откуда взятыми.2)Это невежество обычно имеет агрессивный характер. Все, несвязанное с Java, кажется Java-архитектору имманентно неправильным и не имеющим право на существование. Встретив в коде более-менее нестандартный SQL, он приходит в ярость и заменяет его на row-by-row обработку с использованием Hibernate (см. далее). Такую же реакцию вызывает простенький javascipt для валидации элементарной формы - он выкорчевывается и заменяется на GWT. Со временем Java-архитектор окукливается до такой степени, что грепает логи с помощью apache ant.
3)Java-архитектор имеет странные представления о сравнительной ценности различных технологий. Зачастую не имея базовых знаний в Computer Science или не умея написать более-менее сложный SQL-запрос, в свободное время он тем не менее не стремится ликвидировать пробелы в базовых знаниях, а изучает внутренности какого-то Java-фреймворка.
4)Java-архитектор обычно очень ценит знания о java.util.concurrent и java memory model и очень любит применять эти знания, но редко ему удается применить эти знания к месту и по делу. Один Java-архитектор рассказывал мне, что для импорта CSV-файла в СУБД резал его на части и загружал в несколько потоков. О встроенных в СУБД средствах импорта он не знал по причине, изложенной в пунктах 1 и 2. На собеседовании обязательно спрашивает о double checked locking pattern, о котором прочитал на хабрахабре.
5)Написав с помощью хибернейта сайт, который, чтобы показать главную страницу, делает 1000 запросов к базе, Java-архитектор винит СУБД в том, что она тормозит. Он считает, что проблему должно решить горизонтальное масштабирование (в запущенных случаях горизонтально масштабируется даже какая-нибудь внутренняя автоматизация для отдела из трех человек). Обычно винит во всем SQL и ACID overhead (хотя обычно не может объяснить в чем заключается этот overhead). Также зачастую утверждает, что join - удар по производительности. Обычно считает, что SQL - продукт заговора коррумпированных академических ученых, подкупленных компанией Oracle. По мнению Java-архитектора, в последние годы коррумпированные ученые были наголову разгромлены другими, некоррумпированными учеными, которые открыли и опубликовали CAP-теорему. Непоколебимо убежден в том, что эта теорема опровергает существование СУБД Oracle, хотя не может даже уверенно назвать все слова, составляющие акроним CAP.
6)Очень любит XML. Опытный Java-архитектор обычно имеет за плечами несколько проектов, имевших в составе DSL, основанный на XML. Обычно этот DSL позволяет делать все то же самое, что и обычный код на Java, но не обладает такой же простотой и гибкостью.
7)Java-архитектор обычно бывает одержим какой-то архитектурной идеей, которую пытается реализовать в первом попавшемся проекте. Идея обычно обладает следующими признаками: она решает несуществующую проблему, по ходу создавая намного более серьезные проблемы, и затрудняет написание тривиального кода (*). Другие участники проекта, в котором Java-архитектор пытается реализовать свою идею, обычно бывают против, но соглашаются, чтобы его не обидеть. Как только Java-архитектор увольняется, эту архитектурную идею обычно долго и нудно выкорчевывают из проекта. Какие-то ее останки остаются догнивать в самых затхлых местах кодовой базы, пугая случайно заглянувших туда джуниоров.
(*)Постоянные читатели этого раздела наверное вспомнили как минимум одну архитектурную идею, удовлетворяющую этим признакам.