19 мая 2014 г., 12:05 пользователь Dmitry Smal <[email protected]> написал:
> Допустим, ты начинаем новый полезный проект добра.
> Как ты будешь выбирать технологии?
>
> Что бы:
> 1) минимизировать проблемы с поиском разработчиков
> 2) минимизировать пробелмы с деплоем
> 3) (может быть) обеспечить надежную архитектуру в будущем
> 4) (вероятно) уже есть есть знакомый (ые) девелоперы / команда работающие с
> технологией X.
>
> Каким боком тут подходит Perl? Пунктом #2 и #4,
>
> Давайте подумаем что делать с пунктами 1, 3 и у нас будут проекты которые
> выбирают Perl.
а что не так с п.3 ? какие у perl проблемы с архитектурой?
вот на Rails написал веб приложение, года через 3 посмотрел что с ним
- всё нужно переписывать - старая версия rails объявлена legacy,
разработчиков на неё нет ("они каждый раз разные"),
переделывать нужно всё в т.ч. и архитектуру. если какого-то
разработчика и удастся задействовать, он первым делом будет пытаться
перейти на новые rails, (справедливо) опасаясь за свою карьеру,
которая пострадает если он будет пилить старый Rails, да собственно
аргументы у перехода будут те же - не найти разработчиков в будущем.
если переделать приложение малой кровью, по минимуму, то опять же, в
коде останутся конструкции, которые вроде как счас не используются
(т.к. появились новые парадигмы), и опять же, они выглядят
как legacy код и как "плохая архитектура".
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
