Если вам нужны одинаковые функции в двух проектах, вы должны повторно использовать код между ними, верно? Или ты должен? До тех пор, пока существует профессия разработчика программного обеспечения, мы старались добиться большего повторного использования. Но повторное использование имеет и выгоду и стоимость. Слишком часто стоимость забывается. В этой статье я рассматриваю экономику повторного использования.
Правдивая история. Один из первых проектов, посвященных объектно-ориентированному программированию в 1990-х годах, был реализован с целью максимального повторного использования. Команда, ответственная за создание общей структуры компании, использовала следующую формулу для расчета стоимости своей работы:
|
1
|
[Value of reuse] = [numbers of uses of framework] * [value of the framework to reusers] – [cost of developing the framework] |
Эта формула, очевидно, правильна, но именно здесь они пошли ужасно неправильно: организация сказала
|
1
|
[value of framework to reusers] = [cost of developing framework] |
Другими словами: чем дороже его создавать, тем ценнее его использовать.
Мы явно продвинулись дальше этого мышления. Более обновленная формула сказала бы:
|
1
|
[value of framework to reusers] = [cost of developing the feature in question] |
Но даже это слишком оптимистично.
Ни одна библиотека не предоставляется бесплатно для своих пользователей. По крайней мере, вы должны открыть для себя функции и узнать о деталях. Стоимость повторного использования зависит от многих факторов, таких как качество структуры и документации, а также от типа функции. Сложный алгоритм с простым интерфейсом дешев в использовании, в то время как большинство доменных структур требует много работы для повторного использования. Мы можем выразить это как фактор повторного использования, вероятно, между 90% и 50%. В большинстве случаев мое предположение было бы около 75%.
Итак, мы имеем:
|
1
|
[value of reuse] = [number of users] * ([cost of feature] * [reuse value factor]) – [cost of developing the reusable component] |
А как насчет другого важного фактора: [стоимость разработки повторно используемого компонента] ?
Легко предположить, что стоимость разработки функции в платформе равна стоимости разработки функции в приложении, но дальнейший анализ показывает, что это далеко не так. Повторно используемому компоненту требуется больше документации, он должен обрабатывать больше особых случаев и имеет более медленный цикл обратной связи. Эта стоимость на самом деле значительна и может означать, что разработка функции для повторного использования стоит от 150% до 300% или более . Лично я считаю, что коэффициент затрат на повторное использование составляет около 300%. И чем ниже это число, тем выше, вероятно, будет коэффициент затрат на повторное использование, поскольку это может означать, что мы экономим на документации и т. Д.
Пересмотренное число будет:
|
1
|
[value of reuse] = [number of users] * ([cost of feature] * [reuse value factor]) – [reusability cost factor] * [cost of feature] |
Или же
|
1
|
[value of reuse] = [cost of feature] * ([number of users] * [reuse value factor] – [reusability cost factor]) |
Более сложная формула позволяет нам сделать несколько прогнозов. Допустим, мы предполагаем, что значение коэффициента повторного использования составляет 75% (это означает, что для повторного использования библиотеки требуется не более 1/4 усилия, а не создания элемента с нуля), а коэффициент стоимости повторного использования составляет 300% (это означает, что для этого требуется три раза усилия, чтобы создать то, что стоит использовать повторно). Это означает:
|
1
|
[value of reuse] = [cost of feature] * ([number of users] * 75% – 300%) |
Это уравнение нарушается даже тогда, когда [количество пользователей] = 4. Это означает, что для получения какого-либо значения от повторно используемого компонента вам лучше иметь пять или более повторных пользователей или вам нужно найти способ существенно улучшить [коэффициент повторного использования значения] или [ коэффициент многократного использования. Очень умные люди не смогли этого сделать.
Улучшение стоимости:
- Увеличьте число повторных пользователей: достаточно просто, но когда вы это делаете, вы рискуете, что [коэффициент повторного использования стоимости] упадет, так как среда не подходит всем одинаково хорошо.
- Сократите затраты на повторное использование библиотеки: это означает, что вы инвестируете в документацию, улучшаете свой дизайн, улучшаете тестирование, чтобы сократить количество ошибок, быстрее обрабатывать отчеты об ошибках и запросы функций от повторных пользователей — все это увеличивает ваш коэффициент стоимости повторного использования.
- Сократите лишнюю работу, чтобы сделать библиотеку многократно используемой: Самый важный способ снизить стоимость разработки для повторного использования — это выбрать правильный тип проблемы для решения. Проблемы с небольшой поверхностью и большим объемом лучше. Это означает: легко описать, сложно реализовать. К сожалению, большинство сочных фруктов было собрано несколько лет назад стандартной библиотекой на вашем языке программирования и средами с открытым исходным кодом.
В глобальном масштабе, повторное использование спасло индустрию программного обеспечения огромные суммы. В организации может быть трудно получить тот же эффект. Повторное использование платно как для пользователя, так и для разработчика библиотеки многократного использования. Как вы оцениваете и улучшаете свой [коэффициент повторного использования стоимости] и [коэффициент повторного использования стоимости]?
| Ссылка: | Экономика повторного использования от нашего партнера JCG Йоханнеса Бродуолла в блоге Thinking Inside a Bigger Box . |