Лига программистов

Разработчики игр среди прочего получат ранний доступ к инструментам на базе искусственного интеллекта Unity Muse и Unity Sentis

Unity Muse — позволяет создавать в редакторе Unity «почти все, что угодно» по текстовому описанию или по эскизу

Unity Sentis — кроссплатформенное решение, с помощью которого можно встраивать ИИ в свои проекты

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

Релиз Unity 6 запланирован на 2024 год

Какие есть варианты написания ТЗ для данной задачи?

1️⃣Самый минимальный уровень детализации. Это когда системный аналитик просто ставит задачу на разработку Джире (ну или в рамках небольшой страничке в конфлю\ворде, в зависимости от того, как принято) и в постановке этой задачи пишет что-то вроде "Требуется реализовать процесс получения данных о пользователе и передачу ее с бэка на фронт по REST-запросу. Со стороны фронта требуется создать новую экранную форму приложения - "Личный кабинет" или "Профиль пользователя". Со стороны бэка требуется реализовать новый метод, который будет использовать фронт для запроса информацию по пользователю (и, скорее всего, перечисляет набор полей, которые должны передаваться на фронт в формате "Фамилия", "Имя" и т.д.)". Усё

Я не утрирую - это один из вариантов реального "ТЗ" на эту задачу. Плюсом к этому может быть описан пользовательский сценарий в вольном формате или в формате UC (и то это будет в лучшем случае). Т.е. по сути в рамках такого процесса разработчик получает из полезной информации - только состав полей, передачу которых ему нужно реализовать по запросу с фронта, и то только их наименования.

2️⃣Вариант с немного лучшей детализацией. В этом формате системный аналитик уже пишет ТЗ в каком-либо формате, в рамках которого указывает, что: "Требуется реализовать новый метод GET /users/{id}, указывает полноценно параметры, которые данный метод должен потреблять на вход и параметры, которые он должен отдавать на выходе." Плюс может описать, также как в предыдущем пункте, верхнеуровневый сценарий взаимодействия с этим методом.

Уже чуть лучше и чуть больше полезной информации для разработчика, правда?

3️⃣Вариант с достойной реализацией. Этот вариант обычно используется на большинстве проектов ФинТеховских и я считаю его достаточным для того, чтобы написать хорошее, качественное ТЗ и разгрузить разработчика так, чтобы он не думал о деталях реализации, хотя бы алгоритмических и системных (то, к чему нужно стремиться со стороны СА, имхо).

В рамках этого варианта будет всё из предыдущих + будет полностью описана логика работы данного метода, как бизнесовая, так и техническая. Будут описаны все корнер-кейсы, правила обработки ошибок, варианты того, что может вернуться в ответе (кроме успешного ответа, еще и все варианты негативных). Логика может быть описана или на уровне псевдокода или просто словами - конкретно это уже не имеет значимой роли, главное то - что эта логика пошагово и подробно описана.

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

4️⃣Более полноценный вариант придумать не могу =)

Плюсом к 3 пункту дополнительно описывается еще и swagger-спецификация микросервиса в целом и конкретных эндпоинтов в частности. Кроме того, что это просто удобно, наглядно и очень детально - эту спецификацию разработчики могут использовать, чтобы сконвертировать ее напрямую в готовый код с расписанными классами и эндпоинтами, останется "только" докрутить бизнес-логику и метод готов (Тут просьба поправить меня коллегам, которые более глубоко погружены в разработку - так ли это или есть еще какие-то бенефиты для разработчиков. Могу в этом предложении быть не прав, пишу исходя из того, как мне это объясняли).

Кроме этого, такой подход хорошо использовать в парадигме swagger-first, особенно когда у вас есть насыщенный и активный процесс кросс-командной разработки. Отдать другой команде сваггер аналитику куда проще и быстрее, чем отдать полноценное ТЗ на сервис - хотя бы просто по времени. А большего им и не нужно (потому что им пофиг на то, как работает ваш сервис внутри, главное понять, как вас вызывать и что вы вернете в ответе).

А если это все еще и использовать в связке с asciidoc-документацией, выкладывании ее в git- ммм, сказка просто. Как вспоминаю об этих процессах, наворачивается скупая слеза ностальгии - как же это было здорово! Жаль, что я встретил это ровно в одном проекте, а во всех последующих так и не смог продавить внедрение чего-то похожего.

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

А с какими процессами и подходами работаете вы?

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-, хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

Из-за этого вскрываются новые нюансы, которые надо срочно починить чтоб не блокировать студентов)

А еще иногда ломается автоматизированное тестирование или в нем находят ошибки) и начинаешь задумываться о тестах для тестов) было у вас такое? признавайтесь.

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

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

Что говорят студенты?

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

Когда будет техничка?

В следующем выпуске) там заодно про кубер расскажу)

И вот холиварный опрос решил создать) интересное)

Группа в Телеграм: https://t.me/davaite_pro_it

