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

И если насчёт таких вещей, как правила наименований классов / функций / методов вопросов в целом нет, то вот такие постулаты, как обязательные деления на уровни абстракций, минимизация функций, выделение обработок исключений в отдельные функции и т.п. приводит к результату выше.

С одной стороны - для проектов с сотнями тысяч строк кода структура может быть (ввиду отсутствия объективных исследований утверждение не доказано и не опровергнуто) важнее лаконичности из-за высоких трудозатрат на внесение изменений, с другой стороны... А разумно ли фанатично следовать некоторым правилам вообще везде?

Строки кода, это не просто строки кода. Это ещё и время разработчика (которое становится в итоге стоимостью разработки), а в конечном итоге время и ресурсы выполнения программы... Цену чистого кода мы знаем... А товар который мы за эту цену покупаем?

Разработчики игр среди прочего получат ранний доступ к инструментам на базе искусственного интеллекта 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 метров).

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

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

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

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

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