Java и тяжелое наследие

Недавно перешел на Java. Впечатления с одной просто отличные: современная Java- прекрасный язык, потрясающе мощные и удобные IDE, веб-разработка на Spring 3 — просто сказка. Но с другой стороны, есть у этого языка один существенный (а по-моему, самый главный) недостаток — языку 15 лет, а значит, есть все шансы нарваться на проект 10-летней давности (скажем, на голых сервлетах и JDBC) который отдали на аутсорс и который придется кому-то поддерживать. И хоть язык и там и там один, ощущения от работы совсем другие, все ужасно криво, неудобно, многословно, и вообще убого.
Вопрос Java-программистам: как вы живете с этой проблемой? Как-то ограничиваете круг возможных технологий еще на собеседовании? Или идти в эту область- значит смириться с тем, что возможно придется работать и с такими проектами?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

кому не подобається джава, може перейти на С++ або голий С

він бородатіше і спадщина в нього тяжча

ну чого ви такий злий?

На Рельси, на Рельси, там майже вічний оргазм, кажуть.

Ну або на Python, там кажуть помірне задоволення. Теж надовго.

на php там кажуть — стабільно

Решил поднять топик. На момент создания были сомнения, что может я просто вечно всем недовольный ворчун, который не хочет и не любит работать.
Ан нет, работа на Java, в которой присутствует собственно разработка плюс здравый смысл и свобода в выборе инструментов — чистое удовольствие.

I ♥ Java.

Працюю на проекті, де JDBC це не найгірший варіант. І ще багато яких «скарбів» залишилось з часів 2000-го року. Але як на мене, криві руки програміста який навіть не спробував з"ясувати функціонал і зформувати правильну архітектуру до програмування роблять на багато більше шкоди. А нові технології можна впроваджувати з часом, коли зрозумієш функціонал.

Еще
* 15 лет? Да за два года такого можно наваять, что 10 лет разгребать будешь. Есть умельцы.
* В джава, кстати, за счет развитого инструментария, вычищать код намного проще и быстрее получается. Так что даже наличие голых сервлетов и JDBC еще не показатель. Важнее комманда и ее настрой. Ну и заказчик, конечно.

* Важный критерий версия java. Если до-generic (1.4 — ) - то точно печалька будет.

голые сервлеты еще ниче так- есть куда стремится. А вот я как то видел шаблонизатор до- JSP эпохи — вот это я вам скажу травма половая.

Но с другой стороны, есть у этого языка один существенный (а по-моему, самый главный) недостаток — языку 15 лет, а значит, есть все шансы нарваться на проект 10-летней давности (скажем, на голых сервлетах и JDBC) который отдали на аутсорс и который придется кому-то поддерживать.

Ви так говорите, наче
1) ніколи в житті не бачили проектів 20-літньої давності,

2) це щось погане.

Подавляющее большинство программистов мира начиная с 70ых занимаются сопровождением(поддержка его работоспособности + эволюционные изменения) старого кода. Либо своего, либо чужого. Это — норма. Так было, и так будет, и Java тут ни при чем. Хотя, раз ей 15 лет, и древний код — работает, и для совсем нового — она же используется — то значит что-то в ней есть такое здоровское.
Проблема же наступает когда хочется творить. Что-то свое и великое. Не школьным учителем математики, а доказать что там осталось у Гильберта. Не художником-оформителем, а написать чтобы мир ахнул. Не типовые многоэтажки проектировать и строить, а чтобы шейхи заказали нечто эдакое и засыпали деньгами на реализацию.

Решается же проще некуда — можете творить — творите! Не можете — так работайте. Не можете творить и не можете работать — тогда рюмка, дауншифинг, гималайские пещеры, ..., - выбор большой.

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