Задание на дом, склонировать мой проект, потом туда буду добавлять код для домашнего изучения, а может и ещё что придумаю! (Майнер например засуну - шутка (: )

Жопа. А клиенту уже обещана реализация интеграции прямой. Че делать? Мой архитектор связывается с клиентом говорит вот такая проблема, файликами обмен будет. Они - не вы че какие файлы, вы с дубу рухнули? Такое делали в 2005 году, сейчас нужен обмен на лету!

Архитектор сам не знает че делать, идет ко мне говорит - Леха, проведи работу над тем как можно еще их между собой подружить.

И ВОТ ТУТ КЛЮЧЕВОЕ - я сидел и думал про себя - я чел, который еще месяц даже не отработал, должен буду найти способ интеграции SAP'а, малоизвестной мне программы, с 1С, которую более-менее щупал, но не так чтоб профессионально? Епт, а по хорошему разве не архитектор должен был предусмотреть схему интеграции ДО того, как браться за проект \ заказ, или если он был причастен к продаже - то ДО продажи, не? Ладно, если он это упустил, то разве не ОН должен выкручиваться сейчас? Я ж как бы обычный работяга, которому скажи с помощью чего синтегрировать и как оно по идее должно работать - я сделаю.

Ладно, отставить нытье и спихивание проблем на других, главный вопрос щас - ЧТО ДЕЛАТЬ? Вместе с ним искать варианты или самостоятельно? А как здесь процесс обсуждения найденных вариантов интеграций устроен? Если щас я найду, начну делать, а оно не взлетит - меня ж выкинут с работы, ибо обычно у бизнеса ключевой сотрудник (архитектор) априори никогда не виноват, виноват исполнитель мелкий... Ладно, а если щас заявить, что мол это ваши проблемы, раз нет прямых интеграций, нужно продавливать клиента под обмен файликами - я тогда гарантированно вылечу с работы, ибо никому не нужен "вякающий" работник.

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

В итоге проходит примерно неделя, я нашел такой интересный инструмент как SSIS - SQL Server Integration Services, он может автоматически забирать из API данные и складывать в файл, базу данных и много чего еще может. Реализация автоматического сбора информации из 1С (нескольких) бухгалтерии вроде решена, SSIS по кнопочке сможет забрать данные сразу из нескольких 1С и собрать их воедино для отправки в SAP.

Далее пошел в сам SAP. Увидел обмен файликами это да, но я сразу по опыту знаю, что люди, желающие интеграцию, они сначала захотят простой обмен, а потом начнут навешивать всякие логики сложные. Например, если из первой 1С ("А") будет приходить число, превышающее число из второй 1С ("Б"), то числа "А" скорректировать на числа "Б" (чтоб "А" = "Б" стало), а иначе - берем число "А" как есть и число "Б" тоже как есть.

Поэтому нужно какой-то другой вариант. Желательно единого хранилища, где и будут вот такие взаимосвязи осуществляться. Сразу на ум приходит база данных. Я на тот момент работал только с Oracle и слышал только про другие БД. Немного покопавшись, вижу что SAP отлично дружит с SQL Server (Microsoft). Видел и другие поддерживаемые БД, но интерфейс SQL Server Management мне очень понравился (это ПО работающее с БД SQL Server) и я сразу после этого пошел к архитектору, говорю:

- Давай схему интеграции сделаем так - будет SQL Server, стоящий отдельно от всех 1С. Туда будет поступать информация из всех 1С автоматически с помощью SSIS. Запускаться сбор данных будет из SQL Server. А в SAP будут поступать данные по инициации самой SAP, она забирать данные из SQL Server уже. Если дашь побольше времени, я исследую на тему "А можно ли запускать джобики SQL Server'а из SAP" и скорее всего понадобится инфа "а как из SAP обратно в SQL Server положить"

Он - а SQL Server платный? Лицензия нужна?

Я - (я всегда не любил платить за ПО, любил все бесплатное или максимально хакнуть прогу) щас посмотрю.

В итоге выясняется что есть бесплатные версии и платные. Бесплатные - для домашнего пользования и для разработчиков. Давай выяснять а с чем SSIS умеет работать. Оказалось, что для разработчиков в бесплатной версии, а в платной - со всеми.

Крч, как вы понимаете, бизнес решил пойти бесплатным путем.

Я говорю - дайте мне контакты разработчика 1С, мы с ним обсудим интеграцию с SQL Server.

Туда-сюда, дали контакты, пошла работа... с SSIS до этого не работал, как и со SQL Server, как и с SAP, но я решил пойти ва-банк - либо попробовать реализовать и меня возможно наградят, либо выкинут с позором.

<......>

Короче, что по итогу. Я сам нашел способ интеграции, я сам разрисовал схему интеграции - приходил регулярно к архитектору за одобрением. Я ее (интеграцию) реализовал, в обе стороны. По 1 кнопочке в 1С или в SAP проходила интеграция туда-сюда, со сложной, очень сложной логикой преобразования данных, но бизнес получил что хотел - он начал успешно планировать производство, спрос и предложение. То, на что уходило часы - стало уходить минуты.

Мой архитектор, несколько месяцев спустя, сказал:

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

Это были лучшие для меня слова, никогда не забуду, но черт возьми, через что мне пришлось пройти - от полного непонимания как работает SAP до полной интеграции и настроек всяких разных фич. Вся эта работа, главная составляющая заняла месяца эдак 3 (вместе с согласованиями, доступами, разработками, подключением других 1С-ок...)

А потом еще месяца 3-4 это доработки приятные - чтоб по 1 кнопке шла только нужная информация, ускорение интеграции, доработка логики преобразования данных...

Короче вот такая история вышла