Как бороться с философией повторного использования кода?

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

В какой степени я должен сделать мой код многоразовым?
Должен ли я ограничить его областью применения или сделать его многоразовым за пределами проекта?

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

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

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

Вспомни ПОЦЕЛУЙ и ЯГНИ:

Кодируйте, re-usability better to be consideredкогда у вас есть готовый проектный документ . Это позволит вам увидеть раздел / части кода, которые потенциально могут быть продублированы.

Таким образом, когда у вас нет четкого дизайна, тогда применяйте подход KISS и YAGNI в своей работе!

Это из моего опыта, но я все еще верю, что оно может быть применено и идет в соответствии с тем, что упоминал GlenH7 .

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

1. Самый быстрый метод
   Скопируйте предыдущий код из другого проекта (не так много времени) в мой текущий проект.

2. Метод Second-Fastest
   Скопируйте предыдущий код и поместите его в общую библиотеку, затем включите эту библиотеку в текущий проект (чтобы облегчить продвижение вперед).

   2b. Если я внесу изменения в другой (оригинальный) проект, я реорганизую его для использования новой библиотеки [но, как правило, этого не произойдет, если мне не придется повторно касаться этого проекта].

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

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

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

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