Никогда не делайте ничего, пока не будете готовы использовать это, в том числе и в программном обеспечении? [Тойота принцип]

Question

Я слушал подкаст. Где они говорили о принципах, которые использовала Toyota:

Никогда не делай ничего, пока не будешь готов это использовать.

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

Answer 1

Это может относиться к построению программного обеспечения, но я не уверен, что это применимо

Если мы рассмотрим пять элементов в " способе принятия решений по принципу Toyota ", основанном на принципе, что "то, как вы примете решение, так же важно, как и качество решения":

[режим юмора включен]

• Выяснить, что на самом деле происходит, в том числе Genchi Gembutsu.

  За исключением того, что когда-нибудь, наконец, понимают, что происходит, когда клиент объясняет нам в конце проекта;)

• Понимание основных причин, объясняющих появление на поверхности, - пять раз спрашивать "почему?".

  Конечно, но клиент недостаточно доступен во время проекта;)

• Широко рассматривая альтернативные решения и разрабатывая подробное обоснование предпочтительного решения.

  Слишком поздно программисты уже пишут как безумцы:)

• Достижение консенсуса внутри команды, включая сотрудников Toyota и внешних партнеров.

  К сожалению, программист уже переписывает систему аутентификации, хотя старая работала нормально

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

  Вы слышали "смерть от PowerPoint"? Это не всегда наша сильная сторона;)

[режим юмора выключен]

Серьезно, как указывалось в предыдущих ответах, философия Agile затрагивает некоторые основные принципы этого принципа Toyota.

И это может быть немного богаче, чем просто "Вы не нуждаетесь в этом", как описано в книге " Путь Тойоты "

Answer 2

Вроде да. Это основная часть гибкой философии.

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

Answer 3

Немного старых новостей. Его часто называют "Тебе это не понадобится" ( "You Arent' Going to Need It" на неидоматическом английском языке) и сокращенно YAGNI.

Проблемы, связанные с реализацией функции, когда она вам не нужна:

• реализация отнимает время на разработку необходимых функций
• эту функцию сложно документировать и тестировать, поскольку, если она вам не нужна, кто знает, что именно она должна делать?
• поддержание функции займет дополнительное время
• функция добавляет дополнительный код, усложняя кодовую базу
• эта функция может иметь эффект снежного кома, при этом она предлагает другие функции, которые вы можете затем добавить, даже если они не нужны

Answer 4

Это хорошая гибкая практика, чтобы так думать. Есть также что-то под названием Test-Driven-Development, которое помогает вам получить программное обеспечение без ошибок (почти), но также имеет тот побочный эффект, что реализовано НИЧЕГО, что вы не используете.

Например, у вас есть собственный класс коллекции. Если вам нужен только метод Add и метод ToArray, то зачем использовать время для реализации методов Remove и Count?

Так что да. Следуй этому принципу:)