Хочу поделиться своим опытом организации и построения корпоративной базы знаний для продуктовой ИТ-разработки. В конце статьи подведу итоги внедрения такой системы.

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

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

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

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

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

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

8. Беспокойтесь о правильности каждого решения, поднимайте вопрос о том, будет ли рассматриваемое действие относиться к юрисдикции группы или оно может вызвать конфликт с политикой какого-то более высокого эшелона.

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

В процессе разработки проектного решения мы, как правило вносим множество изменений. Нет, конечно есть проекты, где все требования жестко «приколочены гвоздями» в ТЗ и внесение каких‑либо изменений практически невозможно. Но большинство проектов в той или иной степени используют знаменитую методологию Agile, позволяющую проявлять гибкость при реализации проектов.

При этом, мы не всегда можем четко определить, какие из принятых нами решений в процессе работы являются архитектурными, то есть требующими обязательного документирования, а какие таковыми не являются, хотя также очень важны для проекта. Когда архитектура программного обеспечения развивается в результате принятия командой ряда решений, командам разработчиков требуется способ отслеживать принятые ими архитектурные решения. И здесь им на помощь приходит отчет об архитектурных решениях Architecture Decision Records (ADR). По сути, ADR — это документы, которые описывают принятые архитектурные решения в проекте или системе. Они используются для сохранения и передачи информации о принятых решениях и обосновании их принятия.

Обсудим критерии качества требований и как их применять

О чём пойдёт речь:
1. зачем соблюдать критерии качества при написании требований;
2. как проверить хорошее требование или нет с помощью критериев качества;
3. как исправить требование

Привет, Хабр! Это Саша Бардаш, главный архитектор интеграционных платформ в МТС Диджитал. В прошлый раз я рассказывал о пяти книгах, которые стоит почитать начинающему ИТ-архитектору. Большое спасибо всем, кто читал. Были интересные комментарии на тему, какие еще книги почитать — кое-что из этого я добавил в свою новую подборку. Итак, под катом пять книг, которые будут интересны уже более опытным ИТ-архитекторам. Что ж, поехали!

Привет, Хабр! Меня зовут Александр Бардаш, я главный архитектор интеграционных платформ в МТС. Сегодня расскажу, почему ИТ-архитекторам важно хотя бы иногда всегда читать книги, и поделюсь подборкой для начинающих. Жду вас под катом и в комментариях!

Один раз мне задали вопрос: чем бизнес‑аналитик отличается от секретаря? Казалось бы, разработке ПО в России уже больше 2х десятков лет, но роль бизнес‑аналитика до сих пор вызывает вопросы.

В принципе, вместо секретаря можно добавить любую другую профессию и спросить: а чем БА отличается от бухгалтера, от юриста или технического писателя?

Хотя сейчас я работаю в ИТ-отрасли, много лет назад я верстал рекламную газету, и с тех пор дизайн – мой профессиональный навык и увлечение за пределами профессии.

Сделать диаграммы привлекательными гораздо проще, чем вы думаете. Получить рекомендации на все случаи жизни не выйдет, но освоить несколько приемов в Excel и узнать азы теории, вы сможете за 10 минут. 

Из тридцатилетнего опыта и десятков прочитанных книг я выбрал семь полезных приемов. Их мы и разберем в этой статье в блоге ЛАНИТ.

Рассказываем о самых распространенных шаблонах в архитектуре ПО. Разбираемся с контекстом и решаемыми задачами, обсуждаем достоинства и недостатки.

- Многоуровневая архитектура

- Каналы и фильтры

- Клиент — сервер

- Модель — представление — контроллер

- Управляемая событиями архитектура

- Архитектура на основе микросервисов

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

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

Привет, Хабр! Меня зовут Андрей Бирюков, я эксперт в области информационной безопасности, эксперт Учебного центра IBS. В этой статье я расскажу о лучших шаблонах и паттернах для облачного проектирования, которые помогут вам создать масштабируемые и надежные приложения.

Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.

Привет! Меня зовут Вадим Клеба, я руковожу командой бэкенд-разработки в Телемосте. Последние девять лет я разрабатываю высоконагруженные распределённые системы. Раньше я разрабатывал search-as-a-service-решение с эффективным полнотекстовым поиском с учётом релевантности.

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

"И всё равно, посреди всей этой тьмы, я вижу людей, которые не ломаются, я вижу людей, которые не сдаются. Даже зная, что надежда утрачена. И понимают, что от утраты до обретения, на самом деле, всего один шаг…"

В этой статье вы узнаете, что такое нотации, зачем они нужны, и какие виды моделирования бизнес-процессов существуют в природе. Сравним положительные и отрицательные стороны каждого из них. Более подробно погрузимся в, пожалуй, один из самых универсальных и удобных инструментов – BPMN 2.0. Разберем основные элементы и попрактикуемся на реальном примере. Я предоставлю вам базовые знания, которые позволят вам сразу после завершения знакомства с данной статьёй, спроектировать свою первую BPMN-диаграмму на любую актуальную для вас профессиональную тему.

1. Circuit Breaker
2. Command and Query Responsibility Segregation (CQRS)
3. Event Sourcing
4. Sidecar
5. Backend-for-Frontend
6. Strangler

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

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

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