Повторное использование кода и [закрытый] рефакторинг

Каждая строка кода имеет свою стоимость.

Исследования показывают, что стоимость не зависит от количества строк кода, она экспоненциальна.

Копирование / вставка программирования - самый дорогой способ повторного использования программного обеспечения.

«Требует ли повторное использование водонепроницаемых модульных тестов?»

Нет.

Весь код требует адекватных модульных тестов. Весь код подходит для повторного использования.

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

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

Есть ли лучший способ для этого? проблема; повторное использование требует водонепроницаемости юнит-тесты?

Да и вроде да. Переписывать код, который вы уже сделали правильно, никогда не бывает хорошей идеей. Если вы никогда не используете код повторно, а просто переписываете его, вы удваиваете количество ошибок. Как и многие вопросы типа передовой практики Code Complete изменили мой способ работы. Да, модульный тест в меру своих возможностей, да, повторно используйте код и получите копию Code Complete , и все будет готово.

Одним из наиболее подходящих способов использования копирования и вставки является Триангуляция . Напишите код для одного случая, посмотрите второе приложение с некоторыми вариациями, скопируйте и вставьте в новый контекст - но вы еще не закончили. Если вы остановите на этом этапе, у вас будут проблемы. Дублирование этого кода, возможно, с небольшими вариациями, открывает некоторые общие функции, необходимые вашему коду. Как только он окажется в обоих местах, протестирован и работает в обоих местах, вам следует извлечь эту общность в одно место, вызвать его из двух исходных мест и (конечно) повторно протестировать.

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

Использование копирования и вставки - почти всегда плохая идея. Как вы сказали, у вас могут быть тесты для проверки на случай, если вы что-то сломаете.

Дело в том, что когда вы вызываете метод, вы должны заботиться не о том, как он работает, а о том, что он делает. Если вы измените метод, изменив то, что он делает, тогда это должен быть новый метод, или вы должны проверить, где этот метод вызывается.

С другой стороны, если изменение не влияет на то, ЧТО делает метод (только как), тогда у вас не должно возникнуть проблем где-либо еще. Если да, значит, вы сделали что-то не так ...

Copy and pasting is never good practice. Sometimes it might seem better as a short-term fix in a pretty poor codebase, but in a well designed codebase you will have the following affording easy re-use:

• encapsulation
• well defined interfaces
• loose-coupling between objects (few dependencies)

If your codebase exhibits these properties, copy and pasting will never look like the better option. And as S Lott says, there is a huge cost to unnecessarily increasing the size of your codebase.

Вы должны писать модульные тесты, и хотя да, клонированный код может в некотором смысле дать вам ощущение безопасности, что ваше изменение не влияет на большое количество других подпрограмм, это возможно ложное чувство безопасности. По сути, ваше чувство безопасности возникает из-за незнания того, как используется код. (незнание здесь не является уничижительным, оно просто происходит из-за того, что не может знать все о кодовой базе) Привыкайте использовать свою IDE, чтобы узнать, где используется код, и привыкните читать код, чтобы знать, как он уже используется.

Существуют метрики, которые можно использовать для измерения вашего кода, и вы (или ваша команда разработчиков) должны выбрать адекватный порог. В Ruby on Rails есть Gem " Metric-Fu ", который включает в себя множество инструментов, которые могут помочь вам провести рефакторинг кода и поддерживать его в первоклассной форме.

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

Где вы пишете:

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

Я думаю, вы отменили опасения, связанные с копипастом. Если вы скопируете код в 10 мест, а затем вам нужно будет немного изменить поведение, не забудете ли вы изменить его во всех 10 местах?

Я, к сожалению, работал над большим количеством больших, небрежных кодовых баз, и, как правило, вы увидите результаты этого - 20 версий одних и тех же 4 строк кода. Некоторые (обычно небольшие) подмножества из них имеют одно незначительное изменение, некоторые другие небольшие (и лишь частично пересекающиеся подмножества) имеют некоторые другие незначительные изменения, не потому, что варианты верны, а потому, что код был скопирован и вставлен 20 раз, и изменения были применены почти , но не совсем последовательно.

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

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

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

Кроме того, копирование / вставка может показаться «ОК» в очень простых случаях, но она также запускается заставляют программистов думать, что копирование / вставка - это нормально. Это «скользкая дорожка». Программисты начинают использовать копирование / вставку, когда рефакторинг должен быть правильным подходом. Вы всегда должны быть осторожны с установкой прецедента и с тем, какие сигналы он посылает будущим разработчикам.

Есть даже цитата об этом от кого-то более опытного, чем я,

«Если вы используете копирование и вставку во время кодирования , вы, вероятно, совершаете ошибку дизайна. "
- Дэвид Парнас

В общем, копирование и вставка - плохая идея. Однако, как и из любого правила, из этого правила есть исключения. Поскольку исключения менее известны, чем правила, я выделю некоторые из них, ИМХО, некоторые из них:

1. У вас очень простой дизайн для чего-то, что вы не хотите усложнять с помощью шаблонов проектирования и прочего объектно-ориентированного проектирования. У вас есть два или три случая, которые различаются миллионом тонких способов, то есть линия здесь, линия там. По характеру проблемы вы знаете, что у вас вряд ли когда-либо будет больше 2 или 3 случаев. Иногда может быть меньшее из двух зол - просто вырезать и вставить, чем создавать чертовски сложную вещь для решения такой относительно простой проблемы, как эта. Объем кода имеет свою цену, но также и его концептуальная сложность.

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