Стоимость разработки процедурного программирования против ООП?

Question

Я пришел из довольно сильного OO-опыта, преимущества OOD & OOP для меня - вторая натура, но недавно я оказался в цехе разработки, привязанном к процедурным привычкам программирования. Язык реализации имеет некоторые функции ООП, они не используются оптимальным образом.

Обновление: у всех, похоже, есть мнение на эту тему, как и у меня, но вопрос был:

Были ли какие-либо хорошие сравнительные исследования, сравнивающие стоимость разработки программного обеспечения с использованием процедурных языков программирования по сравнению с объектно-ориентированными языками?

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

Answer 1

Большинство всех этих вопросов смущены проблемой, заключающейся в том, что производительность отдельных программистов изменяется на порядок или более; если у вас есть OO-программист, который является одним из основных в производительности x, и «процедурный» программист, который является 10-кратным программистом, процедурный программист может победить, даже если OO в некотором смысле быстрее.

Существует также проблема, заключающаяся в том, что производительность кодирования обычно составляет всего 10-20 процентов от общего объема работ в реалистичном проекте, поэтому повышение производительности не оказывает большого влияния; даже этот гипотетический 10-кратный программист или бесконечно быстрый программист не может сократить общие усилия более чем на 10-20 процентов.

Возможно, вы посмотрите на бумагу Фреда Брукса "Без серебряной пули" .

Answer 2

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

В первом параграфе говорится:

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

Я думаю, вы обнаружите, что объектно-ориентированное программирование лучше в определенных обстоятельствах, но нейтрально для всего остального. То, что продало моих боссов при преобразовании приложения CAD / CAM моей компании в объектно-ориентированную среду, это то, что я точно показал, в каких именно областях это поможет. Внимание было сосредоточено не на методологии в целом, а на том, как она поможет нам продать какую-то конкретную проблему, которая у нас была. У нас была расширяемая структура для добавления новых фигур, отчетов и контроллеров машин, а также использование коллекций для снятия ограничения памяти старого дизайна.

Answer 3

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

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

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

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

Answer 4

я думаю, что С.Лотт имел в виду феномен «неповторимого эксперимента», то есть вы не можете написать приложение X процедурно, тогда время перемотки и написать его OO, чтобы увидеть, в чем разница.

вы можете написать одно и то же приложение дважды двумя разными способами, но

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

так что на самом деле прямого основания для сравнения нет

эмпирические исследования также бесполезны, по тем же причинам - разные заявки, разные команды и т. Д.

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

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

если нет, возможно, пришло время отшлифовать резюме ...; -)

Answer 5

Хорошая идея. Личное сравнение. Напишите приложение X в процедурном стиле, в стиле OO и измерьте что-нибудь. Стоимость разработки. Возврат инвестиций.

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

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

Сказав это, вы должны сосредоточиться на вещах, которые на самом деле могут видеть другие люди.

1. Время строить то, что работает.

2. Количество ошибок и проблем.

Если ваш подход лучше, вы добьетесь успеха, и люди захотят узнать, почему.

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

Answer 6

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

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

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

Answer 7

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

В середине 90-х у моей компании был дизайн, ориентированный на события, для программного обеспечения CAM, созданного с использованием VB3. Потребовалось много времени, чтобы адаптировать программное обеспечение к новым машинам. Долгое время тестировалось влияние исправлений ошибок и новых функций.

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

Ключ должен объяснить, ПОЧЕМУ ООП принесет пользу проекту. Используйте такие вещи, как Refactoring by Fowler и Design Patterns, чтобы показать, как новый дизайн сократит время на выполнение работы. Также укажите, как добраться из пункта А в пункт Б. Рефакторинг поможет показать, как вы можете работать с промежуточными этапами, которые можно отправить.

Answer 8

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

Мне интересно, так как моя компания начинает изучать инициативу ROWE . На нашей первой сессии было очевидно, что в настоящее время мы не собираем достаточно метрик по результатам.

Итак, вам необходимо сосредоточиться на том, 1) Влияет ли поддержка текущих процессов на дальнейшее развитие? 2) Как разные методы повлияют на # 1?

Answer 9

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

Я также сделаю еще одно замечание: в реальном мире не существует понятия чисто объектно-ориентированного или чисто процедурного. Многие, если не большинство объектных методов написаны с процедурным кодом. В то же время многие процедурные программы используют ОО-методологии, такие как инкапсуляция (некоторые также вызывают абстракцию).

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