Это возражение чаще всего мешает людям начать работу — и оно основано на ложном предположении: будто описание сразу превратится в код без возможности отката. На деле всё устроено иначе. Ваше описание сначала порождает ПЛАН — список данных, экранов и их типов — который показывается вам для проверки и корректировки ДО того, как будет написана хотя бы одна строка кода: переименовать сущность, изменить название поля, добавить или удалить значение статуса («В ожидании», «Подтверждено», «Отменено»), а также изменить тип экрана — например, исправить список на календарь, если именно этого вы намеревались добиться. На этом этапе любая ошибка обходится бесплатно. После генерации приложения изменения по-прежнему возможны — достаточно описать их на русском («добавить поле для даты повторного обращения», «разделить счета-фактуры и коммерческие предложения»), но такая правка перестраивает весь план, заново собирает приложение и проходит автоматическую валидацию. Это надёжно, но не мгновенно — такой шаг уже нельзя назвать лёгкой корректировкой.
Ошибка, которой боятся, на самом деле не происходит
Боязнь состоит в том, что нечёткое описание приведёт к созданию инструмента, не соответствующего задаче, и исправить это будет невозможно. В традиционных проектах этот страх оправдан: техническое задание отправляется подрядчику, первый экран появляется спустя недели, а расхождение между ожиданием и результатом оплачивается днями разработки. Именно эта задержка — а не сложность формулировки — делает процесс тревожным.
Литература по сбору требований говорит то же самое, но с другой стороны: трудность не в том, чтобы записать мысль, а в том, чтобы понять, чего вы хотите, пока не увидите рабочий прототип. Собственные рабочие привычки невозможно угадать — их можно только распознать, когда они визуализированы.
План показывают до кода — и его можно редактировать
Между вашим описанием и готовым приложением есть промежуточный этап — ПЛАН. В нём перечислены данные, которые будет обрабатывать инструмент, их поля и экраны с указанием ТИПА каждого: таблица, календарь, панель управления, карта. Этот план отображается и редактируется.
переименовать сущность и её подпись, скорректировать набор её полей, добавить или удалить значение из списка статусов («В ожидании», «Подтверждено», «Отменено»), изменить название экрана, его значок — а также его тип: если вы намеревались создать календарь, а описали список, исправьте это здесь — одним действием
Именно этот этап делает возражение неактуальным. Приблизительное описание ничего не обязывает: оно порождает предложение, которое вы внимательно просматриваете, и поправка одного слова в плане равносильна тому, чтобы сразу написать его правильно.
После генерации: возможно, но это уже другой тип действия
Когда приложение уже создано, любое изменение по-прежнему запрашивается на русском — «добавить поле для даты повторного обращения», «разделить коммерческие предложения и счета-фактуры». Разница в другом: такая команда пересоздаёт план, полностью пересобирает приложение и снова проходит его через автоматическую валидацию перед возвратом в эксплуатацию. Это надёжно, но не мгновенно.
Поэтому единственный практический совет на этой странице: выделите пять минут на внимательную проверку плана. Это самые дешёвые пять минут всего проекта.
Что важно знать перед изменением работающего приложения
Два момента невозможно угадать — их стоит чётко задать до начала модификации инструмента, уже содержащего ваши реальные данные.
Первое: что произойдёт с уже введёнными данными при изменении структуры (удалении поля, разделении одной сущности на две). Я не утверждаю этого здесь — это вопрос, который необходимо чётко задать перед модификацией приложения в эксплуатации, как на этой платформе, так и у любого другого поставщика ПО.
Второе: кнопки «вернуться к предыдущей версии» не существует. Откат — это подготовленная операция, а не импровизация. Поэтому перед структурными изменениями рекомендуется экспортировать данные: экран «Параметры» поддерживает экспорт в форматах CSV и JSON.