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

Question

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

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

Answer 1

См. 10 tips on writing reusable code за помощью.

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

Answer 2

Если взять Test-Driven подхода развития, то ваш код только становится многоразовым, как ваш рефакторинг на основе предстоящих сценариев.

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

Answer 3

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

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

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

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

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

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

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

Answer 4

Чтобы добавить к вышеупомянутым пунктам, я бы сказал:

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

Answer 5

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

Answer 6

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

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

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

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

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

Также смотрите здесь: Writing Maintainable Code

Answer 7

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

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

Ed.

Answer 8

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

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

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

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

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

Answer 9

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

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

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

Отличный способ, чтобы сделать код для повторного использования будет использовать Bit:

https://github.com/teambit/bit

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

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

Это позволяет нам легко извлекать компоненты кода (UI, backend ...) из нашего кода и использовать их в любом месте по всем проектам и приложениям. Они также просты в обслуживании и хорошо организованы, так как бит обеспечивает двухсторонние изменения кода из любых проектов.

Не стесняйтесь взглянуть и попробуйте, Надеюсь, вам понравится.

Answer 14

еще 2 вещи, чтобы рассмотреть следующие вопросы:

1. Модульность - здесь большой пост по Addi Osmani.

2. Инструментарий - мы используем Bit для организации и обмена многоразовым кодом.

Goodluck!