В новом переводе от команды Spring АйО, Siva Katamreddy, девелопер адвокат в AtomicJar (Testcontainers), поделился своими мыслями о популярных в наши дни TDD, Clean, Hexagonal, Onion и Ports & Adapters. Он также постарался ответить на вопрос, который, возможно, волнует не только его: "Действительно ли мы, разработчики, так любим всё усложнять?".

Я всегда знал, что если отвлекать человека во время работы, это вредит делу. Но до конца не осознавал, насколько это серьёзная проблема. Особенно для разработчиков ПО.

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

Привет, Хабр! Я — Светлана Уварова, ведущий системный архитектор в МТС.

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

Но что, если в эту систему ворвется архитектор? В чем его задачи? Заходите под кат, обо всем расскажу. А потом отправляйте пост коллегам, если они пока не понимают, чем вы занимаетесь в команде.

Мне очень повезло, что я был за рулем, в этот гнусный октябрьский день. Так бы пошел водку пить. А так — вполне себе ничего: едешь, куда глаза глядят, рефлексируешь, и материшься: “за что же мне, хорошему, такая жопа”?

Миллион долларов на разработку уже был потрачен. Первые пользователи потихоньку покупали платные подписки и ставили звездочки в сторах. Но это и близко не окупало затрат на команду. 

Привет!

Данная статья преследует цель осветить проблему непонимания бизнесом и смежными специалистами того, кто такой monitoring engineer. Есть ли вообще такой специалист? Зачем и где он нужен? Почему это не SRE, тестировщик-автоматизатор, разработчик или кто-то еще? Какие задачи он решает? Как им стать и не полысеть? Рассмотрим ключевые вопросы.

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

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

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

Я нашел свою систему «Личного планирования», о чем я поделился в этой статье и передаю этот опыт студентам курсов по менеджменту в Практикуме.

В этой статье расскажу:

— Зачем начинать планирование в начале дня,
— Почему нужно ограничивать количество задач и блокировать время для их выполнения,
— Какие приложения помогают отслеживать продуктивность,
— Зачем подводить итоги дня и анализировать свою эффективность.

Всем привет! Я реализовал, похоже, собственный алгоритм поиска кратчайшего пути с отрицательными ребрами графа.

Почему собственный? Я искал подобное решение, но не нашел, возможно, оно уже было реализовано, просто плохо поискал. Жду Нобелевскую премию =)

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

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

В общем вас ждет теория, ещё теория, словесные примеры и даже примеры кода (он на С++, но написан понятно).

А еще это полезно знать на собесах :-)

Навыки делятся на две основные категории: мягкие (soft skills) и жесткие (hard skills). Мягкие навыки, такие как коммуникативные способности, способность к решению проблем и адаптации, кажутся невесомыми, но они играют решающую роль в профессиональном взаимодействии и карьерном росте. Жесткие навыки, напротив, охватывают технические или специализированные знания и умения, которые легко измеримы и поддаются стандартизации.

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

Хабр, привет!

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

Идеальная документация должна выполнять две основные функции...

Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.

Зачем проводить ретроспективы с командой? 

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

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

2. Вовлечение команды: с участие членов команды в процессе принятия решений  дает им новые возможности и увеличивает их чувство владения проектом.

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:

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

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

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

Тут я расскажу о нём в общих чертах.

В предыдущей статье раскрывались некоторые базовые понятия теории типов. В этот раз мы рассмотрим обобщённые типы (generics) – необходимость появления такой абстракции, ключевые особенности и различные сценарии использования в программировании.

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

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

А также расскажу о своем пет-проекте, который может стать таковым.

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

Spring Boot starter'ы - отличный способ управлять созданием, развитием и поставкой общей кодовой базы. О том как создать свой Spring Boot 3 стартер и поговорим в этой статье.

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

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