Правильный язык для работы - PullRequest
9 голосов
/ 05 мая 2010

Ключом является использование правильного языка для работы - это комментарий, который я прочитал в SO, и я также верю, что это правильно. Из-за этого мы в конечном итоге использовали разные языки для разных частей проекта - например, Perl, VBA (Excel Macros), C # и т. Д. В настоящее время в проекте используется от трех до четырех языков. Использование правильного языка для работы значительно упростило автоматизацию работы, но в последнее время люди жалуются, что любому новому человеку, который должен взять на себя управление проектом, придется выучить так много разных языков, чтобы начать. Также трудно найти такого человека. Обратите внимание, что это один-два человека, работающие над максимумом проекта в данный момент времени. Я хотел бы знать, правильный ли метод, которым мы следуем, или мы должны сойтись на одном языке и попытаться использовать его во всей работе, даже если для этого лучше подойдет другой язык. Ваш опыт, связанный с этим, также поможет.

Используемые языки и их назначение:

  1. Perl - Обработка большого текстового файла (файлы журналов)
  2. C # с Silverlight для веб-отчетов.
  3. LabVIEW для автоматизации
  4. Макросы Excel для обработки данных в таблицах Excel, создания графиков и экспорта в powerpoint.

Ответы [ 8 ]

14 голосов
/ 05 мая 2010

Я бы сказал, что вы все делаете правильно. Почти все проекты, над которыми я когда-либо работал, использовали несколько языков без каких-либо проблем. Я думаю, вы, возможно, переоцениваете трудности, с которыми сталкиваются люди при освоении новых языков, особенно если они все используют одну и ту же парадигму. Если ваш проект использует Haskell, Smalltalk, C ++ и ассемблер, у вас могут возникнуть трудности, я должен признать: -)

13 голосов
/ 05 мая 2010

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

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

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

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

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

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

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

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

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

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

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

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

4 голосов
/ 05 мая 2010

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

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

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

3 голосов
/ 05 мая 2010

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

1 голос
/ 05 мая 2010

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

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

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

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

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

1 голос
/ 05 мая 2010

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

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

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

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

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

0 голосов
/ 05 мая 2010

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

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

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

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

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

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

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

0 голосов
/ 05 мая 2010

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

...