Если оно остановились в развитии, то что же там развивают?
Или, скажем речь о программистах MS пишущих патчи под Windows XP и прочие старые продукты?
Революции в работающем ПО очень рисковы. С точки зрения — пользователей. Если их система устраивает, то у программиста тот самый выбор — или бросить их вместе с системой, или работать.
Здесь нет как таковой проблемы, сопровождение именно старого ПО, которое уже существенно не изменится — тоже вполне — норма, обыденность. А если у вас есть таланты, то вы вполне можете уйти на другую работу, более интересную. Т.е. утрировано — проблема в собственных амбициях не подкрепленных пока (а может и навсегда) талантом, навыками и просто дерзновением.

Вижу 3 варианта:
1) Уйти
2) Ничего не менять и ходить на работу как на каторгу
3) Подстроить проект под себя, прилепить нужные Вам и полезные проекту технологии.

Собственно все. Вам решать.

Это всё круто, а что человек использующий Спринг, не юзал до этого сервлеты, и на JPA он перешел без JDBC? Если да, то сожалею:)

не всем везет на деревянные игрушки в детстве. некоторым сразу дали в руки мягкое, и сказали, что это лучше деревянного. имеет ли смысл, будучи уже взрослым, все таки купить себе деревянный кубик и лично убедиться в его деревянности?

Аналогия не верна (и вы еще удивляетесь почему вас попадаетсо править ХТМЛ, или это не вы :) )

это я )) и да мне не нравится, когда java используется для верстки страничек. если даже в древнем Perl (как и в других более и менее приличных ЯПах) мешать программный код с хтмл уже давно считается дурным тоном, среди жавистов эта практика цветет и пахнет. во всяком случае среди тех, что мне пока встречались.

что до отсылов к истории и прочим легаси технологиям, с удовольствием послушаю альтернативную точку зрения. лично мне, например, довелось поработать и с JDBC и с Hibernate, но точек пересечения я не обнаружил. экспа в первом, оказалась абсолютно бесполезной для второго. аналогично, связь между Sping (учитывая все разннобразие спрингов и экзотику типа Spring Batch) и servlets не есть очевидной.

JDBC и с Hibernate, но точек пересечения я не обнаружил

А то что хибер основан на ДжДБС? То что для многих/некоторых задач приходитсо использовать хибернейт как просто другой интерфейс выполнения запросов?

аналогично, связь между Sping (учитывая все разннобразие спрингов и экзотику типа Spring Batch) и servlets не есть очевидной.

Вот я так же не вижу аналогию :)

не всем везет на деревянные игрушки в детстве. некоторым сразу дали в руки мягкое

И в этой фразе.

Хотя подозреваю, что Кравченко Свят имел ввиду что-то вроде СпрингМВЦ.

Да имеет. Если связь между JDBC и Hibernate такая же как и между ADO.Net и EntityFrameWork, то человеку необходимо знать основы: JDBC и ADO.Net. Логика проста: зная ADO программист сможет создать EntityFramework, а вот зная EF — ADO уже не создать.

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

умение изобретать велосипеды vs умение быстро ездить на уже изобретенных

Аналогия получше. :) Суть в том, что некоторые требуют уменее быстро и долго и самостоятельно ехать на велосипеде (это уже для синьоров, обычно). «долго и самостоятельно» подразумевает умение «подкрутить» велосипед в дороге и понимание того почему и на каких участках пути он может тормозить, чтобы при возможности обойти эти участки.

Тут можно задать два вопроса.
1) Нужно ли знать, как все работает на низком уровне?

2) Нужно ли писать живые проекты на низком уровне?

п.1 — я бы сказал, что скорее нужно, но вообще это тема для флеймового треда на много страниц вроде «нужно ли программисту высшее образование». а вот п.2 — скорее нет: трудозатраты выше, производительность приложения ниже (если получился кривой велосипед вместо внешнего проверенного оптимизированного решения), понятность кода ниже. Со стороны программиста: больше негатива от работы с таким кодом, не растет опыт в востребованных на рынке труда областях. Чтобы осуществить п.1, не нужно поддерживать такой проект годами — темы не настолько сложные, достаточно остновательно проийтись по всем аспектам API в игрушечном приложении.

