Хочу поделиться результатами работы последних нескольких дней, которые включали в себя анализ git истории некоторых крупных Go проектов с целью нахождения коммитов, которые исправляли ошибки c последующей их формализацией для детектирования в случае их появления в новом коде.
Во второй части статьи рассмотрим некоторые новые диагностики в go-critic, которые позволяют находить код, который с высокой степенью вероятности содержит ошибку.
Моя прошлая статья Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы вызвала временами бурное обсуждение в комментариях. Поэтому я решил изложить ряд тезисов по мотивам данного обсуждения.
Очень часто при обсуждении методов проектирования и осуществления проекта информационных систем слышишь критику этих методов со стороны разработчиков (программистов). Читать полностью »
Наш склад размером с две Красные площади и высотой в 5 этажей работает круглый год и никогда не спит — 24/7 364 дня в году (единственный выходной — 1 января). У нас хранится и обслуживается более 8 000 000 товаров, каждый день на смену выходит более 300 операторов. Они работают с товаром, поступающим со всего мира, и собирают заказы для пользователей из четырех стран: России, Украины, Белоруссии и Казахстана. На таких масштабах бизнес требует безупречной автоматизации.
Под катом я, Паша Финкельштейн — тимлид команды разработки и автоматизации склада — расскажу, во что может вырасти open source решение, если к нему приложить хорошую команду разработки и вполне конкретную бизнес-задачу.
Мы в Промсвязьбанке активно переходим от вотерфол-канальных команд к эджайл-продуктовым. Где-то обошлось парой шишек, где-то уже можно менять грабли… но в результате мы накопили немало опыта, связанного c эджайл-трансформацией. В этом посте мы хотим поделиться опытом — вдруг вы откроете для себя что-нибудь новое.
Я думаю руководители отделов IT департамента согласятся со мной, что иногда кажется, что мы находимся на границе двух миров, живущих по разным законам, в разных временных ритмах, а нам приходится жить в обоих этих мирах. И, если трансляцию “образа жизни” сверху вниз, от вышестоящих менеджеров до инженеров, мы в силу своих должностных обязанностей осуществляем регулярно, то вот в обратную сторону — увы…
Поэтому этот пост о том, что я, как инженер, хочу сказать нашим дорогим менеджерам и тем, кто считает их “образ жизни” единственно верным. )
Планирование, диаграммы ганта, “следование процессу”, дисциплина, deadline, распорядок, “два раза не объясняю одно и тоже”, “не успел, значит плохо планировал”… — знакомые вещи? Это сущности и методы “мира менеджеров”. Понятно, что где-то больше, где-то меньше и вообще упрощение, но речь не об этом мире. Он безусловно важен. Его методы отлично работают во многих вещах. Но есть огромный пласт задач, где ничего из этого не работает, а работает совсем другое, подчас противоположное.
Читать полностью »
Сложно начать писать и структурировать мысли, когда за много лет работы скопилось миллион идей и наработок, как сделать оценку проекта быстро и как можно точнее.
Начнем по порядку. За время работы в ИТ ко мне, как в принципе, и к любому ИТ специалисту, приходят с просьбами оценить ту или иную задачу, функциональность или проект. Первая реакция у всех одна и та же: «Почему я?!». На такой вопрос идут типизированные ответы: «Ты же хотел чего-то нового?!», «Ты классный специалист!», «Это твое развитие!» и т. д. и т.п. Можете сами продолжить смысловой ряд, почему жребий судьбы пал именно на вас.
Все это конечно хорошо, но что делать, если тема для вас новая и оценивать не приходилось часто, а тут задача поражающая воображение: «Оцени нам, как отвезти человека на Марс!».
Читать полностью »
5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.
Я очень рада, что такие события проводятся. Стать классным архитектором было и остается моей мечтой. Мне очень долго было не понятно, как вообще попадают в архитекторы, как нужно развиваться и какие направления выбирать, чтобы они привели к архитектуре, и, я думаю, что такие вопросы возникают не только у меня. Замечательно, что есть сообщество, куда можно прийти и задать вопросы архитекторам.
На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.
Доклады были краткими и по сути, а обсуждение очень живое и развернутое.
Читать полностью »
После того как Иван познакомился с когортным анализом, он терпеть не мог любые виды слащавых метрик.
Но ирония была в том, что руководство не знало ничего другого, и знать категорически не хотело. Приходилось переступать через себя и тупо идти на встречу «просьбам» начальника, чтобы не заработать репутацию нехорошего человека, неподчиняющегося указаниям мудрецов.
Иногда из этого даже получались весьма интересные результаты. Об одном таком случае сейчас и пойдет речь.
Как-то руководитель попросил Ивана разобраться, почему в течение 3- недель непрерывно падает конверсия прохождения стенда командами:
Всем добрый день!
До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.
Поехали.
Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.
О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.
Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.
Метрики — они как фломастеры, каждому по вкусу свои. Без метрик существование прибыльного бизнеса как такового невозможно, они окружают нас постоянно, это неприятная, но аксиома. Для кого-то метрика — план продаж на месяц, кому-то — выполнение заказа до оговоренного дедлайна, а другим — количество отработанных часов.
Подходящей «Картинки Для Привлечения Внимания» на эту тему нет, так что держите котика
Почему-то слово «метрики» в IT-сфере плотно ассоциируются с такими «превосходными» по своей тупости практиками, как подсчет написанных строчек кода или закрытых тасков. С уверенностью можно сказать, что это — самые бесполезные и беззубые в управленческом плане «инструменты» контроля. По сути же, адекватные метрики бывают, весьма условно, но все же, только двух типов: метрики для проекта и/или работ, результат и время исполнения которых ясен и прогнозируем во времени, и напротив, метрики для проекта и/или работ, результат и время исполнения которых спрогнозировать физически невозможно. Для первого типа выставляются метрики результата, а для вторых — дистанции, сиречь отработанного времени.
Все прочее от лукавого, и сейчас я поясню почему.
Читать полностью »
