Парадигмы программирования и сопровождение разработчика [закрыто]

9

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

Закрыто 8 лет назад .

Я читал «Факты и ошибки разработки программного обеспечения», в котором есть раздел технического обслуживания. Поскольку я работаю разработчиком технического обслуживания уже много лет, мне были представлены очень интересные факты. Вот три.

Факт 41: обслуживание обычно потребляет от 40 до 80 процентов (в среднем 60 процентов) затрат на программное обеспечение. Следовательно, это, вероятно, самая важная фаза жизненного цикла программного обеспечения.
Факт 42: На расширение приходится примерно 60 процентов затрат на обслуживание программного обеспечения. Исправление ошибок составляет примерно 17 процентов. Поэтому обслуживание программного обеспечения в основном заключается в добавлении новых возможностей к старому программному обеспечению, а не в его исправлении.
Факт 45: Лучшая разработка программного обеспечения приводит к большему количеству обслуживания, а не меньше.

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

Какая парадигма (например, функциональная, объектно-ориентированная, процедурная) обладает наилучшей ремонтопригодностью, и есть ли какие-либо исследования, подтверждающие это?

maintenance maintainability

— KaizenSoze
источник

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

— Томас Оуэнс

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

— KaizenSoze

Если какое-либо из исследований или публикаций, цитируемых в разделе «Факты и заблуждения», касается ремонтопригодности конкретной парадигмы, одним из вариантов будет поиск в базах данных IEEE или ACM других статей и статей, в которых цитируется этот документ. Если у вас нет доступа к базам данных IEEE или ACM, я могу посмотреть на свою копию книги, когда вернусь домой, и посмотреть, смогу ли я выполнить такой поиск. К сожалению, я смогу получить только имена других газет, а не самих газет.

— Томас Оуэнс

12

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

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

Уровень сбора требований и разработка требований
Хорошие практики разработки: (слабая связь, высокая когезия, модульное тестирование, YAGNI ...)
Квалифицированные и квалифицированные инженеры-программисты (стоят в 10 раз больше, чем придурки)
Квалифицированная и организованная команда технического обеспечения
Хорошее управление проектами во главе с компетентными менеджерами проектов (даже труднее найти, чем опытные разработчики программного обеспечения ИМХО)
Хорошие Владельцы Продукта или менеджеры приложений, сильное лидерство, хорошее долгосрочное руководство, хорошая обратная связь с проектными командами, общее видение.

— maple_shaft
источник

+1 Я хочу добавить хорошую документацию в список

— древовидный код

+1 Добавьте процесс «Ориентация на ценность» в список. Процесс определяет и определяет, что сделано, а что нет. Важно то, что измеряет процесс, а что не измеряет процесс. Особенно актуально, когда ребята из HR начинают заполнять места "дебилами".

— Mattnz

2

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

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

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

— JeffO
источник