трудозатраты выше
Для простых случаев — да. Для чуть сложнее чем CRUD — нет.
производительность приложения ниже
Ну это надо постаратсо :)
понятность кода ниже
Понятность кода не зависит от фреймворка. Классический пример EJB (или JSF) — считался спасением всего чего только можно, а сейчас «фууу».
больше негатива от работы с таким кодом
С чего бы это?
не растет опыт в востребованных на рынке труда областях
От тут низя не согласитсо. Но это дело такое: года 4 назад Struts был во всех вакансиях, а сейчас?

Для простых случаев — да. Для чуть сложнее чем CRUD — нет.

Из CRUD и других задач, которые хорошо ложатся на ORM и популярные фреймворки, состоит значительная часть типичного веб-приложения (а иногда и все приложение :) ). Для других задач никто не мешает использовать другие методы, но пусть большой объем работы который должен и может быть простым, и будет простым.

Ну это надо постаратсо :)

например видел (правда не на Java), как велосипедостоители не подумали про n+1 problem, и вот уже вместо 2-х запросов приходит 102.

Понятность кода не зависит от фреймворка. Классический пример EJB (или JSF) — считался спасением всего чего только можно, а сейчас «фууу».

Не знаю, как был воспринят EJB2 в момент его появления, но там же сразу можно было догадаться, что что-то не то придумали по отношению плоезного кода к мусорно-шаблонному. В современной Java я такого не вижу, наоборот, все делают очень хорошо, продуманно и соблюдая DRY.

больше негатива от работы с таким кодом
С чего бы это?

Снижение квалификации и рыночной стоимости, потери времени и сил на вещи, которые можно сделать гораздо проще и быстрее — это весьма демотивирует.

Из CRUD и других задач, которые хорошо ложатся на ORM и популярные фреймворки, состоит значительная часть типичного веб-приложения (а иногда и все приложение :) ) .....

спорно. Кода для CRUDа может быть и относительно много, но самое интересное, challenging и собственно приносящее деньги как правило выходит за эту область. Процитирую умного дядьку:

... For starters, there’s no such thing as a website project. Every one is really an enterprise integration project with an HTML interface.

© Michael T. Nygard , Release It! 2007.

позвольте поинтересоваться новичку, EJB технология устарела, можно не учить? В многих вакансиях ее указывают.

EJB технология устарела

Это не совсем технология, это больше спека. JPA — это так же EJB, например. Поэтому дать рекомендацию «не учить» не могу :)

В многих вакансиях ее указывают.

В вакансиях много чего указывают. Если джун, то надо просто идти на пролом. ИМХО, если контора нормальная то не будут заострять на этом внимание, особенно для джуна. Второй момент, активное использование всего EJB, как правило, верный признак унылого проекта в стадии поддержки перед консервацией, хотя есть и исключения.

Не принимай оффер не посмотрев код

Требую на ДОУ кнопку «Поржал»

Ну если это так потенциально пугает, а рынок позволяет, то почему слабо? Я смотрел код на собеседовании.

И показывал много раз.

Я смотрел код на собеседовании.

Сколько времени вам надо чтобы оценить не маленький проект: более 100Мб исходников, 3+ года разработки, на выходе 3+ артефакта (включая минимум 2 ВАРника)?

Ну если это так потенциально пугает, а рынок позволяет, то почему слабо?

Простите, не понял данную фразу (какая-то она для меня не связная и не связана с моим комментом). Далеко не все могут показать код:
1) У аутсорсера могут быть жесткие контракты.

2) Более мение серьезная контора не будет показывать свой код или любую внутреннюю инфу первому встречному, не зависимо от того аутсорс или продуктовая.

Это Вы про аудит. «Покажите» — на своем workstation, я сам даже клавиатуру и мышь трогать не буду. 10 минут более чем достаточно, чтобы понять о чем будет идти речь.

