Red Collar | DEV

«5 почему». Поиск причин проблемы.

Метод «5 почему» заключается в том, чтобы докопаться до сути проблемы. Нужно задать вопрос, начав со слова «почему», и получить ответ, после чего переформулировать полученный ответ в новый вопрос, добавив к нему «почему».

🧶 Пример:
1. Почему мы не отправили новостную рассылку?
— Потому что релиз не был сделан вовремя.
2. Почему релиз не был сделан вовремя?
— Потому что разработчики все еще работают над новыми фичами.
3. Почему они все еще работают над новыми фичами?
— Один из новых разработчиков не знает регламентов.
4. Почему новый разработчик не знает регламентов?
— Он не был обучен должным образом.
5. Почему он не был обучен должным образом?
— Потому что его руководитель считает, что новых сотрудников не нужно тщательно обучать, и они должны учиться во время работы.

Можно заметить, что первоначальная причина проблемы оказалось совершенно отличной от той, которая предполагалась изначально. Кроме того, очевидно, что проблема носит не технический характер, а процессуальный. Это типично, потому что мы часто сосредотачиваемся на продуктовой части проблемы, пренебрегая человеческим фактором.

Таким образом, метод «5 почему» направлен на глубокое изучение определенной проблемы до тех пор, пока не будет найдена настоящая причина.

Главная особенность и преимущества метода — простота. Пять — это среднее число, достаточное для получения ответа. Но у вас может быть и три, и двадцать вопросов.
#rdclr_QA #product

Принципы менеджмента Э. Деминга, продолжение цикла, 8-14.

В целом, рекомендую к прочтению его полную книгу «Выход из кризиса». Она поможет в освоении новой философии менеджмента через отказ от традиционных методов. Но для скорости продолжаю (и заканчиваю) выжимку принципов, которые вынес из ее.

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

🔓 9. Разрушайте барьеры между подразделениями.
Люди из различных подразделений — аналитики, разработчики, тестировщики, менеджеры должны работать в командах, чтобы устранять проблемы, которые возникают в процессе разработки ПО.

🔦 10. Откажитесь пот пустых призывов, требующих бездефектной работы, но не сообщающих о методах её достижения.
Такие призывы вызывают лишь брезгливое отношение; основная масса проблем низкого качества и производительности связана с системой, и поэтому их решения находятся за пределами рядовых сотрудников.

🧮 11. Откажитесь от количественных оценок работы.
Если система, в которой вы работаете, стабильна, нет нужны определять цель повышения производительности и качества в цифрах — все равно вы получите только то, что может дать сама система. Если система нестабильна, то снова нет смысла определять цель в цифрах, поскольку нет возможности узнать, что выдаст система — о ее возможностях нельзя сказать. А значит, запланированная цель, скорее всего, не будет достигнута. Управление, которое основано на количественных показателя, — это попытка управлять, не зная, что нужно сделать.

👨🏻‍💻 12. Устраните барьеры, которые не позволяют людям гордиться своей квалификацией.
Это предполагает, помимо всего прочего, отказ от ежегодных аттестаций и методов управления целями. И снова обязанности менеджеров должны быть перенесены с достижений чисто количественных показателей — на качественные.

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

🦾 14. Вовлеченность высшего руководства и его действия. Четко установите обязанности высшего руководства в сфере качества. Создайте структуру, которая будет ежедневно давать импульс для продвижения рассмотренным выше тринадцати принципам, и действуйте, чтобы осуществить преобразование. Поддержки здесь недостаточно, нужны конкретные действия.

#rdclr_QA #product

Разберем принципы менеджмента Э. Деминга — первые 7

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

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

🎯 1. Постоянство цели.
Будьте неизменно тверды и постоянны в достижении поставленной цели. Распределяйте ресурсы таким образом, чтобы обеспечить долговременные цели и потребности, а не сиюминутную прибыль.

♟ 2. Новая философия качества.
Примите ее. Она должна быть абсолютной: недопустимость задержек, дефектов, ошибок и брака в работе.

💎 3. Изменение отношения к контролю.
Исключите потребность в массовом контроле, как способе достижения приемлемого уровня качества. Достигайте высокого результата путем встраивания качества в производимое ПО и процессы, сделав качество неотъемлемой их характеристикой.

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

