Оптимизация кода и развитие микросервисной архитектуры занимает значительную часть жизни команды разработчиков МВидео-Эльдорадо. Тем любопытней изучить опыт коллег за рубежом. Предлагаем вашему вниманию очередной пост на тему: «А как там у них». Читать полностью »
В этой статье я не буду рассказывать про успешные внедрения, лучшие практики и общеполезные методики. Я вообще не буду давать какие-либо советы. Наоборот, попытаюсь на основании своего опыта рассказать, как бывает плохо, какие практики быстро становятся ужасными и чего нужно опасаться.
Любой программный продукт, будь то веб-сайт или мобильное приложение, основан на коде. Чем согласованнее и целостнее эта база, тем удобнее с ней будет работать, например, при необходимости доработки проекта, передачи на сопровождение другой команде.
Основными критериями качественного кода являются следующие: простота восприятия, гибкость для модификаций, возможность обновления, понятность, тестируемостьЧитать полностью »
"Читатель проживает тысячу жизней, прежде чем умрет.. Человек, который никогда не читает, проживает только одну "
- Джордж Р.Р. Мартин.
Мне нравится думать, что я смог предвидеть множество проблем и извлек ценные уроки из следующих книг:
Программист-фанатик
Программист-прагматик. Путь от подмастерья к мастеру
Неписаные законы инженерной практики
Remote: офис не требуется
Explain the Cloud Like I'm 10
Привет! Меня зовут Наташа, я руковожу разработкой бэкенда страницы yandex.ru. Сейчас у нас в команде больше двадцати человек, которые входят в отдельные группы разработки. Три года назад я впервые стала «тимлидом» маленькой группы из четырёх человек, накопив к этому времени десяток лет опыта в разработке и эксплуатации. Я не стесняюсь сказать, что переход от разработчика к тимлиду дался мне тяжело — и это нормально!
Мне нравится помогать людям в их жизненном пути и ко мне часто приходят начинающие руководители для получения опыта. Работа с людьми показала, что все проходят одинаковый путь с одинаковыми проблемами. Эта статья — мой способ наглядно показать начинающим руководителям происходящее с ними и дать очень простые инструменты, облегчающие первый переход от исполнителя к руководителю.
Читать полностью »
Эта статья является переводом материала «Tackling Complexity in the Heart of DDD».
Давайте проведем небольшой эксперимент: попробуем объяснить суть предметно-ориентированного проектирования (DDD) тому, кто понятия об этом не имеет. Это, особенно если делать кратко, непросто. Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?
Какие бывают проблемы роста, кроме очевидных, когда из 15 человек становится 80, а из одной команды вырастает 10? Почему разработчики начинают удаляться от пользователей и перестают чувствовать их боль? Как им не выпадать из коммуникационных процессов?
Я Дмитрий Шаронов, и я расскажу, как мы в Tarantool преодолевали проблемы роста и пытались избежать разделения между разработчиками при переходе из опенсорса в ентерпрайз. Какие решения использовали, зачем привлекали новичков и стажеров. Мы выделили 4 проблемы коммуникации в стремительно растущей команде и унифицировали инструменты для этого.
Это расшифровка доклада, Читать полностью »
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
Вот ты и тимлид, сынок! Добро пожаловать в наши ряды. Имя спрашивать не буду, все равно через полгода выгоришь и уволишься.
Главный страх компаний, которые вернулись в офис, когда это стало возможным, - потеря контроля над командой. Высоковата получается цена ошибки, если разработчик с его-то зарплатой сидит и ничего не делает.
Но реалии таковы, что удаленка стала must have для найма. И как тогда контролировать? Что выбрать, чтобы наблюдать за сотрудниками - системы трекинга времени, средства трансляции рабочего стола?
А если мы скажем, что ничего? Не надо тратить ресурсы на лишний контроль. И деньги сэкономите, и людям поможете раскрыться.
Под катом рассказываем, как это у нас работает уже более 5 лет.
