Дизайн для будущих изменений или решить проблему под рукой [закрыто]

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

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

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

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

Чтобы свести это к одному правилу: меньше значит больше.

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

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

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

YAGNI не является общепринятым принципом, даже в сочетании с поддерживающими методами. Необходимость сочетать его со вспомогательными методами, а не использовать его отдельно, является частью первоначального определения XP ...

Вероятно, это одна из самых сложных частей разработки программного обеспечения, потому что вам нужно пройти грань между «YAGNI» и «PYIAC» («Раскрась себя в угол»).

Довольно легко сказать «не пишите функцию, если она вам не нужна». Сложная часть заключается в разработке вашего кода, чтобы вы могли легко добавлять функции позже, когда они вам понадобятся.

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

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

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

Хороший дизайн учитывает будущие изменения и определенно стоит того. Рассмотрим операционную систему UNIX и ее «все это философия файла». Это проектное решение было принято не для удовлетворения насущных потребностей, а с учетом будущих требований. Страшно подумать, как будет выглядеть операционная система, основанная на «гибком» дизайне.

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

Мне кажется, я слышал, как другие люди говорили что-то вроде:

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

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

Это зависит от проекта, и, вкратце, опыт научит вас, что такое «+1».

Философия YAGNI , «Вам это не нужно», может быть обобщена (из статьи):

По мнению тех, кто защищает подход YAGNI, соблазн писать код, который не нужен в данный момент, но может возникнуть в будущем, имеет следующие недостатки:

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

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

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

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

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

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

Что это говорит? «Когда у тебя есть только молоток, все начинает выглядеть как гвоздь».

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