Статья ориентирована на читателя, который еще сомневается, стоит ли ему пробовать чат‑боты в работе. Если вы знакомы с технологией и пробовали её в повседневной деятельности, то вряд ли найдете её полезной.
Немного расскажу о реальном применении GPT у нас в компании.
Введение
Про генеративные модели рассказано много: всевозможные источники предрекали вымирание каждой второй интеллектуальной профессии. Обязательно находились люди, которые рассказывали что «программисты не нужны, вон username из city сделал сайт/скрипт/чертёж.txt при помощи ChatGPT, уволил всех программистов и сидит один грустный ищет новых теперь его бизнес работает сам, а он только деньги собирает».
Благодаря фурору, который произвёл ChatGPT наклейка «АЙ АЙ» появилась на каждом втором утюге. При этом самих же нейронных сетей в различных архитектурах было предостаточно в технологиях, которыми мы привыкли пользоваться без явного подчёркивания, что «там работает искусственный интеллект».
В совокупности, у меня это всё вызывало только раздражение, но отрицать полезность чат‑бота глупо — даже в текущем виде мы применяем его внутри компании, и он помогает моим коллегам и мне решать рабочие рутинные задачи. Сегодня я немного расскажу о некоторых удачных практических применениях.
Генерация UML схем
Прототипирование часто является одной из задач проектировщика. Этот инструмент полезен не только ему самому, но и человеку, который это решение будет имплементировать. Прототипирование сильно упрощает понимание финального концепта конечным разработчиком, а понимание — ключ к успешному взаимодействию.
В процессе проектирования бывшему разработчику проще всего накинуть будущие модели, используя какой‑либо язык программирования, например C# или Typescript. Это удобно, так как в любимых ORM часто используется code first подход, и в коде очень легко выразить нужные связи в естественном для разработчика виде. А на основании этих связей можно накинуть DSL и немного детальнее проработать предметную область.
Но помимо разработчика и архитектора в выработке решения обязательно участвует системный аналитик. И как бы не был силён наш аналитик, языком программирования он не владеет и понять такую схему ему будет трудно, но зато аналитик с лёгкостью поймет ERD. Конечно же, при этом не хочется описывать это ERD вручную, а сгенерировать его из имеющегося кода.
На рынке существует несколько продуктов, которыми я смогу решить эту задачу, но они платные (что ожидаемо) и/или требуют подключения к БД, которой ещё нет. Затраты по времени и усилиям не стоят покупки или использования этих продуктов — быстрее самостоятельно сделать эту диаграмму и бесплатно.
Вот тут на помощь приходит GPT и простая просьба сгенерировать ERD диаграмму с использованием PlantUML. И с этой задачей он справляется относительно неплохо — со 2–3 раза получается вполне читаемая диаграмма, достаточная для иллюстрации решения.
Вот пример решения такой задачи.
Предположим, у нас есть некоторая сущность Order, с которой связанны некоторые объекты имеющие определённый тип. Пример намеренно маленький — на масштабах работает так же.
Hidden text
Пользователь:
Generate entity relationship diagram for PlantUML using following Typescript code
type UUID = String;
type RelatedEntityType = {
key: string;
}
type LinkedObject = {
entityType: RelatedEntityType;
key: string;
}
type Order = {
id: UUID;
linkedObjects: LinkedObject[];
}
GPT:
Sure! Here's the entity relationship diagram (ERD) for the TypeScript code you provided, using PlantUML syntax:
plantuml
Копировать
@startuml
!define ENTITY_RELATIONSHIP_DIAGRAM
package "Types" {
class UUID {
- value: String
}
class RelatedEntityType {
- key: String
}
class LinkedObject {
- entityType: RelatedEntityType
- key: String
}
class Order {
- id: UUID
- linkedObjects: LinkedObject[]
}
}
Order "1" -- "" LinkedObject : containsLinkedObject "" -- "1" RelatedEntityType : has
@enduml
This diagram represents the entities and their relationships as defined in the TypeScript code. The UUID, RelatedEntityType, and LinkedObject classes are defined in the Types package. The Order class has a one-to-many relationship with LinkedObject, denoted by the 1 -- "" notation. The LinkedObject class has an association with RelatedEntityType with a one-to-one relationship, denoted by the "1" -- "1" notation.
Please note that PlantUML allows for different diagram layouts and styling options, so you can customize the appearance of the diagram according to your preferences.
Пользователь:
Use PostgreSQL types for primitives
GPT
Certainly! Here's an updated version of the entity relationship diagram (ERD) incorporating PostgreSQL data types for the primitive types in your TypeScript code:
plantumlКопировать@startuml
!define ENTITY_RELATIONSHIP_DIAGRAM
package "Types" { class UUID { - value: UUID NOT NULL } class RelatedEntityType { - key: VARCHAR(255) NOT NULL } class LinkedObject { - entityType: RelatedEntityType - key: VARCHAR(255) NOT NULL } class Order { - id: UUID NOT NULL - linkedObjects: LinkedObject[] }}
Order "1" -- "" LinkedObject : contains
LinkedObject "*" -- "1" RelatedEntityType : has
@enduml
In this updated diagram, I've replaced the UUID type with the UUID data type supported by PostgreSQL, which is represented as UUID NOT NULL. The RelatedEntityType and LinkedObject types now use the VARCHAR(255) NOT NULL data type to match the string type from TypeScript.
Feel free to adjust the data types according to your specific database requirements.
Пользователь:
Use Crow's Foot notation for relations
GPT:
Certainly! Here's an updated version of the entity relationship diagram (ERD) using the Crow's Foot notation for representing relationships:
plantuml
Копировать
@startuml
!define ENTITY_RELATIONSHIP_DIAGRAM
package "Types" {
entity "UUID" as uuid {
+ value : UUID [PK]
}
entity "RelatedEntityType" as relatedEntity {
+ key : String [PK]
}
entity "LinkedObject" as obj {
+ key : String [PK]
}
entity "Order" as order {
+ id : UUID [PK]
}
order --|{ obj : contains
obj }|-- relatedEntity : has
@enduml
In this diagram, each entity is represented as a box, and the relationships are depicted using Crow's Foot notation. The primary key attributes are denoted with a "+" symbol, and the relationship between Order and LinkedObject is represented with the contains relationship using the "zero or more" (crow's foot) notation on the LinkedObject side. Similarly, the LinkedObject entity has a relationship with RelatedEntityType depicted by the has relationship using the "one or more" (crow's foot) notation on the RelatedEntityType side.
Please note that Crow's Foot notation represents cardinality and relationship types visually but doesn't explicitly depict the data types.
Вот такую диаграмму мы получим на выходе. Описание UUID, конечно, лишнее, но это уже придирки.
Генерация комментариев к коду
Комментировать код является хорошей и распространённой практикой. Комментарии позволяют быстро получить недостающий контекст о назначении участка кода, метода или класса без ущерба читаемости самого исходного кода, и разработчики привыкли эти комментарии оставлять (ну или их принуждают они стараются это делать). Но часто ли вам приходится объяснять назначение каждого ФАЙЛА?
Одним из условий сдачи проекта была передача исходного кода заказчику. Команда вела разработку проекта несколько лет — было написано более 3000 файлов исходного кода. И вот, разработка окончена и начинаются приёмо‑сдаточные испытания.
И какого же было удивление команды, когда стало известно об одном интересном факте: согласно внутренним документам заказчика каждый файл исходного кода должен сопровождаться комментарием о том, для чего он тут нужен.
Возможно, требование покажется абсурдным, возможно, оно уже устарело как морально, так и организационно, но сделать его нужно. Задача кажется трудоёмкой и скучной — зайти в каждый файл, посмотреть на него, сделать некоторое резюме. Скучная, но выполнимая. Кому же поручить такую задачу? Джуниор разработчику? А он не уволится расстроится после такой задачи? Отвлечь на часок всю команду?
И тут мы вспомним про замечательное умение нашего GPT — cпособность к обобщению! А не это ли нам нужно?
Попробуем проверить. Возьмём файлик с нашим кодом и попросим его рассказать: а что тут происходит?
Hidden text
Пользователь:
Продокументируй код и верни ответ в MarkDown
GPT:
|
Как оказалось, GPT вполне явно определил что содержит этот файл. Попробуем на масштабе — немного дорабатываем запрос, проходимся кодом по нашему репозиторию, просим GPT через API обобщить каждый файл и выводим это в текстовый файл.
Мы бегло перепроверили работу помощника. Всё сходилось.
Задача решена, нервы коллег сохранены!
Шторминг проблем
Иногда при шторминге проблем не знаешь, с чего начать: мысли путаются, непонятно, где причина, а где следствие. Проблема часто скорее психологическая — правильно начать, не сбиться с мысли.
Многие часто используют для этого коллегу: собрать созвон и попытаться решить проблему совместно, конечно, увлекательно, но такая практика крадёт уйму рабочего времени у других. Причем часто коллега в этом процессе скорее как утёнок. Но интерактивный.
Если ты не хочешь отвлекать коллегу, то чат‑бот может стать таким собеседником. Он особенно полезен, когда ты не обладаешь глубокой технической экспертизой в определенной области и тебе нужен не просто утёнок, а senior утёнок, который может и подсказку дать.
А иногда вопросы задавать просто стыдно. Наверное самое популярное — это проблемы с git. Несмотря на обширную документацию и огромное количество примеров, очень многие в упор игнорируют его изучения и из раза в раз повторяют одни и те же ошибки или бездумно выполняют скрипты со stackoverflow.
Вопрошающий (которому очень стыдно за эту часть статьи) не только не связал локальный репозиторий с удалённым, но и не сделал коммит.
Hidden text
Пользователь:
HEAD detached at origin/main что значит?
GPT:
Сообщение "HEAD detached at origin/main" в контексте работы с системой контроля версий Git указывает на то, что ваша текущая рабочая копия репозитория находится не на вершине какой-либо ветки, а в состоянии "отсоединённого HEAD" (detached HEAD). Это происходит, когда вы переходите непосредственно к какому-то конкретному коммиту или к тегу, а не работаете в рамках ветки. В таком состоянии вы можете просматривать код, тестировать изменения на определённых коммитах, но любые новые коммиты, созданные в этом состоянии, не будут принадлежать никакой ветке. Если после этого вы перейдёте на другую ветку, без создания новой ветки для этих коммитов, вы рискуете потерять их, поскольку они не будут привязаны к какой-либо из ветвей репозитория.
Чтобы "исправить" это состояние и вернуться к работе в рамках ветки, вы можете выполнить одно из следующих действий:
Если вы хотите сохранить свои изменения в новой ветке:
git checkout -b новая-ветка
Это создаст новую ветку начиная с текущего состояния и переключит вас на неё.
Если вы хотите вернуться к работе в уже существующей ветке и отказаться от изменений в состоянии отсоединённого HEAD:
git checkout имя-существующей-ветки
Например, чтобы вернуться к ветке main, используйте:
git checkout main
Эти команды помогут вам вернуться к нормальной работе в Git, где вы можете продолжить делать коммиты в рамках ветвления.
Пользователь:
warning: remote HEAD refers to nonexistent ref, unable to checkout а это как?
GPT:
Сообщение об ошибке
warning: remote HEAD refers to nonexistent ref, unable to checkout
указывает на проблему, связанную с удалённым репозиторием в Git. Оно говорит о том, что ссылка HEAD в удалённом репозитории указывает на ветку, которой не существует в данном репозитории. Это может произойти по нескольким причинам, например:
Удаление ветки на удалённом репозитории: Если ветка, на которую указывает HEAD удалённого репозитория, была удалена, но HEAD не был обновлён для указания на существующую ветку.
Некорректная настройка удалённого репозитория: Настройка HEAD в удалённом репозитории может быть некорректной, если, например, в конфигурационных файлах указана неправильная ветка.
Что делать?
Чтобы решить эту проблему, вы можете предпринять следующие шаги:
Проверьте текущее состояние HEAD на удалённом репозитории. Это можно сделать, используя команду git remote show origin (предполагая, что origin — это имя вашего удалённого репозитория). Эта команда покажет вам текущее состояние веток на удалённом репозитории и то, на какую ветку указывает HEAD.
Исправьте указатель HEAD на удалённом репозитории. Если вы имеете доступ к настройкам удалённого репозитория, убедитесь, что HEAD указывает на существующую ветку. Как это сделать, зависит от того, какой сервис или какое программное обеспечение вы используете для хостинга вашего репозитория. В некоторых случаях это может потребовать выполнения команды git symbolic-ref HEAD refs/heads/имя_существующей_ветки на сервере.
Обновите ссылки в локальном репозитории. После того как проблема на удалённом репозитории будет исправлена, выполните git remote update origin --prune (или просто git fetch --prune), чтобы обновить информацию о ветках в вашем локальном репозитории. Опция --prune удалит устаревшие ссылки на ветки, которые больше не существуют на удалённом сервере.
Если вы не имеете доступа к настройкам удалённого репозитория (например, если это внешний репозиторий, к которому у вас ограниченный доступ), вам может понадобиться связаться с администратором или поддержкой сервиса хостинга, чтобы они исправили эту проблему.
Иногда для рассуждений нужна экспертиза. Нужно было перенести данные из одной таблицы в другую, используя миграцию. Важным нюансом являлось то, что сервис поддерживал работу с двумя СУБД: PostgreSQL и SQLite.
Переписка с GPT 3.5 была достаточно нудной, и его сложно было заставить выдать нужный результат. А вот GPT 4 с задачей справился.
Решение конечно не полное, но главное, что оно дало толчок к размышлениям в нужную сторону без необходимости призыва старших коллег.
Hidden text
Пользователь:
Как написать миграцию переноса данных из таблицы в другую таблицу в EF Core? Миграция должна корректно выполниться как на PostgreSQL, так и на SQLite.
При переносе нужно сгенерировать новый id типа uuid для каждой записи, используя только SQL.
GPT:
Написать миграцию для переноса данных из одной таблицы в другую в Entity Framework Core можно, используя migrationBuilder.Sql(), которое используется для выполнения сырых SQL-команд. Если вам нужно выполнить это действие на разных типах баз данных, — SQLite и PostgreSQL, вам нужно будет учесть их специфику. Следует помнить, что EF Core не предоставляет универсального способа генерации UUID / GUID для разных диалектов SQL, но вы можете использовать сырой SQL.
Вот пример миграции, которая может быть изменена в соответствии с вашими потребностями:
csharp
Копировать
public partial class DataTransferMigration : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
string idGenerationMethod;
switch (migrationBuilder.ActiveProvider)
{
case "Pomelo.EntityFrameworkCore.MySql":
case "Microsoft.EntityFrameworkCore.SqlServer":
idGenerationMethod = "NEWID()";
break;
case "Npgsql.EntityFrameworkCore.PostgreSQL":
idGenerationMethod = "uuid_generate_v4()";
break;
default:
throw new NotSupportedException("Unknown DB provider: " + migrationBuilder.ActiveProvider);
}
migrationBuilder.Sql($@"
INSERT INTO NewTable (Id, Column1, Column2)
SELECT {idGenerationMethod}, oldTable.Column1, oldTable.Column2
FROM OldTable as oldTable
");
}
protected override void Down(MigrationBuilder migrationBuilder)
{
// Здесь можно добавить логику отката миграции.
// Не забудьте про необратимость операции генерации нового идентификатора.
}
}
Пожалуйста, замените 'NewTable' и 'OldTable', а также 'Column1' и 'Column2', на фактические названия вашей целевой и исходной таблицы и имена колонок, которые вы переносите. idGenerationMethod будет равен функции, которую ваша база данных использует для создания нового uuid или Guid.
Учтите, что SQLite не поддерживает генерацию uuid напрямую в SQL, поэтому если вы предполагаете использовать SQLite, вам придется использовать другие методы. Возможно, вам придётся выполнить перенос данных из кода, а не из SQL.
Эпилог
Нейросети в различных проявлениях всё больше становятся чем‑то обыденным, и внедрение их в продукты становится всё более распространённым. Мы не исключение — мы используем машинное зрение и распознавание текстов для облегчения пользователям ввода бумажных документов в одном из наших продуктов.
GPT же инструмент новый, а значит, пока плохо изученный со стороны использования.
Поэтому пока рано оценивать его эффективность в полноценной работе: то, что чат‑бот не смог решить нужную тебе задачу, не говорит о том, что он не может этого сделать при достаточном опыте владения им. Аналогично можно сказать про умение пользоваться поисковыми системами — далеко не все знают о том, что поисковая строка того же Google имеет встроенные поисковые операторы и ещё меньше ими пользуются в реальной жизни, хотя это существенно сокращает время поиска.
Его использование сейчас конечно имеет известные недостатки:
Чат‑бот может дать неправильный ответ или даже выдумывать его — это опасно, если ты не обладаешь экспертизой по задаче и результат нельзя проверить при помощи тулинга.
GPT не знает о событиях и технологиях возникших до определённого года, — по свежим проблемам и технологиям чат‑бот не спросишь.
Несмотря на это, мы поощряем использование AI помощников в работе — как показал эксперимент с описанием файлов, инструмент действительно может увеличить производительность и позволяет прикладывать моральные и умственные усилия к более интересным задачам вместо рутины.
А иногда просто помогает улыбнуться.
