Стандартизация группы Release / Tools на определенном языке

Question

Я работаю в команде из шести человек, занимающейся сборкой и выпуском программного обеспечения. Мы также поддерживаем множество инструментов для разработчиков, таких как Fisheye, Jira и т. Д. Atlassian, Perforce, Bugzilla, AnthillPro, а также несколько инструментов для домашнего пивоварения (например, мой генератор заметок о выпуске Django).

В большинстве случаев наша команда просто пишет небольшие плагины для более крупных приложений (например, настраивают рабочие процессы в Anthill), долгосрочные служебные сценарии (готовят релиз для QA) или такие вещи, как триггеры Perforce (не позволяйте люди регистрируются в конкретной ветке, если в их описании изменений не указан номер ошибки; выполняется аутентификация в Active Directory вместо внутренних паролей Perforce). Это масштаб наших проблем, хотя иногда мы решаем что-то более значительное.

Мой начальник, достаточно технический специалист, попросил нас стандартизировать один или два языка, чтобы мы могли легче заменять друг друга. Он защищает скрипты bash и Perl из-за их универсальности и простоты. Я понимаю его точку зрения - мы в основном делаем «клей», так почему бы не использовать «клейкие» языки, вместо того, чтобы возиться с чем-то, предназначенным для гораздо больших проектов? Поскольку некоторые из инструментов, с которыми мы работаем, основаны на Java, нам нужно использовать что-то, что иногда говорит на JVM. (Путь наименьшего сопротивления для этих проектов - это BeanShell и Groovy.) Я чувствую огромный зуд к адвокации языка, но я стараюсь не говорить: «Мы должны использовать Python, потому что мне это нравится, а Perl - грубый».

Вместо этого я пытаюсь найти хороший подход к определению нашего набора задач: какие проблемы мы решаем с помощью сценариев? Получим ли мы пользу от библиотеки общих функций нашей команды, или большинство наших проектов более изолированы? Что стоит ожидать, чтобы мои коллеги учились? Какие языки дают нам наибольшую простоту разработки и простоту модификации?

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

Answer 1

Два очка:

• "Eww Perl gross" - это своего рода городская легенда. Вы можете написать отличный чистый самодокументированный код на Perl, и вы можете написать код только для записи практически на любом языке. Это собственность разработчика, а не язык.

  То, что вы пишете клейкий код, вовсе не означает, что код должен сосать, как это делают некоторые клеевые хаки.

• Из многих потоков, сравнивающих Perl с Python на SO, мне кажется, что CPAN в Perl более обширный, чем репозиторий Python, но у меня нет опыта работы с Python и я не могу подтвердить это реальным сравнением.

  НО, одну вещь я знаю. После 5-секундного поиска CPAN имеет модуль JIRA . Является ли это хорошим фактором для вас или нет, решать вам.

Answer 2

Google стандартизировал на Python для таких задач (и многих других) немного раньше, чем я присоединился к компании; Насколько я знаю, огромные преимущества, такие как отличные реализации Python для JVM и .NET, даже не сыграли роли в принятии решения - все дело в удобочитаемости. В то время (и в некоторой степени, даже сейчас) теория в Google заключалась в том, что каждый инженер должен при необходимости настраивать каждую часть кодовой базы - включая, конечно, скрипты сборки, пауки (которые были в Python на время) и пр. Требование к инженерам, уже опытным в C ++ и Java, чтобы выучить еще много «скриптовых» языков (Python, Perl, Bash, Awk, Sed и т. Д.), Было просто бессознательным: нужно было выбрать one . Учитывая это ограничение, Python был очевидным выбором (при других ограничениях Perl мог бы также быть - но я не вижу неизбежного сочетания Bash, Awk и Sed, когда-либо конкурирующих на таких основаниях! _) - и вот как я закончил работать там, чуть позже; -).

Учитывая, что общий потенциал Python против Ruby против Perl против PHP против Bash + Awk + Sed против ... примерно равен, выбор one явно является победителем - и Python обладает хорошей читабельностью, сильной реализацией на JVM и .NET, что делает его энергичным. Серьезно, я могу думать только о Javascript (неизбежном для работы на стороне клиента, теперь богатом сильными реализациями, такими как V8) как о возможном «конкуренте» (к сожалению, JS неизбежно несет много багажа для обратной совместимости - если вы не можете используйте use strict; -подобное ограничение, чтобы помочь в этом, это должно быть важным недостатком).