🚀 5. Улучшайте каждый процесс.
Сегодня и всегда улучшайте все процессы анализа, планирования, разработки, тестирования, поддержки. Выискивайте проблемы, чтобы совершенствовать все этапы разработки ПО, повышайте качество и производительность и, таким образом, постоянно уменьшайте издержки.

🎱 6. Учите всех, в том числе и менеджмент.
Введите в практику современные подходы к подготовке и переподготовки всех сотрудников, чтобы лучше использовать возможности каждого из них. Чтобы успевать за всеми изменениями, постоянно требуются новые навыки и умения.

🤝 7. Новые методы руководства. Руководитель — учитель, а не надзиратель.
Если руководитель тратит свое время на жесткий контроль подчиненных, это прямо свидетельствует о низких стандартах качества. Менеджмент будет сам себя вводить в заблуждение, что недобросовестное отношение рабочих к делу — причина низкого качества. Необходимо создать такую среду, в которой люди буду заинтересованы в своей работе. Однако часто можно видеть противоположную картину. Условия принуждают человека выполнять свое дело плохо, и он тогда теряет интерес к работе, что приводит к более низком качеству.

#rdclr_QA #product

Всем привет! Меня зовут Максим. В компании Red Collar я занимаю позицию QA инженера. На этой неделе поговорим немного о качестве ПО.

Цикл Деминга-Шухарта — универсальный подход к ведению проекта и его непрерывному улучшению.

Цикл Деминга-Шухарта, или Цикл PDCA — известная модель непрерывного улучшения процессов, получившая название цикла Шухарта-Деминга или цикла PDCA, применение которой в самых различных областях деятельности позволяет эффективно управлять этой деятельностью на системной основе. Цикл состоит из 4 этапов.

Планирование (Plan) — разберитесь, почему что-то не получается, в чём проблема. На этом этапе необходимо сформулировать цель, а также выяснить, к какому результату стремитесь и какие методы помогут в его достижении. Для этого составляется так называемые action план или план действий.
|
Реализация (Do) — работайте согласно новому плану и не нарушайте его условия.
|
Проверка (Check) — этот этап продразумевает проверку полученных результатов и их исследования. Необходимо понять куда мы движемся. Процесс становится лучше или хуже, и в чем причины этого.
|
Действие (Action) — здесь необходимо исправить ошибки. Если нужно, то внести изменения в требования и сам процесс.

Цикл Деминга не имеет конца, это постоянный цикл улучшения процесса разработки ПО.

#rdclr_QA #product

Нетоксичной выходной атмосферы всем в этом чатике!

#meme

Ловушка @Transactional или использование Self-inject’ов
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не выполнится.

Один из самых популярных вопросов на собеседовании для java-разработчиков вплоть до middle позиций включительно. В реальной жизни тоже встречается довольно часто, поэтому стоит следить за аннотациями над методами и понимать, как они работают.

Почему же транзакция не выполнится? Дело в том, что когда мы делаем someService.callMethod() — вызывается метод Бина, а когда внутри a() дергаем b() — вызывается метод Класса, т.е. без каких-либо прокси-оберток Спринга и прочего. Именно из-за этого транзакция метода b() и не выполнится, потому что сам класс про неё ничего не знает.

Одним из вариантов решения этой проблемы, дабы сохранить транзакционность, является использование self-инжектов. Суть в том, что мы должны взаимодействовать не с методом b() напрямую, а через бин самого себя. Ниже приведен пример такой реализации.

#rdclr_backend #java

Пример реализации

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

Задача состоит в следующем: отловить ошибку и превратить стек-трейс в понятое всем сообщение. В этом нам поможет «магия» от спринга в виде аннотации @RestControllerAdvise, которую мы повесим над классом-обработчиком. И так же аннотация @ExceptionHandler, с помощью который мы обозначаем, какие именно ошибки перехватывать.

