Парадигми програмування та розробник технічного обслуговування [закрито]

9

Наразі це запитання не підходить для нашого формату запитань. Ми очікуємо, що відповіді будуть підкріплені фактами, посиланнями або експертними знаннями, але це питання, ймовірно, вимагатиме дискусій, аргументів, опитувань чи розширеної дискусії. Якщо ви вважаєте, що це питання можна вдосконалити та, можливо, знову відкрити, відвідайте довідковий центр для ознайомлення .

Закрито 8 років тому .

Я читав "Факти та хибності інженерії програмного забезпечення", де є розділ технічного обслуговування. Оскільки я вже кілька років займаюся розробником технічного обслуговування, мені були представлені дуже цікаві факти. Ось три.

Факт 41: На технічне обслуговування зазвичай витрачається від 40 до 80 відсотків (в середньому, 60 відсотків) витрат на програмне забезпечення. Тому це, мабуть, найважливіший етап життєвого циклу програмного забезпечення.
Факт 42: Покращення несе відповідальність за приблизно 60 відсотків витрат на обслуговування програмного забезпечення. Виправлення помилок становить приблизно 17 відсотків. Тому технічне обслуговування програмного забезпечення значною мірою полягає у додаванні нових можливостей до старого програмного забезпечення, а не до його виправлення.
Факт 45: Вдосконалення розробки програмного забезпечення призводить до більшого обслуговування, а не менше.

Цей був контрінтуїтивним, виявляється, що хороше програмне забезпечення має більше обслуговування, тому що це легко змінити. Отже, він залишається у використанні довше, що призводить до, так, більше змін.

Яка парадигма (як функціональна, об'єктно-орієнтована, процедурна) має найкращу ремонтопридатність, і чи є дослідження, які підтверджують це?

maintenance maintainability

— KaizenSoze
джерело

Я маю копію фактів і помилок, і для кожного факту (і помилок) є цитати для різних публікацій, які це підтверджують. Я не маю під рукою копії, але чи будь-яка з цих цитат обговорює вплив парадигми на технічне обслуговування?

— Томас Оуенс

Книга була написана в 2003 році, значна частина висновків залишається актуальною і сьогодні. Мені було цікаво, якби люди мали якісь нові дослідження з певних парадигм. Технічне обслуговування видається занедбаною частиною дискусії.

— KaizenSoze

Якщо будь-яке з досліджень чи публікацій, цитованих у «Фактах і помилках», стосується ремонтопридатності певної парадигми, одним із варіантів було б пошук у базі даних IEEE або ACM за іншими статтями та документами, які цитують цей документ. Якщо у вас немає доступу до баз даних IEEE або ACM, я можу переглянути свою копію книги, коли повернусь додому, і побачу, чи можу я здійснити такий пошук. На жаль, я зможу отримати вам лише назви інших паперів, а не самих паперів.

— Томас Оуенс

12

Я думаю, ви побачите, що такі парадигми, як функціональна, OO та процедурна, ймовірно, не суттєво співпадають з ремонтом програмного забезпечення.

Що ви можете знайти наступні співвіднесення набагато чіткіше з ремонтом програмного забезпечення:

Рівень збору вимог та проектування вимог
Хороші практики розробки: (сильне зчеплення, висока згуртованість, тестування блоку, YAGNI ...)
Кваліфіковані та кваліфіковані інженери програмного забезпечення (вони варті в 10 разів більше, ніж дебіл)
Кваліфікований та організований технічний колектив із забезпечення якості
Гарне управління проектами під керівництвом компетентних керівників проектів (Ще важче знайти, ніж кваліфіковані розробники програмного забезпечення IMHO)
Хороші Власники продуктів чи менеджери додатків, міцне лідерство, хороший довгостроковий напрямок, хороші відгуки командам проектів, загальне бачення.

— кленовий вал
джерело

+1 Я хочу додати гарну документацію до списку

— treecoder

+1 Додати процес до списку "Орієнтований на значення". Процес визначає та визначає те, що зроблено, а що не зроблено. Те, що процес вимірює, є важливим, а що не вимірює - неважливо. Особливо вірно, коли хлопці з персоналу починають заповнювати місця "дебілами".

— mattnz

2

Цей був контрінтуїтивним, виявляється, що хороше програмне забезпечення має більше обслуговування, тому що це легко змінити. Отже, він залишається у використанні довше, що призводить до, так, більше змін.

Ви, здається, переглядаєте це на суму обслуговування, а не на відсоток витрат. Гарне програмне забезпечення, яке має більше функцій, - це лише більша кількість програмного забезпечення. Якщо відсоток технічного обслуговування буде фіксованим (оскільки це було гарне програмне забезпечення і ми припускаємо, що додаткові функції були додані як хороше програмне забезпечення), сума збільшиться. Це просто більший шматок пирога з такою ж кількістю скибочок.

Виходячи з того, що ви запитуєте, важливо, чи було написано "хороше" програмне забезпечення: функціональний, OOP чи процедурний код. Чи дасть кому-небудь лазерна керована електропилка заощадити на деревині, якщо людина не вміє вимірювати?

— JeffO
джерело