Двойная функциональность среди нескольких проектов

Question

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

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

Какие-нибудь предложения от людей, которые могли бы иметь дело с подобной ситуацией?

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

Answer 1

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

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

Answer 2

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

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

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