Comments 209
К сожалению так не работает. Описание логики во всех её деталях и подробностях это программный код. На другом языке получится другое описание. Высокоуровневые способы позволяют очертить какие-то грани, быстрее въезжать в проект, но неизбежно теряют информацию. Архитектурные решения также имеют свойство устаревать.
Если вы сможете рассказать в чем разница учебных задач и производственных, то много сомнений отпадет. При правильном подходе к проектированию вы сможете держать проект «в узде» долгое время. Чаще проблема архитектуры связана с низкими навыками разработчиков и следованием за трендами (хайпом)
Мы в Android разработке в 15м году выбрали правильный путь с полной протоптанной архитектурой еще от майкрософта. До сих пор не поменялся подход, сменили кучу библиотек, парадигм и подходов, но архитектура неизменна. Смена каллбеков на rx, коннекшнов на http клиенты, файловые таблицы на бд всегда происходили без проблем.
Но мобилки это рассказ о локальных архитектурах, сервера куда интереснее, но даже там какой либо jvm сервер будет выбирать между ktor, netty, akka и своим решением. А на PHP подобных только доменная и объектная архитектура по всем правилам, массивы и «новомодные» подходы строжайше запрещены в вопросах архитектуры, но внутри алгоритмических задач полная свобода
Использую .Net Framework 4.6.1, мечтаю перейти на .Net5 :)
Посмоторите ролик на заставке, какие красивости можно делать быстро и нативно, маковская ХСode нервно курит в сторонке.
www.embarcadero.com/products/delphi
Ну хорошо, не устаревший, вот недавно в мае новая версия вышла :). Просто заброшенный комьюнити разработчиков. Сложно искать компоненты, на форумах почти не обсуждается, мало опен-сорс решений ну и т.д.
Вы меня в чем убедить хотите? Мы на нём и пишем как раз и стараемся верить, что он еще не совсем устарел. Но как только я открываю вакансию "Delphi-разработчик" в нашем небольшом городе, мне становится очень грустно :)
Но:
1. стороннему разработчику, привыкшему к C++/Java/etc, для работы в вашей песочнице нужно переучиваться.
2. за пределами вашей песочницы умения в Delphi не особо востребованы.
Поэтому с ротацией кадров, возможно, есть особенности.
Или всё так же в var наверх прыгать?
Подвезли.
Не надо.
Функциональное программирование, определение переменных в коде и автовывод типов уже подвезли?
Или всё так же в var наверх прыгать?
По некоторым своим свойствам Pascal от рождения был получше куда как более навороченного C++, например, вложенные функции-замыкания были в нём еще в прошлом веке.
Тут и обратная ситуация джавистам можно выгнать, и возять с рынка другого, благо их на рынке много.
благо их на рынке много.
Хороших джавистов, открытых для предложений, увы, не так уж и много, и нанять их не так уж легко. Ну, если не рассматривать варианты с предложением $$$ в полтора-два раза выше средних по рынку.
Хороших в любой профессии — мало. Какой-то отдельный язык программирования тут ничем не выделяется.
И всегда так было.
Но это не мешает экономике крутиться и технологиями развиваться.
1. стороннему разработчику, привыкшему к C++/Java/etc, для работы в вашей песочнице нужно переучиваться.
2. за пределами вашей песочницы умения в Delphi не особо востребованы.
Навыки, паттерны, алгоритмы, концепции — это всё очень и очень похоже на разных языка программирования.
А как там объявляется переменная — тип впереди, а имя переменной опосля; или же в обратном порядке — это вторично.
Трудно даются именно паттерны, алгоритмы, принципы.
Сам язык программирования — тьфу.
Я сам с удовольствием возьму в проект на другом языке человека с двумя годами опыта по совсем иной технологии.
Нежели нулевого специалиста, который якобы «знает» мой язык, но реального опыта не имеет.
Первый из них выучит новый язык за неделю (да, это просто и быстро, если вы уже действующий программист, ибо подавляющее большинство современных языков программирования очень похожи, исключения редки) и уже будет значительно более полезен, чем второй.
Вот когда вы изучаете ваш самый первый язык программирования — вам кажется, что это не так, что сам язык важен.
Но это только потому что вместе с языком программирования вы сразу и разбираете эти паттерны и алгоритмы и концепции.
Ко второму и третьему и т.д. языку — вы учите этих базовых вещей всё меньше и меньше. Ибо паттерны, алгоритмы, концепции выученные вами раннее прекрасно подходят и к новому языку.
Если ко второму языку еще не все очевидно. Но к третьему вы уже прекрасно понимаете, что паттерны, концепции, алгоритмы переходят из языка в язык.
Это всё понятно. Но чем вы человека с двумя годами опыта заинтересуете?
Это всё понятно. Но чем вы человека с двумя годами опыта заинтересуете?
Это индивидуальный вопрос.
Имхо, на сегодня джунов перебор, их очень много (2 года — это еще джун, имхо). Это миддлов и сеньоров дефицит.
И далеко не всегда джуны выбирают работу мечты. А выбирают всего лишь «куда берут».
То есть ничем таким особым заинтересовывать и не нужно. Просто работа. Просто за деньги.
На рынке довольно много работодателей, которые на свои вакансии требуют опыта в конкретном стэке. И это не Дельфи. Получается ваши джуны, проработав у вас 3 года и став для вас миддлами, на рынок, если что выйдут опять джунами. Да, с опытом разработки вообще, но с нулевым опытом по востребованным технологиям. Так?
Да, с опытом разработки вообще, но с нулевым опытом по востребованным технологиям. Так?
habr.com/ru/post/519630/#comment_22091700
Получается ваши джуны, проработав у вас 3 года и став для вас миддлами, на рынок, если что выйдут опять джунами
Если у человека есть выбор пойти работать в Google или Netflix — то он туда и пойдет.
Если его берут только на устаревшую технологию за 2*X бабла или на модную технологию за X бабла, то что то мне подсказывает, что большинство выберет «деньги уже сегодня».
1 255 вакансий «Программист javascript»; от 340 000 руб — 12 вакансий
1 056 вакансий «Программист java»; от 370 000 руб — 9 вакансий
104 вакансии «Программист c++»; от 215 000 руб — 6 вакансий
37 вакансий «Программист delphi»; от 170 000 руб — 2 вакансии
2х бабла — это не про Delphi, а совершенно наоборот.
1 255 вакансий «Программист javascript»; от 340 000 руб — 12 вакансий
1 056 вакансий «Программист java»; от 370 000 руб — 9 вакансий
104 вакансии «Программист c++»; от 215 000 руб — 6 вакансий
37 вакансий «Программист delphi»; от 170 000 руб — 2 вакансии
2х бабла — это не про Delphi, а совершенно наоборот.
Умиляют всегда такие сравнения.
Понимаете, цифры легко сравнить — поэтому на них обращают внимания.
А вот профессиональные требования — это плохо формализуемая вещь. Поэтому их в подобных сравнениях напрочь игнорируют, что порождает такие вот казусы.
1) С чего это вы решили, что там речь идет об одинаковой квалификации?
2) Какое отношение имеют отдельно вами выделенные топовые вакансии к делу? Если, как правило, нужно только поддерживать старый проект в рабочем состоянии?
3) Почему вы проигнорировали огромное количество предложений с крайне низкой оплатой, которые присутствуют для JS?
Ради любопытства проверил по этому сайту мою специализацию — Go — так я даже в глухой провинции зарабатываю в два-три раза больше, чем предлагается на hh в Питере. Нет, не на заграницу работаю, местный заказ.
Что лишний раз подтверждает, что бездумно верить выборке из hh нельзя, а нужно индивидуально смотреть что там за конкретно за вакансия.
Если, как правило, нужно только поддерживать старый проект в рабочем состоянии?
Значит, нужно ставить крест на профессиональном развитии. Не вижу в этом ничего плохого, но для выпускника института, например, это странный выбор.
Топовые вакансии — тоже метрика.
Тут от обратного идет уже. Не специалиста подбирают под технологию. А наоборот.
Топовый специалист уже сам выбирает технологию, по которой целесообразнее реализовывать тот или иной проект.
Именно потому он и топовый специалист.
Значит, нужно ставить крест на профессиональном развитии. Не вижу в этом ничего плохого, но для выпускника института, например, это странный выбор.
Я понимаю, в начале карьеры кажется: «выучил не тот язык и жизнь пошла прахом».
Но это не так.
Мы учим концепции, паттерны, алгоритмы. Просто используем для этого какой-то конкретный язык программирования.
Когда мы учим первый язык нам кажется что сложно выучить именно язык. Но сложно выучить паттерны, алгоритмы, конецпии, которые мы учим с этим языком. Только поэтому.
Но изучение второго, третьего языка — идет уже не долгие месяцы как первого, а считанные дни.
Потому что концепции, паттерны, алгоритмы там все те же, от языка слабо зависят. Из массовых языков концептуально иных — раз два и обчелся (это например SQL). А Delphi, C++, C#, Python, Java, JavaScript, Go, Dart — они же крайне похожи.
От меня джуны через 2 года уходят со знанием одного основного и 2-3 вспомогательных языков.
И по началу они боятся-страшаться-не хотят изучить что либо кроме одного-единственного. Потому что помнят каких усилий им стоило освоить свой первый язык.
Но буквально через неделю уже пишут простенькую программу на каком-нибудь вспомогательном языке, что используется в нашем проекте.
Значит, нужно ставить крест на профессиональном развитии.
Вам всё равно нужно изучать новые технологии в течении своей карьеры.
И даже в одном языке есть очень разные вещи скажем React vs Vue в JS.
Имхо сам JS и TypeScript освоить куда проще, чем React и Vue.
Не с нуля, конечно. Но если вы сложившийся специалист, то изучение языка занимает считанные дни.
А вот изучение библиотеки/фреймворка — это надолго.
И заниматься вы этим будете неоднократно.
Дельфи вас никак не сдерживает в вашей карьере. Кроме небольшой паузы-переключения на новый стек.
Ибо принципы там ровно те же самые, что и, к примеру, для десктопного программирования с C#.
Однако то же самое переключение React -> Vue у вас может произойти в пределах одного языка JS.
Не вижу никакого креста на карьере в случае JS. Почему он будет если вы после Delphi решите перейти на JS или Python?
Очередной новый язык программирования, начиная с третьего (про второе еще можно поспорить) — изучается влёт. Исключения — крайне редки. Ну, может, в особенностях и многочисленных стандартах С++ и его нюансах вы раберетесь не очень шустро.
Хотя при этом начать на нём программировать после Delphi вам будет не сложно и это займет считанные дни, меньше недели.
Именно потому он и топовый специалист.
И топовым специалистам со знанием некоторых языков предлагают больше денег. Совпадение?
Я понимаю, в начале карьеры кажется: «выучил не тот язык и жизнь пошла прахом».
Не так. В начале карьеры сел заниматься поддержкой legacy проекта. А через 10 лет, к примеру, проект закрылся, и ты снова junior со занием никому не известных фреймворков. И предложения на hh.ru не радуют.
И топовым специалистам со знанием некоторых языков предлагают больше денег. Совпадение?
Я вам уже ответил — у топовых спецов вообще всё иначе.
Мне предлагают еще больше денег, чем это упомянуто на hh.
И при этом никто у меня не спрашивает на каком языке программирования я собираюсь делать проект, архитектором и ведущим разработчиком которого я являюсь.
Ну ок, разве что определяемся с менеджерами — а сможем ли мы привлечь на проект специалистов соответствующего профиля, не слишком ли они редки.
Но проект не на зубодробительном Хаскеле, куда найти спецов или научить своих было бы сложно.
Никаких проблем найти специалистов на не самый распространенный Go не было. Хотя, если верить hh, с Go все плохо? Но нет. Это оказалось совсем не так.
Язык учится быстро. Если ты уже программист. И хорошо знаешь другой язык. Все основные языки программирования очень похожи. Исключения крайне редки.
Не так. В начале карьеры сел заниматься поддержкой legacy проекта. А через 10 лет, к примеру, проект закрылся, и ты снова junior со занием никому не известных фреймворков. И предложения на hh.ru не радуют.
Занимаюсь программированием более 25 лет.
Учить новые технологии — это нормально для программиста.
Выучил их уже уйму.
И я уже успел и позабыть те языки и технологии что когда то выучил. И даже их названия не всегда вспомню.
А через 10 лет, к примеру, проект закрылся, и ты снова junior со занием никому не известных фреймворков.
В одночасье ничего не произойдет.
Так как люди довольно инертны. А в массе своей — и подавно инертны.
И не образуется в одночасье большого количества программистов, хорошо владеющих новым фреймворком.
Тебе понадобится время, чтобы его освоить, но — sic! — твоим коллегам-конкурентам понадобится то же самое время.
Вон, до сих пор полно вполне себе живых проектов на почившем в бозе PHP4. А сколько лет он уже официально не поддерживается?
Или только-только идет окончательный отказ от Python 2 в пользу Python 3, да и то не везде. И сколько лет назад вышел Python 3?
и ты снова junior со занием никому не известных фреймворков.
Кроме маааааленькой такой детальки.
Настоящие джуны, приходящие в эту технологию с нуля — только за пару лет достигнут более-менее вменяемого уровня.
А тебе, опытному уже разработчику, понадобится пара недель-месяц для достижения того же уровня.
P.S.:
Поймите, количество вакансий и их суммы на hh нельзя сравнивать в лоб.
Ибо вам совсем не нужны эти тысячи вакансий. Вам нужна ровно одна.
Что до сумм — мои суммы зарплат и того что публикуется в вакансиях — более-менее совпадали разве что первые 4 года карьеры.
Для сколько-нибудь опытных специалистов публикуемые в вакансиях цифры уже не отражают действительности.
Эти вакансии потому и висят так долго, что работодатель пытается и пытается найти специалиста за так дёшево.
Реальные вакансии уже закрыты, так как специалиста по ним уже нашли.
Эти вакансии потому и висят так долго, что работодатель пытается и пытается найти специалиста за так дёшево.
Реальные вакансии уже закрыты, так как специалиста по ним уже нашли.
Вынужден согласиться. Вакансии на hh.ru не отражают НИ-ЧЕ-ГО. Это как bias сайтов знакомств. Никто нормальный туда не пойдет, потому что никого нормального там не найти. А если даже кто-то нормальный там обретается, то он скорее найдет нормальную половинку (не важно где) и на сайтах знакомств опять останутся только те, у кого какие-либо недостатки.
Та же история с рынком недвиги. Заходишь на ЦИАН или Авито. Хорошие объявления сметают как пирожки — моментально. Остаются что? Либо "бабушкины варианты", либо совсем переоцененные квартиры, либо какой-то брак (залог, невменяемые соседи и пр.)
Вы меня в чем убедить хотите? Мы на нём и пишем как раз и стараемся верить, что он еще не совсем устарел. Но как только я открываю вакансию «Delphi-разработчик» в нашем небольшом городе, мне становится очень грустно :)
Дело не в зарплате, нет?
Как человек, занимающийся разработкой 25 лет, утверждаю, что язык вторичен.
Типичный джун приходящий под мое руководство через 2 года уходит с практикой на одном основном языке программирования и еще двух-трех вспомогательных языках. Это не сложно.
Пост не столько о судьбах разработчиков, сколько о судьбах проектов, построенных на устаревающих технологиях. Кода с каждым годом всё больше, а желающих в нём разбираться всё меньше.
Пост не столько о судьбах разработчиков, сколько о судьбах проектов, построенных на устаревающих технологиях. Кода с каждым годом всё больше, а желающих в нём разбираться всё меньше.
Есть люди, которые с удовольствие будут работать у вас и по 25 лет. Лишь бы платили.
Причин обновить проект куча.
И далеко не все из них связаны с языком программирования.
Язык может быть и более-менее современный, а внутри уже такого наворотили, что проще сделать с нуля. Или не проще сделать с нуля.
Нужно просто оценивать целесообразность поддержания старого проекта куммулятивно, включая туда все факторы, в том числе и поиск разработчиков, в том числе и стоимость внесения изменений, в том числе и необходимость поддержания зоопарка мостиков к современным компонентам.
И сравнивать это всё с экономической выгодой оставаться на старом или перейти на новое.
То, что делают программисты имеет конечную экономическую цель. И оценивать нужно именно с точки зрения денег. А не технической сложности.
Если бизнесу выгоднее оставаться на старой системе — значит так тому и быть. Ну а как это будет происходить — платить больше за старые технологии или попросту прекратить развивать проект (чаще всего именно этот путь и выбирают).
Прошло 13 лет разработчики на Джаве открывают хелп приложения развивающегося на Delphi и дорабатывают новые фичи которые уже сделаны оттестированы и описаны. И эта гонка будет бесконечной.
Ну то есть Java версия так и не запущена в эксплуатацию? А живет просто в параллели, точнее не живет, а лишь только "пишется"?
Запущена только работает хуже чем исходная. Как правило просто переписывание без анализа платформы и реинжиниринга ничем хорошим не кончается.
Личный опыт.
Архитектура проекта была DB+backend+frontend. Бизнес-логика, разграничение доступа, FTS, валидация данных в DB.
Посредине разработки архитектура была изменена DB+kafka+Elastic search+Node.js+frontend.
Бизнес-логика в backend, валидация данных в backend+frontend.DB исключительно как хранилище данных.
Функциональные требования не изменились, команда разработки выросла в 10 раз, разработка новых фич была остановлена на 4 месяца.
Пока ничем кроме как необходимостью выделить и освоить бюджет, объяснить сложно.
По опыту работы, банковские системы на Cobol работают до сих пор. Говорят и Фортран жив и умирать не собирается.
Так, что необходимость регулярной смены платформы раз в 10-15 лет кажется в некоторых случаях (наверное даже в большинстве случаев) надуманна искусственно.
А нефункциональные? Вот или скажем так — мне как-то пришлось подключать к проекту некую шину для передачи данных. Специализированную, ориентированную на биржу, котировки, сделки и т.п. И реализована она была строго под Windows. Ну и чтобы вы думали… почти как у вас, только вместо кафки где-то посредине появился ActiveMQ, чтобы связать воедино имеющееся ядро, работающее пусть и на Java, но под Linux, и новые компоненты под Windows. И никакого распила бюджета, все естественно и само собой.
>регулярной смены платформы
Ну конечно просто так нет — разве что безнадежное устаревание делает затруднительным искать того, кто станет это хоть как-то поддерживать и развивать.
Опять же — у нас много чего жило на Java 6. А потом пришли безопасники, и сказали — нафиг, уже Java 7 EOL, всем живо перейти на 8 (это было уже несколько лет назад). И начинается миграция. А многие компоненты, типа криптографии, скажем, на которых работала старая система, для Java 8 просто так не найти.
И даже простая попытка повторить один в один старый стенд, чтобы развернуть параллельно новую систему, привела к неожиданным эффектам. Например, новые машинки — новые диски, сетевые карты и пр. Идентичная старой версия линукса это железо тупо не поддерживала, пришлось линукс обновить, заменив RHEL 6 на 7 (опять же, это было не вчера). Попробовали развернуть такую же версию QPID — оказалось, что на официальном сайте такой версии уже не найти днем с огнем, она не поддерживается. Меняем QPID. Меняем HAProxy. Меняем вообще почти все, что не на Java.
Вы так пишите как будто увеличение штата и затрат это что-то плохое. Большие проекты заинтересованы в надёжности и минимизации рисков. В этом смысле зондеркоманда из 10 говнокодеров под присмотром 2-х немного более опытных лучше, чем пара-тройка редких гениальных специалистов.
"зондеркоманда из 10 говнокодеров под присмотром 2-х немного более опытных лучше, чем пара-тройка редких гениальных специалистов."
Просьба аргументировать данный тезис.
Минусы я могу сказать сразу — сроки и бюджет возрастают с ростом числа разработчиков, и у меня большие подозрения, что нелинейно.
Какие плюсы ?
В случае проблем с качеством вы как бизнес теряете лишь очередную версию. В случае проблем с уникальными специалистами вы оказываетесь в тупике. Большие проекты это в первую очередь про минимизацию таких вот рисков.
"В случае проблем с качеством вы как бизнес теряете лишь очередную версию. " — Это по вашему и есть плюс раздувания штата разработчиков ?
Я работал в одном из таких проектов. Это типичный международный энтерпрайз, пожалуй самый крупный в своей нише. За несколько лет штат в разработке увеличился в несколько раз, а средний уровень синьерности, напротив, упал. Специалистов, которые раньше казались незаменимыми, практически не осталось как класса. И знаете, это пошло только на пользу. Хотя локальных заморочек создало конечно массу.
Незаменимых специалистов в команде не должно быть. Это к размеру и уровню команды отношения не имеет. По мне так это базис.
Это в идеале так. В реальной жизни практически невозможно встретить команду из действительно сильных разработчиков, которых можно легко заменить.
Незаменимых специалистов в команде не должно быть.
Тут есть пара вопросов (жизненных, к сожалению):
- Менеджер или тимлид должны быть легкозаменяемыми? Если нет, то просто может всех труднозаменимых надо повысить и все, проблема решена?
- Как определяется труднозаменимость? Если через год общая производительность оставшихся четырех человек упала в два раза, то был ли незаменимым пятый, ушедший? А если да, то как надо было это определить год назад?
- Про какого размера компании Вы говорите? 10 человек? Или 1000+?
- Про какого размера оплату вы говорите? Если стоимость похожего специалиста более 300к рублей в месяц (говоря другими словами — не так много людей обладает такими знаниями), то найти такого же сложно (так как людей просто нет столько, чтобы каждый день резюме приходило). А отсюда вопрос — за сколько времени на рынке труда должна находиться замена заменимому?
- Допустим, существует команда из трех человек, которые оберегают свою job security. Мало кто знает, как на самом деле работает их проект. Любые попытки забрать их проект приводят к жалобе бизнесу "нам мешают, тогда мы уйдем", на что бизнес отвечает "мы тут деньги зарабатываем, не трогайте их". Попытки реализовать частично проект в других командах приводят опять к крику и аргументам "зачем плодить сущности? У нас уже все есть и сделано". Вопрос: как IT управленцу Вы бы посоветовали бороться с данной ситуацией? Сразу замечу — неполадки в проекте могут стоит места этому самому менеджеру.
1.Менеджер и тимлид — самое слабое звено любого проекта. На текущем проекте уже трое product owner сменились с декабря прошлого года.
2.Незаменяемых быть не должно в принципе. Нужно строить внутренние процессы, так, что бы избежать рисков при выпадении любого участника команды.
3.1000+.
4.Это вопрос не инженеру, это вопрос HR. Пусть работают.
5.это косяк вселенского масштаба. Тот из топов кто довел ситуацию до данной — сам виноват. Средним менеджерам и инженерам остается только посочувствовать. Я в такой ситуации ни разу не был, поэтому сорри, ничего не скажу.
Вопрос: как IT управленцу
Мы друг друга несколько не понимаем, потому, что говорим на разных языках. Я не управленец, я инженер. Всю свою жизнь всячески стараюсь избегать перехода в управленцы. Но чувствуется скоро дожмут ;-(
У девопсов есть метафора Pets vs Cattle. Смысл в том, что пока нечто является штучным товаром, как домашний питомец, то вы его холите и лилеете, пылинки сдуваете, за ушком чешете, потакая всяким капризам. Если же оно лишь часть большого стада, то основной вашей проблемой становится только вовремя подоить. Масштаб решает.
Крутой специалист это как болид формулы 1, с кучей всяких своих наворотов, чтобы максимально быстро доставить каску стартапера от старта к финишу. Малейшая поломка и замены не будет, вы аутсайдер. Таковы риски. Но когда проект растет и вам надо возить уже тысячи касок, экономя топливо и запчасти, вы покупаете грузовик. Или кучу грузовиков. Тупых, банальных и простых. Внутри могут быть какие-то навороты как в болиде, но если вдруг что-то из этого отвалится, то общий запас прочности такого агрегата даст гарантию, что доставка не пострадает.
Надеюсь я объяснил. Не какого-то одного решения со сплошными преимуществами, всякий раз надо смотреть по ситуации. Многие выигрывают, тупо отдав разработку на аутсорс, после чего вместо пары-тройки умников, ваш проект начинает двигать целая когорта брутальных гребцов.
Я надеюсь, это был сарказм… Ибо мне кажется, что эта модель упрощена настолько, что она стала слишком далека от реальности.
Крутой специалист это как болид формулы 1, с кучей всяких своих наворотов, чтобы максимально быстро доставить каску стартапера от старта к финишу. Малейшая поломка и замены не будет, вы аутсайдер.
Мы говорим про компании в 5 человек, или в 1000? В первом случае на такую настоящую звезду просто денег не хватит, а во втором — в компании немало есть таких "звезд". И разговор скорее идет "а сколько их должно быть?" Для действительно ценного проекта просто попросят помочь всем миром, дадут денег больше или что-то в этом духе. Все равно зп разработчика в разы меньше зарплаты высокого менеджера.
Про грузовик — мне кажется, что модель слишком далека отреальности.
Если у Вас программисты вынуждены делать одинаковые действия, то это просто не программисты. Если надо сделать 100 одинаковых форм, то создается программа, которая будет делать эти 100 действий. Если они не совсем одинаковые, а есть группы, то находятся схожие вещи и используется наследование, композиция и пр., разве что на архитектурном уровне. Следуя вашей модели, Вы может разве что заменять болиды формулы 1 на машины такси, так как маршруты все равно будут уникальными. Хотя и эта модель далека от реальности, ибо многовато платят за такие простые вещи, если надо просто довезти из пункта А в пункт Б.
Многие выигрывают, тупо отдав разработку на аутсорс, после чего вместо пары-тройки умников, ваш проект начинает двигать целая когорта брутальных гребцов.
Надеюсь, это шутка какая-то. В стратегическом плане аутсорс/аутстафф всегда проигрывает своим сотрудникам, что я наблюдаю всю свою карьеру с обоих сторон. У меня был случай, когда проект забрали у аутсорсера, заменив 40 человек на пятерых (и наняв еще троих). И ведь затраты на каждого из тех сорока были больше, чем затраты на забранных людей (на каждого), хотя заработную плату повысили. Другой пример — NVidia делала драйверы сами, а ATI/AMD заказывала их у Люксофт. Догадайтесь, про качество разработки кого уже есть куча шуток в интернете?
У девопсов есть метафора Pets vs Cattle. Смысл в том, что пока нечто является штучным товаром, как домашний питомец, то вы его холите и лилеете, пылинки сдуваете, за ушком чешете, потакая всяким капризам. Если же оно лишь часть большого стада, то основной вашей проблемой становится только вовремя подоить. Масштаб решает.
Да, но только если этот масштаб есть.
Нередко бывает ситуация, что сама технология выведения в «просто подоить корову» дороже самого проекта и нафиг не нужна поэтому.
И потому и остается «ручной режим» с питомцами, за которыми тщательно ухаживают. При всех рисках — это приносит прибыль.
- В чём причина забирать проект у команды?
В случае проблем с качеством вы как бизнес теряете лишь очередную версию.
По моим заметкам, как бы это было бы хорошо, если бы просто сразу терялось качество. Но ведь оно потеряется тогда, когда будет уже поздно. В моем опыте несколько раз была следующая трансформация:
- Проект делается опытной командой, система хорошо спроектирована для бизнеса, расширяемая, покрытая тестами, внутри есть подстраховки в виде consistency check и пр.
- Изначальная команда начинает постепенно расходиться: кто на повышение, кому предложили больше в другой компании. Менеджмент пока не видит проблем с качеством, так как бизнес еще не начал особо жаловаться. А потому управленцы начинают экономить: ведь фразой "Java-программист" можно описать людей с разным багажом знаний, опыта и умений.
- В уже новой команде (а название старое, прямо как корабль Тесея) главным становится тот, который больше всего был в проекте. Пытливые ушли раньше, еще в пункте "1", а потому начинают появляться "карго-культы" в стиле "вся настройка вот этого модуля строго вон в том xml'e" (и пофиг, что файл разросся до размера пары десятков мегабайт, ведь андалы и первые люди все хранили в нем, пусть он и был тогда 100 Кб всего).
- Через некоторое время бизнес заказывает большую фичу, и новая команда вмазывается по полной. Сроки провалены, работает все плохо и так далее. Но формально проект еще работает. И тогда начальник из пункта "2" делает волевое решение: "минимум изменений, работает-не трогай, наш проект очень важный, чтобы его менять".
- В итоге, проект начинает зарастать легаси и старыми решениями, скорость добавления новых фич упала, обновление библиотеки теперь является серьезным шагом, так как тесты давным-давно не работает. Команда становится больше похожа на техножрецов из Warhammer, которые скорее стерегут остатки технологий прошлого, чем создают технологии будущего. Но проект все еще приносит деньги, а потому команду все еще держат у руля, начальник с умным видом говорит, какой у них сложный и важный проект и так далее. Конкурентов внутри компании давят в зародыше, ибо зачем плодить сущности, правда ведь?
Между пунктами 0 и 4 разница в несколько лет. И для бизнеса довольно сложно заметить, что по сути эти проекты уже очень разные. В пункте 0 был потенциал роста, был запас прочности, а в пункте 4 его давным-давно нет.
Одним из способов удерживать проект как можно больше в состоянии 0 — это держать команду тех самых "спецов", которые просто смогут поддерживать некую "правильность" архитектуры, сохранять запас прочности и так далее. Люди могут меняться, но вот их минимальный уровень должен быть более-менее неизменным. Такую схему используют FAANG компании с переменным успехом.
Как я уже сказал выше — это лишь мои заметки. В точности такую же схему я видел два раза целиком, части этой истории я видел тоже, однако полноценного исследования я не проводил.
Судя по вашему описанию там была сразу пачка разных моментов, которые с увеличением масштабов и возраста стали выглядеть как целая плеяда различных проблем. Хочется лишь отметить, что если уход специалиста становится сильно болезненным, то это сигнал того, что что-то идёт не так.
Хочется лишь отметить, что если уход специалиста становится сильно болезненным, то это сигнал того, что что-то идёт не так.
Если бы все было так просто. Основная проблема — это время обнаружения. Я опишу два сценария. Второй — это то, что часто происходит с подачи очередных эффективных менеджеров.
Сценарий 1: человек стягивает под себя несложные задачи, но так, чтобы никто быстро с ними не разобрался. Так как более-менее нормальный тимлид способен уследить за таким, это происходит или из-за низкого уровня управления (а значит в компании еще ворох проблем), или потому-то тимлид и есть тот самый человек.
Перед уходом человек грозится "на мне все держится", предлагает команде самой заполнять какую-нибудь кривую форму на 30 полей для компенсации переработок. Ну или команда сама может обновить версии библиотек, так как на деле там хитрая схема из восьми связанных файлов.
Таких людей надо выкидывать как можно быстрее. Яркий маркер — такой человек не делится знаниями, не делает никаких митингов с объяснением сложных аспектов и пр.
Сценарий 2: уходит специалист, который знал дофига всего по проекту и по бизнесу. В отличии от пункта выше, человек активно всем помогал, не греб под себя и тд. А потому, перед уходом человек предупредил за месяц, что его не будет, а потом активно помогал команде: в задачи добавлял детали, в код — необходимые комментарии и тесты.
После ухода человека первые два месяца все идет по накатанной — все детали оставил тот самый, а потому все проходит безболезненно. Тимлид идет докладывать наверх "как я и говорил, все прекрасно, незаменимых здесь нет (ну кроме меня)". Однако, на протяжении года все чаще команда сталкивается с вопросами, которые требуют глубокого знания бизнеса и технологий. И вот тут становится ясно, что очень зря отпустили того человека. И очень классно, если в команде внезапно найдется второй такой же (а если он был, то и оба сценария неприменимы изначально), но ведь откуда ему/ей взяться так неожиданно?
Где-то в середине года команда начинает замечать, что зря отпустили. Бизнес тоже начинает замечать, что ответы теперь не столь конкретные, отмазки теперь более обтекаемые и так далее.
Однако, тимлид докладывает менеджменту, что все хорошо (ибо это его зона ответственности, нельзя же признаться, что облажались?). Менеджмент, если начинает изучать детали, то тоже понимает, что в прошлый раз поступили не совсем эффективно, но нельзя же признать собственную ошибку?
А потому только через кучу месяцев становится более-менее очевидным факт того, что зря недоплачивали/отпустили "того самого мифического". Хотя по всем бумагам все равно все остается, что "проблем нет". Ну как и развития, что и является основным маркером — если после ухода человека команда через год (примерно) не способна делать такие же крупные фичи, что и раньше, то отпустили зря.
Это то, что я вижу, обычно, в командах. Как я уже говорил, фраза "Java программист" может означать сильно разные вещи, как бы ни хотелось обратного.
Половина разработчиков и компаний занята тем, что каждые пять лет переписывают на новой парадигме или языке то, что и так работало. Неужели вы решили, что вас это каким-то образом минет?
Про остальное… Не знаю, так и хочется написать про «вечные ценности», но… не буду. Заплюют. Просто оставлю этот коммент здесь и подожду ответов. Своим проектам уже около 15 лет. Ядро написано на С/С++ и планомерно переносится и по необходимости правится. Спасибо тем, кто 15 лет назад придумал как это написать так, чтоб потом проблем не было. Увы, некоторые уже в небесном ВЦ на прошивки для грешников патчи готовят. А интерфейс переделывается чуть-ли не с каждой новой итерацией. Я даже не знаю на чем современный написан.
У нас был проект на VB. Переписывается в связи со смертью разработчика… Причем человеком без того огромного багажа опыта и существенно быстрее. А приложения исходного проекта продолжают использоваться. Применение- промышленная автоматизация
P.S.
А VisualBasic'ом в промышленной автоматизации удивили. Нет, я много где его встречал, но все равно откровенно не типичное применение. Спасибо.
Вычислительная часть выполнялась на другой платформе (DOS) и писалась на QBasic и С
А VisualBasic'ом в промышленной автоматизации удивили. Нет, я много где его встречал, но все равно откровенно не типичное применение.Есть такая система — WinCC. В ней можео писать скрипты либо на хардкорном ANSI C, либо на урезанном VBS (Visual BullShit).
В случае переписывания с нуля не тратится время на реинжиниринг.
Если только вы не про тот ноль, в котором нет даже идеи проекта.
Есть нюансы. Если это стартап в новой предметной области, то писать с нуля будет сложно — из-за отсутствия экспертизы будет много проб, ошибок и кривых решений, что довольно быстро начнет тормозить дальнейшее развитие. Если стоит задача повторить известное и понятное в целом решение, то написать с нуля может быть проще, т.к. отсутствует груз легаси, обратной совместимости и поддержки. Поэтому нередко сначала делают PoC, а потом переписывают как надо.
Думаю всю эту радость проще с нуля переписать, чем пытаться как-то исправить.
У меня сейчас проект который работает на Java не выше 1.7.79, на 1.7.80 уже не работает, не говоря о версиях выше.
Я пришел, когда вся команда «Встала ушла».
Документация устарела лет на 5. Тесты не работают года 3.
И команда ушла, когда разрабатывали «новую фичу».
Пришлось доделывать новую фичу. И запускать на проде.
Благо основа была норм. Но после 5 поколений программистов, там много накопилось технического долга.
Особенно «радуют» вывихи мозга, когда ты пол дня ищешь класс, в котором возникла проблема (пакеты и классы именовались кодогенератором, потому имена у них расчитаны не на людей, что-то вроде: rjdh_885546962_ggjsyr_888.ett_888_jjj.MakeSomeShit_yyusyrm_777.java (сакральный смысл всех этих суфиксов и цифирек командой давно уже утерян)
Потом когда ты его все-таки находишь, оказывается что это самое дно иерархии из 100500 классов, и собственно бажный код находится где-то в верхних ее классах, в жутком спагетти из instanceof…
Попутно, продираясь сквозь это все говнище, приходится копаться в исходниках ORM велосипеда, который все это генерирует, что-бы хотя-бы что-то найти.
Определенно это писали не люди, возможно RenTV с их рептилоидами, не так уж и не правы…
На личном примере — я почти 4 года проработал в одной компании. За это время .NET Core развился до 2 версии. Которую уже было не стыдно использовать в проектах. Все больше вакансий, где стали требовать .NET Core. Все, я устарел. Либо учится по вечерам после работы, что уже тяжело — возраст, семья, другие заботы. Либо искать новую работу, где стартует новый проект и учиться на нем. Если, конечно, возьмут и насколько придется подвинутся по зп в меньшую сторону.
Я бы даже сказал больше — каждый проект проходит через две стадии: разработка с первым выходом в прод и дальнейшая поддержка. На каждом этапе актуальны свои навыки. На этапе разработки — новые подходы, технологии и фреймворки. На этапе поддержки — узнаешь насколько хорошую архитектуру заложил, все ли невзгоды она выдержала и насколько достойно. В итоге хорошо бы вернуться и переделать архитектуру, но это дорого. Поэтому только на следующем проекте. Попутно изучив все то новое, что появилось за эти годы. Так что на этапе поддержки навыки уже начинают устаревать.
Бизнесу менять языки и инструменты не выгодно, это и ежику понятно. А вот программист засидится, растеряет актуальность навыков и ему будет сложнее найти работу в случае увольнения, какая бы причина ни была. Разумеется это в меньшей степени затрагивает тех, кто по 20 лет работают в одном НИИ или на одном заводе, но им же и труднее всего потом.
Э нет, тут не так все просто. Java 11 работает быстрее, чем Java 8 (по нашим замерам). Вывод — меньше стоимость содержания серверов. А проекты Loom + GraalVM вообще очень вкусные по части производительности. Ну и, конечно же, вопросы аудита и лицензий зачастую тоже вынуждают смотреть вперед.
В Scala/Kotlin можно выразить кучу вещей более строго, нежели просто в Java. Как следствие — дешевле добавление фичей, меньше багов (ибо уже не получится забыть что-то переопределить). Еще косвенный плюс — если меньше кода, то больший объем логики можно затолкать в один проект до того, как он станет нечитаемым. Вывод — меньше проектов, проще граф связей, больше вещей выполняются в одном процессе, а не в разных (ну то есть экономия на сетевых пересылках и пр., так как сеть требуется реже).
С учетом громадного числа функционала в Spring Cloud, зачастую выгодно было бы переписать проект с .Net/Delphi на JVM язык, чтобы выкинуть велосипеды по общению с очередями и пр. Важно — выкинуть можно только существующие велосипеды, так что далеко не всем проектам нужна эта перепись.
Для более-менее больших баз стоимость лицензий Oracle будет такой, что можно нанять еще команду и поставить в три раза больше серверов. И вот такое бизнес легко поймет.
Плюс есть еще тонкости. Например, по моим скудным наблюдениям, часто C++ проекты мутируют следующим образом:
- Ура, наш native работает быстрее этого тупого .Net'а
- Через пару лет: так, у нас ошибка грязной памяти. Теперь мы будем выделять все объекты под общим lock'ом. А еще вон ту операцию обернем целиком в lock, так как внутренняя библиотека выделяет память без блокировок, что ломает нашу многопоточность.
- Хмм, странно, у нас создание 1000 объектов в Native работает медленнее, чем в .Net (ибо каждое выделение объекта в куче требует блокировки потоков, см. пункт "2"), да и в целом все тормозит ...
Так вот, на пункте "3" крайне было бы разумным или нанять грамотных плюсовиков, или переписать побольше всего на managed язык, или пересмотреть архитектуру (чтобы убрать многопоточность и использовать многопроцессность, например). Но подобное далеко не всегда случается, однако, по моим заметкам, часто бывает для долгоживущих проектов.
Сервер стоит 20-100 баксов в месяц, зп сениора 3000-5000 баксов в месяц и он еще год будет это все переписывать. Если не уволится. А если уволится придет новый и скажет — «че за хрень тут понаписали, надо все переписать». А еще через год опять будет новая java 15, работает еще быстрее и надо опять все переписывать.
C Scala/Kotlin там больше шансов обосновать конечно, но бизнесу нужны цифры. Насколько быстрее в деньгах программисты будут добавлять фичи? Никто так этого и не посчитал и не посчитает. Потому что зависит от многих факторов — и подход, и язык, и инструменты, и сами программисты. Реально, чтобы объективно сравнить два подхода/языка/инструмента — надо чтобы одна и та же команда программистов реализовала один и тот же проект два раза. Но прикол в том, что второй раз они уже будут лучше понимать требования проекта и с более худшим инструментом могут написать его быстрее, по памяти. Придется еще каждому битой голову отбить, чтоб забыл что писал в первый раз.
Сервер стоит 20-100 баксов в месяц
Если в проекте такая нагрузка и на обновление версий надо потратить аж месяц, то пофиг на производительность. Пусть используют что угодно, это не наш случай.
Я же рассматриваю ситуации, когда надо инвестировать несколько недель (ну только если проект не совсем уже зарос) на то, чтобы он выполнялся быстрее на десятке серверов, каждый из которых обходится в $2000-$5000 в год (то есть в этом случае можно уменьшить число этих самых серверов).
В Facebook, как мне рассказал коллега оттуда, вообще ряд проектов делают строго на C++, так как серверов настолько много, что использование не самого эффективного языка для разработки оправдывается.
А еще через год опять будет новая java 15, работает еще быстрее и надо опять все переписывать.
Если переход с Java 11 на Java 15 требует полной переписи проекта, то правильнее уволить вообще всех: от менеджера, который не замечал такого, до последнего специалиста, так как не смог никого уведомить. Это просто позор индустрии какой-то.
Такого уровня деградации я не встречал никогда.
C Scala/Kotlin там больше шансов обосновать конечно, но бизнесу нужны цифры. Насколько быстрее в деньгах программисты будут добавлять фичи?
Тут только экспертный совет и так далее. Чаще получается, что пилотный проект выходит удачным, потом среднего размера проект тоже получается удачным, а потом и жирное легаси начинают переписывать (к этому моменту в команде уже есть опыт разработки, выработаны внутренние правила и так далее).
Если же это единственный проект в компании, то переписывать с нуля необходимо только в случае уволенной дремучей команды разгилдяев, которые все оформляли на чем-то древнем и неподдерживаемом. В остальных случаях (а я думаю, в 99%, хоть у меня и нет статистики) это просто неэффективно.
А нормальный руководитель, который знает как лить металл, но ничего не знает про языки программирования — будет требовать цифры и будет прав.
Я единственный раз занимался технико-экономическим обоснованием, когда писал диплом. Я это делал на примере конкретного гос. учреждения и конкретной программы для конкретного бизнес процесса.
Там все делали руками, в ворде печатали бумажки, распечатывали, складывали на полки в папочки и перекладывали, что-то считали на калькуляторе. В этом случае окупаемость мой программы составила почти два года. Потому что там не только моя зп (а писал я ее 2-3 месяца), но и зп бизнес-аналитика, расходы на обучение пользователей, налоги, аренда, прибыль компании-исполнителя и так далее. И то я не уверен, что все правильно посчитал.
Разница была — из-за времени выполнения операций (поиск нужного документа на полке в папке или расчет каких-либо цифр на основе нескольких таких документов = построение отчета). Вручную на это тратилось минуты, десятки минут, а с моей программой доли секунды или секунды. И был показатель — среднее кол-во операций в день.
В итоге даже если бы люди пользовались экселем (занес туда данные — это и так и так придется делать, добавил фильтры на листе и накликал пару отчетов) — никакая новая программа никогда не окупилась бы. А уж тем более переписывание моей программы с C# на какой-нибудь Kotlin.
В итоге даже если бы люди пользовались экселем (занес туда данные — это и так и так придется делать, добавил фильтры на листе и накликал пару отчетов) — никакая новая программа никогда не окупилась бы. А уже тем более переписывание моей программы с C# на какой-нибудь Kotlin.
Кстати по опыту работы с иностранными заказчиками — «А почему вы не переведете систему с Cobol на что-то более новое ?»
1) А зачем? Какие бизнес выгоды?
2) А кто оплатит?
Все, тема закрыта.
Кстати по опыту работы с иностранными заказчиками — «А почему вы не переведете систему с Cobol на что-то более новое ?»
О, а у моих коллег был такой опыт. Им надо было переписать систему с COBOL на Java (а точнее — с COBOL на технологию, которая им удобнее, в их случае была Java).
Там была классика — какой-то hello world был написан на COBOL лет 30 назад, работал на IBM Mainframe. И все было хорошо, если бы не два пункта:
- На любое ПО/железо необходимо покупать поддержку или же иметь штат специалистов, который это и разрабатывает. Это требование аудита, а потому в корпорациях тот же Linux не бесплатный, а лицензирован у Red Hat по несколько тысяч долларов за сервер. Как следствие — на старую систему поддержка стоила безумных денег. И никто бы не обратил даже внимание, если бы не внимательный внутренний аудитор, который заинтересовался этой странно большой статьей расходов.
- Бизнес давно уже хотел расширить функционал, вот только специалистов не было. Были outsource компании, которые за немалые деньги просто были готовы поддерживать существующий код. А менять его (а значит и тестировать, разбираться в коде) они не хотели даже за свои немалые деньги. Java/.Net разработчики лезть туда не хотели, так как не было незанятых добровольцев, которые были бы согласны поиграть с кусками от мамонта полгода. Как я уже говорил, код там гонялся относительно простой, это не какой-то сверхсложный биллинг (такие критически-важные проекты разумно поддерживать в живом состоянии).
Как результат — команда потратила несколько месяцев на воссоздание решения на Java. В итоге уже за первый год была экономия на пункте "1". Я бы еще предположил, что получилось увеличить функционал, но здесь у меня нет данных.
У вас есть опыт переписывания проекта на 1000000+ строк кода?
А у кого его нет? Я за свой 10+ опыт разработки дважды участвовал в подобном. И не удивлюсь, что половина хабра так же видела похожее.
Если предложат в одиночку переписать проект подобного объема, то это будет просто неразумным. Даже более-менее эффективно поддерживать таких монстров и выпускать новые фичи одному будет практически нереально (ну если только не лгать в стиле "я тут все знаю", когда на самом деле "я точно знаю, что в 90% кода лучше не лезть").
Если мы говорим про 1.000.000 строк на Java, то это около 2.500 классов по 400 строк. Судя по моим собственным замерам, в одиночку на Kotlin такой объем достигается за 2-3 года (не тупой набор текста, а осмысленный).
В новом проекте, скорее всего, будут новые функции и, что самое важное — выкидывание старых и систематизация оставшихся (ну чтобы был смысл). А значит, за один год команда из 4-5 человек запросто родит рядом проект-аналог, что не выглядит слишком сложным. Из этих 4-5 человек достаточно 1-2 участвовать ранее в хоть чем-то подобном, а значит, если в команде у всех опыт 5-15 лет в индустрии, то практически каждая такая команда обладает необходимым умением.
Плюс не забывайте, что когда вы получаете тонну легаси-кода, то «взять и переписать» — это действительно очень просто. Только в случае если вы понимаете, зачем конкретно этот код что-то делает. А я бьюсь об заклад, что ощутимо значимая часть подобного кода будет покрыта сумраком — и на распутывание бизнес-логики и зависимостей времени уйдёт в два-три раза больше, чем на написание нового кода. И это при наличии в команде человека со склонностями к бизнес-анализу и реверс-инженирингу бизнес-процессов, а вообще желательно — полноценного бизнес-аналитика. И хорошее подробное ТЗ тоже из воздуха не возьмётся. И вменяемые вовлечённые представители со стороны заказчика.
*То есть смело умножаем ещё на два — как минимум пять лет. Чудес не бывает.
Тут сильно зависит от того как именно решено переписывать. Полноценное ТЗ зачем, например?
Ну ок, вы берётесь командой в 4-5 человек переписать подобное за год. Смело умножаем это время на 2 и накидываем 20% сверху, то есть где-то 2.5 года* только на новый код.
А почему накидываем 20%? Может сразу 1000%? Или сразу на e^10^10^10 давайте домнажать, зачем себя ограничивать?
Я написал реальную скорость, просто выразил её через такую кривую и не надежную метрику как классы. Понятно, что для их создания потребовалось написание некоторых временных типов, которые потом были удалены. Так что это и есть финальная скорость, причем я учел, что 4-5 человек потратят некоторое время на внутреннюю синхронизацию.
Плюс не забывайте, что когда вы получаете тонну легаси-кода, то «взять и переписать» — это действительно очень просто. Только в случае если вы понимаете, зачем конкретно этот код что-то делает. А я бьюсь об заклад, что ощутимо значимая часть подобного кода будет покрыта сумраком — и на распутывание бизнес-логики и зависимостей времени уйдёт в два-три раза больше, чем на написание нового кода. И это при наличии в команде человека со склонностями к бизнес-анализу и реверс-инженирингу бизнес-процессов, а вообще желательно — полноценного бизнес-аналитика.
Это совсем запущенный случай, хотя я касался и такого кода (недолго, правда).
Я опишу один пример из бывшей соседней команды. Я в нем не принимал участие, однако, про детали слышал.
Итак, был проект внутри большой корпорации. Проект был для себя, а потому внутренние пользователи работали с ним для того, чтобы облегчить себе жизнь, так что они прекрасно знали, для чего необходима та или иная фича. Так что вы правы, что команды по-хорошему требуется бизнес-аналитик. Просто если такие проекты живут сами по себе, то проблема тут намного глубже, чем просто легаси.
Как я говорил, программу надо было переписать с логики "пишем напрямую в базу" на "работаем через intermediate server", ибо:
- Дорогой Oracle делал много лишних действий, так как каждый клиент вычитывал словари и прочие вещи, которые хорошо было бы кешировать.
- Из-за вписанного пароля на сервер, пользователи работали через Citrix (иначе можно было бы слишком легко увидеть пароль), а он стоил единицы миллионов долларов в год.
- Заодно планировалось разгрузить серверы, сменить их ОС на более дешевую.
Итак, проект длился около двух лет тогда. Переписывалось, по сути, UI приложение. Экономия — единицы миллионов долларов в год, примерно. И плюс бизнесу легче стало оформлять хотелки, да и UX улучшился.
Пример выше — это реальный случай оправданного переписывания проекта. Никакого ТЗ не требовалось, да и предыдущее приложение было важным на самом деле (а не в фантазиях менеджеров), так что минимальная чистота кода поддерживалась.
Ну ок, вы берётесь командой в 4-5 человек переписать подобное за год. Смело умножаем это время на 2 и накидываем 20% сверху, то есть где-то 2.5 года* только на новый код.
А почему накидываем 20%? Может сразу 1000%? Или сразу на e^10^10^10 давайте домнажать, зачем себя ограничивать?
Угу.
Моя практика показывает, что даже в гораздо более простых и явных ситуациях нужно использовать коэффициент 3. А в подобных сложных неочевидных случаях — и того больше.
Уж слишком программисты оптимистичны в своих оценках. Это еще Ф. Брукс заметил в «Мифический человеко-месяц».
Не везде применимо, но:
- выделение модулей/компонентов в отдельные dll/so/чтотамвjvm/чтотамдотнете, которые можно писать на чем угодно в рамках платформы
- то же, но в те самые микросервисы
Устаревает не код, а стареют специалисты, его поддерживающие.
С возрастом специалисты становятся профессиональнее, найти и выцепить с насиженных мест таких профи становится с каждым годом все сложнее. А молодые специалисты начинают работу уже с новомодных или хайповых языков и технологий, и изучать проверенные, но не модные языки просто не желают.
Я до сих пор уверен, что Delphi — один из лучших языков программирования. Embarcadero создал много интересных и удобных технологий, и продолжает развивать этот язык. Посмотрите на сегодняшний Embarcadero RAD Studio 10.4. Кто еще может похвастать тем, что одна и та же кодовая база используется для компиляции приложений для Win, Mac, iOS, Android, Linux?
В далеком 2006 году, когда мы создавали свою платформу, на хайпе был Delphi, и мы умышленно выбирали этот язык, надеясь на то, что будет легко искать программистов. Но наше счастье было не долгим, после 2010-го искать дельфистов было все сложнее, а сегодня вообще нереально.
И несмотря на это, я все равно мечтаю переписать проект с Delphi 7 на Embarcadero Delphi 10.4
Я бы сказал, что устаревают как раз выбранные платформы. Прежде всего именно морально устаревают: и молодежь не хочет с ними работать, и специалисты свитчатся и на другие платформы, и на другие карьеры, а кто и просто умирает уже. И только за большие деньги могут "тряхнуть стариной" на пару лет. Как правило как раз на задачи "нам это надо переписать, но не останавливая развития". Я вот с такими предложениями когда обращаются свой обычный рейт на 2 умножаю, готов поторговаться до 1,5 но ниже.
каждый раз вбивать begin/end
Мой первый язык был С, Паскаль по молодости бесил до нервного раздражения.
Если бы не Delphi — Паскаль бы умер…
уже в 2006 году был понятно, что Delphi тупиковая ветвьИнтересно как это могло быть понятно, если в 2006 году технический ВУЗ только в нашем небольшом городе выпустил несколько десятков студентов, изучавших программирование на базе Delphi? (вопрос риторический)
сильная избыточность по текстуС таким подходом html, xml и прочие вещи вообще не имеют права на жизнь.
Embarcadero на первых этапах был заметно глючнее и медленнее, чем DelphiСами того не понимая, вы разделили IDE (Embarcadero) и собственно сам язык (Delphi).
И если бы вы писали проекты от 100тыс.строк на Delphi, вы говорили бы совсем по-другому.
плюс к этому неоправданно дорогой — я думаю это его добило.Тут можно согласиться, что дороговизна отпугнула большое число поклонников.
В настоящий момент, эта ошибка исправлена, уже давно есть бесплатная версия IDE — «Community Edition»
Интересно как это могло быть понятно, если в 2006 году технический ВУЗ только в нашем небольшом городе выпустил несколько десятков студентов, изучавших программирование на базе Delphi? (вопрос риторический)наш ВУЗ выпускал до 2012, это просто преподам лень менять программы. На судьбу делфи это не повлияло.
С таким подходом html, xml и прочие вещи вообще не имеют права на жизнь.вы вручную пишите html или xml?
Сами того не понимая, вы разделили IDE (Embarcadero) и собственно сам язык (Delphi).внезапно :) я всю жизнь считал, что язык — Паскаль, а Delphi и в Embarcadero — IDE. Как IDE, или даже RAD — Delphi была прорывом для своего времени. Так же как и C++Builder.
И если бы вы писали проекты от 100тыс.строк на Delphi, вы говорили бы совсем по-другому.я умею признавать ошибки и при необходимости сходить с тупикового пути. Это касается не только Дельфи, в других областях тоже есть свои тупики.
Тут можно согласиться, что дороговизна отпугнула большое число поклонников. В настоящий момент, эта ошибка исправлена, уже давно есть бесплатная версия IDE — «Community Edition»Поезд уже ушел. Конечно они еще продержатся несколько лет — может даже лет 20, за счет клиентов для поддержки старых проектов, но не более того. Даже в нашей деревне паскаль уже не изучают. Более того, постепенно переписывается софт, который был написан на delphi, в связи с отсутствием специалистов для поддержки.
Язык — Паскаль, потом — ObjectPascal, но учитывая, что потом выходили Дельфи с синтаксическим сахаром и расширениями языка и по сути они являются эталонной реализацией, думаю, честным называть последующие ревизии языка — как Delphi
Сейчас Delphi -это именно язык (самостоятельный)
вы вручную пишите html или xml?
Дело в том, что и разработчики на делфи не пишут вручную begin и end целиком.
Достаточно начать и будет закончена конструкция автоматически. Как собственно и со всеми конструкциями. В это включено перевод каретки в нужное место и возможность переключаться табом между местами ввода.
Даже в нашей деревне паскаль уже не изучают.
Да мало ли чего к конкретном учебном заведении не изучают?
Распространенных языков программирования слишком много, всегда можно найти тот, что «не изучают».
В учебном заведении учат на самом деле вовсе не язык (если это конечно не курсы по конкретному языку, а именно изучение программирования как такового).
А учат алгоритмы, концепции, паттерны с использованием какого-то конкретного языка, но не важно какого. Просто иначе как вы попрактикуетесь?
Паскаль был создан как учебный язык. И использовать именно его для обучения программированию вполне себе удобно.
В учебном заведении учат на самом деле вовсе не язык (если это конечно не курсы по конкретному языку, а именно изучение программирования как такового).Но гораздо лучше это делать на языке, который имеет реальное применение. Хотя именно для начала паскаль был неплох.
Паскаль был создан как учебный язык. И использовать именно его для обучения программированию вполне себе удобно.Именно там он и мог остаться, и даже как средство разработки для быстрых мелких поделок, при соответствующем ценнике, но никак ни в ентрепрайзе. То что хорошо для обучения не всегда является оптимальным для реальной работы. Но это давало платформе хоть какой-то шанс, а сейчас и того нет.
Но гораздо лучше это делать на языке, который имеет реальное применение.
Какой именно?
Почему именно этот а не тот?
Что делать, когда тенденции моды в индустрии поменяются?
Менять все учебные материалы?
А зачем?
Ведь учат не язык.
Учат концепции его применения, паттерны, алгоритмы и т.п.
Учат и язык, и программирование. Первый язык с перекосом в программирование, остальные (в рамках одной парадигмы) с перекосом в язык, вплоть до сравнения конструкций языков.
2. без разницы, сейчас слышал про C#, питон и java.
3. менять программу обучения. Вас не удивляет что сейчас не изучают ламповую схемотехнику, а при обучении вождению не рассказывают как запрягать лошадь?
4. да
5. чтобы не тратить время на бесполезные и неприменимые знания
Не язык. Но хорошо бы, что бы эти концепции алгоритмы и т.д. можно было применить сразу, а не потратив еще время на изучение актуального языка? А если не программист? В общем попадались мне американские курсы программирования для непрограммистов, не помню как называется. Именно быстрое обучение реальным навыкам, что бы через полгода биолог мог написать простенький сайт, а химик посчитать свои реакции. Вот это самый правильный подход.
Вас не удивляет что сейчас не изучают ламповую схемотехнику, а при обучении вождению не рассказывают как запрягать лошадь?
Я вас удивлю:
Закон Ома (опубликован 1827 году) и т.п. — изучают до сих пор.
В общем попадались мне американские курсы программирования для непрограммистов, не помню как называется.
Так это курсы.
Мы же вроде о ВУЗе, там априори более всеобъемлющее образование, более фундаментальное.
А курсы всегда были и есть — по вполне конкретной технологии.
Вас не удивляет что сейчас не изучают ламповую схемотехнику, а при обучении вождению не рассказывают как запрягать лошадь?
Я позволю себе маленькую ремарочку к вашей беседе.
Жаль на самом деле, что не изучают. Я больше скажу — стоит изучать не только ламповую, но и релейную схемотехнику. Логические элементы ей описываются сильно проще и понятнее, чем транзисторные. Отчасти поэтому каждому вновь испеченному схемотехнику приходится на пальцах объяснять то, что посчитали не нужным в учебном заведении. И да, все начинается с реле, потом лампы, потом транзисторы и блоки. В итоге я уже раз 20 прочитал курс «Как начинать понимать схемотехнику бакалавру с дипломом». В пору книгу писать, но… Далеко еще до пенсии — некогда. Работать надо.
Что до запряжения лошадей… boroda-30.livejournal.com/405214.html Буду благодарен за ссылку на оригинал — сей шедевр неоднократно цитировался, увы без указания автора (а тут просто явно перевод). И да, я обучен запрягать лошадей. Учить этому, пожалуй, не надо. Но хороший преподаватель просто обязан рассказать и об этом (хотя бы ради разрядки обстановки). И ещё… Лошадинная сила до сих пор популярная единица измерения.
И да, знания очень редко оказываются бесполезными. Как минимум кроссворды разгадывать проще будет. Впрочем, это просто ремарка. Не надо на нее хоть как-то реагировать.
Delphi — один из лучших языков программирования.
Как и эсперанто — лучший язык для общения. ;)
Проблема Delphi в том, что это собственность одной компании. Сколько компиляторов под этот язык? Сколько IDE?
Проблема Delphi в том, что это собственность одной компании. Сколько компиляторов под этот язык? Сколько IDE?А что вы скажете про C#?
Пожалуй, то же самое. Только у Microsoft больше $$$, чем у Embarcadero.
Только большая часть этого бабла вовсе не средствах разработки.
В своё время почему появился C#? «Маленький Borland» сливал большую и богатую MS на рынке средств разработки. И чтобы переплюнуть «маленький Borland» даже перекупили архитектора, создавшего Delphi (и Turbo Pascal ранее) и поставили во главе проекта C#.
Delphi угасла вовсе не по причине что это проприетарный продукт и не по причине того, что у MS больше бабла. Это всё косвенные причины.
Delphi угасла из-за странной политики инвесторов-владельцев, которые на волне успеха Delphi вместо того, чтобы вкинуть полученные с прибыли ресурсы в развитие успешного проекта, начали покупать на полученную прибыль совсем другие продукты.
И чего-то там не рассчитали. Купленные ими продукты ушли потом за бесценок. Потеряли на этом огромное количество бабла.
А развитию своего лучшего продукта Delphi не смогли/не захотели выделить достаточно ресурсов — и как раз в это время начали выпускать новые глюкавые версии Delphi, еще больше теряя прибыль.
Странное сравнение...
.Net необходим для MS, чтобы упростить разработку ПО под своими технологиями. И тут аналог для .Net только Java (строготипизированная многопоточная среда со сборкой мусора), и урок с Google научил всех, что с Oracle нельзя иметь никакой стратегии. Так что .Net для MS необходим не для прямого заработка, а чтобы упростить клиентам зарабатывать деньги на иных технологиях. Ну и плюс .Net открыт, что уменьшает уровень проблем от Vendor Lock.
С Delphi проблема в том, что вся экосистема (компиляторы и пр.) целиком завязана на одну компанию, которая в общем-то только на этом и зарабатывает. То есть любые финансовые неудачи могут целиком все похоронить, также, как если бы у Oracle была бы только база данных (я уже рассказывал, что компания недавно решила взять и поднять стоимость лицензий для своих баз данных).
Так что для C# риски несравненно меньше, хотя в теории они и того же плана.
Делфи жив с 3 миллионами коммерческих компаний заказчиков
Жив, да. Но вакансий на программиста на Delphi, например,
Но вакансий на программиста на Delphi,
Чисто теоретически на Delphi может/должен уметь писать любой выпускник. Это же Паскаль + SQL.
Либо сейчас в ВУЗах не преподают Вирта либо они не хотят?
Если посмотреть на github, на проекты, созданные в 2020 году.
created:>2020-01-01 language:Pascal 4,127
created:>2020-01-01 language:C 197,705
created:>2020-01-01 language:javascript 2,115,257
Ну хотя бы например вот я, разработал вполне себе полезный проект, который, но вряд ли выложу его на GitHub. По причине нерешенности вопроса принадлежности интеллектуальной собственности и возможных проблем с ИБ.
Так мало вакансий, а не людей, которые могу писать на Дельфи. Я вот могу (с гуглом первое время), но если предложат, то откажусь. Зачем мне восстанавливать навык, по которому мало вакансий?
А если смотришь и проект, и язык/платформу/стэк?
Так я и ищу проекты с интересными мне предметными областями с интересным мне техстэком и методологиям разработки и управления ею с интересными мне деньгами и прочими плюшками.
Слабо представляю предметную область, в которую готов погрузиться на Delphi, или там PHP 3/4 за обычные для условного сеньористого "джависта" деньги.
Слабо представляю предметную область, в которую готов погрузиться на Delphi
А при чем тут лично вы?
Индустрии не нужны лично вы.
Ну не хотите вы — мир не рухнет.
Ну не хотите вы — мир не рухнет.
На самом деле, VolCh прав в том, что если есть выбор между "работать с перспективной технологией" и "работать с субъективно устаревшей технологией", то разумнее предпочесть первое.
Через год перспективная технология может взлететь, что увеличит стоимость специалиста на ней. А вот "устаревшая технология" может еще уменьшить свое присутствие на рынке, так что существующим специалистам достанется меньший кусок пирога (или надо будет срочно переучиваться).
Аналогично, что за те же деньги лучше находиться в компании с высоким потенциалом роста, так как в этом случае, если рост действительно произойдет, можно стать тимлидом/управленцем/архитектором почти на ровном месте (условно, новенькие будут работать под управлением стареньких).
Так что выбор VolCh вполне рационален на сегодня. Но это все лишь предположения...
На самом деле, VolCh прав в том, что если есть выбор между «работать с перспективной технологией» и «работать с субъективно устаревшей технологией», то разумнее предпочесть первое.
Как же я люблю категоричные утверждения моих оппонентов и гипотетические ситуации!
Ну а если у вас 3 детей и ипотека, а за устаревшую технологию вам предлагают хотя бы на 20% весомых золотых монет больше уже сейчас?
Каково тогда будет ваше положительное решение в пользу вакансии с устаревшей технологией?
Лично знаю кучу народа что предпочитают более практичную и прекрасно монетизированную уже сегодня синицу в руках, а не журавля в небе. Причем не по глупости и трусости, а как раз потому что журавли уже неоднократно показывали им свой зад, стремительно улетая в ничто.
К слову, ИТ существует и бурно цветёт уже не первое десятилетие. И огромная куча софта уже разработана и живет и нуждается в поддержке и развитии.
То есть legacy это не исключение — а типовая ситуация.
Сейчас куда не плюнь то повсюду, кроме стартапов, уже устаревшие технологии. А в стартапах на всех мест не хватит, уже не говоря про туманные перспективы с продолжительным финансированием стартапа, что делает выбор стартапа с новыми технологиями неоправданно-безответственным, если на вашей шее трое детей и ипотека.
Через год перспективная технология может взлететь, что увеличит стоимость специалиста на ней. А вот «устаревшая технология» может еще уменьшить свое присутствие на рынке
А может и не взлететь. Такое нередкость.
Устаревшая — может еще десятилетия существовать.
Вон, до сих пор еще в ходу PHP4 и Python2 и в том числе и новые заказы на них поступают знакомым фриленсерам.
Аналогично, что за те же деньги лучше находиться в компании с высоким потенциалом роста
Конечно, лучше.
Но если у вас есть машина времени, чтобы смотаться в будущее и посмотреть, то лично я бы просто купил бы ту валюту/акции, что целесообразнее продать в будущем.
«Знал бы заранее куда упаду — подстелил бы соломки»
Ну а если у вас 3 детей и ипотека, а за устаревшую технологию вам предлагают хотя бы на 20% весомых золотых монет больше уже сейчас?
Каково тогда будет ваше положительное решение в пользу вакансии с устаревшей технологией?
Лично знаю кучу народа что предпочитают более практичную и прекрасно монетизированную уже сегодня синицу в руках, а не журавля в небе. Причем не по глупости и трусости, а как раз потому что журавли уже неоднократно показывали им свой зад, стремительно улетая в ничто.
Тогда Delphi противопоказан. Если хочется стабильности и предсказуемости, то надо смотреть на JVM технологии и JS/TS. Во вторую очередь — на .Net/Python. Все эти вещи крайне распространены, зп в них больше, чем в Delphi (уже приводили здесь детали), объем кода просто гигантский, устаревшим ничего из вышеперечисленного не является.
Устаревшая — может еще десятилетия существовать.
Вон, до сих пор еще в ходу PHP4 и Python2 и в том числе и новые заказы на них поступают знакомым фриленсерам.
Да, просто чаще всего (не всегда, а именно чаще всего, да еще и по моим оценкам) число таких проектов снижается со временем, а число специалистов остается примерно тем же (не успевают люди умирать и уходить из специальности).
Условно, разрабатывая проект вы получаете три вида ресурсов:
- Улучшаете знания предметной области
- Улучшаете знания по технологиям
- Получаете доход (зп и пр.)
Для устаревших технологий второй пункт выдает мало ресурсов. Да и зарплаты уже привели — они просто ниже, чем в тех же JVM языках.
Но если у вас есть машина времени, чтобы смотаться в будущее и посмотреть, то лично я бы просто купил бы ту валюту/акции, что целесообразнее продать в будущем.
Я ниже ответил на ваш же комментарий.
Если хочется стабильности и предсказуемости, то надо смотреть на JVM технологии и JS/TS.
Можно еще смотреть на RDBMS — они будут всегда ;-)
Но вот именно разработчиков RDBMS гораздо меньше требуется чем обычных бэкендеров а-ля Java/.Net/PHP+SQL
Нет такой СУБД которую не сможет уронить разработчик-энтузиаст, а собирать все будет DBA ;-)
Каждому своё. Мне вот собирать за другими не очень нравится. А SQL-разработчики (DBA — это же администраторы?) реально же мало где требуются.
habr.com/ru/post/312134
habr.com/ru/company/lingualeo/blog/515530
habr.com/ru/post/515628
Устаревшая — может еще десятилетия существовать.
Вон, до сих пор еще в ходу PHP4 и Python2 и в том числе и новые заказы на них поступают знакомым фриленсерам.
Да, просто чаще всего (не всегда, а именно чаще всего, да еще и по моим оценкам) число таких проектов снижается со временем, а число специалистов остается примерно тем же (не успевают люди умирать и уходить из специальности).
Было бы удивительно, если бы было наоборот.
1) Но вы же не зеленый первокурсник будете к тому времени, когда работы вообще не будет. Совсем не сложно заметить и поменять специализацию. Для опытного специалиста это проще чем первокурсника. Программирование, оно, по сути, одинаковое. Это я вам говорю как человек, что за 25 лет сменил уже столько технологий, что уже про некоторые забыл как они называются. Особых сложностей переходы не вызывали. Напротив, с годами опыта начинаешь понимать, что оно всё на самом-то деле одинаковое.
2) Процесс вымирания технологий, по причине человеческой интерности происходит крайне медленно. Годами и десятилетиями (как мы видим на примере Delphi, PHP4, Python2). Вы успеете перейти.
Ну а если у вас 3 детей и ипотека, а за устаревшую технологию вам предлагают хотя бы на 20% весомых золотых монет больше уже сейчас?
Не рискну за 20%, для себя установил минимум 50%, если проект сам по себе интересен. Проект с устаревшей технологией очень рисковое вложение своего времени на срок порядка 10 лет с тремя детьми и ипотекой… Может ещё десятилетиями крутиться, а может в любой момент быть принято решение переписать
лучше находиться в компании с высоким потенциалом роста,
Интересно было бы узнать критерии оценки
можно стать тимлидом/управленцем/архитектором почти на ровном месте
А нужно ли? Каждый ли программист хочет стать управленцем?
Я совершенно точно знаю, что не каждый.
Интересно было бы узнать критерии оценки
Иногда компания хочет резко увеличить число сотрудников. ДоДо пицца открыто это заявляла — "Прошлой осенью мы объявили о том, что планируем расширить IT-команду с 48 до 250 человек."
Сейчас Citi Group планирует открыть большой офис разработки в Москве (пруфов не будет).
Конечно, зачастую все это не особо разглашается, так что воспользоваться таким не так-то просто.
А нужно ли? Каждый ли программист хочет стать управленцем?
Я специально же написал — "архитектор". Важно другое — расти по погонам легче в компаниях, где идет активный рост проектов и численного состава. А уже куда расти, как специалист, или как управленец, выбрать должен сам человек (ну по-хорошему).
Иногда компания хочет резко увеличить число сотрудников
Хм, и это все?
Ну с другой стороны — как резко увеличит, точно также резко и сократит.
Я специально же написал — «архитектор».
Может мне не повезло, и мне не встречались правильные архтекторы, то в качестве ориентиров, тех кого встречал на жизненном пути — не не хочу.
расти по погонам легче в компаниях, где идет активный рост проектов и численного состава.
Это обобщение и оно ложно. С прошлого места работы я ушел, потому, что уперся в потолок. Хотя арифметически численный состав рос постоянно.
P.S. Опять таки. Мы на разных языках говорим. Я инженер-технарь, вы — управленец.
Я всегда говорил — менеджеры это люди с другой планеты, они в своем мире живут. И шестеренки не они обтачивают, что бы все работало.
Может мне не повезло, и мне не встречались правильные архтекторы, то в качестве ориентиров, тех кого встречал на жизненном пути — не не хочу.
у меня два таких знакомых есть… Даже трое. Но они архитекторы/тим-лиды, а не просто чуваки, которые рисуют блок-схемы в принятой в конкретно взятой организации нотации
Чисто теоретически на Delphi может/должен уметь писать любой выпускник. Это же Паскаль + SQL.
Либо сейчас в ВУЗах не преподают Вирта либо они не хотят?
Вот читая ваш пёрл «Delphi = Паскаль + SQL» становится очевидно что нет.
В ВУЗах C# и Python сейчас в основном. С примесью базового C++
Потому что, продают знания в области железных дорог и заказчикам абсолютно по барабану на чем этот симулятор сделал.
Вы правильно подметили. В мире госсакупок и госкорпораций технологии вторичны. На первом месте — сертификация, определенный уровень коррупции, связи, небольшая норма политики, чуть-чуть монопольного положения и пр.
Ведь Ваша фраза похоже на "заказчикам не важно, из какого железа сделан поезд", тогда как, по моему опыту, это важная информация.
Если же мы говорим о продукте, то решени на Delphi проигрывает браузерному хотя бы по таким пунктам:
- Сложнее обновлять ПО, так как это необходимо сделать на каждом компьютере пользователя.
- Сложнее делать версии для мобильных платформ. Если решение устанавливается на компьютер, то нельзя с телефона быстро проверить определенные параметры.
- Сложнее поддерживать кроссплатформенность, так как необходимо продумывать схему доставки контента на эти платформы. Например, в Windows админ все сделает через AD, в Linux надо будет уже что-то колдовать с пакетами, а если у кого-то Mac OS, то там отдельная песня. А в случае Web все очень сильно упрощается.
Так что с технически точки зрения, олдскульный продукты выше проигрывал бы аналогичному по функциональности на современных технологиях. Вот только в госсакупках важны другие факторы, к сожалению ...
Еще раз.
Если мы говорим про гостендеры и подобные решения, то там не всегда требуется даже наличие рабочего решения. А если и требуется, но требования по качеству будут далеко не на первом месте.
Ну и потому нет смысла говорить, что "решение есть" — лет 20-30 назад было много решений в стиле "программа-склад", которые требовали установки на компьютер. Потом конкуренция утащила немало из них на Web. А где не было конкуренции, там никто и не тратил деньги.
Те, кто говорил "решение есть", просто ушли из гонки, кроме трех с половиной исключений. Условный SalesForce расчистил один рынок, его аналоги потеснили "существующие решения" на других рынках (например, непрофессиональные трейдерские программы теперь тоже в web). Потом пришли мобильные телефоны и еще раз уменьшили долю рынка компаний, которые распространяли толстого клиента.
А если на рынке монопольное положение, важны связи, необходима коррупционноемкая сертификация и попадание в реестр "правильного ПО", то на реальных пользователей становится натурально плевать, так как на конечное решение о закупке они оказывают околонулевое влияние.
Да и вообще внутренняя кухня программистов мало кого (кроме программистов) интересует.
Несмотря на правдивость фразы, она мало что объясняет. Внутренняя кухня юриспруденции мало кого интересует, просто Вы наймете, скорее всего, юриста, чтобы уже он помогал вам разбираться. Или найдете лицензированного консультанта по тендеру, как это принято с госами.
А случае IT решений, по моим заметкам, выбор продукта стоит или за управленцами (а значит главное — это хорошая презентация, лицензированность/крутизна и немного отката), или на специалистах (в этом случае просто кто-то шибко умный в IT будет выбирать вместе с ответственным за бюджет), или на пользователях.
Бывают и другие сценарии, однако, по моим заметкам, все сводится вот к этим трем.
Первый случай мне не интересен, там будут госсазаказы и прочая муть.
Во втором случае будет главным обоснованность кучи моментов: что будет, если компания рухнет (а куда без этого); сколько стоит это самое решение; насколько легко его синтегрировать в общую систему и так далее. Например, сейчас ряд продуктов (такие, как тот же Gradle Enterprise) вообще предоставляют контейнер для "Kubernetess-совместимого" облака. Так что клиент хостит все у себя (а иначе корпорации сразу забьют), однако настраивать серверы по сути не надо. Аналогично оценивается, насколько легко накидать плагинов, насколько легко смотреть на UI с разных устройств, сколько будет стоить environment (а вдруг для продукта надо еще купить сервер Oracle?), насколько легко добавлять пользователей и обновлять продукт и так далее. А потому, во втором случае сидеть на legacy просто опасно — вас обойдет конкурент просто по фичам. И специалисту вы вряд ли сможете продать "дык поставьте пользователям вон тот zip руками, а обновлять никогда не надо будет".
В третьем случае вообще надо бежать в ногу со временем. Если приложение конкурента позволяет легко и удобно все настроить с условного планшета, то на предложение "установить ПО на комп с миллиардом галочек" никто даже не посмотрит.
К сожалению, даже то, что я сейчас описал, является лишь упрощением реального положения дел. И вот именно из-за таких пунктов выходит, что сидеть на старых технологиях просто стратегически рискованно (говоря языком бизнеса).
Просто для них продукт это занния физики движения поезда. Поставляется под ключ, как правило вместе с железом. Проблем перноса на над ругие системы, а тем более андроид, вообще нет. Зачем разработчику тренажера локомотива думать о возможном перносе на телефон, когда поставляет решение? Его задача сдеалть что бы модель в тренажоре соотвесвовала реальному локомотиву.
Весь вопрос устаревания кода и проблемы с ним — это сохранять возможность с постоянной скоростью развивать и поддерживать бизнес решение.
Сейчас кольцо замкнулось и есть новые команды, которые находятся на этапе выстраивания нового самописного решения вместо готового на базе всех модных вещей, которые есть: облака, кубер, сервисы, лёгкий фронт, унификация, коучбейз, мемкэш, эластик как поисковик, графана и тд и тп полный фарш. Непонятно куда это всё в итоге приедет, но пока тяжело даётся, потому что новые люди не учитывают предыдущий опыт проекта, но очень надеюсь, что получится.
Следующие проблемы возникли на нашем проекте на протяжении такой долгой жизни:
— неправильное/недостаточное использование фреймворка на начальном этапе привело к тому, что фичи фреймворка мы пилили сбоку и сами (долго, дорого). Промахнулись с изначальными бизнес требованиями;
— отсюда произошло следующее — крайняя сложность/дороговизна апдейта версии фреймворка, поэтому сделали это один раз и только для минорной версии;
— смена всех людей на стороне заказчика привело к потере договорённостей, смене несколько раз некоего общего курса и необходимости поддержки функционала, который уже никому не нужен. В какой-то момент, мы из-за этого не смогли дожать переезд на джава 8, который потенциально мог бы решить/облегчить даже текущие проблемы с перфом хотя бы за счёт G1, например;
— меняются менеджеры на стороны исполнителя, т.е. тактика «сдать релиз, а потом пусть хоть всё сгорит на проде» приводит к накоплению годами костылей, что в итоге значительно удорожает и разработку, и поддержку. Не нужно спрашивать разрешения делать свою работу хорошо, не нужно вот этого всего: «сегодня надо закрыть все мажоры» «быстрей, быстрей, у нас дедлайн», «быстро закроем, потом переделаем»;
— меняются собственно сами команды — найти разработчика на джава 1.6 становится таки проблемой. Возникает необходимость обязательного входного обучения и формализация кодстайла, процессов разработки и прочего. Я имею ввиду, чтобы это было прям реально хорошо сделано. Иначе даже на обычных PR будут проблемы. Если каждый будет фигачить как он хочет — будут проблемы в поддержке такого решения. Мы сделали такие ошибки(дали волю разработчику, полагаясь на его опыт на проекте) и есть пару мест в проекте, где никто особо не разбирается, кроме него(ну и собственно сам результат работы неоднозначен);
— меняются люди в смежных системах, с которыми есть интеграции — приводит к появлению новых багов в функционале, который давно не трогали, из-за кривизны новых данных или неправильного использования или использования не по назначению;
— в целом, как мне кажется, смена людей приводит к большим проблемам, чем смена технологий, подходов в разработке, тестировании, деплоя и тому подобных технических вещей. Поэтому важны не только процессы прихода новичков, но и уход опытных людей должен быть сопровождён какими-то артефактами. Это актуально не только для разработчиков, но и для qa, ba, менеджеров всяких. А ещё спеки/документация это хорошо, и поддержка всей этой документации тоже отдельная сложная задача.
— бизнес хочет фич и не хочет вкладываться в техдолг. Отсюда несколько последствий. У бизнеса возникает ощущение, что похожий функционал будет разрабатываться быстрее, а по факту медленнее, идёт сильно расхождение между ожиданиями и реальностью, которое вываливается в недоверие/усиленнный контроль/митинги по разбору полётов и прочие довольно неприятные вещи. Чем более запущенней становится какой-то кусок, тем больше вероятность, что следующая фича полностью ломает функционал(такое было дважды) и приводит в полному переписыванию. Работа с техдолгом обязательна, необходимо формализовать и объяснять бизнесу/командам/PO/SM для чего это делается;
— большое количество «временных» решений, которые потом становятся постоянными, а через пару лет вообще превращаются в баг, и найти историю почему было сделано именно так довольно сложно. Обязательно надо комментировать код/писать тестик в случае такого костыля. Как пример, нашли баг, оказалось что проблемы в интеграции не с нашей стороны, другой системе для починки нужно много времени, Делаем хотфикс у нас, и получается что на нашей стороне обработка интеграции в определённом случае идёт по-другому. Коммент с тикетом для другой системы и юнитест на этот кусочек логики очень просто позволил потом снять с нас обвинения в неправильной работе, когда дошли до очередного этапа разбора полётов.
и нет, дело было даже близко не в зарплатных ожиданиях, з/п могли предложить вполне рыночную
Для устаревших технологий, если долго не можете найти хорошего специалиста какого-то уровня (джун-сеньор — не важно), то логично предлагать выше рынка этого уровня по "конкурирующему" стэку. Грубо, не можете найти на Delphi сеньора за те же Н денег, что предлагают сеньору за Java, вам предлагать надо Н1.5, а то и Н2. Глядишь и тот же Java сеньор согласится вспомнить универ и опять писать на Delphi ))
Для устаревших технологий
Вроде, Delphi выше позиционируют как "язык для дешевой разработки". То есть его продают как технологию, стоимость специалистов на которой будет 50-100 тр. А Вы предлагаете купить специалиста за 300.000*2=600.000. При такой математике бизнес-модель legacy как-то совсем рушится.
Вроде, Delphi выше позиционируют как «язык для дешевой разработки».
Да, это было так, когда Delphi только появилась.
RAD — rapid application development. Потом появился C# (кстати, там был тот же архитектор, что и Delphi придумал, он перешёл в MS для создания C#) — вполне себе альтернатива.
Возможно вы где-то еще встретили этот слоган.
Но на сегодня средств RAD имеется несколько штук и помимо Delphi
RAD — rapid application development.
Формошлепство иными словами ;)
Формошлепство иными словами ;)
Ну вот видите — в наше время этим уже никого не удивишь.
А во времена появления Delphi — это был один из первых хорошо взлетевших подобных проектов.
И альтернатив Delphi, обладающих подобными инструментами — на сегодня имеется уже.
MS Visual Studio с Mfc — не RAD?
А дельфи — хотя бы изначально — разве не RAD для windows only? Это потом уже всякие kylix появились (и провалились)
Если считать 1995-2010 годы, то Delphi — это RAD IDE исключительно для Windows. Но за последние десять лет Delphi сделал мощный прорыв, который многие не хотят видеть.
Например, я знаю Delphi, но не знаю JavaScript и нет времени его изучать, но мне очень надо написать web-приложение. Как это сделать на Delphi?
Очень просто. Берете компоненту TMS Web Core и шлепаете web-формочки JS в родной среде и на родном языке Delphi.
Результат, поверьте, превзойдет все ожидания. Посмотрите видео в интернете про эту компоненту TMS Web Core. Я был не то, чтобы в восторге, а немного шокирован.
Хм. Интересно. А в Delphi разработка не такая же как в MSVS.NET — когда веб-приложение == сервлет для IIS? Но это же совсем не те веб-приложения, что пишут в основном сейчас
А TMS Web Core позволяет писать не только обычные сайты, но и PWA, Electron…
А TMS Web Core позволяет писать не только обычные сайты, но и PWA, Electron…Все верно, коллега. Спасибо за скриншоты.
Я как раз пытаюсь донести до людей, далеких от Delphi, что сегодняшний Delphi очень гибкий и мощный инструмент для RAD быстрой разработки приложений, при чем не важно, web, мобильное или десктоп-приложение.
И альтернатив Delphi, обладающих подобными инструментами — на сегодня имеется уже.Если вы имеете ввиду RAD IDE, то не могли бы вы назвать, какие на сегодня имеются альтернативы для быстрой разработки приложений одновременно для всех основных платформ (Win, Linux, Mac, Android, iOS) или хотя бы для нескольких из них?
Из кроссплатформенного с UI и дизайнером форм первое что приходит в голову это QT.
Погуглил, для Java/Kotlin народ еще JavaFX/TornadoFX предлагает. Я на Джаве не писал никогда — поэтому оценить пригодность не могу.
Особенно чехарда с их IDE меня улыбнула.
Знакомый всю жизнь писал для Android на Eclipse, а потом Google что-то поменяла в своем фреймворке так, что пришлось пересаживаться на Android Studio от гугла.
Обычно "RAD" или "не RAD" решается принятием в команду разработчика с большим опытом в конкретной технологии, который быстро обучает остальных. Потому что "разбираться с нуля самому" в любой новой технологии — это уже не быстро.
Есть только холивар gradle vs maven :-)
Веб-приложения, фреймворки и CMS без счёта
Я просил назвать инcтрумент (IDE), позволяющий разрабатывать разные виды приложений для разных платформ, используя разные технологии.
Embarcadero Delphi именно к таким инструментам и относится.
Я понимаю, что сложно будет назвать альтернативу, но вы хотя бы назовите удобный инструмент для БЫСТРОЙ разработки приложений для веба, чтобы все было «в одном флаконе».
Я просил назвать инcтрумент (IDE), позволяющий разрабатывать разные виды приложений для разных платформ, используя разные технологии.
учитывая, что сейчас все делают на без веб-технологий, а потом суют в какой-нибудь Electron… не знаю даже.
платформы(веб), технологии(фреймфорки) и виды приложений(CMS).
есть немного, но доля истины есть в словах VolCh
сейчас все делают на веб-технологий, а потом суют в какой-нибудь Electron…Прямо в точку.
Но позвольте, делать нативное приложение из web'a, это же через одно место…
Да-да, Electron, Ionic, React Native — те еще инструменты. Хотя Flutter, говорят, вроде ничего :-)
IDE от JetBrains, например. В зависимости от выбранного фреймворка или CMS (может CMF будет точнее). Можно взять IDEA и писать на любом из десятка, наверное, поддерживаемых.
IDE от JetBrainsОно само скомпилирует исходники в нативный код, а я думал, что JetBrains — это продвинутый редактор кода
Плюс кодогенератор.
Плюс много чего.
А так JVM — мир изначально строился по Unix-филсофии.
Поэтому компилятор, сборщик, система управления библиотеками/зависимостями и IDE это отдельные приложения.
Это дает возможность комбинировать и встраивать в другие приложения.
В частности в CI/CD.
А комбайны… Ну Eclipse по началу пытался идти в этом направлении.
Как оказалось это никому особо не нужно.
MS тоже двигает Visual Studio Code. Это вроде бы «просто редактор»
В какой-то мере само, хотя SDK и рантайм надо установить "снаружи". Но в плагинах для некоторых языков и установщик есть, насколько я помню.
IDE — интегрированная среда разработки. У неё есть внешние зависимости, в каких-то случаях минимальные, в каких-то побольше работы надо сделать при первоначальной настройке. Но вот дальше IDE покидать практически не надо — она покрывает весь процесс обычной разработки от создания проекта до отладки его на удалённых серверах.
Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу?Посоветовал бы применить решения, которые позволяют перевести проект на другую платформу. То есть не защищаться от новых технологий, а сразу готовить проект к переезду.
В случае серверной части это микросервисы — если что переписываем на новую платформу/язык/библиотеки. В случае с десктоп-приложениями это плагинная архитектура.
В случае серверной части это микросервисы — если что переписываем на новую платформу/язык/библиотеки.
Микросервисы решают проблему горизонтального масштабирования прежде всего.
Проблему одновременного использования разных технологий в одном проекте — они тоже решают попутно, но за это приходится поиметь кучу лишних накладных расходов. Что не всегда целесообразно.
Вполне возможно писать и монолитное решение, но изначально строго поделив на компоненты внутри кода, так, чтобы в дальнейшем этот компонент можно было заменить прокси-объектом для доступа к компоненту, реализованному в виде отдельного сервиса.
Чегой-то у Вас ту мач болда (жирного).
Проблему одновременного использования разных технологий в одном проекте — они тоже решают попутно, но за это приходится поиметь кучу лишних накладных расходов. Что не всегда целесообразно.
Конечно не целесообразно. Можно для себя сделать отметку — "сколько человекочасов мы готовы выкинуть, в случае, если платформа будет под запретом".
Если 0, то проект сразу надо делать на нескольких языках и платформах. Тогда можно мгновенно отказаться от одной из них. Целесообразность сомнительна, как мне кажется, хотя, почему бы и нет.
Если это число равно году, то надо посчитать, сколько будет стоить переписать ключевые компоненты на новую технологию. И пока эта оценка ниже планки, можно забить на микросервисность — монолит и монорепа тупо будет проще (хотя тут тоже есть моменты). А как пробили планку — пора вытеснять функции из ядра в отдельные проекты.
К тому же, зачастую может оказаться так, что отдельные функции легче решаются на другой платформе. Условную математику лучше сделать в Native и скомпилировать под конкретный процессор, к условному MS Exchange легче ходить из .Net'а, работать со сложной моделью легче всего на Scala и тд.
Однако, Вы правы — в общем случае микросервисы будут просто растратой ресурсов.
Об устаревании кода и жизненном цикле ПО