Правильный язык для задания

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

• достаточно ли у нас навыков и опыта для успешной реализации
• сможем ли мы найти необходимые ресурсы для его поддержки
• используем ли мы язык / технологию в нашей системе
• усложняется ли вся система в целом (например, проблемы интеграции, влияние на автоматизацию сборки ) перевешивают преимущества использования «абсолютно лучшего» языка
• , есть ли другой язык, который мы уже используем и имеем опыт, который можно использовать вместо «абсолютно лучшего» языка

. Я работал с системой примерно с дюжиной инженеры, которые использовали C ++, Java, SQL, TCL, C, сценарии оболочки и немного Perl.Я был горд тем, что мы использовали «лучший язык» там, где они имели смысл, но в одном случае использование «лучшего языка» (TCL) было ошибкой - не , потому что это был TCL, а скорее потому, что мы не смогли увидеть все соотношение затрат и выгод при выборе: *

• у нас был только 1 инженер, глубоко знакомый с TCL - первоначальный инженер, который отказался использовать что-либо, кроме TCL, для конкретного целевого компонента - а затем этот инженер покинул проект

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

• , компонент также мог быть реализован на другом языке, который мы уже использовали, который у нас был большой опыт работы с (C или C ++) с некоторыми дополнительными усилиями

• , компонент выглядел обманчиво простым, но на самом деле имел тонкие угловые случаи, которые укусили нас в производстве (не то, что мы тогда могли знать, но всегда что-то, что нужно учитывать как возможность позже)

• нам пришлось внести специальные изменения в ночная сборка, потому что компилятор TCL (да, мы скомпилировали код TCL в исполняемый файл) не будет работать, если он сначала не отобразит свой логотип на экране - экран, который был недоступен во время автоматической ночной сборки, инициированной cron. (Мы прибегли к использованию xvfb , чтобы удовлетворить его.)

• когда обнаруживались ошибки, нам было трудно найти инженеров, которые хотели бы поработать над ним

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

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

Хотя есть ряд вещей, которые мы могли бы сделать, чтобы предотвратить некоторые из проблем, с которыми мы столкнулись в будущем (например, уделить больше внимания раннему ознакомлению с TCL, запустить более качественные тесты для более раннего обнаружения проблем и т. д.) ), я считаю, что общее соотношение затрат и выгод не оправдывает использование TCL для кодирования этого единственного компонента. Опять же, было не ошибкой использовать TCL, потому что это был TCL (TCL - прекрасный язык), а, скорее, это была ошибка, потому что мы не смогли полностью учесть соотношение стоимости и стоимости. пособия .

Любой современный программный проект любого масштаба - даже если это работа одного человека - требует более одного языка. Например, веб-проекту обычно требуются Javascript, серверный язык и язык запросов к БД (хотя любой из них может быть создан на внутреннем языке). Тем не менее, есть порог, который легко достигается, и тогда будет очень сложно найти новых разработчиков, которые возьмут на себя проекты. Какой предел? Три языка? Четыре? Скажем: пять - это слишком много, но одного будет слишком мало для любого достаточно сложного проекта.

Использование правильного языка для правильной работы определенно уместно - я в основном веб-программист, и мне нужно знать программирование на стороне сервера (Rails, PHP и другие), SQL, Javascript, jQuery, HTML и CSS (не языки программирования строго, но сложные вещи, которые мне нужно знать) - для меня было бы невозможно сделать все это на одном языке или одной технологии.

Если у вас есть команда умных разработчиков, освоение новых языков не будет для них проблемой. На самом деле они, вероятно, захотят это сделать. Просто убедитесь, что у них достаточно времени (и наставничества) для изучения нового языка.

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

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

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

Я бы начал с того, что вопрос в том, используете ли вы правильную парадигму для работы?

Предположим, вы знаете, как выполнять объектно-ориентированное программирование на C #. Я не думаю, что переход на Java - это так уж здорово. Хотя вам придется познакомиться с библиотеками и синтаксисом, идея очень похожа.

Если в вашем проекте есть процедурные части, такие как синтаксический анализ файлов и различные преобразования данных, ваши макросы Perl / Excel кажутся очень похожими.

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

1) Синтаксический сахар объясняется в комментариях. Сахара довольно специфичны для языка и могут быть не очевидны для нового читателя. Например, я помню, что в VBA есть свойства по умолчанию, так что TextBox1 = "Hello" - это то, что вы должны написать вместо TextBox1.Text = "Hello". Это может сбивать с толку. Кроме того, такие вещи, как операторы LINQ, могут иметь неочевидное значение. Так что убедитесь, что у людей есть комментарии для чтения.

2) Если два компонента из разных языков должны работать вместе, сделайте мучительно конкретные детали о том, как это происходит. Например, однажды мне пришлось написать компонент C, который будет вызываться из Excel VBA. Приведу цитату из нескольких шагов и возможных ошибок, особенно в отношении флагов компилятора. Убедитесь, что обе стороны знают, как происходит их взаимодействие.

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

Я бы придерживался мнения, что если я, программист в моей команде, захочу ввести второй (или третий) язык в проект, то лучше будет ОЧЕНЬ ОЧЕНЬ веская причина для этого; как руководитель проекта я должен быть уверен, что затраты на это более чем компенсируют проблемы. И для этого потребуется немало убедительных доказательств.

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

Изменить: я не говорю об использовании javascript и C # в одном проекте, я говорю об использовании C # для большей части кода, F # для нескольких частей, а затем VB или C ++ для других - потребуется непреодолимая причина.

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

РЕДАКТИРОВАТЬ: Я не полностью против добавления языков, но бремя доказательства лежит на том, кто хочет это сделать. KISS (для меня) относится не только к тому, чтобы проект / продукт был готов и отправлен, но также должен учитывать срок службы. и требования к поддержке. Многие языки приходят и уходят, и программистов привлекают новые языки, как мотылек на свет. Большинство проектов, над которыми я работал, я все еще наблюдаю и / или поддерживаю 5 или 10 лет спустя - последнее, что я хочу видеть, это какой-то давно забытый и / или осиротевший язык, отвечающий за некоторые ключевые части приложения, которое мне нужно поддерживать.

Мой опыт использования C ++ и Lua показал, что я написал больше клея, чем фактический рабочий код, и для сомнительной выгоды.

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

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

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