Если Вам требуется возвращать не объект в респонсе, а какое-то представление (например, html), то можете воспользоваться @ControllerAdvise. Разница между ними такая же, как и между @Controller и @RestController. В итоге получаем единую точку обработки всех исключений, и если в приложении что-то случится, весь поток выполнения программы перейдет в RestControllerAdvise.

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

#rdclr_backend #java

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

Если делать прямо в лоб, то мы пишем большой SQL запрос, где будет перебор параметров фильтра в блоке where. Минусы тут очевидны: при увеличении размеров фильтра будет раздуваться и SQL запрос, из чего следует повышение сложности запроса, ухудшение его читаемости, сложность дебага и рост ошибок.

Тут на помощь приходит CriteriaApi. Данный пакет инструментов позволяет динамически строить запрос в БД, оперируя объектами, а не самим SQL. Вдобавок к этому, Spring фреймворк предоставляет нам интерфейс Specification<T>, который упрощает взаимодействие с CriteriaApi. Пример работы приведен на картинке ниже.

#rdclr_backend #java

MapStruct
Сегодня утром я проводил код-ревью нашего java-стажера и заметил участок кода, который можно автоматизировать.

В разработке Spring-based приложений зарекомендовал себя подход разделения приложения на «слои» — Controller -> Service -> Repository (в базовом представлении). При его использовании важно следить, чтобы нижний слой не имел доступа к слою выше. Наших данных это тоже касается и, если в слое контроллеров у нас участвуют сущности БД, то это считается плохим тоном и требуется проводить рефакторинг. Тут нам на помощь приходят DTO (Data Transfer Object), в которые мы заносим данные из наших сущностей и оперируем уже ими.

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

Ссылка на библиотеку — https://mapstruct.org/

#rdclr_backend #java #library

Всем привет! Меня зовут Андрей и в компании Red Collar я занимаю позицию Backend Java-разработчика. На этой неделе у меня будет много ревью-кода от стажеров до middle разработчиков, поэтому вначале рассмотрим решения и инструменты, с помощью которых можно повысить качество проекта.

#rdclr_backend #java

Автоформаттер black принял «политику стабильности». В 2022 ожидайте стабильный релиз. После принятия «политики стабильности» фреймворк Django собираются начать форматировать свой код при помощи black.

Стоит заметить, что автоформаттер black постепенно становится де-факто стандартом оформления кода.

https://twitter.com/llanga/status/1455496802812239876

#rdclr_backend #python #news

Мы уже познакомились с Себастьяном Рамирез по библиотеке SQLModel, но это не самая популярная библиотека у Себастьяна. Фреймворк FastAPI — это быстро набирающий популярность инструмент для разработки HTTP сервисов на Python. FastAPI из коробки дает тайпинг для валидации данных вкупе с библиотекой pydantic, автогенерацией openapi спецификации и много приятных мелочей. Была затронута и тема популярности: для примера, у фреймворка Django сейчас — 60к звезд на GitHub, а у FastAPI — 37к.

https://github.com/tiangolo/fastapi

#rdclr_backend #python #read

Насколько трудно объединять крайне полезные библиотеки с другими библиотеками? У Sebastián Ramírez это выходит отлично.

Сегодня посмотрим на SQLModel. Без SQLModel нужно было провалидировать входные данные pydantic, а потом написать код для модели данных, используя SQLAlchemy. Благодаря SQLModel решается проблема дублирования кода модели.

https://github.com/tiangolo/sqlmodel

#rdclr_backend #python #read

Доброе утро. Сегодня твой день. Начнем с рекомендации библиотеки для разворачивания PostgreSQL одной строчкой. Это будет полезно для тестов или пет-проектов, где используется множество серверов с базой данных.

pip install postgresql-wheel

После запуска в виртуальном окружении python у вас будет полноценный PostgreSQL: изолированный, скомпилированный и не требующий sudo.
Теперь через код можно создавать и удалять сервера. Данный пакет будет работать только под Linux.
https://github.com/michelp/postgresql-wheel

#rdclr_backend #python #read

Всем привет! Меня зовут Иван, и на этой неделе я пишу от лица разработки Red Collar. Сейчас я бэк и пишу на python. На этой неделе посмотрим на интересные библиотеки и соединим полученные знания в проект.

#rdclr_backend #python