Answer 3

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

Краткий ответ: «Используйте то, что будет наиболее приятным для разработчиков». Если всем нравится Python больше, чем Perl, по какой-то причине они, вероятно, сделают больше в Python. Если им нравится Ruby больше, чем Python, это одно и то же.

Некоторые вещи для оценки как часть вашего выбора:

• Что уже знают разработчики?
• Чему они больше всего хотят научиться?
• Сколько еженедельного времени ваша команда может потратить на изучение новых вещей (например, обеденных семинаров, официальных занятий и т. Д.)?
• Что большинство людей в сообществе используют для работы с инструментом, который вам необходим для поддержки? Например, Fisheye имеет Java API и несколько примеров REST для Perl и Python. Если вы пишете расширения Fisheye, Java, кажется, победит там. Если вы просто получаете доступ к данным Fisheye, любой язык может использовать REST.
• Какова основная часть вашей кодовой базы? Что вы можете заменить и что вы должны продолжать поддерживать? Я считаю, что многие компании не могут ответить на этот вопрос, потому что каждый разработчик добавляет две новые технологии, о которых они никому не рассказывают. :)
• Какие платформы вам нужно поддерживать? Некоторые языки имеют проблемы с платформой, и я имею в виду не только Windows против Unix. У вас есть устаревшее оборудование, которое вы должны поддерживать? Ваш инструмент работает на этом?
• Какая часть продукции, которую вы производите, может принести пользу другим подразделениям компании? Что используют другие команды?
• Знают ли люди, отстаивающие один инструмент, достаточно хорошо, чтобы стать его защитником? Я спрашиваю Какие пять вещей он ненавидит в вашем любимом языке? Если люди не могут назвать пять действительных вещей, которые не соответствуют их языку или инструменту, у них недостаточно опыта.

Более длинный ответ

Люди склонны сводить это к техническому аргументу, потому что они боятся признать свои предубеждения или изучить, почему они думают так, как думают. Ваш босс может предпочесть bash и Perl, потому что именно этим он занимался, когда начинал. Вам может понравиться Python, потому что у вас есть личная близость к тому, как Python делает вещи. Мне нравится Perl, потому что мне нравится его гибкость и DWIMmery. Как и в любой социальной ситуации, разных людей будут привлекать разные части разных вещей. То, что ты любишь шоколад, не делает ванили злом. Я мог бы дать вам много хороших аргументов, почему Perl может быть полезен, но это не значит, что что-то еще не может дать вам такое же значение.

Какие проблемы мы решаем с помощью скриптов?

На этот вопрос ты должен ответить сам. :)

Нам нужна библиотека общих функций нашей команды, или большинство наших проектов более изолированно?

Скорее всего, это хорошая вещь в Python, Perl, Ruby, Java и почти любом другом языке, который вы можете выбрать. Я думаю, что эта часть вашего требования не зависит от языка. Независимо от того, какой вы выберете, вы, вероятно, захотите это сделать.

Чего стоит ожидать, чтобы мои коллеги учились?

Хороший разработчик должен уметь работать с несколькими разными языками, по крайней мере, до уровня ученика. Эти языки должны включать в себя те, которые имеют совершенно разные предположения о том, как люди выражают проблемы, например, набор {Smalltalk Perl C Lisp Java}.

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

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

И помните, вы никогда не прекращаете учиться. Как разработчику, вам не нужно выбирать один язык, а затем защищать его своей жизнью, отказываясь от всех других, от болезней и здоровья и так далее. Хорошие разработчики будут продолжать отслеживать новые технологии и оценивать их на предмет полезности для своих задач. Тот факт, что вы выбираете один инструмент перед другим, не означает, что вы перестаете обращать внимание.

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

Какие языки дают нам наибольшую простоту разработки и простоту модификации?

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

