Как сделать код многоразовым?

Question

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

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

Answer 1

См. 10 советов по написанию кода многократного использования для получения справки.

1. Держите код СУХОЙ. «Сухой» означает «Не повторяйся сам».
2. Заставить класс / метод сделать только одну вещь.
3. Напишите модульные тесты для своих классов И упростите тестирование классов.
4. Удалите бизнес-логику или основной код из любого кода платформы
5. Попытайтесь мыслить более абстрактно и используйте интерфейсы и абстрактные классы.
6. Код для расширения. Напишите код, который может быть легко расширен в будущем.
7. Не пишите код, который не нужен.
8. Попробуйте уменьшить сцепление.
9. Будь более модульным
10. Пишите код как ваш код внешнего API

Answer 2

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

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

Answer 3

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

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

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

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

Я предлагаю ознакомиться с лучшими практиками для выбранного вами языка / парадигмы программирования (например, Шаблоны и SOLID для типов Java / C #), литературой по Lean / Agile и, конечно же, книгой «Завершить код». Понимание преимуществ и недостатков этих подходов улучшит вашу практику кодирования без конца. Тогда весь ваш код станет пригодным для повторного использования - но «случайно», а не по замыслу.

Также см. Здесь: Написание обслуживаемого кода

Answer 4

Для большинства определений «повторного использования» повторное использование кода является мифом, по крайней мере, по моему опыту. Можете ли вы сказать, что у меня есть некоторые шрамы от этого? :-)

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

Я думаю, что первым шагом является установление мышления, что для создания повторно используемого компонента потребуется как минимум 3 итерации. Почему 3? Поскольку при первой попытке повторного использования компонента вы всегда обнаруживаете что-то, с чем он не может справиться. Итак, вы должны изменить это. Это происходит пару раз, пока, наконец, у вас не появится компонент, который, по крайней мере, можно использовать повторно.

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

Answer 5

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

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

1. Скопируйте и исправьте. Теперь вам нужно почти одинаковые пакеты - дорогая ошибка.

2. Сделать оригинальную упаковку многоразовой в двух ситуациях.

Просто сделайте это для повторного использования. Ничего более. Слишком много размышлений о «потенциальном» повторном использовании и неопределенных «других ситуациях» может стать пустой тратой времени.

Answer 6

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

Итак, вы должны определить модули, которые можно использовать повторно, для этого

1. Определите основные компетенции каждого модуля. Например, если ваш проект должен сжимать файлы, у вас будет модуль, который будет обрабатывать сжатие файлов. НЕ заставьте его сделать больше, чем ОДНА ВЕЩЬ . Только одно.

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

3. Вам не нужно доводить ее до совершенства в первый раз, когда вы на самом деле повторно используете библиотеку, вы, вероятно, обнаружите недостатки в дизайне (например, вы не сделали ее достаточно модульной, чтобы иметь возможность легко добавлять новые форматы сжатия), и вы можете исправить их во второй раз и улучшить возможность повторного использования вашего модуля. Чем больше вы используете его (и исправляете недостатки), тем легче будет его повторно использовать.

Самая важная вещь, которую следует учитывать, это разделение, если вы пишете тесно связанный код, многократное использование - первая жертва.

Оставьте все необходимое состояние или контекст вне библиотеки. Добавьте методы для указания состояния в библиотеке.

Answer 7

Другие упоминали эту тактику, но здесь они формально. Эти три уведут вас очень далеко:

• Соблюдать Единую ответственность Принцип - он гарантирует, что ваш класс только «делает одну вещь», а это означает, что более вероятно, что он будет многократно использоваться для другого приложения, включающего ту же самую вещь.
• Придерживаюсь Лисков Принцип подстановки - он гарантирует, что ваш код «делает то, что предполагается, без сюрпризов», а это означает, что более вероятно, что он будет многократно использоваться для другого приложения, которому нужно сделать то же самое.
• Придерживайтесь принципа Open / Closed - он гарантирует, что ваш код может работать иначе, без изменения его источника, что означает, что он с большей вероятностью может использоваться повторно без прямой модификации.

Answer 8

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

Answer 9

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

Один из способов помочь модульному коду - использовать инкапсуляцию, см. Теорию инкапсуляции здесь: http://www.edmundkirwan.com/

Ed.

Answer 10

Я бы добавил концепцию «Композиция классов поверх наследования классов» (которая получена из других ответов здесь). Таким образом, «составленный» объект не заботится о внутренней структуре объекта, от которой он зависит, - только о его поведении, что приводит к лучшей инкапсуляции и упрощению сопровождения (тестирование, меньше деталей для обработки). В таких языках, как C # и Java, это часто имеет решающее значение, так как нет множественного наследования, поэтому это помогает избежать того, что может иметь граф наследования.