KLIP Number — Title

Автор: ваше имя и имя пользователя на GitHub | Целевая версия выпуска: версия выпуска, на которую нацелена эта функция | Статус: В обсуждении или Одобрен дизайн или В разработке или Объединён | Обсуждение: ссылка на PR обсуждения дизайна

tl;dr: Краткое изложение того, почему мы должны это сделать, и (если возможно) кто выиграет от этого. Если это непонятно или слишком многословно, это явный признак того, что нам нужно сделать шаг назад и переосмыслить предложение.

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

Мотивация и предпосылки

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

Что входит в рамки

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

Что не входит в рамки

Что мы явно не хотим рассматривать в этом предложении и почему.

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

Ценность/Возврат

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

Публичные API

Как это меняет публичные API? Меняется ли язык запросов KSQL? Добавляем/удаляем ли мы поддержку форматов данных? Добавляем / удаляем конфигурации? и т.д.

Дизайн

Как работает ваше решение? Это должно охватить основные потоки данных и управления, которые меняются.

План тестирования

Каковы сценарии отказа, которые вы собираетесь охватить в своём тестировании? Какой масштаб тестирования вы планируете провести? А как насчёт тестирования производительности и нагрузки? Само собой разумеется, что большинство классов должны иметь модульные тесты.

LOE и этапы поставки

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

Небольшие функции — скажем, те, которые могут быть выполнены за две-три недели — могут иметь только один этап доставки.

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

Разбиение функции на этапы и задачи не обязательно выполнять при первом представлении KLIP, поскольку объём, функциональность и дизайн могут измениться в ходе обсуждения. Тем не менее эти разбивки в идеале должны быть предоставлены, когда KLIP завершается и до начала выполнения.

Обновление документации

Какие изменения необходимо внести в документацию? Например:

• Нужно ли нам изменить краткие руководства KSQL(s) и/или демонстрацию KSQL, чтобы продемонстрировать новую функциональность? Какие конкретные изменения следует внести?
• Нужно ли обновлять справочник по синтаксису?
• Нужно ли добавлять/обновлять/удалять примеры?
• Нужно ли обновлять часто задаваемые вопросы?
• Нужна ли нам документация, чтобы пользователи знали, как настроить KSQL для использования новой функции?
• и т. д.

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

Последствия для совместимости

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

Последствия для безопасности

• Осуществляются ли внешние коммуникации? Какие новые угрозы могут возникнуть?
• Существуют ли механизмы аутентификации, авторизации и аудита?