Как «Вам это не нужно» и «Теперь лучше, чем никогда» играть вместе?

Я часто нахожусь в объятиях «сейчас лучше, чем никогда», когда я продвигаю СУХОСТЬ дизайна. Как правило, я нахожу, что мне нужно развивать понимание Единого авторитетного Места для части знаний в контексте системы других частей знаний. Таким образом, я склонен проектировать систему «сейчас».

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

Как эти два образца выстраиваются?

Какие практики вы используете, чтобы они играли хорошо?

Как вы учите их вместе, не создавая путаницы?

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

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

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

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

ЯГНИ означает, что все делается, когда нужно, а не раньше. Это не значит, что они никогда не закончатся, если только они никогда не понадобятся. Это означает, что вы делаете только то, что дает клиенту немедленную ценность для бизнеса . Что означает непосредственная ценность для бизнеса, субъективно для каждого клиента и каждого проекта.

В любом случае, вы ничего не можете потерять с YAGNI.

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

пример

Если я работаю над прототипом / доказательством концепции или версией приложения 1.0, мне не нужен дизайн для масштабирования до уровня Facebook. Черт возьми, мне не нужен дизайн для масштабирования до уровня Facebook, пока я не увижу, что у меня такой трафик.

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

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

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

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

Путь Дзен Питона говорит:

Сейчас лучше, чем никогда. Хотя никогда не бывает лучше, чем сейчас.

Идея в том, что это не потому, что теперь вы можете определить что-то, что должны Вам это нужно сейчас?

• Да, сделай это сейчас!
• Нет, не делай этого! Ждите нужды! YAGNI!

Случаи, когда это менее очевидно, находятся в случаях рефакторинга. Должен ли я применять СУХОЙ каждый раз, когда могу? Ответ неясен, потому что бывают случаи, когда применение DRY стоит больше (затраченного времени), чем дублирование. Тем не менее, в долгосрочной перспективе применение DRY до тех пор, пока у вас есть технические / эксплуатационные причины, не всегда хорошо.

Итак, YAGNI, пока вы не сделаете, тогда делайте это сейчас. Не жди!

Я не думаю, что они играют вместе вообще. Я думаю, вы либо наклонитесь так или иначе. И я склоняюсь к ЯГНИ.

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

Просто мои два цента.

Как эти два образца выстраиваются?

Они ортогональны и не имеют ничего общего друг с другом.

Какие практики вы используете, чтобы они играли хорошо?

Um. У них обоих? Что еще может быть?

Как вы учите их вместе, не создавая путаницы?

YAGNI описывает особенности, видимые пользователями. Тебе не нужны фантазии.

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

Если «никогда» не означает «не сейчас», то ваш дизайн имеет недостатки.

Локальные решения, которые вы принимаете, должны быть прозрачными для остальной системы.
Например, если у вас есть компонент CookieSource, который требует преобразования CookieFactoryв CookieRecipesнего, который он знает Cookies, на основе некоторых ваших входных параметров, то он CookieSourceне должен и, следовательно, не должен зависеть от того, как CookieFactoryреализован и как CookieRecipesпредставлен.
Если CookieFactoryэто на самом деле Bakery, что может принять любое Recipeв соответствии Pastryне должно иметь значения. И если вам не нужна эта функциональность, вам не нужно ее реализовывать. И в мире нет причин, по которым вы не сможете добавить его позже, кроме случаев, когда нет четкого абстрагирующего барьера между CookieSourceуслугами, которые он использует.

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

Самое простое решение, которое я нашел, - ожидать изменений при написании кода заранее. Когда я передаю некоторое значение bool в функцию, я обычно заменяю его на флаг / перечисление, так что оно а) более читабельно и б) легко расширяется. Аналогично, если я замечаю, что я передаю кучу параметров, где пахнет, как будто мне нужен еще один, я обычно создаю специальную структуру. Надежда на то, что YAGNI это сделает, но если вы сделаете это в какой-то момент, это сразу не сломит всех пользователей, и «грубая работа» уже сделана. Довольно часто, вы также можете просто добавить некоторые комментарии, такие как / * будущие добавления идут сюда * / или так, чтобы было ясно, что он еще не реализован, но здесь есть место, чтобы добавить его. Это обычно помогает больше всего, поскольку рефакторинг интерфейса позже показался мне наиболее трудоемким.

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

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

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

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