В более-менее серьезной конторе проблемы от такого просмотра не будет. И NDA в большинстве случаев не нарушит. Другой вопрос — параноидальные конторы. В любом случае задать вопрос ничто не мешает, может быть хорошим тестом на адекватность.

10 минут более чем достаточно, чтобы понять о чем будет идти речь.

Кнопка «Поржал» нужна однозначно.

Небольшой пример:

Есть 10-летний проект в котором есть много костылей (за 10 то лет), при этом есть много вменяемого (а на мой взгляд хорошего) кода. За 10 минут вы (ну лично я уж точно) не сможете оценить качество кода. Этого времени хватит только чтобы понять качество одного «модуля» (логического куска) или чтобы бегло потыкаться по класам, но в таком случае нельзя провести нормально оценку качества кода (не вникая в то что он делает).

В любом случае задать вопрос ничто не мешает, может быть хорошим тестом на адекватность.

Этот тест будет иметь очень много «ложных срабатываний». В больших конторах есть процедуры, порой довольно бюрократичные. Есть конторы в которых не наплевательски относятся к безопасности, и то что для вас «паранойя» для многих норма.

К примеру: Ваш проект полностью опенсорс? Где его можно посмотреть? Почему МС, Оракл, Гугл не открывают весь свой код (а то что открывают, как правило утилиты, а не корневая функциональность).

Богдан, Вы или не совсем поняли мой message, или не хотите его понять. Во втором случае флеймить не о чем, для первого — разжую. Оценка качества кодобазы за время интервью — это так же реально (с приставкой не-), как и оценка подходящести кандидата или позиции. Мы все играем в игру с многими неизвестными и очень малым временем на принятие решения. Другой вопрос, что с опытом приходит понимание на чем нужно фокусироваться, и вероятность правильных решений увеличивается.

Опять же, у каждого вопроса есть область применимости, и врядли мы будем спрашивать про код на собеседовании в Гугль. И если в какой-то конторке поменьше нам адекватно скажут почему показать не могут — это тоже не проблема. Будут надувать щеки и съезжать — есть повод задуматься, насколько это соотносится с другими сигналами.

А умение тактично задавать нестандартные вопросы — это всегда хорошо для интервью. Так что я все еще не вижу что такого «ржачного» в моем совете в контексте вопроса bsod.

Так что я все еще не вижу что такого «ржачного» в моем совете в контексте вопроса bsod.

2 момента:
1) Вполне адекватная контора может вам отказать в этом. И тут важнее как они ответят.

2) Оценить код за 10 мин вряд ли даст полноценные корректные результаты.

как и оценка подходящести кандидата или позиции.

На собеседовании оценивают человека, а его навыки программирования вы можете оценить довольно поверхностно. Точно так же если вам надо оценить проект, вы можете задавать вопросы и на основании ответов делать выводы.

А «покажите мне свой код» — это очень похоже на «Сделай тестовое задания». Далеко не каждый разработчик готов тратить время на то чтобы сделать тестовое задание хорошо — но это не значит что он плохой.

и врядли мы будем спрашивать про код на собеседовании в Гугль

Почему? В гугле нет гуанокода?

Спросить о коде может и стоит (но, ИМХО, лучше поговорить с разработчиками о проекте), но скорее чтобы посмотреть на реакцию. Но

Не принимай оффер не посмотрев код

Для человека ниже гуру работать не будет, ибо результаты такого просмотра могут не соответствовать реальности (в любую сторону).

это все хорошо, но не значит что не имеет смысла спросить. Я спрашиваю. Не гуру, но полезно. Вам не подходит — дело хозяйское.

Аудит можно провести за несколько минут с помощью таких тулов как NDepend, к примеру. Общую картину точно составите.

С вами долго разговаривают после просьбы установить левую приблуду, чтобы посмотреть код?