При этом на разных языках сложились разные культуры и разные наборы инструментов. Людям Perl нравятся vi или emacs, людям Ruby нравится TextMate, людям Java нравится Eclipse или IntelliJ. Это не всегда так, но культура, которая развивается вокруг инструментов, часто более важна, чем технические детали инструмента. Если вашим разработчикам нравится конкретный инструмент типа , им, вероятно, понравится язык, основанный на культуре такого инструмента.

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

Answer 4

Во-первых, важно отметить, что очень трудно убедить кого-то, что он неправ.

Он защищает сценарии bash и Perl, из-за их универсальности и простота

Скрипты Bash не простые. Модель программирования bash действительно сложна и недружелюбна. if заявления и выражения, в частности, ужасающие.

Perl может быть или не быть простым.

Баш универсален. Однако Perl так же универсален, как и Python. Python предустановлен практически во всех дистрибутивах Linux. Так что этот аргумент является правдоподобным.

«Универсальность» bash, Perl и python в точности одинакова. «Простота», однако, не то же самое. Вам будет нелегко «доказать» или «убедить» кого-либо в этом, если они уже объявили Perl простым.

Ситуация .

Если босс защищает Perl, а Perl не является ответом, вы обнаружите, что очень трудно убедить кого-то, что он неправ, делая это усилие почти невозможным.

Если босс просто выбрасывал идеи, то это просто сложно.

Быстрый взлом .

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

Даже это чревато страшными опасностями.

1. Некоторые люди действительно думают, что код гольф важен. Питон проигрывает в коде гольф. Perl побеждает. Нет ничего хуже, чем «Angry Co-сотрудник с Perl Bias», который убьет вас с помощью решений для игры в гольф, которые - потому что они меньше - могут сбить с толку руководство, думая, что они более ясны или «лучше» в произвольном масштабе .

2. Некоторые люди действительно думают, что явное "многословно" и плохо. Python часто проигрывает, потому что предположения указаны как фактические значения параметров. Некоторые люди могут (и делают) жаловаться на то, что на самом деле записывают вещи. Прочитайте Переполнение стека для всех вопросов по Python, где кто-то хочет, чтобы блок try: ушел в кучу предположений.

Если вы выбираете случайные проблемы, вы можете - случайно - выбрать что-то, для чего есть существующий фрагмент Perl или Python, который можно загрузить и установить. Язык может победить только в случае ничьей. Вместо более глубокого сравнения языковых возможностей.

Лучшая ставка

Лучшее, что вы можете сделать, это следующее.

1. Определите, что люди ценят. Вы можете назвать эти «нефункциональные» требования. Это качественные факторы. Каковы основные, основные принципы? Открытый, Доступный, Переносимые Навыки, Простота, Чистота, Честность, Честность, Бережливость, Почтительность, Терпение, Тяжелая работа, Чувство Перспективы, Подводный камень в ветре свыше 20 кН и т. Д. Это сложно. Здесь нет сочувствия.

2. Определите технические случаи использования. Это «функциональные» требования. Какие кусочки клея и интеграции есть? Это тоже сложно. Когда вы это делаете, возникают требования из дерева. Кроме того, когда у вас есть фанат Perl в команде, в эту область будут вливаться многочисленные нефункциональные требования. Ваш менеджер - который предложил Perl - может быть фанатом Perl, и случаи использования могут быть трудны для сбора в присутствии фаната Perl.

3. Определите, как (a) Perl + Bash и (b) Python против (c) Java соответствуют этим основным ценностям и функциональным требованиям. Обратите внимание, что использование Python означает, что вам не нужно так часто использовать Bash. Кстати, я предпочитаю сократить Bash до минимума.

Это большая, сложная работа. Это сложно сократить. Если вы обнаружите, что Perl - это не ответ, и фанат Perl, который вам нужно убедить, это менеджер, который первым предложил Perl, вы можете обнаружить, что убедить кого-то в том, что он неправ, очень сложно.

Edit. Я знаю, что мне запрещено использовать строку «Perl Bigot», чтобы описать потенциальный уровень смещения менеджера по отношению к Perl. Однако я настаиваю на использовании «Perl Bigot» для описания менеджера, предложившего Perl. Вопрос не содержит информации о том, что можно изменить. В худшем случае (а) менеджер - это фанат Perl и (б) Perl - не ответ.