Как делают Вы избегаете Технического Долга, в то время как все еще сохраняют верными для Гибкого, т.е.: предотвращение нарушения YAGNI и предотвращения BDUF? [закрытый]

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

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

Я очень настоятельно рекомендовал бы книги Mike Cohn по гибкому планированию:

1. Пользовательские прикладные истории
2. Гибкая оценка и планирование

Обновление: После Вашего разъяснения о предотвращении YAGNI и BDUF в рамках повторения...

BDUF... Если бы я чувствовал, что функция не была ясно определена, прежде чем я запустил работу над нею, то я создал бы маленькую "функцию" или историю для составления части типа дизайна необходимой работы. Так, чтобы, возможно, меньшая история имела точечную оценку истории 1 вместо 5 реальной функции. Тем путем дизайн упаковывается временем в меньшую историю, и Вы будете управляться для хождения дальше к самой функции.

Чтобы постараться не нарушать YAGNI, я работал бы, чтобы очень согласиться с тем, что клиент ожидает для функции в рамках повторения. Только работайте, который отображается на то, что ожидает клиент. Если Вы думаете, что что-то дополнительное должно быть добавлено, создать новую возможность для него, и добавлять его к отставанию в работе, которое будет сделано. Вы затем убедили бы клиента видеть преимущество его; так же, как клиент стремился бы к функции, сделанной в определенный момент вовремя.

Вы, кажется, говорите, что "YAGNI" подразумевает "быстрый и грязный". Я не вижу это.

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

• Разработка через тестирование (TDD), как процесс, является хорошим способом избежать YAGNI. Код, который это просто там "в случае, если это будет полезно", имеет тенденцию быть непротестированным и трудно протестировать.
• TDD также в основном удаляет принуждение к BDUF: когда Ваш процесс должен запуститься путем присаживания и начать делать что-то, что на самом деле поставляет значение, Вы не можете баловаться BDUF.
• TDD, поскольку практика дизайна означает, что большой дизайн появится, поскольку Вы приобретаете опыт с проблемой, и осуществляют рефакторинг реальный код.
• Интеграция Continous означает разработку процесса, таким образом, продукт чрезвычайно публикуем в любое время. Это означает, что у Вас есть интегрированный качественный процесс, который пытается препятствовать тому, чтобы качество магистрали отбросило.

По моему опыту, основные формы технического долга:

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

Не уверенный, если это ответило на Ваш вопрос, но я весело провел время, пишущий это.

Troy DeMonbreun прокомментировал:

Нет, это не было моей точкой... "быстрой и грязной" = (неумышленно риск Техническим Долгом при попытке придерживаться YAGNI"). Это не означает, что YAGNI только быстр и грязен. Фраза, "быстрая и грязная", то, что я раньше заключал Martin Fowler в кавычки в его описании Технического Долга

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

Я думаю, что мог бы все еще упускать суть Вашего вопроса.

Было интересное обсуждение Технического Долга на основе Вашего определения сделанных на HanselMinutes несколько недель назад - Что Сделано. Основы шоу были то, что, если Вы переопределяете 'Сделанный' для увеличения воспринятой скорости, затем Вы накопите Технический Долг. Заключение этого - то, что, если у Вас нет надлежащего определения 'Сделанных' затем, Вы, скорее всего, получаете список объектов, которые должны будут быть закончены перед выпуском независимо от методологии проектирования.

Я нахожу, что подход Разработки через тестирование (TDD) Robert Martin помогает с этими проблемами.

Почему?

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

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

'Традиционный' ответ XP осуществляет рефакторинг объединенный с автоматизированным поблочным тестированием.

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

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

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

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

Конечно, быть гибким движение должно сохранить Ваш TD вниз для какого-либо данного проекта?

То, что Вы реализуете то, что клиент хочет, т.е. с их обратной связью, сводит TD к минимуму,

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

Вот почему Вы находите много "подходящих инженеров" составлением новых методов разработки программного обеспечения.

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

Я не мог бы собирающийся необходимый, но возможно я буду, потому что в моем бетоне bussiness/company/department эта вещь действительно происходят, или мне будет нужен он, но у меня просто нет права времени не настолько быстрый и грязный взлом, чтобы заработать деньги и хранить верность моей работе, или мне, возможно, понадобился бы он, и рефакторинг позже будет болью в заднице, стоящей в 10 раз больше, чем просто выполнение его теперь от царапины, и у меня есть время ТЕПЕРЬ.

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

Править: Кстати, TDD является противоположностью YAGNI, Вы создаете тест перед ровным знанием, если Вы собираетесь нуждаться в них. Серьезно, прекратите слушать академиков!! Нет никакого волшебного способа произвести программное обеспечение.

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

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