Должны ли вы стандартизоваться на языке сценариев в dev-группе?

Question

На работе мы пишем небольшое или небольшое количество сценариев, чтобы помочь нам в нормальном развитии. У нас есть некоторые люди, которые более удобны в python, некоторые в perl, некоторые в php и т. Д.

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

Другие моменты, когда я думаю, что мы выиграем от стандартизации, чтобы было больше разделяемых библиотек, и поэтому мы не попадаем в ситуацию «Я не могу работать над этим скриптом, потому что я не могу знать питон ".

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

Answer 1

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

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

Answer 2

No.

Ваше окружение DEV это, мы надеемся, живое существо, что изменения и культивируется. Новые возможности (языки сценариев) должны быть укомплектованы, а старые места, которые не посещались годами, когда-нибудь будут устранены инструментами или время от времени пересматриваться, и будет проведена оценка. Надеемся, что скрипты dev - это небольшое количество разработок и автоматизации. Скорее всего, команда будет дрейфовать к набору стандартов (ant, python и т. Д.).

Answer 3

Мое мнение таково, что он подобен любой другой среде разработки. Вы стандартизируете один язык разработки? Зачем? То же самое должно быть верно для вашей среды сценариев. Я не только склоняюсь к стандартизации на конкретном языке, я думаю, вы должны стандартизировать все те же вещи, которые, как мы надеемся, выполняем в вашей среде программирования (соглашения об именах, стиль кодирования и т. Д.). Конечно, есть счетные аргументы, и иногда будут исключения, но, надеюсь, их будет мало и по уважительным причинам.

Answer 4

Как и все, есть перебежки и минусы.

Как разработчик мне не нравится ограничиваться «официальными стандартами компании». Чаще всего эти правила имеют тенденцию сдерживать и задыхаться.

Я думаю, что самое главное - всегда иметь двух человек, которые могут читать и писать сценарий на персонале, чтобы один человек мог отправиться в отпуск или болеть, не подняв работу.

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

Answer 5

Я бы отстаивал стандартизацию на нескольких языках. «Вы должны использовать либо Python, либо Perl, либо Ruby. Не Rexx, ни PHP, ни NewBatch, ни другое, потому что ваши братья должны быть способны читать ваши письма без излишнего отчаяния или резки их кожи».

Answer 6

Я думаю, что подходящее место, чтобы задать этот вопрос с вашей собственной командой.

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

Конечно, есть преимущества для каждого подхода. Если каждый член команды может свободно выбирать свой родной язык, он может быть более продуктивным, и ваш бизнес пойдет на пользу. С другой стороны, если кто-то пишет критический инструмент на языке, который только она знает, а затем что-то происходит с ней (болезнь, новая работа и т. Д.), Вы можете застрять в одной точке отказа, которую никто не знает, как исправить.

Answer 7

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

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

Если некоторые разработчики жалуются на сценарий, не написанный на их языке, попросите его изучить его, особенно если это один из распространенных, таких как Ruby, Perl и др.

Answer 8

Per Project, все, что нужно проверить, должно, вероятно, следовать правилу минимальной сложности.

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

Когда мы подхватили подобные проекты, мы в значительной степени считали создателей дураками и высмеивали их. Они не могли потрудиться, чтобы изучить один скриптовый язык ???

Сказанное, если вы не проверите его - кому это нужно?