Не только разговаривают, но и нанимают с хорошой прибавкой, когда видят какие метрики «эта левая приблуда» показывает в отчете. С надеждой что эти метрики улучшатся. Или ты предпочитаешь сказать «Ваш код — дерьмо и сопровождать я его не буду ни за какие деньги»?

Или ты предпочитаешь сказать «Ваш код — дерьмо и сопровождать я его не буду ни за какие деньги»?

Вы тему и ветку читали?

я бы не был столь категоричным. Это может быть весьма полезная мысль. Конечно, если ты джуниор, то такая просьба бы выглядела забавно. Но если тебя берут на должность старшего разработчика, ТЛ, то это вполне разумная мысль. Ты будешь знать хотя бы на что идешь и за что будешь отвечать.

Прочитайте всю ветку dou.ua/...ic/5350/#182652

я бы не был столь категоричным.

Я как раз не категоричен и говорю, что категоричная рекомендация:

Не принимай оффер не посмотрев код

Мало эффективна в общем случае.

вопрос стилистики и ее восприятия.

ну лично я обычно при разговоре с потенциальным заказчиком в том числе упоминаю, что способен быстро разбираться и приводить в чувство любой г..код

в принципе это challenge с одной стороны, и более высоко оплачивается с другой (особенно если проект уже приносит деньги, сравните с каким нить стартапом, где деньги очень лимитированы)

а про ужасно — это субьективно, как по мне вся жаба ужасна и те, кто решил что живые люди должны редактировать хмл, и те, кто написал «суперуниверсальные либы» где для простых задач надо создать пять классов и имплементировать пятнадцать интерфейсов, прокляты навеки

ну лично я обычно при разговоре с потенциальным заказчиком в том числе упоминаю, что способен быстро разбираться и приводить в чувство любой г..код

при этом от кондидата обычно требуется
— разобраться
— пофиксить критичные баги исключительно костылями (быстро и дешево)
— писать еще в том же стиле (потому что вся команда к нему уже привыкла)

а приводить в чувство не требуется (долго и дорого)

ну тут однозначного ответа нет, был проект, где я побыстрому свалил, хотя и согласны были переписывать, но там такая жуткая codebase была, что я решил не связываться

на текущем проекте обычно если критичный баг — затыкается по-быстрому, и создается таск на нормальное решение
если новые фичи — то зачастую приходится рефакторить вокруг, заодно вычищая мелкие баги

хороший код обходится недёшево, но в итоге он выгоднее чем икэбана из костылей.
вот только чтобы его получить нужно нанять девелоперов с опытом, и\или устаканить процесс разрабтки.
но д’эФфективным манагерам подай всё и сразу — за 2 недели «насобирай червонцев на рубль.»
отсорс. бессмысленный и беспощадный, развивающийся по индийской
модели.
зы: с другой стороны, благодаря маразму есть работа.

временами маразматическая.

мощные и удобные IDE, веб-разработка на Spring 3 — просто сказка

Попробуйте Play + Scala и эта «сказка» вам покажется адом из нагромождения костылей в которых без «мощной IDE» не разобраться.

А что как ОРМ используешь если не секрет?

В Плей, кажись, что-то свое есть.

В плей кажется идет небольшая надстройка над jpa, но в scala-play к примеру они ее выпилили т.к. jpa-шные анотации не совместимы а с анотациями скала(пример неполной совместимости скала и джава кстати). Есть какие то скаловские орм, но он как по мне слишком инопланетянские.

К сожалению под сколько нибудь сложные задачи я ещё всё это не использовал, но я пробовал на GAE с objectify и siena.

как раз о комбинации play и scala слышал очень плохие вещи. А плей просто так хвалили. Можно подробнее про ваш проект — интересно ?

как раз о комбинации play и scala слышал очень плохие вещи.
Подробнее пожалуйста.
Сейчас попробую вспомнить
— Anorm — неюзабельные дрова без поддержки
— куча проблем совместимости java и scala в итоге писать в скала стиле почти не реально
-херовый ’хрупкий’ шаблонизатор ( может отвалится от лишнего ентера и тп)

