У любой большой системы есть неписаные правила. Формально они нигде не закреплены, но именно по ним в итоге и живет организация.
В прошлой статье я рассказал о своем 12-летнем опыте работы в системе ФНС и о том, как на определенном этапе столкнулся с характерной для больших госорганизаций установкой: «прикинуться дурачком и не высовываться», что бы с тебя не спросили и не поручили лишней работы.
«Не высовываться» (далее…)
Когда у вас один‑два сервиса и несколько интеграций, внешний API легко держать под контролем. Но если их десятки и каждый хочет выставиться наружу, приходится придумывать свой велосипед.
Меня зовут Юрий Коберман, я технический продакт в Точка Банк. Мы в команде несколько раз меняли систему работы с API. Начинали с одной команды, которая писала всё вручную, и постепенно пришли к универсальному инструменту, с помощью которого сервисы могут выходить наружу самостоятельно без очереди и потери качества. Подробности — в этой статье.
Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. Чуть больше года назад я пришел в компанию в момент, когда продукт только прошел стадию MVP, которую мы делали быстро, чтобы проверить гипотезу. Гипотеза подтвердилась, появились клиенты, но вместе с ними пришел беспорядок: запросы терялись между почтой и чатами, сроки срывались, процессы перестали работать.
В этой статье расскажу, как мы за год превратили стартап-проект в управляемый продукт — с конкретными решениями, ошибками и чек-листом действий, которые можно применить в любой команде разработки.
Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. Чуть больше года назад я пришел в компанию в момент, когда продукт только прошел стадию MVP, которую мы делали быстро, чтобы проверить гипотезу. Гипотеза подтвердилась, появились клиенты, но вместе с ними пришел беспорядок: запросы терялись между почтой и чатами, сроки срывались, процессы перестали работать.
В этой статье расскажу, как мы за год превратили стартап-проект в управляемый продукт — с конкретными решениями, ошибками и чек-листом действий, которые можно применить в любой команде разработки.
Итак, Вы – руководитель разработки (главный инженер, архитектор и т.п.) большой системы. После здравых размышлений Вы (обосновано) выбираете для системы микросервисную архитектуру. Далее Вы (и опять обоснованно) разделяете систему на микросервисы, продумываете API, рисуете стрелочки и диаграммы и можно программировать.
Можно? Наверное, но лучше сначала рассмотреть принципы для организации доступа к данным.
Мы будем рассматривать и сравнивать между собой два принципа:
· Данными владеет только владелец.
· Локальность данных.
Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд.
Мы в команде давно и настойчиво говорим об одном: документация — это не довесок к разработке, это ее часть. Писать доку нужно до кода, вместе с кодом, а не после — когда контекст уже размылся, а решения давно забыты. Считаем, что это инженерная культура, без которой появляется куча проблем: медленный онбординг, повторяющиеся споры об уже принятых решениях, техдолг.
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом
Java называют языком программирования. С формальной точки зрения это может быть и так. На практике картина более широкая. Я же утверждаю, что Java — это технология: целая программная система для гибкой (agile) разработки. В ней можно выделить четыре ключевых подсистемы, которые вместе образуют Java платформу:
Система ведения онтологии, то есть модели мира из набора абстрактных концептов, которые каждый разработчик переносит к себя в голову через когнитивные ассоциации.
Система формальной верификации типов (далее…)
Аналитики ActivTrak Productivity Lab провели исследование с использованием данных пользователей после внедрения ИИ-сервисов в рабочие процессы. Они сравнили активность 10 584 сотрудников за 180 дней до и после внедрения таких инструментов. Выяснилось, временные затраты на все категории рабочих задач выросли от 27% до 346%.
