Всем привет!
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария должен быть тикет, по которому ведутся работы. В начале текста комментария. В идеале - один тикет. Если правка одной строки исправляет несколько багов\закрывает несколько задач - то лучше закрыть лишние тикеты как дубликаты. Если не хочется заводить тикет на каждый чих - можно завести и использовать тикет типа "мелкие правки"
3) любой комментарий должен быть содержательным, т.е. описывать суть изменений. Лучше не привязваться к именам файлов\классов, т.к. они меняются при рефакторинге, а оперировать понятиями предметной области
4) по длине рекомендую сильно не увлекаться, ограничиваться одной или несколькими фразами. Заодно и сommit-ы будут более атомарными, проще будет revert-ть.
5) формат сommit должен быть единообразным, можно даже контролировать это на сервере. Т.к. по моему опыту без контроля сложно придерживаться единообразия, периодически проскакивают неформатные комментарии)
6) конечная цель комментариев - чтобы список commit-ов нес полезную информацию и его можно было использовать как changelist сервиса
7) следствие из предыдущего пункта - можно и нужно использовать amend для слияния нескольких commit-ов в один. Единственное исключение - если ваш git server синхронизируется, в другую подсеть например, и синхронизация ломается при amend. Опять же при односторонней синхронизации проблему решить можно.
8) следующий уровень - перед созданием Pull request\Merge request можно отрефакторить список commit-ов - переименовать, слить несколько из середины. IDEA позволяет все это сделать. Также можно хардкорно, через коммандную строку с помощью rebase - https://habr.com/ru/post/201922/ С одной стороны так мы становится на путь перфекционизма, но помнить о такой возможности надо)
9) Описание формата commit должно быть в readme.md проекта
Отдельно хочу сказать про язык комментариев. Есть мнение о необходимости английского - я с ним не согласен. По желанию команды. Все-таки не все в совершенстве владеют английским, как среди текущих разработчиков сервиса, так и среди будущих. А читаемость прежде всего!) Да, в английском нет родов у глаголов, поэтому с ним проще. В русском лучшим вариантом кажется использовать стадательный залог - "сделано то-то". Добавление рода или числа - сделал\сделали\сделала - кажется лишней информацией.
Также отдельная тема - нужны ли какие-то специальные обозначения в commit message. Например, алиас для тип изменений: фича, багфикс, рефакторинг, конфиги, тесты. Или указание модуля, где менялся код. Считаю, что не обязательно, но может быть полезно.
#git #code_review
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария должен быть тикет, по которому ведутся работы. В начале текста комментария. В идеале - один тикет. Если правка одной строки исправляет несколько багов\закрывает несколько задач - то лучше закрыть лишние тикеты как дубликаты. Если не хочется заводить тикет на каждый чих - можно завести и использовать тикет типа "мелкие правки"
3) любой комментарий должен быть содержательным, т.е. описывать суть изменений. Лучше не привязваться к именам файлов\классов, т.к. они меняются при рефакторинге, а оперировать понятиями предметной области
4) по длине рекомендую сильно не увлекаться, ограничиваться одной или несколькими фразами. Заодно и сommit-ы будут более атомарными, проще будет revert-ть.
5) формат сommit должен быть единообразным, можно даже контролировать это на сервере. Т.к. по моему опыту без контроля сложно придерживаться единообразия, периодически проскакивают неформатные комментарии)
6) конечная цель комментариев - чтобы список commit-ов нес полезную информацию и его можно было использовать как changelist сервиса
7) следствие из предыдущего пункта - можно и нужно использовать amend для слияния нескольких commit-ов в один. Единственное исключение - если ваш git server синхронизируется, в другую подсеть например, и синхронизация ломается при amend. Опять же при односторонней синхронизации проблему решить можно.
8) следующий уровень - перед созданием Pull request\Merge request можно отрефакторить список commit-ов - переименовать, слить несколько из середины. IDEA позволяет все это сделать. Также можно хардкорно, через коммандную строку с помощью rebase - https://habr.com/ru/post/201922/ С одной стороны так мы становится на путь перфекционизма, но помнить о такой возможности надо)
9) Описание формата commit должно быть в readme.md проекта
Отдельно хочу сказать про язык комментариев. Есть мнение о необходимости английского - я с ним не согласен. По желанию команды. Все-таки не все в совершенстве владеют английским, как среди текущих разработчиков сервиса, так и среди будущих. А читаемость прежде всего!) Да, в английском нет родов у глаголов, поэтому с ним проще. В русском лучшим вариантом кажется использовать стадательный залог - "сделано то-то". Добавление рода или числа - сделал\сделали\сделала - кажется лишней информацией.
Также отдельная тема - нужны ли какие-то специальные обозначения в commit message. Например, алиас для тип изменений: фича, багфикс, рефакторинг, конфиги, тесты. Или указание модуля, где менялся код. Считаю, что не обязательно, но может быть полезно.
#git #code_review
Хабр
Изменение коммитов в Git
Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно...
👍2
Всем привет!
Сегодня хотел бы поговорить про код-ревью.
Для начала - что оно нам дает?
1) единообразие кодовой базы. Люди приходят и уходят, а код остается) Новичок в команде должен во-первых быстро разобраться в проекте, а во-вторых - писать код в едином стиле. Я говорю не только про код-стайл, но и про наименования, разделение по модулям и слоям, переиспользование кода и многое другое
2) понятный, "чистый" код в проекте. Тут можно снова сказать про важность быстрого вхождения в проект новых людей. Важная ремарка - чтобы код был простым и понятным ревьювер должен сознательно ставить себе такую цель.
3) общее владение кодом в команде. Если код посмотрел ревьювер и сделал это качественно, а не формально - этот код теперь знают два человека. Легче вносить какие-то правки, проводить рефакторинг.
4) альтернативный взгляд на решение задачи. Не всегда предложенное решение будет правильным, и нужно все переделывать. Но узнать о других вариантах и обсудить к примеру будущий рефакторинг точно будет полезно. Отдельно хочется отменить, что иногда лучше прорабатывать решение до написания кода, чтобы избежать потерь времени на код-ревью и переделывание. Примеры: новичок в коданде или просто сложная задача.
5) обмен знаниями о проекте, библиотеках, утилитах и даже языке программирования. Причем узнать что-то новое может и автор кода, и ревьювер.
6) повторяющиеся ошибки\"холиварные" вопросы на код-ревью должны обсуждаться и фиксироваться. И т.об. они являются источником для новых правил в статическом анализаторе кода и в правилах работы над проектом
И как следствие вышесказанного получаем повышение качества кода.
P.S. Далее расскажу про рекомендации для автора и ревьювера, а также про кросс-командное ревью.
#code_review
Сегодня хотел бы поговорить про код-ревью.
Для начала - что оно нам дает?
1) единообразие кодовой базы. Люди приходят и уходят, а код остается) Новичок в команде должен во-первых быстро разобраться в проекте, а во-вторых - писать код в едином стиле. Я говорю не только про код-стайл, но и про наименования, разделение по модулям и слоям, переиспользование кода и многое другое
2) понятный, "чистый" код в проекте. Тут можно снова сказать про важность быстрого вхождения в проект новых людей. Важная ремарка - чтобы код был простым и понятным ревьювер должен сознательно ставить себе такую цель.
3) общее владение кодом в команде. Если код посмотрел ревьювер и сделал это качественно, а не формально - этот код теперь знают два человека. Легче вносить какие-то правки, проводить рефакторинг.
4) альтернативный взгляд на решение задачи. Не всегда предложенное решение будет правильным, и нужно все переделывать. Но узнать о других вариантах и обсудить к примеру будущий рефакторинг точно будет полезно. Отдельно хочется отменить, что иногда лучше прорабатывать решение до написания кода, чтобы избежать потерь времени на код-ревью и переделывание. Примеры: новичок в коданде или просто сложная задача.
5) обмен знаниями о проекте, библиотеках, утилитах и даже языке программирования. Причем узнать что-то новое может и автор кода, и ревьювер.
6) повторяющиеся ошибки\"холиварные" вопросы на код-ревью должны обсуждаться и фиксироваться. И т.об. они являются источником для новых правил в статическом анализаторе кода и в правилах работы над проектом
И как следствие вышесказанного получаем повышение качества кода.
P.S. Далее расскажу про рекомендации для автора и ревьювера, а также про кросс-командное ревью.
#code_review
👍2
8) Ревью кода - не менее сложная задача, чем его написание. Я бы даже сказал более сложная. А чем больше кода - тем сложнее в него вникнуть. Поэтому лучше договориться на берегу о размерах PR в команде и строго требовать соблюдения этого правила. Если договоренностей не было - один раз стоит "помучаться", потом поговорить с автором, но начиная со 2-го отклонять такие PR. Иначе есть риск, что большая часть правок будет пролистана, ведь часто даже не понятно, где ключевые изменения. А в этом случае теряется смысл ревью кода. Еще альтернатива - спросить у автора куда смотреть в первую очередь. Но это все костыли, лучше придерживаться правила по размеру. Я бы его ограничил в 100 строк кода.
9) Я надеюсь, что у вас подключен автоматический prcheck - проверка PR. Если это так - не нужно комментировать то, что уже прокомментировал бот SonarQube. О том, какие замечания SonarQube правим также нужно договорится на берегу и включить в Quality Gate.
Да, о настройках DevOps для код ревью сделаю отдельный пост.
10) Типовые ошибки на код-ревью лучше проговорить со всей командой и вынести в отдельный документ или в SonarQube. Это сэкономит время в будущем.
11) Не забывайте пользоваться галкой игнорировать различие в пробелах, если ваша система для проведения ревью поддерживает такую фичу.
12) Нужно строго соблюдать scope задачи. Как бы ни хотелось поправить еще один, найденный на код-ревью баг - нельзя, это затягивает процесс. Начали с исправления бага, а закончили архитектурным рефакторингом всего сервиса - да, возможно, но не в рамках одного PR) А у нас есть Lead Time и бэклог
13) Если ревью зашло в тупик - подключайте вашего техлида, тимлида, любого авторитетного разработчика. Возможно нужен взгляд со стороны.
14) В абсолютном большинстве PR в целом код хороший. Если это не так - стоит подумать там ли вы работаете) Если вы видите крутое решение - стоит это отметить отдельным комментарием. Если просто хороший код, но с замечаниями - в первом замечании стоит отметить, что "в целом все хорошо, но..."
15) если в PR несколько однотипных ошибок, не стоит оставлять замечания на всех. Это захламляет PR. Лучше отменить одну, максимум две. А далее можно посмотреть - найдет ли автор остальные)
#code_review
9) Я надеюсь, что у вас подключен автоматический prcheck - проверка PR. Если это так - не нужно комментировать то, что уже прокомментировал бот SonarQube. О том, какие замечания SonarQube правим также нужно договорится на берегу и включить в Quality Gate.
Да, о настройках DevOps для код ревью сделаю отдельный пост.
10) Типовые ошибки на код-ревью лучше проговорить со всей командой и вынести в отдельный документ или в SonarQube. Это сэкономит время в будущем.
11) Не забывайте пользоваться галкой игнорировать различие в пробелах, если ваша система для проведения ревью поддерживает такую фичу.
12) Нужно строго соблюдать scope задачи. Как бы ни хотелось поправить еще один, найденный на код-ревью баг - нельзя, это затягивает процесс. Начали с исправления бага, а закончили архитектурным рефакторингом всего сервиса - да, возможно, но не в рамках одного PR) А у нас есть Lead Time и бэклог
13) Если ревью зашло в тупик - подключайте вашего техлида, тимлида, любого авторитетного разработчика. Возможно нужен взгляд со стороны.
14) В абсолютном большинстве PR в целом код хороший. Если это не так - стоит подумать там ли вы работаете) Если вы видите крутое решение - стоит это отметить отдельным комментарием. Если просто хороший код, но с замечаниями - в первом замечании стоит отметить, что "в целом все хорошо, но..."
15) если в PR несколько однотипных ошибок, не стоит оставлять замечания на всех. Это захламляет PR. Лучше отменить одну, максимум две. А далее можно посмотреть - найдет ли автор остальные)
#code_review
👍3
Всем привет!
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение при сохранении в IDEA. Т.об. ревьювер увидит более корректный код, и ему будет проще найти серьезные ошибки, ради которых мы и проводим ревью кода.
2) не стоит отправлять на сервер код, для которого не проверена компилируемость и прохождение тестов. Да, я надеюсь ваш DevOps пайплайн это проверяет, но даже в таком случае это лишняя нагрузка на инфраструктуру, а также лишний цикл ошибка-исправление-запуск CI и замедление скорости попадания кода на тестовую среду и в конечном итоге на ПРОМ.
3) также рекомендую подключить SonarLint в IDEA и чинить баги SonarQube локально. Причины те же, что в предыдущем пункте
4) как я уже писал - ревью кода тяжелая работа. С увеличением размера кода сложность этой работы увеличивается, причем нелинейно. Поэтому декомпозируйте задачу, уменьшайте каждого размер PR. Если изменений по одной декомпозированной фиче все равно достаточно много - разбивайте PR на несколько commit. Рекомендуемый размер PR - не более 100 строк.
5) а чтобы облегчить понимание сути изменений в PR - делайте содержательные комментарии, как именно - я уже описывал в https://t.me/javaKotlinDevOps/81 Если кроме информации в отдельных commit и в тикете, по которому сделан PR, есть еще какая-то высокоуровневая логика, понимание которой важно для ревью - напишите об этом в шапке PR или отдельным комментарием к PR.
6) если ревьювер "пропал" (это плохой, но вполне реальный кейс) - постарайтесь достучаться до него по всем возможным каналам и понять причину отсутствия реакции на PR. Если оперативное ревью невозможно - найдите другого ревьювера.
7) снова о психологии) замечания к PR - это не замечания к вам лично, это замечания к вашему коду. Поэтому относится к замечаниям надо спокойно, возможно с помощью ревьювера вы узнаете что-то новое о сервисе, фреймворке, платформе или даже языке программирования. Ошибки делают все, это нормально. Главное не доводить их до ПРОМа)
8) Если копнуть глубже - ваш код на самом деле не ваш, это код команды. Вся команда отвечает за фичу. Т.е. вы с ревьювером в одной лодке, ваша общая цель - быстро вывести качественную фичу на ПРОМ.
9) как бы ни был велик соблазн пропихнуть в PR еще пару тройку мелких правок - ему нужно сопротивляться. По себе знаю, что это сложно) Но scope PR должен соблюдаться, это сильно упрощает ревью!
10) код-ревью - это диалог, а замечания - не приговор. Ревьювер может что-то не понять, не учесть или просто ошибаться. В этом случае нужно ему вежливо объяснить детали
11) ну и снова скажу что текст - ограниченный способ коммуникации. Чтобы избежать недопонимания - пообщайтесь с ревьювером лично если есть возможность, позвоните ему или поговорите по зуму
12) если PR сложный и\или работа над ним шла долго - по возможности гляньте его сами, перед тем как добавлять ревьюверов. Посмотрите именно как PR, чтобы увидеть что изменилось и что увидит ревьювер. Возможно, найдете какие-то простые баги сами или поймете, что нужно добавить комментарий
13) на замечания ревьювера лучше отвечать правками в коде, после которых они станут неактуальны, чем объяснять что-то в комментариях. Если идею сразу не понял ревьювер - очень может быть что ее не поймут люди, которые будут править этот код через год
14) и еще одна важная вещь: недостаточно просто поправить замечание в коде. Напишите что-то типа "сделано" в ответ на каждое замечание. Скажу по себе - ревьювер вам мысленно скажет спасибо!)
#code_review
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение при сохранении в IDEA. Т.об. ревьювер увидит более корректный код, и ему будет проще найти серьезные ошибки, ради которых мы и проводим ревью кода.
2) не стоит отправлять на сервер код, для которого не проверена компилируемость и прохождение тестов. Да, я надеюсь ваш DevOps пайплайн это проверяет, но даже в таком случае это лишняя нагрузка на инфраструктуру, а также лишний цикл ошибка-исправление-запуск CI и замедление скорости попадания кода на тестовую среду и в конечном итоге на ПРОМ.
3) также рекомендую подключить SonarLint в IDEA и чинить баги SonarQube локально. Причины те же, что в предыдущем пункте
4) как я уже писал - ревью кода тяжелая работа. С увеличением размера кода сложность этой работы увеличивается, причем нелинейно. Поэтому декомпозируйте задачу, уменьшайте каждого размер PR. Если изменений по одной декомпозированной фиче все равно достаточно много - разбивайте PR на несколько commit. Рекомендуемый размер PR - не более 100 строк.
5) а чтобы облегчить понимание сути изменений в PR - делайте содержательные комментарии, как именно - я уже описывал в https://t.me/javaKotlinDevOps/81 Если кроме информации в отдельных commit и в тикете, по которому сделан PR, есть еще какая-то высокоуровневая логика, понимание которой важно для ревью - напишите об этом в шапке PR или отдельным комментарием к PR.
6) если ревьювер "пропал" (это плохой, но вполне реальный кейс) - постарайтесь достучаться до него по всем возможным каналам и понять причину отсутствия реакции на PR. Если оперативное ревью невозможно - найдите другого ревьювера.
7) снова о психологии) замечания к PR - это не замечания к вам лично, это замечания к вашему коду. Поэтому относится к замечаниям надо спокойно, возможно с помощью ревьювера вы узнаете что-то новое о сервисе, фреймворке, платформе или даже языке программирования. Ошибки делают все, это нормально. Главное не доводить их до ПРОМа)
8) Если копнуть глубже - ваш код на самом деле не ваш, это код команды. Вся команда отвечает за фичу. Т.е. вы с ревьювером в одной лодке, ваша общая цель - быстро вывести качественную фичу на ПРОМ.
9) как бы ни был велик соблазн пропихнуть в PR еще пару тройку мелких правок - ему нужно сопротивляться. По себе знаю, что это сложно) Но scope PR должен соблюдаться, это сильно упрощает ревью!
10) код-ревью - это диалог, а замечания - не приговор. Ревьювер может что-то не понять, не учесть или просто ошибаться. В этом случае нужно ему вежливо объяснить детали
11) ну и снова скажу что текст - ограниченный способ коммуникации. Чтобы избежать недопонимания - пообщайтесь с ревьювером лично если есть возможность, позвоните ему или поговорите по зуму
12) если PR сложный и\или работа над ним шла долго - по возможности гляньте его сами, перед тем как добавлять ревьюверов. Посмотрите именно как PR, чтобы увидеть что изменилось и что увидит ревьювер. Возможно, найдете какие-то простые баги сами или поймете, что нужно добавить комментарий
13) на замечания ревьювера лучше отвечать правками в коде, после которых они станут неактуальны, чем объяснять что-то в комментариях. Если идею сразу не понял ревьювер - очень может быть что ее не поймут люди, которые будут править этот код через год
14) и еще одна важная вещь: недостаточно просто поправить замечание в коде. Напишите что-то типа "сделано" в ответ на каждое замечание. Скажу по себе - ревьювер вам мысленно скажет спасибо!)
#code_review
Telegram
(java || kotlin) && devOps
Всем привет!
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария…
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария…
Всем привет!
Поговорим про инфраструктуру и DevOps, не относящуюся напрямую к ревью кода, но сильно облегчающую его проведение.
1) обязательно должна быть автоматическая проверка Pull Request (PR) на компилируемость, прохождение тестов и статический анализ кода. Одно из распространенных названий этой процедуры - prcheck. Те ошибки, что могут найти роботы - должны искать роботы)
2) обязательно должна автоматически запускаться контрольная сборка с запуском тестов после вливания кода в master\develop\release. Так мы как можно раньше локализуем проблемы, которые могут возникнуть после слияния. Несмотря на наличие prcheck и ручное ревью после слияния вполне могут появится ошибки. Особенно важен этот и предыдущий пункт если у вас не микросервис и над кодом работают несколько команд. Т.к. в этом случае ошибка, попавшая в master, заблокирует работу всех команд.
3) рекомендую сделать документ с требованиями по коду (guideline), которые невозможно автоматизировать. То, что можно автоматизировать - описывать текстом не нужно, а следует добавить в статический анализатор. SonarQube, номер один на этом рынке, дает нам кучу правил из коробки, кроме того есть дополнительные плагины с правилами, например, https://github.com/spotbugs/sonar-findbugs, а также можно создавать свои правила. Правила нужно поддерживать его в актуальном состоянии и строго им следовать. Это может быть файл в формате Markdown (.md) в Bitbucket, тогда с ним тоже можно работать через PR, либо статья в формате wiki. Главное чтобы четко было понятно, где лежит последняя версия правил
4) также должны быть правила наименования веток, PR и формата commit
5) в случае монолита будет полезным механизм, определяющий какого рода код изменился и автоматически добавляющий в PR ответственных за данную функциональную область
6) как я уже говорил ранее может быть полезен отдельный чатик для призыва ревьюверов в PR) email уведомления тоже полезны, но почту читают реже, письма могут попасть в спам
#code_review
Поговорим про инфраструктуру и DevOps, не относящуюся напрямую к ревью кода, но сильно облегчающую его проведение.
1) обязательно должна быть автоматическая проверка Pull Request (PR) на компилируемость, прохождение тестов и статический анализ кода. Одно из распространенных названий этой процедуры - prcheck. Те ошибки, что могут найти роботы - должны искать роботы)
2) обязательно должна автоматически запускаться контрольная сборка с запуском тестов после вливания кода в master\develop\release. Так мы как можно раньше локализуем проблемы, которые могут возникнуть после слияния. Несмотря на наличие prcheck и ручное ревью после слияния вполне могут появится ошибки. Особенно важен этот и предыдущий пункт если у вас не микросервис и над кодом работают несколько команд. Т.к. в этом случае ошибка, попавшая в master, заблокирует работу всех команд.
3) рекомендую сделать документ с требованиями по коду (guideline), которые невозможно автоматизировать. То, что можно автоматизировать - описывать текстом не нужно, а следует добавить в статический анализатор. SonarQube, номер один на этом рынке, дает нам кучу правил из коробки, кроме того есть дополнительные плагины с правилами, например, https://github.com/spotbugs/sonar-findbugs, а также можно создавать свои правила. Правила нужно поддерживать его в актуальном состоянии и строго им следовать. Это может быть файл в формате Markdown (.md) в Bitbucket, тогда с ним тоже можно работать через PR, либо статья в формате wiki. Главное чтобы четко было понятно, где лежит последняя версия правил
4) также должны быть правила наименования веток, PR и формата commit
5) в случае монолита будет полезным механизм, определяющий какого рода код изменился и автоматически добавляющий в PR ответственных за данную функциональную область
6) как я уже говорил ранее может быть полезен отдельный чатик для призыва ревьюверов в PR) email уведомления тоже полезны, но почту читают реже, письма могут попасть в спам
#code_review
GitHub
GitHub - spotbugs/sonar-findbugs: SpotBugs plugin for SonarQube
SpotBugs plugin for SonarQube. Contribute to spotbugs/sonar-findbugs development by creating an account on GitHub.
👍4
Всем привет!
До сих пор говоря про ревью кода, я акцентировал внимание на команде. Когда же может быть полезно кросс-командное ревью.
Основной кейс, когда внешнее ревью обязательно - над общей кодовой базой ведет работу несколько команд. Внешний ревьювер здесь играет роль независимого аудитора. Ведь правки одной команды могут что-то сломать для другой команды. Или новая команда может нарушить единообразие архитектуры.
Привлечение ревьюверов из другой команды может быть полезно, если не хватает опыта по используемой платформе или технологии.
Также кросс-ревью может быть полезно, если модули, выпускаемые командами, интегрированы друг с другом. С одной стороны может показаться, что это нарушает инкапсуляцию, которую дает нам API. Но бывают случае, когда между "соседними" командами возникает недопонимание - почему API сделано именно так или почему его стали использовать именно таким образом. Для начала в таких случаях стоит собраться и обсудить API. Если же этого мало - возможно, погружение в код соседей поможет понять причины.
Еще один вариант призыва внешнего ревьювера(ов), назовем его "пожарная команда" - если в команде в данный момент не хватает ревьюверов по причине отпуска, увольнения или набора новой команды.
И последний кейс - внешний ревьювер как арбитр для разрешения споров внутри команды. Как правило это техлид или просто опытный разработчик.
#code_review
До сих пор говоря про ревью кода, я акцентировал внимание на команде. Когда же может быть полезно кросс-командное ревью.
Основной кейс, когда внешнее ревью обязательно - над общей кодовой базой ведет работу несколько команд. Внешний ревьювер здесь играет роль независимого аудитора. Ведь правки одной команды могут что-то сломать для другой команды. Или новая команда может нарушить единообразие архитектуры.
Привлечение ревьюверов из другой команды может быть полезно, если не хватает опыта по используемой платформе или технологии.
Также кросс-ревью может быть полезно, если модули, выпускаемые командами, интегрированы друг с другом. С одной стороны может показаться, что это нарушает инкапсуляцию, которую дает нам API. Но бывают случае, когда между "соседними" командами возникает недопонимание - почему API сделано именно так или почему его стали использовать именно таким образом. Для начала в таких случаях стоит собраться и обсудить API. Если же этого мало - возможно, погружение в код соседей поможет понять причины.
Еще один вариант призыва внешнего ревьювера(ов), назовем его "пожарная команда" - если в команде в данный момент не хватает ревьюверов по причине отпуска, увольнения или набора новой команды.
И последний кейс - внешний ревьювер как арбитр для разрешения споров внутри команды. Как правило это техлид или просто опытный разработчик.
#code_review
👍4
Всем привет!
Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit
Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.
Что думаете?
#git #code_review
Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit
Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.
Что думаете?
#git #code_review
dhwthompson.com
My favourite Git commit
I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit.
Всем привет!
Ну и наконец немного расскажу о плохих практиках ревью кода.
Суббота. Баг на ПРОМе. Подключение из дома. Какой-то странный код, напоминающий спагетти. Много нецензурных выражений и энергичных пожеланий в адрес его автора)))
Не надо до такого доводить.
#code_review #joke
Ну и наконец немного расскажу о плохих практиках ревью кода.
Суббота. Баг на ПРОМе. Подключение из дома. Какой-то странный код, напоминающий спагетти. Много нецензурных выражений и энергичных пожеланий в адрес его автора)))
Не надо до такого доводить.
#code_review #joke
Всем привет!
В продолжение темы функциональности IDEA и подготовки кода к code review, см. https://t.me/javaKotlinDevOps/148
Некоторые проверки и исправления можно подвесить на одно из двух событий:
1) на сохранение файла: Alt-Alt - Actions on Save. Рекомендую включить Reformat code и Optimize import.
2) перед commit на Git сервер - открыть окно Commit (Ctrl-K) и нажать там шестеренку. Рекомендую включить Analyze code, Check TODO и если выполнение тестов занимает приемлемое время - то еще и прогон тестов.
Легко заметить, что набор опций в обоих случаях похож, но на сохранении можно включить только те, где фиксы применяются без участия человека. В частности и Cleanup, и Analyze выполняют правила из набора инспекций (Inspections), только в первом случае включаются только те правила, где есть quick fixes, которые можно применить автоматически.
Насчет Cleanup - IMHO его вполне можно включить на commit, главное перепроверить набор активных правил: Shift-Shift - Inspections, а там включить фильтр Cleanup only. К слову - там еще есть профили с набором правил, можно добавить свой.
И еще важный момент - инспекции из IDEA можно запустить из командной строки, и т.об. включить в CI процесс: https://www.jetbrains.com/help/idea/command-line-code-inspector.html
Они частично повторяют проверки SonarQube, но не идентичны им.
#idea #code_review #clean_code #git
В продолжение темы функциональности IDEA и подготовки кода к code review, см. https://t.me/javaKotlinDevOps/148
Некоторые проверки и исправления можно подвесить на одно из двух событий:
1) на сохранение файла: Alt-Alt - Actions on Save. Рекомендую включить Reformat code и Optimize import.
2) перед commit на Git сервер - открыть окно Commit (Ctrl-K) и нажать там шестеренку. Рекомендую включить Analyze code, Check TODO и если выполнение тестов занимает приемлемое время - то еще и прогон тестов.
Легко заметить, что набор опций в обоих случаях похож, но на сохранении можно включить только те, где фиксы применяются без участия человека. В частности и Cleanup, и Analyze выполняют правила из набора инспекций (Inspections), только в первом случае включаются только те правила, где есть quick fixes, которые можно применить автоматически.
Насчет Cleanup - IMHO его вполне можно включить на commit, главное перепроверить набор активных правил: Shift-Shift - Inspections, а там включить фильтр Cleanup only. К слову - там еще есть профили с набором правил, можно добавить свой.
И еще важный момент - инспекции из IDEA можно запустить из командной строки, и т.об. включить в CI процесс: https://www.jetbrains.com/help/idea/command-line-code-inspector.html
Они частично повторяют проверки SonarQube, но не идентичны им.
#idea #code_review #clean_code #git
Telegram
(java || kotlin) && devOps
Всем привет!
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение…
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение…
👍2
Всем привет!
Я периодически провожу код-ревью. И лично у меня ранее был страх - а вдруг я не замечу что-то важное. Смотришь PR, явных ошибок не видно, но апрув "не ставится". А когда Pull Request (PR) очень большой - даже не хочется его открывать, т.к. примерно понимаешь, какой объем информации придется "загрузить в голову", чтобы точно можно было сказать - да, здесь ошибок нет. Крайний случай слишком тщательного подхода к код-ревью, встреченный мной на практике - когда разработчик просит освободить его от других задач, чтобы он мог полностью погрузиться в ревью: прочитать аналитику, изучить архитектуру кода...
Но как я уже писал в https://t.me/javaKotlinDevOps/146 - скорость прохождения код-ревью очень важна для быстрого выявления ошибок и предотвращения merge конфликтов. Что же тут можно сделать?
Во-первых я предлагаю рассматривать код-ревью как еще одну из сетей для поиска проблем в коде. Есть и другие сети - валидация в IDEA, модульные и интеграционные тесты, CI pipeline, SonarQube и другие инструменты статистического анализа, включая сканирования на уязвимости. Это если говорить о тех, что работают до код-ревью. После - регресс, тесты нового функционала, нагрузочное тестирование, демо (приемо-сдаточные испытания), канареечное развертывание, chaos engineering... Т.е. код-ревью - полезно, но это не последний рубеж обороны.
Второй момент: когда я провожу ревью - я вижу те проблемы, которые считаю важным. Т.е. мой взгляд субъективен, на него влияет мой опыт, и особенно проблемы, с которыми я сталкивался ранее. Да, важно то, что мой взгляд отличается от взгляда автора кода. Это позволяет найти те ошибки, которые автор из-за замыленности не увидел. Но с другой стороны - что-то я в принципе увидеть не могу. В этом плане будет полезно иметь несколько ревьюверов, внутри и кросс командное ревью.
Итого: ручное код-ревью полезно, к нему не стоит подходить формально, но не надо забывать про время. Исключения - когда время не критично. Например, это ревью кода новичков. Там важно передать текущие практики и требования к проекту.
#code_review
Я периодически провожу код-ревью. И лично у меня ранее был страх - а вдруг я не замечу что-то важное. Смотришь PR, явных ошибок не видно, но апрув "не ставится". А когда Pull Request (PR) очень большой - даже не хочется его открывать, т.к. примерно понимаешь, какой объем информации придется "загрузить в голову", чтобы точно можно было сказать - да, здесь ошибок нет. Крайний случай слишком тщательного подхода к код-ревью, встреченный мной на практике - когда разработчик просит освободить его от других задач, чтобы он мог полностью погрузиться в ревью: прочитать аналитику, изучить архитектуру кода...
Но как я уже писал в https://t.me/javaKotlinDevOps/146 - скорость прохождения код-ревью очень важна для быстрого выявления ошибок и предотвращения merge конфликтов. Что же тут можно сделать?
Во-первых я предлагаю рассматривать код-ревью как еще одну из сетей для поиска проблем в коде. Есть и другие сети - валидация в IDEA, модульные и интеграционные тесты, CI pipeline, SonarQube и другие инструменты статистического анализа, включая сканирования на уязвимости. Это если говорить о тех, что работают до код-ревью. После - регресс, тесты нового функционала, нагрузочное тестирование, демо (приемо-сдаточные испытания), канареечное развертывание, chaos engineering... Т.е. код-ревью - полезно, но это не последний рубеж обороны.
Второй момент: когда я провожу ревью - я вижу те проблемы, которые считаю важным. Т.е. мой взгляд субъективен, на него влияет мой опыт, и особенно проблемы, с которыми я сталкивался ранее. Да, важно то, что мой взгляд отличается от взгляда автора кода. Это позволяет найти те ошибки, которые автор из-за замыленности не увидел. Но с другой стороны - что-то я в принципе увидеть не могу. В этом плане будет полезно иметь несколько ревьюверов, внутри и кросс командное ревью.
Итого: ручное код-ревью полезно, к нему не стоит подходить формально, но не надо забывать про время. Исключения - когда время не критично. Например, это ревью кода новичков. Там важно передать текущие практики и требования к проекту.
#code_review
Telegram
(java || kotlin) && devOps
Всем привет!
Продолжаю тему code review, поговорим про рекомендации ревьюверам.
1) работа с PR - это как правило текстовая коммуникация: Bitbucket, Gitlab, ... При таком общении теряется часть информации - тон, эмоциональная окраска... Следовательно, фразу…
Продолжаю тему code review, поговорим про рекомендации ревьюверам.
1) работа с PR - это как правило текстовая коммуникация: Bitbucket, Gitlab, ... При таком общении теряется часть информации - тон, эмоциональная окраска... Следовательно, фразу…
🔥5
Сколько багов в час делает разработчик?
И снова цитата из Совершенного кода:
Хоть ты код не пиши!)))
А если серьёзно - рулит код-ревью и тесты. Именно в таком порядке.
Типичный концер процент нахождения багов в ПО при использовании различных практик из той же книги:
Неформальный обзор дизайна (тех. проекта) 35%
Формальные инспекции дизайна (тех. проекта) 55%
Моделирование и прототипирование 65%
Неформальный обзор кода (code review) 25%
Самостоятельная проверка код 35%
Формальные инспекции кода 60%
Юнит-тестирование 30%
Регрессионное тестирование 25%
Тестирование новой функции (компонента) 30%
Интеграционное тестирование 35%
Системное тестирование 40%
Бета-тестирование (<10 тестеров) 35%
Бета-тестирование (>1000 тестеров) 75%
Что бросается в глаза:
1) очень высокая эффективность ревью кода. Что понятно, т.к. получаем shift left и, главное, при код-ревью мы не просто находим баг, но ещё и его причину, в отличие от тестирования. Т.е. не тратим время на отладку.
2) формальные ревью сильно эффективнее неформальных. Немного странно на первый взгляд. Но объяснение есть - формальное = выделено время + есть чек-лист + нужен отчёт. Т.е. его сложно провести "формально" (да, велик и могуч русский язык))) Т.е. правильно было бы назвать его глубокое код-ревью
3) Хорошая эффективность у самостоятельного ревью, а его провести проще всего. Например, при подготовке pull request. И снова понятно почему - своей код ты уже знаешь, главное чтобы между кодированием и ревью прошло время, чтобы сменился фокус.
4) низкая эффективность unit тестов, сравнимая с регрессом и тестированием нового функционала. Это странно. Но если подумать - TDD тогда ещё только появилось, да и сейчас его проникновение оставляет желать лучшего. А без него UT - это в основном регресс. И немного тестирование нового функционала, но методом "прозрачного" ящика.
5) высокие цифры у прототипирования и бета-тестах на большом числе людей. Пр сути они связаны - это проверка гипотезы и реализации. Провести сложно, но эффект похоже есть.
Ну и банальная вещь - ни один метод сам по себе не даёт 100%. Только в комплекте.
#code_review #quality_assurance
И снова цитата из Совершенного кода:
Исследования, проведенные в Институте
разработки П0 (Software Engincering Institute), показали, что разработчики допускают в среднем
от 1 до З дефектов в час при проектировании и от 5 до 8 дефектов в час при кодировании
(Humphrey, 1997). Ясно, что устранение дефектов — обязательное условие эффективного конструирования.
Хоть ты код не пиши!)))
А если серьёзно - рулит код-ревью и тесты. Именно в таком порядке.
Типичный концер процент нахождения багов в ПО при использовании различных практик из той же книги:
Неформальный обзор дизайна (тех. проекта) 35%
Формальные инспекции дизайна (тех. проекта) 55%
Моделирование и прототипирование 65%
Неформальный обзор кода (code review) 25%
Самостоятельная проверка код 35%
Формальные инспекции кода 60%
Юнит-тестирование 30%
Регрессионное тестирование 25%
Тестирование новой функции (компонента) 30%
Интеграционное тестирование 35%
Системное тестирование 40%
Бета-тестирование (<10 тестеров) 35%
Бета-тестирование (>1000 тестеров) 75%
Что бросается в глаза:
1) очень высокая эффективность ревью кода. Что понятно, т.к. получаем shift left и, главное, при код-ревью мы не просто находим баг, но ещё и его причину, в отличие от тестирования. Т.е. не тратим время на отладку.
2) формальные ревью сильно эффективнее неформальных. Немного странно на первый взгляд. Но объяснение есть - формальное = выделено время + есть чек-лист + нужен отчёт. Т.е. его сложно провести "формально" (да, велик и могуч русский язык))) Т.е. правильно было бы назвать его глубокое код-ревью
3) Хорошая эффективность у самостоятельного ревью, а его провести проще всего. Например, при подготовке pull request. И снова понятно почему - своей код ты уже знаешь, главное чтобы между кодированием и ревью прошло время, чтобы сменился фокус.
4) низкая эффективность unit тестов, сравнимая с регрессом и тестированием нового функционала. Это странно. Но если подумать - TDD тогда ещё только появилось, да и сейчас его проникновение оставляет желать лучшего. А без него UT - это в основном регресс. И немного тестирование нового функционала, но методом "прозрачного" ящика.
5) высокие цифры у прототипирования и бета-тестах на большом числе людей. Пр сути они связаны - это проверка гипотезы и реализации. Провести сложно, но эффект похоже есть.
Ну и банальная вещь - ни один метод сам по себе не даёт 100%. Только в комплекте.
#code_review #quality_assurance
Чем заменить сложный if?
В рамках борьбы за читаемость кода, конечно же.
Ответ - табличным методом.
Название, возможно, неизвестное, но многие этим подходом пользовались, не зная как его назвать.
Но ближе к коду)
Вот есть у нас, предположим, такое условие:
Сложно, т.к. много кода. Но вот так намного проще:
Собственно таблица - это коллекция, из которой по ключу получаем нужное значение в одну строчку без if.
Хорошо. Но не всегда ключ можно прямо замапить на значение.
Возможно, ключ однозначно преобразуется в требуемый. Тогда получаем табличный доступ с преобразованием:
Еше кейс. Предположим, у нас целевое значение зависит от положения точки в диапазоне, тогда получаем табличный метод со ступенчатым доступом:
Ну и возвращать можно не только значение, но и лямбду:
Важный плюс такого решения - "таблица" легко выносится в файл при необходимости настройки.
Или любой внешний источник.
Таблица может быть мапой, а не только массивом или списком.
P.S. Да, это снова Совершенный код)
#code_review #code
В рамках борьбы за читаемость кода, конечно же.
Ответ - табличным методом.
Название, возможно, неизвестное, но многие этим подходом пользовались, не зная как его назвать.
Но ближе к коду)
Вот есть у нас, предположим, такое условие:
int getDaysInMonth(int month) {
if (month == 1) return 31;
else if (month == 2) return 28;
else if (month == 3) return 31;
// ... ещё 9 веток
}Сложно, т.к. много кода. Но вот так намного проще:
private static final int[] DAYS_IN_MONTH = {
31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
};
int getDaysInMonth(int month) {
return DAYS_IN_MONTH[month];
}Собственно таблица - это коллекция, из которой по ключу получаем нужное значение в одну строчку без if.
Хорошо. Но не всегда ключ можно прямо замапить на значение.
Возможно, ключ однозначно преобразуется в требуемый. Тогда получаем табличный доступ с преобразованием:
public int resolveMonth(LocalDate date) {
return date.getMonthValue();
}
int getDaysInMonth(LocalDate date) {
return DAYS_IN_MONTH[resolveMonth(date)];
}Еше кейс. Предположим, у нас целевое значение зависит от положения точки в диапазоне, тогда получаем табличный метод со ступенчатым доступом:
@Getter
@RequiredArgsConstructor
enum Zone {
NIGHT ("Ночная", 2.15),
SEMI_PEAK ("Полупиковая", 4.30),
PEAK ("Пиковая", 6.45);
private final String label;
private final double ratePerKwh;
}
private static final int[] HOUR_THRESHOLDS = { 6, 9, 16, 20, 22, 23 };
private static final Zone[] TARIFF_TABLE = { Zone.NIGHT, Zone.PEAK, Zone.SEMI_PEAK, Zone.PEAK, Zone.SEMI_PEAK, Zone.NIGHT };
private static Zone lookupZone(int hour) {
for (int i = 0; i < HOUR_THRESHOLDS.length; i++) {
if (hour <= HOUR_THRESHOLDS[i]) {
return TARIFF_TABLE[i];
}
}
}
public static double getZonePrice(int hour) {
var zone = lookupZone(hour);
return zone.getRatePerKwh();
}
Ну и возвращать можно не только значение, но и лямбду:
private static final Map<String, Consumer<String>> HANDLERS = Map.of(
"ERROR", msg -> System.err.println("[ERROR] " + msg),
"WARNING", msg -> System.out.println("[WARN] " + msg),
"INFO", msg -> System.out.println("[INFO] " + msg),
"DEBUG", msg -> { /* no-op in prod */ }
);
public static void dispatch(String level, String message) {
HANDLERS.getOrDefault(level, m -> System.out.println("[UNKNOWN] " + m))
.accept(message);
}
Важный плюс такого решения - "таблица" легко выносится в файл при необходимости настройки.
Или любой внешний источник.
Таблица может быть мапой, а не только массивом или списком.
P.S. Да, это снова Совершенный код)
#code_review #code
👍2
Ты что такое или как AI ревьювит код?
Изучаю сейчас плагин superpowers, который включает в себя много чего интересного, и в т.ч. и код-ревью.
Вижу два интересных момента.
Первый. Модель постоянно берет куски нового кода и запускает их с каким-то параметрами, например, с краевыми случаями.
Для начала куски метода, потом методы целиком.
Это явно плюс в карму AI, т.к. живому человеку это делать долго и дорого.
Кто-то так делал вообще?)
Надо отметить, что в Java это еще и сложнее сделать, чем в том же Python или JS, хотя подвижки есть - https://t.me/javaKotlinDevOps/412
Тут видится хорошая область, где AI ревьювер может дополнить человека.
Для демонстрации второго момента приведу кусок кода - это лог выполнения скрипта, который агент прогонял на этапе ревью. Код python, но он простой:
На первый взгляд бред какой-то. Код ничего не делает, только печатает очевидные вещи, частично как комментарии, частично через print.
Но если подумать - похоже модель проверяет логику на отсутствие ошибки "ошибки на единицу".
Проговаривая ее для себя. Ну и возможно для меня, но видится в первую очередь для себя.
Т.к. это все попадает в историю диалога с LLM и далее в ее контекст, влияющие на результат выполнения последующих запросов.
С таким проговариванием человек справляется успешно, но радует, что модель тоже, хоть и вот так, странненько.
P.S. Ошибка между прочим известная, не у каждой ошибки своя статья в wikipedia есть https://ru.wikipedia.org/wiki/Ошибка_на_единицу
P.P.S. Но импорты явно лишние)
P.P.P.S. Риски самому перестать думать возрастают)))
#ai #code-review
Изучаю сейчас плагин superpowers, который включает в себя много чего интересного, и в т.ч. и код-ревью.
Вижу два интересных момента.
Первый. Модель постоянно берет куски нового кода и запускает их с каким-то параметрами, например, с краевыми случаями.
Для начала куски метода, потом методы целиком.
Это явно плюс в карму AI, т.к. живому человеку это делать долго и дорого.
Кто-то так делал вообще?)
Надо отметить, что в Java это еще и сложнее сделать, чем в том же Python или JS, хотя подвижки есть - https://t.me/javaKotlinDevOps/412
Тут видится хорошая область, где AI ревьювер может дополнить человека.
Для демонстрации второго момента приведу кусок кода - это лог выполнения скрипта, который агент прогонял на этапе ревью. Код python, но он простой:
{"command":"python -c \"
import pandas as pd
import numpy as np
# Probe: does max_pos + 1 in rng.integers allow the window to exceed bounds?
# n = 10, duration = 3, max_pos = 7
# rng.integers(0, max_pos + 1) -> [0, 7] inclusive
# pos=7: index[7], window is [index[7], index[7]+3min)
# If index has exactly 10 rows (0..9), this is index[7], index[8], index[9] -> 3 rows OK
# pos=8: This would only happen if max_pos=8, which requires n-duration=8, so n=11 - fine
print('Boundary logic: max_pos = n - duration_minutes')
print('rng.integers(0, max_pos+1) is [0, max_pos] inclusive')
print('At max_pos, window covers indices [max_pos..max_pos+duration-1], which is valid')
print()
\"
","description":"Verify off-by-one and boundary correctness in random placement logic"},На первый взгляд бред какой-то. Код ничего не делает, только печатает очевидные вещи, частично как комментарии, частично через print.
Но если подумать - похоже модель проверяет логику на отсутствие ошибки "ошибки на единицу".
Проговаривая ее для себя. Ну и возможно для меня, но видится в первую очередь для себя.
Т.к. это все попадает в историю диалога с LLM и далее в ее контекст, влияющие на результат выполнения последующих запросов.
С таким проговариванием человек справляется успешно, но радует, что модель тоже, хоть и вот так, странненько.
P.S. Ошибка между прочим известная, не у каждой ошибки своя статья в wikipedia есть https://ru.wikipedia.org/wiki/Ошибка_на_единицу
P.P.S. Но импорты явно лишние)
P.P.P.S. Риски самому перестать думать возрастают)))
#ai #code-review
Telegram
(java || kotlin) && devOps
Можно ли быстро сделать и запустить single-file прототип на Java?
Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.…
Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.…
🔥2