Всем привет!

Недавно посмотрел интересное видео про управление техдолгом https://youtu.be/pvZDcytPU3w

На самом деле видео не про управление техдолгом в целом. Там нет архитектурного техдолга, технологического. Оно про техдолг, возникающий при реализации конкретной фичи - когда появляется TODO в коде.

Речь идет о извечной проблеме разработчика - "сделать все идеально". Но идеально может потребовать дни или даже недели. А у нас Agile, спринты в 2 недели, бизнес ждет свою фичу.
Что предлагается:

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

2. если при реализации выясняется, что фичу невозможно сделать в запланированные сроки, а их можно прикинуть исходя из длины спринта, числа задач и их оценки - нужно сделать часть фичи, допускающую продвижение дальше команды. Опять же - декомпозировать сложно, но итеративно это получается лучше.

3. расставить по коду подробные TODO, рассказать команде что сделано, а что нет и почему, и влить доработку. Т.об. мы гарантировано получаем большую прозрачность. А если правильно удалось определить, что блокер для команды - еще и лучший Lead Time.

4. далее некий робот сканирует код, находит TODO и делает из них таски в вашем трекере

5. таски будут оценены на очередном планировании и взяты в работу, возможно другим разработчиком

   Самое интересное - для одной и той же задачи пункты 1-5 могут повторяться. Наверное, если это происходит в 5-й раз - стоит детальнее взглянуть на задачу. Похоже она сильно влияет на архитектуру.

   Итого - идея мне нравится!

Всем привет!

TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций.

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

Что там может быть:

• входные данные -> выходные данные

• обработка возможных исключений

• повторный запуск: идемпотентность, докат или ошибка

• параллельный запуск

• поведение при различных значениях настроек

• поведение при различных настройках кодировки, языка, часового пояса, файловой системы

• эффекты из-за отсутствия транзакционности (там где ее нет) ...

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

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

Всем привет!

Нашел отличное видео по исключениям в Java https://www.youtube.com/watch?v=UIbbNsta2UE

Краткий конспект, не влияющий на рекомендацию посмотреть видео:

1. затраты на выбрасывание исключений конечно же есть, но если исключение в вашем сервисе = ошибке, то проблем с производительностью не будет. Т.к. частота ошибок сильно меньше RPS.

2. если ваши исключение выбрасывается в строго определенном месте кода - можно убрать из него stacktrace, это неплохо увеличит производительность. На самом деле если просто не обращаться к stacktrace, то она уже увеличится, но для надежности лучше вообще не прикреплять stacktrace. Или использовать StackWalking API https://www.baeldung.com/java-9-stackwalking-api

3. самый спорный и опасный совет для предыдущего кейса - закэшировать исключение, так его выброс будет еще быстрее. Но по сути это старый добрый "go to". Использовать с осторожностью!)

4. исключение должно содержать весь контекст ошибки, в идеале с предложениями по ее исправлению. Чтобы структурировать информацию об ошибке есть библиотека https://github.com/melix/jdoctor Активность в репозитории слабенькая, но сама идея мне нравится.

5. как известно, есть исключения, которые не стоит ловить - например, OOM и StackOverflow. А если очень хочется OOM поймать?) Тогда нужно заранее создать необходимые для сохранения информации о проблеме объекты, ведь после OOM памяти уже не будет.

   А еще из интересного - после просмотра видео станет понятно, как работает SneakyThrows в Lombok

Всем привет!

Наткнулся на интересную статью про различные типы разработчиков https://habr.com/ru/articles/135865/ Тут не про уровень - джун, миддл, сеньор, - а про разные названия должностей и что за этим стоит. Кодер, хакер, разработчик, инженер, архитектор...
В целом классификация норм, но хотел бы подсветить пару моментов.

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

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

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

Разница между разработчиком и инженером. На первый взгляд особой разницы не видно. Очевидно, что диплом не делает инженера лучшим спецом, чем разработчик. Но рассмотрим ПО для критической инфраструктуры: авиаперевозки, космос, атомные станции, медицина.
ПО нужно сертифицировать. А раз так, то и сертификация разработчика, который это ПО пишет, выглядит логичной. Как минимум есть подтверждение, что он сдавал экзамен по чему-то важному, что требуется в данной отрасли. Но речь именно про специализированные экзамены, а не про программирование на Java или не дай бог Pascal)

Но первая мысль, которая мне пришла в голову после прочтения - главное, чтобы ChatGPT не сделал из разработчика кодера)))

Всем привет!

Попробую немного развить тему с законом Конвея из предыдущего поста. Я достаточно много раз за свою карьеру в разработке сталкивался с упоминанием данного закона. Уже не вспомню где конкретно, но у меня осталось стойкое впечатление, что отношение к нему было как к неизбежности, с которой нужно бороться. Способы борьбы можно вспомнить такие:

• корпоративные архитекторы, выравнивающие архитектурные шаблоны

• внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования

• техрадар как способ ограничить технологический стек

• единые практики найма и онбординга

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

Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации. Причем если верить wiki, а в данном случае IMHO это можно делать, закон был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

P.S. Интересно и то, что в 1967 году разработка как отрасль уже достигла уровня, позволяющего формулировать определенные принципы.

Всем привет!

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

Плохо, когда генерируемый код похож на правильный. Или даже очень похож. Тогда ты принимаешь рекомендацию, мысленно помечаешь задачу как выполненную и пытаешься идти дальше. А приложение падает в неожиданном месте. Пример из моей практики - сгенерированный shell скрипт. Выглядит как настоящий, отличается одним отсутствующим пробелом. Такие же проблемы возможны с RegExp. Да и с обычным кодом, например, если в цепочке вызовов выбран один неправильный метод.

Да, часто ошибки находятся благодаря тестам. И конечно же сгенерированный код надо проверять. Но, например, есть тривиальный код, который с одной стороны не хочется писать самому, т.к. он тривиальный, а с другой стороны он часто покрывается не модульными, а интеграционными тестами. А condition coverage у интеграционных тестов по понятным причинам хуже, чем у модульных.

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