Исследования относительных затрат на развитие на разных языках

Question

Кто-нибудь видел недавнее (и достаточно сбалансированное) исследование относительной стоимости разработки программного обеспечения с использованием разных языков? Особенно хотелось бы увидеть относительную стоимость Java Vs. C # Vs. Delphi.

Answer 1

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

Общее:

Все они лучшие в своих областях:

• Java - лучший вариант разработки Java.
• C # - лучший вариант разработки для .NET.
• Delphi - лучший вариант разработки для Native.

Все они имеют:

• Сторонние поставщики по всему миру, предоставляющие качественные компоненты и библиотеки.
• Всемирно известные приложения, созданные с их помощью (например, Delphi, могут быть более известны: Yahoo Go for TV !, Macromedia Captivate, TotalCommander, MediaMonkey, FinalBuilder, InstallAware, WinLicense, MySQL Administrator и т. Д.).

Все они:

• Высоконадежные технологии с возможностями RAD.
• Поддерживается лучшими инструментами помощи в разработке (UML и т. Д.).
• Выпуск основных обновлений в своих технологиях (Java 7, .NET 4.0 и мультиплатформа Delphi).

Отличия:

3 вещи, в которых C # лучше:

• Количество доступных разработчиков (по сравнению с Java), которые могут кодировать в нем (*).
• Имеет Microsoft позади.
• Удешевление затрат на разработку с точки зрения заработной платы (обычно).

3 Что лучше для Java:

• Количество доступных разработчиков (по сравнению с Delphi), которые могут кодировать в нем (*).
• Портативность.
• Солнце позади.

3 вещи, в которых Delphi лучше:

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

---

(*) существует очень надежный факт, что существует больше разработчиков на других языках, которые могут кодировать на C #, чем разработчики на других языках, которые могут кодировать на Java, что означает, что легче найти программистов на C #. Возможно, это объясняет, почему на многих веб-сайтах (таких как этот) и форумах, на которых разрешены многоязычные вопросы, рефакторинг и т. Д., Обычно используется больше вопросов и ответов по C # ( 84k против 50k ). Кроме того, поскольку задания Java лучше всего оплачиваются во многих частях мира, здравый смысл указывает на то, что разработчики Java остаются дольше на своих заданиях, чем на C #, что затрудняет поиск доступных разработчиков Java, чем на C #. И, конечно, есть некоторые другие факторы, которые можно обсудить, но я уверен, что обычно найти программиста на C # легче, чем программиста на Java.

Answer 2

Я не знаю о формальных исследованиях, но я слышал множество анекдотичных отчетов о компаниях, которые по какой-то причине переписывали его на C # и переписывали его на C #. Все они заканчиваются примерно одинаково.

Переписывание программы на C # заняло вдвое больше времени, чем на первоначальное написание ее на Delphi, даже при том, что вся бизнес-логика и знание предметной области уже проработаны и представлены в виде существующей базы кода Delphi. В течение этого времени они не выпускали обновления, потому что все их ресурсы были заняты переписыванием, что позволило их конкурентам завоевать долю рынка. И когда это было сделано, это был продукт уровня 1.0. Глючный, медленный и сложный в использовании, часто с серьезными проблемами обратной совместимости.

Причиной, по которой открыта интерпретация, но я думаю, что одним из основных факторов, делающих Delphi гораздо более продуктивным, чем C # (или Java), является внешний вид и восприятие языка.

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

Это не формальное исследование, но о нем стоит подумать.

Answer 3

Количественные сравнения такого рода было бы очень трудно определить из-за количества усложняющих переменных: опыт разработчиков в отношении языка, соответствие языка целевому домену, общее качество разработчиков (утверждается, что не основные языки привлекают разработчиков более высокого качества), компромиссы с конечным продуктом (приложение Ruby или Python так же быстро, как хорошо написанное приложение Delphi или C ++?) и т. д.

В Code Complete, 2nd Ed. , Стив МакКоннелл перечисляет несколько языков с точки зрения их выразительной силы (сколько строк эквивалентного кода C может быть выражено в одном выражении каждый язык). Предполагается, что производительность программистов в строках кода относительно постоянна независимо от языка; если это правда, то выразительная сила каждого языка должна дать приблизительную оценку относительной стоимости разработки на каждом языке. Из таблицы 4.1, стр. 62:

LANGUAGE       LEVEL RELATIVE TO C
C              1
C++            2.5
Fortran 95     2
Java           2.5
Perl           6
Python         6
Smalltalk      6
Visual Basic   4.5

Он перечисляет несколько источников для этой таблицы: Оценка стоимости программного обеспечения , Оценка стоимости программного обеспечения с Cocomo II и "Эмпирический "Сравнение семи языков программирования" (Пречелт, IEEE Computer , октябрь 2000 г.).

Цифрам, которые приводит Макконнелл, всего несколько лет, но, насколько я понимаю, модель Cocomo II до смешного детальна, поэтому текущий материал Cocomo II может предлагать текущие числа на Delphi и C #.

Answer 4

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

Чтобы сделать это правильно:

• Вам необходимо указать ряд нетривиальных проектов в разных областях применения.

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

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

Так что вам потребуется усилие разработчика, эквивалентное project-size * nos-languages * nos-projects * nos-repetitions. Если предположить, что нетривиальный проект занимает 1 человеко-год, то есть 5 проектов, и они разрабатываются 5 раз на каждом языке (чтобы дать нам достаточно большой размер выборки, чтобы иметь статистическую значимость), то есть 25 лет опытного разработчика. ... скажем, от 2 до 5 миллионов долларов США ... НА ИЗУЧЕННЫЙ ЯЗЫК.

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

И даже тогда результаты исследования не будут касаться:

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

И результаты будут устаревшими через 3 - 5 лет.

Answer 5

ВВС США проявили интерес и обнаружили, что Delphi значительно ускоряет кодирование. Соревнование C ++ каждый год привлекает к участию команды, занимающиеся быстрым кодированием. Delphi-кодеры скрывают это соревнование и почти всегда приходят значительно быстрее с требуемым кодом.

После своей карьеры в качестве главы отдела разработки ВВС мой бывший начальник Билл Ретцхайм написал книгу об оценке затрат на разработку программного обеспечения. Его выбор, на голову выше всех остальных, был Дельфи. Это была версия 3/4. Рационал использовал свою схему оценки. Я до сих пор пользуюсь им, и за все те годы, что я делал, ничего лучшего не было.

Ясность дизайна и сила выражения в коде не сильно меняются в зависимости от версии. Большую часть времени вы смотрите на визуальные изменения и постепенное увеличение. Основные лучшие практики 20 лет тому назад все еще применяются. Это то, что делает архитектуру возможной. Мы знаем, как выглядят лучшие практики, потому что в определенном масштабе код должен соответствовать определенному набору стандартных требований, которые не сильно различаются. Вы почти всегда можете сделать его более приятным в использовании или иметь меньше глупых неловких интерфейсов, но системы данных, безопасности / фильтрации и рабочих процессов, которые заставляют бизнес-системы работать, по-прежнему используют те же шаблоны проектирования, что и в книге «Шаблоны проектирования GoF». И если маленькие устройства научили нас чему-то, то это высокая ясность и простота заслуживают похвалы. Очень важно, насколько просто использовать вашу кодовую базу для этой цели. Во всех основных средах проектирование доменов может быть достаточно хорошим. Скорость работы системы и простота разработки делают Delphi и Node.js моими двумя предпочтениями. Но с возможностями C # и Java все в порядке. Если бы я беспокоился о безопасности среды от разработчиков, в некоторых ситуациях я бы использовал C #, потому что кодерам сложнее нарушать правила. Но когда мне не нужны эти правила, то есть большую часть времени, я предпочитаю более открытую среду, которая масштабируется. Когда я не особо беспокоюсь о безопасности, я могу предпочесть Node.js, потому что он делает это в спешке. Большую часть времени я нахожу, что слишком легко совершать ошибки в Node, и в конечном итоге мне нужно полное покрытие тестового кода. Delphi - мой первый выбор на балансе.

Answer 6

Peopleware (от Тома Демарко и Тимоти Листера) содержит раздел в восьмой главе, посвященный "Кодовым военным играм" С 1984 по 1986 год более 600 разработчиков приняли участие.

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

Answer 7

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

--- разглагольствования о «сравнительных исследованиях» о компетенции программиста завершены ---

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

А стоимость разработки обычно составляет лишь часть совокупной стоимости владения системы, особенно если это что-то вроде многоуровневого приложения, работающего на серверах приложений с базами данных и т. Д. Если у клиента уже есть серверная ферма, на которой запущен IIS с базами данных MS SQL Server в качестве бэкэнда, продажа ему приложения Java EE с использованием бэкэнда Oracle оказывает им плохую услугу, даже если в противном случае это было бы наиболее логичным выбором для приложения. Стоимость разработки может быть ниже, но эксплуатационные расходы для клиента будут намного выше.

С другой стороны, веб-сайт вашего углового продуктового магазина, который хочет начать принимать заказы через сеть для доставки по соседству, не должен быть реализован ни в .NET, ни в Java EE. Стоимость решения (особенно хостинга) намного перевесит преимущества. Простая вещь, основанная, например, на php или rails, намного лучше послужит этому клиенту. Снижается стоимость хостинга, не нужно платить дорогостоящие лицензионные сборы за серверы баз данных и приложений, он может на самом деле заработать немного денег, используя получившийся веб-сайт.

Answer 8

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

Если посмотреть на вещи в перспективе, если вы столкнулись с серьезным недостатком языка и вынуждены применить обходной путь - вы теряете несколько часов. Поддерживающий человек может потратить еще несколько часов, чтобы понять, что и почему вы там сделали. Рабочий день или два будут потеряны. Что ж, если вы пришли на работу не в том настроении, вы проиграли в тот же день. Если у вас есть проблемы с пониманием требований или общением с коллегами и руководством, вы легко теряете недели и месяцы.