Часть 2: Загрузка данных and Improving или "Хождение по промтам"

Цель этой публикации — показать процесс взаимодействия с ИИ при написании мобильного приложения. Обычно в таких историях публикуют исходный промт, а затем готовый результат. Здесь же хотелось показать более подробно именно сам процесс «Хождения по промтам», как по ходу выстраиваются «взаимоотношения» и происходит взаимообучение ИИ и разработчика. Думаю это будет полезно как уже работающим с ИИ для написания кода, так и тем, кто только начинает входить в этот сегодняшний main stream.

Статья написана в продолжение поста, в котором рассказывалось как с помощью Claude Sonnet 3.7 было написано небольшое мобильное приложение на SwiftUI. Это пользовательский список фильмов. И да, я знаю, что таких приложений вагон и маленькая тележка, но как любому разработчику не нравится брать что‑то навороченное и непонятное, а хочется, как всегда, сделать что‑то «простое и удобное».

Загрузка данных

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

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

Однажды, в ходе очередной попытки освоить программирование, мне попалась переводная книга, где автор на первых страницах обещал научить программировать даже тех, кто никогда этого не делал. И в качестве примера приводил собственного сына 8 лет, которого он как бы научил тоже.

Воодушевлённый таким началом я бодро взялся за чтение. И вот, где-то на первых страницах, при обсуждении типов данных, автор ничтоже сумняшеся сообщает, что целое число, которое Int, может быть Int16, Int32 и т.д., со всеми вытекающими подробностями.

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

Потом подумал, что он, наверное, это где‑то объяснил, а я пропустил. Проверил предыдущие страницы, не нашёл. Может он потом объяснит, бывают же такие преподы, сначала что‑то скажет, а потом разберёт. Посмотрел вперёд, не нашёл тоже.

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

С тех пор, если встречается в книге, что автор научит всех, даже тех, кто «никогда не программировал», то невольно вздрагиваю, как от легкого удара электрическим током.

И самое смешное, что недавно, на современном курсе по изучению программирования, услышал то же самое. Преподаватель, как только зацепился за тип Int, тут же начал рассуждать все о тех же Int16, Int32, Int64 и т. д. Как будто он попадает в разъезженную колею и уже не может из нее выбраться.

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

Постановка проблемы

На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code.

Все они в той или иной мере работают с тремя основными сущностями - Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter.

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

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

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

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

Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д.

Продолжая пример с изучением воды следует сказать, что единицей её анализа является молекула воды. Это мельчайшая частица воды, которая тем не менее содержит в себе все её свойства.

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

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

При этом, задача понимается как бизнес-процесс.