Массовый переход от монолитов к микросервисам решает ряд проблем:
раздельный деплой и рефакторинг;
удобное масштабирование частей системы;
прозрачное разграничение ответственности команд;
снижение бласт-радиуса;
снижение когнитивной нагрузки на разработчика.
Ретроспектива — сложный формат совместной работы группой, содержащий элементы брейншторма (совета), коачинга и обратной связи.
Регулярные ретроспективы вызывающие изменения снизу — важнейший признак организовавшейся живой команды.
К сожалению, достаточно часто ретроспективы становятся скучным формальным ритуалом не приводящим к изменениям, или вовсе сходят на нет. Возможно, это происходит из-за потери сути ретро, как встречи для работы с эмоциями.
Для проведения ретроспективы желателен опытный фасилитатор. Особенно это важно в стартующих командах.
Если вы такой человек и хотите углубить ретро, в статье вы найдете оригинальный взляд
на эту встречу с т.ч. работы мозга и цели стимуляции личностного роста участников.
Распространено мнение, что цель ретроспективы — улучшить работу. Это упускает ключевую деталь — самостоятельность. Считаю, цель ретроспективы — чтобы команда сама улучшила свою работу.
А значит цель — изменение людей. Т.е. ретроспектива, это чуть-чуть психотерапия. Нужно создать новые привычки, изменить взгляд на что-то, продать всем изменения, а не просто придумать новые инструкции.
Для контроля инструкций нужен менеджер. А автономная команда должна сама их контролировать, что требует принятия решений членами команды на личностном уровне.
Таком образом, ретроспектива это, по сути, коачинг команды. Исходя из этого можно переложить на группу стандартный коачинговый подход и посмотреть на структуру встречи через эту призму.
Мы все понимаем, что такое автоматические тесты. Мы разрабатываем софт, и хотим, чтобы он решал какие-то проблемы пользователей. Написав тест, мы убеждаемся, что конкретная проблема решается конкретным участком кода. Потом требования изменяются, мы меняем тесты и меняем код соответствующим новым требованиям образом. Но это не всегда спасает. Кроме высокого тестового покрытия наш код должен быть спроектирован таким образом, чтобы защищать разработчика от ошибок ещё при его написании.
В статье я постарался описать одну из проблем, которую может решить хорошая архитектура: связанные участки кода могут разъезжаться между собой, это может приводить к багам, и тесты тут не спасут. А грамотный дизайн может помочь.
Читать полностью »
Уже много лет мы помогаем нашим клиентам отправлять потребителям хорошие, информативные и человеческие письма. В них вместо сухого “Добрый день” мы пишем “Здравствуйте, Никита!”, а вместо “Ваш баланс пополнился” сообщаем “вы получили 25 баллов”. Но маркетологи становятся все изобретательнее, и современное письмо от интернет-магазина должно выглядеть так:
И мы хотим уметь генерировать такие письма автоматически.
Всем привет. Делюсь впечатлениями от обучения в школе скрам-мастеров от ScumTrek, под хабракатом шесть страниц текста моих мыслей и впечатлений по этому поводу. Велкам.
Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.
У нас в солюшене 51 проект. В 10 из них используется TypeScript. Объем минимизированного JavaScript-кода ~1 MB. TypeScript-код одних проектов зависит от кода других проектов. Для многих React-компонентов используются глобальные переменные.
Все вместе это приводит к долгим часам отладки front-end кода. Чтобы упростить себе жизнь, мы внедрили Webpack. А по пути отловили грабли.
npm i -g webpack typescript Всем привет.
Прошло уже больше года с тех пор, как мы начали использовать ReactJS в нашей разработке, и мы наконец созрели для того, чтобы поделиться тем, насколько счастливее стала наша компания после этого. В этой статье я собираюсь рассказать о причинах, которые привели нас к использованию этой библиотеки и о том, как мы её используем.
Небольшой комментарий по поводу форматирования статьи. Небольшие листинги я привожу как есть. Все скриншоты и большие листинги я заворачиваю в спойлеры, так как мне кажется, что так читать статью удобнее
Мы — маленькая компания, наш штат — порядка 50 человек, 20 из которых — разработчики. Сейчас у нас 4 команды разработки, в каждой из которых сидит примерно по 5 fullstack разработчика. Но одно дело — называть себя fullstack-разработчиком, а другое дело — действительно разбираться одинаково хорошо в тонкостях работы SQL Server'а, ASP.NET, разработке на C#, разбираться в OOP, DDD, знать HTML, CSS, JS и уметь этим всем разумно пользоваться. Конечно же каждый разработчик тяготеет к чему-то своему, но все мы так или иначе специалисты именно в разработке на .NET и 90% кода мы пишем на C#.
Наш продукт — система автоматизации маркетинга — подразумевает довольно большой объем настроек для каждого конкретного клиента, и для того, чтобы наши менеджеры могли заниматься этой самой настройкой продукта под клиентов, у нас есть административный сайт, в котором можно заводить рассылки, создавать триггеры и другие механики, кастомизировать сервисы и многое другое. Этот административный сайт содержит довольно много различного нетривиального UI'а, и чем сильнее мы углубляемся, чем более тонкие моменты мы даём настраивать, чем большее количество фич мы выпускаем в продакшн, тем более интересным он становится. Чтобы не быть голословным, пара скриншотов (уже под катом, и скриншотов там отнюдь не пара!):
Читать полностью »
За последний год мы перенесли внушительную часть настроек DirectCRM в базу данных. Множество элементов промо-кампаний, которые мы до этого описывали исключительно кодом, теперь создаются и настраиваются менеджером через админку. При этом получилась очень сложная структура БД, насчитывающая десятки таблиц.
Однако, за перенос настроек в базу данных пришлось расплачиваться. Об архитектуре, позволяющий кэшировать редко меняющиеся Linq to SQL сущности, смотрите под катом.
Читать полностью »
С моего предыдущего поста прошёл месяц, по-моему самое время продолжить. В этот раз поговорим об Inheritance Mapping’е, ну а особо интересующихся в конце статьи ждёт сюрприз.
Итак, начнём.
Разумеется, мы храним в нашей базе данных полиморфные сущности. Например, есть сущность CustomerOperation, которая отражает некоторую операцию, которую можно совершать над потребителем. Операции совершаются в основном через сервисы, поэтому есть наследник CustomerServiceOperation, а так же у нас есть механизм WebTracking’а, для которого есть WebTrackingOperation. Но довольно слов, лучше покажу код:
Читать полностью »