Есть ли связь между сложностью кода и производительностью разработчика?

10

Стоит ли тратить время на рефакторинг кодовой базы в долгосрочной перспективе с точки зрения продуктивности разработчиков?

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

productivity complexity Бенни Халлетт
источник
Смотрите РЕКОНСТРУКЦИЯ
Хакре
1
Начни поддерживать беспорядок самостоятельно и будь судьей.
Тулаинс Кордова

Ответы:

16

Опытным путем сложнее поддерживать программное обеспечение с более высокими показателями сложности, такими как цикломатическая сложность. Существуют исследования, подтверждающие это, начиная с 1970-х годов («Сложность программ и продуктивность программистов», ET Chen) . Также есть работа, которая предполагает, что плотность сложности, которая является цикломатической сложностью по сравнению с размером системы, также связана со временем обслуживания («Плотность цикломатической сложности и производительность обслуживания программного обеспечения», GK Gill, CF Kemerer) , которое также доступно здесь бесплатно . К сожалению, подписка IEEE необходима для статьи Чена, но вы можете попробовать поискать ее в других источниках, если вам интересно.

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

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

Томас Оуэнс
источник
2
Еще один момент, который нужно добавить, это то, что при рефакторинге вы, вероятно, также реализуете функции более качественно, эффективно и чисто. Есть поговорка, которую я слышал бесчисленное количество раз, когда говорилось, что «через 5 лет вы поразитесь, что считаете, что ваш код был« хорошим »»
Уорр
1
@hakre Я проверял, когда отправлял это, и теперь снова, используя и веб-поиск Google, и Google Scholar. В то время, когда я изначально писал этот пост, ни одна бумага не была доступна без покупки. Однако с тех пор одна статья была опубликована в домене Питтсбургского университета, который, по-видимому, принадлежит одному из авторов, и я добавил ссылку на него. Другой документ не доступен бесплатно. Я добавил заголовки в основной текст поста, чтобы облегчить их поиск. Если вы не хотите читать статьи, вам нужно принять мой анализ в сочетании с моими знаниями и опытом.
Томас Оуэнс
0

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

Тогда перестань тратить свое время здесь.

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

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

  3. Измерьте сложность с помощью любого из широко доступных инструментов сложности.

  4. Греться в доказательствах.

Вы предоставили цифры для подтверждения очевидного.

С. Лотт
источник
5
На самом деле, нет. сложность задачи, выполняемой программным обеспечением, следует отличать от дополнительной сложности, вызванной выбранной реализацией.
reinierpost
4
-1 не ответ
Дейв Хиллиер