Это мне конечно Рабиновичь напел но я ему склонен верить :)

Ниче, им до плэй 2 еще 3 тикета осталось закрыть, возможно там получше все будет.

хотелось бы верить, благо задумка у них хорошая.

Есть небольшой минус комбинации Play + Scala — большее время компиляции в но в дев моде это почти не чувствуется, ну и конечно шаблоны на скале много приятнее грувевских. К тому же Play 2.0 уже с родной поддержкой скалы, сбт и других приятных вещей.

К тому же Play 2.0 уже

Еще не уже, а только РК2

Ну конечно релиза не было ещё но шаблоны уже работают и я так сходу даже не смог поломать их компиляцию как в 1.2.4.

есть все шансы нарваться на проект 10-летней давности (скажем, на голых сервлетах и JDBC) который отдали на аутсорс и который придется кому-то поддерживать.

И в чем проблема? Если заказчик адекватен, то прикручивайте хоть спринг10. Если заказчик не адекватен, то ни какой спринг вам не в радость будет. С продуктовыми точно так же, наверное даже проще.

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

но думаю
Меньше думайте, больше делайте.
за годы оброс костылями и больше похож на огромный карточный домик
Проекту чуть менее 10 лет. Оброс костылями (сем пару прикрутил :) ). При это никто не говорит «не трогай»; бери переделай, но ко всему надо подходить ответственно.

Минутка рекламы на ДОУ:
В Worldapp разработчики ограничены в выборе технологий только здравым смыслом.

Меньше думайте, больше делайте.

Так ведь не получается ничего сделать: прикрутить опенсорсную библиотеку с либеральной лицензией заметно улучшающую некоторый аспект системы- нельзя; относительно безобидное но масштабное изменение системы — нельзя. Как-бы чего не поломалось, как-бы чего не вышло. Все уже работает, все уже приносит деньги, ничего трогать нельзя.

заметно улучшающую некоторый аспект системы

Если заказчик не адекватен, то ни какой спринг вам не в радость будет.

прикрутить опенсорсную библиотеку с либеральной лицензией заметно улучшающую некоторый аспект системы

Если не секрет: Что это за либа и что за аспект?

[лучше удалю во избежание :) ]

Поменяйте проект, поменяйте работу.

Поменять проект не получилось (позиция компании: «Или делай что дают, или лучше сразу увольняйся», в принципе, понятная и правильная, зачем им проблемные сотрудники). Менять работу очень не хочется — и не время, и нет гарантии, что подобная ситуация не повториться в другом месте, аутсорс то один на всех.

Вы как мой друг, такой же мазохист. Работает над одним проектом много лет, один. Хочет выйти, никак не может. Ищет постоянно для себя причины, почему он не может покинуть этот проект, хотя сам страдает т.к. проект уже надоел и сам не развивается (деградирует).
Выбирайте дорогу, какая для Вас лучше, по той ступайте и идите.

ИМХО, предлагайте переделывать проект, если нет — идите в другую компанию развиваться.

похожая проблема. что удивительно, древний код (2 таблички — 42 класса на портлет: Struts + Spring + Hibernate + чья-то доморощенная хрень, не считая JSP+JS) пишут сидящие рядом очень молодые (раза в 1.5 моложе меня) люди. и костылями их код нифига не обрастает. он с ними рождается ))) вопщем долго не выдержал. с учетом, что непосредственно с Java работать получалось не более 10% всего времени плюс еще пара менее значимых причин.. решил проблему радикально — уволился нахрен )) ну практически. 1 марта стану безработным. хожу, ищу работу. вижу в требованиях JSP, JS, HTML,CSS — отказываюсь сразу. ищу чего-нить интересного уже месяц. чем и когда все закончится — без понятия ))

Правильно, на работу нужно ходить в удовольствие, а не на мучение.

Підписатись на коментарі