Когда предпочитать обобщенное решение решению конкретных случаев


18

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

XKCD - общая проблема

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

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


4
Почему так много голосов?
Pureferret

3
Похоже, разумный вопрос для меня. Похоже, у вас есть незаконченное редактирование; Вы можете позаботиться об этом.
Стюарт Маркс


@gnat это между разными программами / проектами. Я спрашиваю о том же проекте / сценарии.
Pureferret

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

Ответы:


29

Во-первых, вы передаете соль. Тогда вы передаете перец. Затем вы передаете тертый сыр пармезан. На данный момент у вас достаточно опыта, чтобы начать разработку общей системы передачи приправ.

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


4
Это отличный ответ!
Pureferret

И именно поэтому Agile скалы.
Эйфорическая

1
вроде как связано с en.wikipedia.org/wiki/Zero_one_infinity_rule
jk.

9

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

Опыт.

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

Даже тогда вы не очень знаете ; тебе просто лучше угадать.


3

Чтобы основываться на ответах от dasblinkenlight и Paddy3118 , если у вас нет нескольких вариантов реализации, вам не нужно обобщать! Причина смешного карикатуры XKCD заключается в том, что это преждевременное обобщение . Когда его просят передать соль, невидимый персонаж немедленно переходит к «разработке системы для передачи произвольных приправ», когда все, о чем просил первый персонаж, была соль. Это хорошая шутка для разработчиков, так как я думаю, что мы все видели случаи преждевременного обобщения.

Принцип, противостоящий преждевременному обобщению, - это ЯГНИ (Тебе это не нужно). Есть много материалов об этом, доступных в Интернете, но в основном YAGNI указывает на ряд рисков в обобщении без выгоды нескольких реальных случаев использования, включая возможность того, что множественные варианты использования могут фактически не появляться. Или, что более тонко, отсутствие реальных вариантов использования требует, чтобы делать предположения о том, что необходимо в будущем. Эти предположения могут быть и часто являются неверными.


2

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

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


2

Сделайте это один раз, сделайте это дважды, сделайте это три раза, обобщите.


1

Раз, два, много!

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.