Чи існує кореляція між складністю коду та продуктивністю розробника?

10

Чи варто витрачений час на рефакторинг кодової бази в перспективі з точки зору продуктивності розробника?

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

productivity complexity

— Бенні Халлетт
джерело

Дивіться РЕКОНСТРУКЦІЯ

— hakre

1

Почніть вести безлад і будьте суддею.

— Tulains Córdova

16

Емпірично програмне забезпечення з більш високими показниками складності, наприклад, цикломатична складність, важче підтримувати. Існують дослідження, що підтримують це, починаючи з 1970-х років ("Складність програми та продуктивність програміста", Е. Ч.) . Існує також робота, яка дозволяє припустити, що щільність складності, яка є цикломатичною складністю щодо розміру системи, також стосується часу обслуговування ("щільність цикломатичної складності та продуктивності обслуговування програмного забезпечення", GK Gill, CF Kemerer) , яка також доступна тут безкоштовно . На жаль, підписка на IEEE необхідна на папері Чена, але ви можете спробувати знайти її в інших джерелах, якщо вам це цікаво.

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

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

— Томас Оуенс
джерело

2

Ще один момент, який потрібно додати, - це те, що ви, рефактор, також реалізовуєте функції краще / ефективніше / чистіше. Є приказка, яку я неодноразово чув, що "через 5 років ти будеш тискувати, що ти вважаєш, що ваш код" хороший "

— warren

1

@hakre Я перевірив, коли я опублікував це і знову зараз, використовуючи пошук в Інтернеті Google і Google Scholar. У той час, коли я спочатку писав цю публікацію, жоден папір не був доступний без покупки. Однак з тих пір одна доповідь була розміщена на домені Університету Піттсбурга, яка, схоже, належить одному з авторів, і я додав посилання на неї. Інший папір не доступний безкоштовно. Я додав заголовки до основної публікації, щоб полегшити пошук їх. Якщо ви не хочете читати статті, вам потрібно прийняти мій аналіз у поєднанні з моїми знаннями та досвідом.

— Томас Оуенс

0

Я за деякими твердими доказами

Тоді перестаньте витрачати свій час тут.

Знайдіть код, який дорого підтримувати. Це легко. Подивіться на проблематичні квитки вашої організації.
Знайдіть код, який дешево підтримувати. Знайдіть код, який працює часто, але в ньому є мало або без проблемних квитків.
Виміряйте складність будь-яким із широко доступних інструментів складності.
Баскет в доказах.

Тепер ви надали номери, щоб підтвердити очевидне.

— С.Лотт
джерело

5

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

— reinierpost

4

-1 не відповідь

— Дейв Хіллер