Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.
Ну да, скрипт или часть/модуль которую можно отдельно исправить без пересборки всего и вся.
Ну да, риск увеличивается, хотя, если уже существующий сломанный «скрипт» прошёл в прод — значит риск что даже при правильном деплое что то будет сломано тоже велик )
Ну нет же. Допустим вероятность того, что разработчик сломал что-то во время фикса в коде равна p > 0. Но есть еще вероятность q > 0 того, что он сломал что-то во время подключения (например подключился не на тот сервер, добавил лишний пробел или запятую, скопировал файл с line break виндовским из IDE, скопировал из IDE не ту версию скрипта и т.п.). Получили вероятность p+q > p.
А есть ещё вероятность что где то в процессе деплоя есть ошибка, в процессе сборки, в людях которые этим занимаются и прочая-прочая.
Между итоговым риском хотфикса человеком который это делал и понимает в чём ошибка сразу по живому против скорости и стоимости внеплановой выкатки изменений по штатному расписанию обычно (по моему личному опыту) выбирают первое. И в этом есть смысл ) Как в прочем и в обратном.
ЗЫ: но разработчиков которые регулярно промышляют описанными вами вещами я бы и до теста не допускал, не то что на прод хотфиксы выкатывать.
На самом деле к алгебре у меня претензий нет.
Есть — к отсутствию программирования. (информатика в школах несёт слишком базовый характер, по сравнению с нынешними требованиями… если она есть вообще)
ЗЫ: а ещё истории, географии, фальклору и прочим прекрасным вещам. Но это — сугубо моя боль человека, закончившего гуманитарный лицей… а потом поступившего в МГУ.
Что то мне подсказывает, что программистам нужна не столько школьная алгебра, сколько алгоритмическое мышление, понимание и распознавание паттернов и прочие прекрасные вещи.
Да, алгебра даёт местами похожие навыки, а местами нет. Но говорить что именно для этого она нужна — как то неправильно.
Если б в школе учили алгол, к примеру, или какой то другой ЯП — это давало бы намного больше полезного детям в плане будущей карьеры программиста, чем алгебра и совсем небыло бы возможно без её изучения.
Вопрос то в комментариях задавался не раз: где вам нужны квадратные уравнения кроме непосредственно связанных с ними областей?
Сделать сайт — нужна алгебра?
Сделать выборку из базы данных?
Импортировать файлы и, адаптировав данные, передать дальше?
Дёрнуть апи или создать апи-сервис?
В подавляющем большинстве случаев — квадратного уравнения (или кубического, или какой то иной степени) вы там не встретите.
Ну да, эти показатели бывают связаны. Но всё-равно надо понимать что для тебя из этого важнее — что бы это было интересно или что бы это было именно на делфи (подставьте на это место язык по выбору). =)
Зависит от условий работы, и количества денег, наверное, в первую очередь. А во вторую — от предпочтений. По крайней мере примерно так выглядят приоритеты тех кого я знаю (и кому уже, в общем то, всё-равно на чём писать из своего стека).
Надо быть очень счастливым в жизни, что бы стек играл бОльшую роль при выборе работы, чем интересность задач, условия труда, формат и организация работы, коллектив и количество денег.
На мой взгляд, по крайней мере.
Ну мы говорим о равноценных приложениях с одинаковым функционалом. т.е. с одинаковой скоростью обновления страниц и сохранением контента, округлыми кнопками и горизонтальным скролом.
К примеру, обычные десктопные приложения, которые не сильно изменились в плане функционала и интерфейса за последние 20 лет.
Безусловно, сравнение приложений с отсутствием функционала и наличием его всегда будет простым. Но вопрос то в том, что функционал остаётся прежним, просто меняются технологии на которых оно написано.
Поэтому и возникло столько к Вам вопросов — мы просто разные вещи сравниваем. Вы — два приложения с разным функционалом и на разных технологиях, я — с одинаковым функционалом и на разных технологиях.
Для ясности — я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.
ну так и я о фирмах с штатом больше 100 разработчиков (иногда на порядок)
1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
это по определению не так ) потому что кроме самого непосредственного внесения правок, ещё и полный цикл деплоя.
2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.
=)) т.е. надо ещё и дежурного девопса держать?
Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.
Все знают риски. А кто не знает — тем это быстро объяснят. Но те кто за это отвечают (чаще всего бизнес) предпочитают скорость решения бага возможными осложнениями. Особенно во время, когда больше части работников нет в доступе (выходной, к примеру) и держать дежурного QA, Тестировщика, Девопса, и разработчика (желательно ещё кодревьюера) причём способных поддержать ВЕСЬ проект (или каждую из его частей) и ждать пока фикс пройдёт все тесты, кодревью и задеплоится (что не так уж и быстро бывает, особенно если народ по удалёнке).
И это вполне приемлимо, если правильно оформлять фиксы и потом спокойно и правильно доделать когда наступит рабочее время.
А если исходить из того, что человек может быть членистоног и что то сломает — так он с тем же успехом выпустит фикс который пройдёт все тесты и опять положит прод (как тот, который положил), или QA неправильно что то сделает или ещё кто то в цепочке деплоя. Риски, в общем то, те же )
Если у вас иначе — хорошо. =) Но чем длиннее цепочка — тем она длиннее.
По мне так это скучно и явно не перспективно. Хотя, как сказал Егор, в корпорациях можно бесконечно пилить один и тот же код. Потом переписывать его с Дельфи на Джаве или С# и не париться до пенсии.
Э? С чего его, вдруг, «переписывать»? Зачем? Никогда не видел бизнеса, которому было бы интересно, что бы код просто переписывали. (вру, видел, но из этого ничего хорошего не вышло)
И что значит «пилить один и тот же код». Что?! Задачи разные, бизнес разный, автоматизация разных систем — разная… даже архитектура у похожих проектов чудовищно разная.
«Один и тот же код». Бугагашечки.
Ну да, Дельфи конечно не для игр. В общем, главное, что Вы довольны. По мне так это скучно и явно не перспективно.
1. Ну так и бизнес это не только и не столько игры )
2. А чем можно быть недовольным? Зарплата у тех, кто поддерживает старые технологии обычно повыше рынка. Задачи интересные, а начальство лояльное.
3. О каких перспективах речь? Карьерных? Они не зависят от стека. Зарплатных? Они весьма неплохи. Ещё варианты?
4. Скучно. Ну тут уж каждому своё… мне не скучно программировать, строить логику и архитектуру. А что не скучно вам?
Я понимаю что то, что я сейчас напишу, звучит не особо приятно и я рискую нахватать минусов, но вы уверены что проблема в новых вещах, а не в тех кто их эвалуирует и применяет? :)
О_О
На самом деле я уверен что почти всегда это именно так.
И это касается любых технологий, старых и новых %)
ЗЫ: причём, чаще всего проблема в тех, кто этим руководит.
Что вы будете делать если внезапно выясниться что по какой-то причине на Delphi он дальше жить не может? Что вы будете делать если ваши Delphi-программисты внезапно поувольняются или уйдут на пенсию, а новых вы не найдёте? Переделывать всё в авральном порядке?
1. Технологически, я слабо представляю, почему проект может не мочь дальше жить на этом стеке. Ну, допустим.
2. Такой риск, кстати, был. Но на рынке всегда можно найти необходимые програмистские ресурсы. Или обучить. Или предвидеть ситуацию и потихоньку набирать/обучать.
А если такое всё таки случится…
В таком случае компания просто закроется/ направление прикроют / поручат эту область ответственности другому подразделению и оно будет его создавать ещё пару лет в первом приближении. Примерно такие варианты )
Потому что переписывать такую хрень — реально затратное дело, и чаще всего требует новых специалистов. «Попробуйте включить-выключить».
ЗЫ: на самом деле не столько страшно, если Delphi нельзя будет использовать. В конце-концов, основная логика на сервере. Вот если MS SQL нельзя будет использовать и придётся переходить на что то принципиально не мигрируемое с него… вот тогда будет праздник )))
Я надеюсь, что «кровавый энтерпрайз» хорошо компенсирует подобный подход к разработке.
Чаще хорошо, чем плохо. В конце-концов ничего такого в таком подходе нет — я, к примеру, люблю программировать, создавать логику, строить процессы, а не искать фреймворки и общаться с Илоном )
Но не все работают там. А вне энтерпрайза процветает паратигма «плоского мира», когда чтобы пообщаться с тем же Илоном Маском, к примеру, надо знать английский и его аккаунт в Твиттере :)
Как в прочем и не все работают в плоском мире. Вообще, мне очень хочется сказать, что в энтерпрайзе куда больше народу, чем тех, кто перебирают фреймворки (ну или по крайней мере, они занимаются куда более серьёзными вещами, чем клепание сайтиков и игр), но не буду. Хотел бы я знать реальное распределение между программистами )
А не думали, что будет после ухода из энтерпрайза?
Думал. Но… зачем? )
ЗЫ: нет, мне правда интересно )
Весь мой профессиональный опыт говорит мне о том что в ИТ идёт постоянный прогресс и новые вещи обычно лучше старых. Естественно не нужно хвататься за каждую новую технологию и переписывать проекты с нуля каждый год, но внедрять новые фреймворки и технологие нужно.
Ну, вот, я не вижу почему то чем новые вещи были бы принципиально лучше старых. Более того, один из проектов-таки переписали… но не смогли запустить. =)) так и остался суровый легаси вариант и дальше работать.
Возможно, новые продукты и проекты и впрямь стоит писать на новых фреймворках и технологиях (в конце-концов, их делают в том числе и с расчётом на более быструю разработку и конечный продукт как цель). С этим я даже спорить не собираюсь )
Но переписывать проекты с огромной кодовой базой, идущей ещё из прошлого тысячелетия, отказываться от текущих разработчиков и нанимать новых, поддерживать и развивать паралельно два проекта (включая тестирование пользователями и бизнесом), пока не будте перенесён весь функционал, а потом поддерживать уже новый — в этом я никакой особой выгоды (в плане технологий) даже среднесрочной я не вижу.
Вот в том, что бы пересмотреть архитектуру и избавиться от какой то части техдолга — определённо есть смысл, хотя и меньше чем может показаться.
Ну, с точки зрения бизнеса, если проект отлично живёт на Delphi, то почему бизнес должен считать что для проекта существует что то лучше в мире? И в каком плане оно вообще будет лучше? )
не думаю, что если даже я в рабочее время пообщаюсь с авторами SSMS или Delphi 7 — они мне ответят ))
и, да — поиск библиотек и фреймворков для кровавого энтерпрайза не занятие — там уже всё это давно нашли. А программисты должны у них программировать, а не с авторами общаться и по туалетам бегать )
Ну, без хотя бы такого работать не получится.
А по поводу остальных вещей — ими занимается очень небольшое количество программистов.
Причина проста — если для работы их навыков достаточно, то работа обычно не позволяет этим заниматься в рабочее время. А нерабочее время посвящать прокачке профессиональных навыков не все готовы )
Не согласен. Растёт и то и другое, но стоимость поддержки по моему опыту всегда растёт быстрее.
Очень субъективная оценка.
Большая часть проектов которые я видел нуждались в поддержке в большей степени из-за архитектуры и размера и в меньшей — из-за техдолга. Переписывание (кроме того, что это само по себе очень затратное мероприятие, хотя бы потому что на это время нельзя остановить разработку и поддержку оригинального проекта) в итоге приведёт примерно к такому же объёму работы по поддержке и развитию. Вдвойне по причине наличия новых багов (а если это новая технология, так вообще) и нюансов.
В данном контексте «качественнее» для меня означает менее подвержено багам и критическим ошибкам.
Новые технологии, нюансы которых ещё не отшлифованы годами до блеска? Недокументированными возможностями, неустаканенными версиями и огромным проектом, который только что на этом всём написали?
Вообще говоря, достаточно спорное утверждение.
Я вижу «качественность» немного в других областях, если честно. Оптимизация скорости, объёма данных, прозрачность архитектуры, поддерживаемость итп. Как минимум, большая часть «качества» — это продуманность архитектуры и процессов. И она слабо зависит от модности фреймворков. В меньшей — реальная скорость работы и количество ресурсов для этого. Скорость в древних системах, обычно, уже дотюнингована до требований пользователя, а ресурсы… только ради них всё затевать — как то странно. Тем более что и выигрыш там обычно не так уж велик )
Это зависит и от того и от другого. Естественно архитектура и подход имеют большее значение, но и «инструменты» играют свою роль. Если бы это было не так, то до сих пор все бы писали исключительно на ассемблере или даже на перфокартах.:)
Я до сих пор вижу что люди пишут и новые проекты и ищут на существующие, к примеру, на Delphi. После определённого уровня абстракции разница в инструментах не так уж критичная, особенно когда умеешь ими пользоваться.
Извини, просто тяжело общаться с человеком, который просто утверждает что что то «качественее» просто потому что он так сказал. А потом ещё всячески уходит от попыток как то это обосновать.
Ну раз попытки узнать, откуда информация про «качественность» в твоих постах — самоутверждение, то пусть будет так.
И так много времени потратил впустую на разговоры с тобой.
Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.
Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки. =) А если не развивается — зачем переписывать?
И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.
И снова — что значит «качественнее»? И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )
Ну да, риск увеличивается, хотя, если уже существующий сломанный «скрипт» прошёл в прод — значит риск что даже при правильном деплое что то будет сломано тоже велик )
А есть ещё вероятность что где то в процессе деплоя есть ошибка, в процессе сборки, в людях которые этим занимаются и прочая-прочая.
Между итоговым риском хотфикса человеком который это делал и понимает в чём ошибка сразу по живому против скорости и стоимости внеплановой выкатки изменений по штатному расписанию обычно (по моему личному опыту) выбирают первое. И в этом есть смысл ) Как в прочем и в обратном.
ЗЫ: но разработчиков которые регулярно промышляют описанными вами вещами я бы и до теста не допускал, не то что на прод хотфиксы выкатывать.
На самом деле к алгебре у меня претензий нет.
Есть — к отсутствию программирования. (информатика в школах несёт слишком базовый характер, по сравнению с нынешними требованиями… если она есть вообще)
ЗЫ: а ещё истории, географии, фальклору и прочим прекрасным вещам. Но это — сугубо моя боль человека, закончившего гуманитарный лицей… а потом поступившего в МГУ.
Да, алгебра даёт местами похожие навыки, а местами нет. Но говорить что именно для этого она нужна — как то неправильно.
Если б в школе учили алгол, к примеру, или какой то другой ЯП — это давало бы намного больше полезного детям в плане будущей карьеры программиста, чем алгебра и совсем небыло бы возможно без её изучения.
Вопрос то в комментариях задавался не раз: где вам нужны квадратные уравнения кроме непосредственно связанных с ними областей?
Сделать сайт — нужна алгебра?
Сделать выборку из базы данных?
Импортировать файлы и, адаптировав данные, передать дальше?
Дёрнуть апи или создать апи-сервис?
В подавляющем большинстве случаев — квадратного уравнения (или кубического, или какой то иной степени) вы там не встретите.
Так что — дело не в алгебре.
Но если всё-же разделить эти понятия и принять прочие равными, то что останется? )
Надо быть очень счастливым в жизни, что бы стек играл бОльшую роль при выборе работы, чем интересность задач, условия труда, формат и организация работы, коллектив и количество денег.
На мой взгляд, по крайней мере.
К примеру, обычные десктопные приложения, которые не сильно изменились в плане функционала и интерфейса за последние 20 лет.
Безусловно, сравнение приложений с отсутствием функционала и наличием его всегда будет простым. Но вопрос то в том, что функционал остаётся прежним, просто меняются технологии на которых оно написано.
Поэтому и возникло столько к Вам вопросов — мы просто разные вещи сравниваем. Вы — два приложения с разным функционалом и на разных технологиях, я — с одинаковым функционалом и на разных технологиях.
ну так и я о фирмах с штатом больше 100 разработчиков (иногда на порядок)
это по определению не так ) потому что кроме самого непосредственного внесения правок, ещё и полный цикл деплоя.
=)) т.е. надо ещё и дежурного девопса держать?
Все знают риски. А кто не знает — тем это быстро объяснят. Но те кто за это отвечают (чаще всего бизнес) предпочитают скорость решения бага возможными осложнениями. Особенно во время, когда больше части работников нет в доступе (выходной, к примеру) и держать дежурного QA, Тестировщика, Девопса, и разработчика (желательно ещё кодревьюера) причём способных поддержать ВЕСЬ проект (или каждую из его частей) и ждать пока фикс пройдёт все тесты, кодревью и задеплоится (что не так уж и быстро бывает, особенно если народ по удалёнке).
И это вполне приемлимо, если правильно оформлять фиксы и потом спокойно и правильно доделать когда наступит рабочее время.
А если исходить из того, что человек может быть членистоног и что то сломает — так он с тем же успехом выпустит фикс который пройдёт все тесты и опять положит прод (как тот, который положил), или QA неправильно что то сделает или ещё кто то в цепочке деплоя. Риски, в общем то, те же )
Если у вас иначе — хорошо. =) Но чем длиннее цепочка — тем она длиннее.
Вот как раз энтерпрайз вечен. =)
Э? С чего его, вдруг, «переписывать»? Зачем? Никогда не видел бизнеса, которому было бы интересно, что бы код просто переписывали. (вру, видел, но из этого ничего хорошего не вышло)
И что значит «пилить один и тот же код». Что?! Задачи разные, бизнес разный, автоматизация разных систем — разная… даже архитектура у похожих проектов чудовищно разная.
«Один и тот же код». Бугагашечки.
1. Ну так и бизнес это не только и не столько игры )
2. А чем можно быть недовольным? Зарплата у тех, кто поддерживает старые технологии обычно повыше рынка. Задачи интересные, а начальство лояльное.
3. О каких перспективах речь? Карьерных? Они не зависят от стека. Зарплатных? Они весьма неплохи. Ещё варианты?
4. Скучно. Ну тут уж каждому своё… мне не скучно программировать, строить логику и архитектуру. А что не скучно вам?
О_О
На самом деле я уверен что почти всегда это именно так.
И это касается любых технологий, старых и новых %)
ЗЫ: причём, чаще всего проблема в тех, кто этим руководит.
1. Технологически, я слабо представляю, почему проект может не мочь дальше жить на этом стеке. Ну, допустим.
2. Такой риск, кстати, был. Но на рынке всегда можно найти необходимые програмистские ресурсы. Или обучить. Или предвидеть ситуацию и потихоньку набирать/обучать.
А если такое всё таки случится…
В таком случае компания просто закроется/ направление прикроют / поручат эту область ответственности другому подразделению и оно будет его создавать ещё пару лет в первом приближении. Примерно такие варианты )
Потому что переписывать такую хрень — реально затратное дело, и чаще всего требует новых специалистов. «Попробуйте включить-выключить».
ЗЫ: на самом деле не столько страшно, если Delphi нельзя будет использовать. В конце-концов, основная логика на сервере. Вот если MS SQL нельзя будет использовать и придётся переходить на что то принципиально не мигрируемое с него… вот тогда будет праздник )))
Чаще хорошо, чем плохо. В конце-концов ничего такого в таком подходе нет — я, к примеру, люблю программировать, создавать логику, строить процессы, а не искать фреймворки и общаться с Илоном )
Как в прочем и не все работают в плоском мире. Вообще, мне очень хочется сказать, что в энтерпрайзе куда больше народу, чем тех, кто перебирают фреймворки (ну или по крайней мере, они занимаются куда более серьёзными вещами, чем клепание сайтиков и игр), но не буду. Хотел бы я знать реальное распределение между программистами )
Думал. Но… зачем? )
ЗЫ: нет, мне правда интересно )
Возможно, новые продукты и проекты и впрямь стоит писать на новых фреймворках и технологиях (в конце-концов, их делают в том числе и с расчётом на более быструю разработку и конечный продукт как цель). С этим я даже спорить не собираюсь )
Но переписывать проекты с огромной кодовой базой, идущей ещё из прошлого тысячелетия, отказываться от текущих разработчиков и нанимать новых, поддерживать и развивать паралельно два проекта (включая тестирование пользователями и бизнесом), пока не будте перенесён весь функционал, а потом поддерживать уже новый — в этом я никакой особой выгоды (в плане технологий) даже среднесрочной я не вижу.
Вот в том, что бы пересмотреть архитектуру и избавиться от какой то части техдолга — определённо есть смысл, хотя и меньше чем может показаться.
Ну, с точки зрения бизнеса, если проект отлично живёт на Delphi, то почему бизнес должен считать что для проекта существует что то лучше в мире? И в каком плане оно вообще будет лучше? )
не думаю, что если даже я в рабочее время пообщаюсь с авторами SSMS или Delphi 7 — они мне ответят ))
и, да — поиск библиотек и фреймворков для кровавого энтерпрайза не занятие — там уже всё это давно нашли. А программисты должны у них программировать, а не с авторами общаться и по туалетам бегать )
А по поводу остальных вещей — ими занимается очень небольшое количество программистов.
Причина проста — если для работы их навыков достаточно, то работа обычно не позволяет этим заниматься в рабочее время. А нерабочее время посвящать прокачке профессиональных навыков не все готовы )
Большая часть проектов которые я видел нуждались в поддержке в большей степени из-за архитектуры и размера и в меньшей — из-за техдолга. Переписывание (кроме того, что это само по себе очень затратное мероприятие, хотя бы потому что на это время нельзя остановить разработку и поддержку оригинального проекта) в итоге приведёт примерно к такому же объёму работы по поддержке и развитию. Вдвойне по причине наличия новых багов (а если это новая технология, так вообще) и нюансов.
Новые технологии, нюансы которых ещё не отшлифованы годами до блеска? Недокументированными возможностями, неустаканенными версиями и огромным проектом, который только что на этом всём написали?
Вообще говоря, достаточно спорное утверждение.
Я вижу «качественность» немного в других областях, если честно. Оптимизация скорости, объёма данных, прозрачность архитектуры, поддерживаемость итп. Как минимум, большая часть «качества» — это продуманность архитектуры и процессов. И она слабо зависит от модности фреймворков. В меньшей — реальная скорость работы и количество ресурсов для этого. Скорость в древних системах, обычно, уже дотюнингована до требований пользователя, а ресурсы… только ради них всё затевать — как то странно. Тем более что и выигрыш там обычно не так уж велик )
Я до сих пор вижу что люди пишут и новые проекты и ищут на существующие, к примеру, на Delphi. После определённого уровня абстракции разница в инструментах не так уж критичная, особенно когда умеешь ими пользоваться.
Ну раз попытки узнать, откуда информация про «качественность» в твоих постах — самоутверждение, то пусть будет так.
Не насилуй себя )
И снова — что значит «качественнее»? И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )