Реальные преимущества использования Moo (se) над Perl OO

Question

В настоящее время я работаю в компании, где мы занимаемся разработкой Perl. Однако код действительно беспорядочен, использует действительно старые идиомы Perl, поэтому я решил медленно очистить его и научить моих коллег о Modern :: Perl, хорошем дизайне программного обеспечения, OOP - абстракции, сцеплении, наследовании, принципах SOLID и т. Д. У меня есть недостаток, что я работаю здесь всего месяц, поэтому я здесь совершенно новый.

Мой вопрос: могу ли я (если это так) убедить их в том, что вы решили переключиться на Moo (se) из простого Perl OO? В чем его преимущества? Мне нужны действительно веские причины для их рассмотрения.

Есть ли высокая стоимость с использованием этих модулей? Я знаю по опыту, что очень удобно использовать эти модули (также черты действительно хороши), но я боюсь, что они откажутся переключиться из-за соображений производительности.

So. Есть ли преимущество и как бы вы описали его разработчикам Perl, которые застряли в до 2000 года?

Answer 1

Я бы начал с просьбы - ваши коллеги ценят то, что вы подразумеваете под этими условиями, и почему они хорошие вещи? Всегда есть сложная задача, связанная с принятием новой парадигмы, потому что ДАЖЕ ЕСЛИ ваш «новый способ» во всех отношениях лучше ... вы будете создавать устаревшую кодовую базу, которая все еще должна поддерживаться. Или переработано.

Убедить кого-то «пойти OO», если они построили свое понимание Perl из сценариев bash для взлома perl ... может быть проблемой. Они вполне могут - совершенно правильно - указать, что, хотя есть преимущества для переключения, применим «самый низкий общий знаменатель». Есть много людей, которые знают «не-лося» perl по сравнению с теми, кто знает «лося».(Это может считаться в вашу пользу, хотя - укажите, что это полезный технический специалист, который улучшает их будущую возможность трудоустройства)

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

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

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

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

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

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

Answer 2

Для Moose конкретно есть интересные обсуждения производительности на PerlMonks и Stackoverflow. Суть его в том, что у Муса есть значительный штраф за запуск, но не так много после этого.

Однако, я думаю, что здесь есть большой вопрос: Когда вы должны переписать существующий код?

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

1. Инструмент/метод XYZ является полезным, поэтому мы должны использовать его при написании нового кода.
2. Инструмент/метод XYZ настолько полезен, что мы должны переписать существующий код, чтобы использовать его.

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

Изменение объектной системы, используемой существующей базой кода, близко к фундаментальной перезаписи кода. Это большая стоимость и риск, и для этого вам нужна очень веская причина. Больше, чем просто «Moose лучше писать код».

Когда придет время написать новый фрагмент кода, который довольно отделен от устаревшего кода, это может быть подходящее время, чтобы попробовать Moose. Но я подозреваю, что изменение всего существующего кода на самом деле не оправдано. (Кроме того, с точки зрения фактического привлечения людей к вашим идеям, небольшие поэтапные изменения будут работать намного лучше, во всяком случае).