РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 16:00
Тезисы:
http://backendconf.ru/2017/abstracts/2703.html
Последние два года я делаю платежную систему с нуля.
Подобные проекты при создании проходят через несколько различных стадий (создание каркаса, запуск и доработка напильником, развитие и сопровождение), каждая из которых требует специальных инструментов, отдельных подходов к организации разработки, своих особенностей в декомпозиции задач и даже разных навыков от разработчиков.
...
Как потратить 4 года и мешок денег на рефакторинг и ничего не запустить / М.Ч...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 17:00
Тезисы:
http://backendconf.ru/2017/abstracts/2636.html
Итак, вам повезло - у вас большой проект с многолетней историей. Проблема в том, что многолетняя история - это чаще всего значит много legacy кода, на который стыдно смотреть и тяжело делать всё остальное. И вот в один прекрасный момент все понимают, что так жить больше нельзя и нужно (всё) менять. Здесь самое опасное - начать всё переписывать заново. Почему это плохо и к чему это привело у нас, в Ultimate Guitar, и будет посвящён этот доклад.
...
Платежная система за год / Филипп Дельгядо (Информационные технологии и системы)Ontico
По мотивам одного из последних проектов буду рассказывать об особенностях разработки систем с сложной бизнес-логикой, ощутимыми требованиями к производительности и высокими требованиями к надежности.
Расскажу об особенностях платежных систем, опишу причины выбора основных архитектурных решений (Java, PostgreSQL, сервисы) и особенности процесса разработки.
Основные интересные моменты, на которых остановлюсь подробнее:
1) как решать популярные проблемы с БД и что делать, если не хватает IOPS;
2) какую надежную очередь стоит использовать;
3) какие нестандартные практики были успешными: IDE driven development, JSON вместо ORM, Functional test вместо Unit test;
4) какие решения были неправильными: PyTest, Spring Security, docker, велосипеды, разработчики, магия;
5) зачем менять методологию разработки три раза за год — и почему во многих проектах это тоже стоит делать.
Надеюсь, часть из сказанного вызовет несогласие и дискуссию.
Как работать в калифорнийском стартапе, не уезжая из РоссииSam Faktorovich
Никита Прокопов (AboutEcho.com) рассказывает об атмосфере стартапов и о том, чем стартапы отличаются от обычных компаний, 15.04.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Андрей Савченко (Ruby Developer, Chief Technical Officer в Aejis, г.Киев)
Доклад: «Домовёнок Кузя изгоняет Лешего»
О чём: Увлекательная история от Андрея о том, как «Continuous delivery» побеждает зло, а «TDD-богохульники» изнывают в бесплодной пустыне.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
Как потратить 4 года и мешок денег на рефакторинг и ничего не запустить / М.Ч...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 17:00
Тезисы:
http://backendconf.ru/2017/abstracts/2636.html
Итак, вам повезло - у вас большой проект с многолетней историей. Проблема в том, что многолетняя история - это чаще всего значит много legacy кода, на который стыдно смотреть и тяжело делать всё остальное. И вот в один прекрасный момент все понимают, что так жить больше нельзя и нужно (всё) менять. Здесь самое опасное - начать всё переписывать заново. Почему это плохо и к чему это привело у нас, в Ultimate Guitar, и будет посвящён этот доклад.
...
Платежная система за год / Филипп Дельгядо (Информационные технологии и системы)Ontico
По мотивам одного из последних проектов буду рассказывать об особенностях разработки систем с сложной бизнес-логикой, ощутимыми требованиями к производительности и высокими требованиями к надежности.
Расскажу об особенностях платежных систем, опишу причины выбора основных архитектурных решений (Java, PostgreSQL, сервисы) и особенности процесса разработки.
Основные интересные моменты, на которых остановлюсь подробнее:
1) как решать популярные проблемы с БД и что делать, если не хватает IOPS;
2) какую надежную очередь стоит использовать;
3) какие нестандартные практики были успешными: IDE driven development, JSON вместо ORM, Functional test вместо Unit test;
4) какие решения были неправильными: PyTest, Spring Security, docker, велосипеды, разработчики, магия;
5) зачем менять методологию разработки три раза за год — и почему во многих проектах это тоже стоит делать.
Надеюсь, часть из сказанного вызовет несогласие и дискуссию.
Как работать в калифорнийском стартапе, не уезжая из РоссииSam Faktorovich
Никита Прокопов (AboutEcho.com) рассказывает об атмосфере стартапов и о том, чем стартапы отличаются от обычных компаний, 15.04.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Андрей Савченко (Ruby Developer, Chief Technical Officer в Aejis, г.Киев)
Доклад: «Домовёнок Кузя изгоняет Лешего»
О чём: Увлекательная история от Андрея о том, как «Continuous delivery» побеждает зло, а «TDD-богохульники» изнывают в бесплодной пустыне.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
подробности - в статье: http://dspotapov.ru/blog/108-statya-lichnoe-cherez-ternii-k-zvezdam-luchshe-odin-raz-vovremya-chem-sto-raz-pravilno-ili-evolyuciya-proekta-dspotapovru-as-is.html
All iso standards available in english and russian (translation) languages, s...Suhrob Nadjimov
Gostperevod.ru - Стандарты, строительные нормы, правила, положения и законы РФ и СНГ на английском языке
Все стандарты ИСО на английском и русском языках (перевод), стандарты ISO Международной организации по стандартизации, переводы стандартов ИСО на русский язык, ИСО ISO стандарты на русском языке, ИСО ISO стандарты на английском языке
https://gostperevod.ru/international/iso
Gostperevod.com - Standards, norms, rules, regulations and laws of the Russian Federation and CIS in English
All ISO standards available in English and Russian (translation) languages, Standards of International Organization for Standardization
https://gostperevod.com/international/iso
Когда код «убивает», или зачем нам тестировать наши продуктыОлег Стрекаловский
Доклад посвящен теме тестирования и надёжности ПО. Что вы получаете, когда забываете о качестве разрабатываемого продукта и "куда копать", если вы вдруг решите начать проверять то, что у вас разрабатывается.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?Krivoy Rog IT Community
Что такое кранонит, как устроен клуб, как его можете использовтаь вы, какие встречи мы провели, какие проблемы у нас есть, какая наша публика и многое другое.
Как доказывать программы
Ефремов Д. В. (efremov(a)ispras.ru)
Доклад прочитан на конференции PHDays VII в секции Lightning Talks.
Текстовые комментарий к докладу https://blog.llkl.org/phdays-how-to-prove-programms/
PHDays VII, Moscow, May 23 2017
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...Ontico
HighLoad++ 2017
Зал «Сингапур», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2948.html
Не так часто на конференциях рассказывают про архитектуру платежных систем, особенно если они делались без legacy. Нашей платежной системе всего три года, из которых два в продакшне. Мы изначально проектировали надежную и масштабируемую систему, и за прошедшее время накопилось тем для рассказа.
...
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Как не подавиться большим старым проектомAndrey Karpov
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3073.html
Весь этот год мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающихся как по масштабам, так и по технологиям. На данный момент (сентябрь 2017) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 130 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом, полученным в результате выстраивания CI/CD для таких приложений.
...
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
Egor Fedorov "Behavior-driven development in Python"Fwdays
The goal of the BDD technique is to establish successful communication between customers, business analysts, programmers, and testers for the whole life of the project.
That is why a language was created, in which the expected behavior of the application is described in simple text form, and then through the BDD framework, the text is translated into program code, which could already be used in testing the software product.
Where BDD is applied, software requirements turn into living code, and tests instead of a programming language are written in simple human language.
In this talk, using the automation of website testing as an example, the Behave framework for Python will be shown.
The talk will be about:
writing bdd files;
performing them in behave;
running BDD as tests in pytest;
integrating everything into the CI pipeline.
подробности - в статье: http://dspotapov.ru/blog/108-statya-lichnoe-cherez-ternii-k-zvezdam-luchshe-odin-raz-vovremya-chem-sto-raz-pravilno-ili-evolyuciya-proekta-dspotapovru-as-is.html
All iso standards available in english and russian (translation) languages, s...Suhrob Nadjimov
Gostperevod.ru - Стандарты, строительные нормы, правила, положения и законы РФ и СНГ на английском языке
Все стандарты ИСО на английском и русском языках (перевод), стандарты ISO Международной организации по стандартизации, переводы стандартов ИСО на русский язык, ИСО ISO стандарты на русском языке, ИСО ISO стандарты на английском языке
https://gostperevod.ru/international/iso
Gostperevod.com - Standards, norms, rules, regulations and laws of the Russian Federation and CIS in English
All ISO standards available in English and Russian (translation) languages, Standards of International Organization for Standardization
https://gostperevod.com/international/iso
Когда код «убивает», или зачем нам тестировать наши продуктыОлег Стрекаловский
Доклад посвящен теме тестирования и надёжности ПО. Что вы получаете, когда забываете о качестве разрабатываемого продукта и "куда копать", если вы вдруг решите начать проверять то, что у вас разрабатывается.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?Krivoy Rog IT Community
Что такое кранонит, как устроен клуб, как его можете использовтаь вы, какие встречи мы провели, какие проблемы у нас есть, какая наша публика и многое другое.
Как доказывать программы
Ефремов Д. В. (efremov(a)ispras.ru)
Доклад прочитан на конференции PHDays VII в секции Lightning Talks.
Текстовые комментарий к докладу https://blog.llkl.org/phdays-how-to-prove-programms/
PHDays VII, Moscow, May 23 2017
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...Ontico
HighLoad++ 2017
Зал «Сингапур», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2948.html
Не так часто на конференциях рассказывают про архитектуру платежных систем, особенно если они делались без legacy. Нашей платежной системе всего три года, из которых два в продакшне. Мы изначально проектировали надежную и масштабируемую систему, и за прошедшее время накопилось тем для рассказа.
...
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Как не подавиться большим старым проектомAndrey Karpov
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3073.html
Весь этот год мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающихся как по масштабам, так и по технологиям. На данный момент (сентябрь 2017) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 130 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом, полученным в результате выстраивания CI/CD для таких приложений.
...
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
Egor Fedorov "Behavior-driven development in Python"Fwdays
The goal of the BDD technique is to establish successful communication between customers, business analysts, programmers, and testers for the whole life of the project.
That is why a language was created, in which the expected behavior of the application is described in simple text form, and then through the BDD framework, the text is translated into program code, which could already be used in testing the software product.
Where BDD is applied, software requirements turn into living code, and tests instead of a programming language are written in simple human language.
In this talk, using the automation of website testing as an example, the Behave framework for Python will be shown.
The talk will be about:
writing bdd files;
performing them in behave;
running BDD as tests in pytest;
integrating everything into the CI pipeline.
Room8: Внедрение практик code review как важная составляющая успеха мобильног...DevGAMM Conference
Успех любого программного продукта зависит от многих факторов и одним из основных является качество кода. В условиях часто меняющихся требований и параллельной разработки нескольких проектов следить за данным показателем невероятно сложно. Обсуждаемые в докладе практики призваны помочь руководителям отделов разработки и разработчикам решить эту проблему.
Задача №1 для россиян — учиться хотеть работать. Под лежачий камень деньги не текут. А онлайн-рынок, между тем, предлагает богатый набор инструментов, кто хочет повысить производительность труда. Причём программные решения хороши как для директоратов, так и для отчаянных домохозяек. Какие это решения?
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Presentation explains different aspects why engineers. designers, UX designers should not force people to figure out how to do their tasks. It also explains why interfaces and things should be intuitive.
Similar to Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп Дельгядо (20)
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп Дельгядо
1. Сложный проект с нуля:
через воду, огонь и
медные трубы
Филипп Дельгядо
Банальности, проверенные опытом
2. О чем этот доклад
Дельгядо Филипп, ИТИС, 2017
2
До запуска Запуск Развитие
3. О чем этот доклад
О людях
О процессах
Об инструментах
Дельгядо Филипп, ИТИС, 2017
3
4. О чем этот доклад
О людях
О процессах
Об инструментах
Но для разработчиков
Дельгядо Филипп, ИТИС, 2017
4
5. О проекте
Платежная система
1 год до боевых
1.5 года в бою
Много разработки до выхода в свет
Много рисков в процессе выхода
Постоянное развитие
Дельгядо Филипп, ИТИС, 2017
5
13. Работа с требованиями
Зачем?
зачем нужна эта функциональность?
зачем нужно делать именно так?
зачем нужна эта библиотека?
зачем нужен этот отчет?
Дельгядо Филипп, ИТИС, 2017
13
19. Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Легко менять архитектуру
Дельгядо Филипп, ИТИС, 2017
19
20. Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Легко менять архитектуру
Не страшно менять UX
еще нет привыкших пользователей
Дельгядо Филипп, ИТИС, 2017
20
21. Надо помнить
Будет дорого менять внешние API
Будет дорого менять архитектуру
Будет дорого менять структуру БД
Будет дорого менять внутренние API
Будет дорого менять контрагентов
Дельгядо Филипп, ИТИС, 2017
21
23. Простота отладки
Провоцирует не писать логи
Но потом будет поздно
на боевых не будет ничего, кроме логов
а иногда и логов не будет (PCI DSS)
на боевых не будет доступа к СУБД
Дельгядо Филипп, ИТИС, 2017
23
25. Простота общения
Провоцирует пренебречь правилами
Но потом будет поздно
сформулируйте сode style
опишите принципы разработки
что такое хорошо и что такое плохо
договоритесь о правила сode review
соблюдайте no warnings
настройте static bug analyzing
Дельгядо Филипп, ИТИС, 2017
25
30. Эксплуатация
Любите ребят из эксплуатации
объясните им смысл настроек и параметров
укажите внешние зависимости и используемые порты
расскажите, что произойдет при внезапном останове
прикиньте, сколько нужно ресурсов
Дельгядо Филипп, ИТИС, 2017
30
31. Эксплуатация
Любите ребят из эксплуатации
объясните им смысл настроек и параметров
укажите внешние зависимости и используемые порты
расскажите, что произойдет при внезапном останове
прикиньте, сколько нужно ресурсов
И тренируйтесь
Дельгядо Филипп, ИТИС, 2017
31
34. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Дельгядо Филипп, ИТИС, 2017
34
35. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Дельгядо Филипп, ИТИС, 2017
35
36. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Слишком качественное тестирование
Дельгядо Филипп, ИТИС, 2017
36
37. Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Слишком качественное тестирование
Потерянный технический долг
Дельгядо Филипп, ИТИС, 2017
37
49. Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Дельгядо Филипп, ИТИС, 2017
49
50. Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Чатики
разработки, решения проблем, флудилка
Дельгядо Филипп, ИТИС, 2017
50
51. Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Чатики
разработки, решения проблем, флудилка
Мониторинг
Дельгядо Филипп, ИТИС, 2017
51
54. Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Узнайте их регламенты
как говорят с пользователями
Дельгядо Филипп, ИТИС, 2017
54
55. Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Узнайте их регламенты
как говорят с пользователями
Научитесь им доверять
Дельгядо Филипп, ИТИС, 2017
55
61. Особенности
Вы и сами все про это знаете
Но даже в уже запущенном продукте бывают проекты,
проходящие через воду, огонь и медные трубы
Дельгядо Филипп, ИТИС, 2017
61
Руководитель разработки в компании ИТИС,
специализируюсь на создании продуктов с нуля и еще долго потом.
java, базы данных, сложная логика, нагрузки, надежность и вот это все.
В этом докладе я буду рассказывать о особенностях разных стадий продукта.
А, но зачем мне это на BackendConf, тут вам не WhaleRider
Я буду говорить о тех вещах, что нужны именно разработчикам.
Сейчас все больше команда принимает организационные и управленческие решения,
так что коммуникация, процессы, планирование становятся важным не только для менеджеров,
но и для разработчиков.
Увы, никогда нельзя надеяться на достаточную компетентность менеджеров и руководителей,
часто нужно помочь вашему Scrum master или product manager, а многие вещи
в проекте могут сделать и сами разработчики, не надеясь на начальство.
Последние три года я делал платежную систему и заметная часть
примеров взята из нашей истории, хот и не все.
Ну и перед собственно началом рассказа напомню,
Почти 20 лет назад
Продукт решили делать и вот, вы приступаете к разработке
И да, зачастую - сферического коня.
Постановки - обычно высасываются из пальца или, в крайнем случае, подсматриваются у конкурентов
Нет точных знаний, как и что делать - и поэтому многие задачи вида "а как бы это могло быть"
Нет реальных пользователей
Раз нет реальных пользователей, есть ощущение, что все можно просто поменть
И вообще - многие вещи кажутся (да и являются) простыми.
Во время разработки даже пилотной версии заметная часть постановок полностью изменится.
Проект, задуманный как мировой сервис внезапно станет коробочным решением,
в первоначальном списке задач забудут про безопасность, зато будет много про пиковую нагрузку,
хотя в реальности важнее окажется безопасность, а нагрузка к старту проекта окажется не столь важной и т.д.
Я уж и не говорю про сценарии взаимодействия с пользователем, тонкости бизнес-модели или списка контрагентов
для интеграции.
Как следствие, самым важным делом на этом этапе оказвается
Ну, кроме собственно разработки.
Это те вещи, которые лучше сразу делать хорошо.
Расскажем попродробнее о практиках для всех этих действий
Работа с требованиями - это отнюдь не задачи аналитика или тимлида.
В конце концов, пока вы пишете еще сферический проект в вакууме,
вам постоянно приходится принимать решения, которые потом
окажутся архитектурными для вашего проекта
Умение задавать вопрос "зачем" - главный инструмент работы с входящими требованиями.
Когда вы начнете его практиковать, то на вас будут обижаться, ругаться, негодовать, писать докладные записки,
но после десятого раза, когда данный вопрос таки заставил вовремя пересмотреть огромную постановку с съэкономил
кучу ресурсов - ругаться начнут спокойнее и скорее "для виду". Благодарности, впрочем, все равно не ждите.
самое частое - это попытка понять, зачем нужна та или иная функциональность, какие задачи пользователя она решает.
Как ни странно, даже у знающих scrum менеджеров, описывающих все через пользовательские сценарии зачастую нет ответа,
а зачем вообще данный сценарий нужен.
Тут могут быть и варианты "а зачем это пользователю", "а точно ли он без этого не обойдется первые пару лет".
Вопрос вида "а зачем вообще мы делаем продукт" все-таки считаются неприличными, их лучше не задавать.
Этот вопрос и позволяет уменьшить scope разработки и сделает понятным возможные доработки, а зачастую позволяте решать
проблемы задолго до его исчезновения.
Очень часто после понимания "зачем" становится понятно, что задачу можно решить гораздо проще. Например, вместо
попытки придумать, как показать на экране табличку на 100 000 записей, как попросил заказчик, получится показать
десяток строк с частичными суммами. Так как все, что ему было надо - это скопировать табличку в эксель и там сделать
суммирование по месяцам, например.
Точно так же надо не забывать задавать этот вопрос и самому себе - при добавлении в проект новой модной технологии, еще одной
библиотеки или инструмента сборки. И помнить, что ответ "я хочу в проекте эту модную библиотеку, потому что с ней проще устроится
на новую работу" хотя и правдив, но непрофессионален.
Не надо выписывать завитки на гриве сферического коня в вакууме. Очень часто на этом этапе
постановки избыточно точны и универсальны, но при этом не понятно, а нужна ли будет конкретная функциональность
кому-бы то ни было.
Да, вам хорошо понятно, зачем пользователю подробная история всех его платежей за последние три года в разрезе по годам.
Но нет нужды думать, как делать эту задачу, пока у вас вообще нет клиентов с платежами и вы еще далеко от продакшена,
первое время достаточно простых решений. И разработчик вполне себе вправе и должен уточнить у постановщика,
а зачем делать сложный инструмент с поиском, фильтрацией и рассчитанный на длинную историю еще до выхода на боевые.
Очень близок к этому и замечательный принцип
Хотя он уже относится не столько к работе с постановками, сколько к собственно кодированию.
Как бы вам (или постановщику) не хотелось сразу придумать универсальное решение, помните, что прямую можно провести
по двум точкам. Я придерживаюсь эмпирического правила - делать общее решение после того, как сделано три частных,
иначе все равно придется переделывать, так как реальность всегда богаче наших ожиданий.
Ну, например, не надо делать универсального шлюза к платежной системе, пока вы не реализовали хотя бы три разных шлюза
с разными требованиями. Так как выяснится, что даже похожие карточные шлюзы внутри предполагают совершенно разные алгоритмы
работы, разные протоколы и разную ответственность.
После того, как я написал первый вариант "надежной очереди", я честно думал, что он удобен для всех.
После третьего сценария ее использования я посмотрел на костыли и переписал все с нуля, зато теперь
разработчики гораздо довольнее. Но первых двух из сценариев мне было бы мало.
Это, конечно, универсальный принцип работы, важный не только при работе с требованиями.
Лгут не только постановщики, контрагенты, но и вендоры, производители железа, консультанты.
Ну и главное - очень часто врете вы сами - себе.
Обычно врут не специально. Специалист-бухгалтер будет вам говорить, что проводки после закрытия дня не меняются
и только потом вы узнаете, что он хотел сказать "почти никогда не меняются". Контрагент вам скажет, что "платежи
проходят в течении рабочего дня" и признает, что бывает и неделя только после того, как вы ему покажете конкретный пример.
И так - всегда.
Поговорим про архитектуру.
"Разработка в вакууме" делает многие вещи достаточно простыми и этим нужно пользоваться
У вас нет уже имеющихся данных, которые нужно мигрировать. Просто изменили таблицы и все.
Пока еще можно двигать ответственность между компонентами или вообще заменить
SQL-базу на распределенный кэш, не нужно думать о том, как эти изменения применять на продакшене,
цена ошибки пока еще нулевая. И этим нужно пользоваться.
Так что вы можете уговорить дизайнера и продакта поменять UX под более простой или более удобный
в текущей архитектуре или успеть поменять идеологию под выбранный UX.
Но этой простотой будут пользоваться и постановщики, так что надо быть готовым к изменениям.
И этой простотой нужно пользоваться, так как потом, на
Вообще, на этапе "работы до продакшена" надо помнить,
Поэтому все эксперементы стоит сделать заранее, пока еще не поздно.
Для внешних API дописать хотя бы одну тестовую реализацию и посмотреть, насколько это удобно и понятно
Эксперементы с архитектурой провести до выхода в продакшн и понимать, а как она будет меняться
Нужно заранее подумать, а как будете менять БД в будущем, что для этого нужно. Это, впрочем, тема отдельного разговора.
Аналогично, а как будете поддерживать версии вашего API, можно ли его расширять. Это те вопросы, которые стоит задавать сразу.
Именно поэтому на водяной стадии нужно смело менять все вышесказанное, когда это потребуется.
Потом уже у вас не будет таких возможностей, так что эксперименты лучше ставить сразу.
В водной стадии многое просто - и эта простота таит в себе кучу опасностей
Ну зачем логи, если я могу запустить отладчик в IDE, вон он какой крутой.
Лучше сразу привыкать искать проблемы через логирование.
Да, вы все умные и вас еще мало, вы в проекте с самого начала и вы прекрасно договорились друг с другом,
как писать код, что такое хорошо и что такое плохо, зачем вам какие-то документы по этому поводу.
Но потом резко возрастет стоимость коммуникации,
а то, о чем не договорились с самого начала - уже не добавить.
Да, Code style - это стандартно, но лучше сразу договориться, что "магия" - это плохо, а пятистраничные SQL-запросы - это хорошо.
Или наоборот, но единообразно.
Если сразу не предусмотрели, то в живой проект добавить статический анализ кода или поддержать "никаких предупреждений компилятора"
будет сложно и дорого, это надо делать сразу.
Ну, все же все понимают в системе, если что - быстренько расскажем
Полную документацию писать не всегда нужно, но некотрые базовые вещи лучше описывать сразу.
Ну, как минимум для security audit пригодится. Да и при запуске быстрее будет посмотреть на картинку,
нежели думать, к чему приведет такой-то сбой.
Нужно ловить момент фиксации конкретной компоненеты/сервиса/интерфейса и в этот момент его описать
Ну и конечно по максимуму использовать документирование в коде.
Собственно, больше всего документация будет нужна даже не разработчикам,
а тем, кто будет эксплуатировать продукт - системным администраторам, dev-ops,
третьей линии поддержки и так далее.
Хотя проект еще не запущен, уже стоит подумать над тем, как его будут эксплуатировать.
И эту задачу нужно держать в голове каждому разработчику
Неплохо бы с ними познакомиться, узнать что их уже беспокоит и что им будет нужно.
При создании кода, при проектировании отдельных сервисов нужно думать о администраторах и
стараться уменьшить количество проблем.
Чем чаще отдельные программисты будут спрашивать и инженеров и системных администраторов
"а как для вас проще сделать такую-то настройку" и "а есть ли дырка в firewall между этими двумя сервисами",
тем надежнее будет система и тем быстрее будут они отвечать на ваши просьбы.
Мы даже название компонент и настроек стараемся согласовывать с эксплуатацией. Нам не сложно, а им приятно.
А если вы еще и картинки нарисуете - они будут счастливы
Даже если все прекрасно работает на тестовом стенде, то на рабочем датаценте будет плохо.
Это всем всегда очевидно, но времени на решение проблем обычно никто не выделяет
Собственно, при тренировке вам станет понятно, а что нужно написать про все
ваши сервисы, что бы было понятно что и как делать.
Есть еще несколько очень хороших практик, которые не так уж и подходят
на данном этапе разработки.
На этой стадии процесс разработки довольно прост, хотя и не очень
укладывается во многие популярные методологии - задачи в основном длинные,
постановки нечеткие и неподробные, показывать зачастую нечего.
Это приводит к нескольким рискам
Вы используете процесс, который не соответствуем вашим задачам.
на этом этапе даже канбан иногда кажется слишком громоздким и искусственным, зачастую достаточно
доски и текущих крупных задач для разработчиков, а иногда и это лишнее.
Но если у вас очень простой процесс, возникает соблазн использовать простой трекер типа трелло или ютрека.
когда у вас внезапно резко вырастет потребность в инструменте (а это будет как раз незадолго до запуска),
переходить на более удобный инструмент уже не будет времени. Лучше возьмите продукт на вырост сразу.
Все равно точных и подробных постановок не будет, много исследовательских задач, нет
статистики производительности, так что даже процесс декомпозиции не будет иметь особого смысла.
Мы обходились понедельным планом по разработчикам на квартал вперед, пересматривали его раз в пару недель
и этого вполне хватало для всех задач. При этом средний размер задачи на разработчика составлял 2-4 недели.
Пока не нужны feature-бранчи, показ демо можно делать со сборки по конкретному тегу.
Бранчи нужны только если две задачи начинают сильно мешать друг другу
Да, это ужасно, но пока у вас функциональность меняется пять раз на дню, делать полное покрытие тестов
слишком дорого. Unit-тестами надо покрывать совсем уж базовые или важные вещи, в остальном обходится
интеграционными тестами на основные сценарии.
Авторизацию и работу с деньгами надо тестировать максимально качественно сразу, тут вариантов нет.
Да и многие сложные вещи вообще не протестировать - у многих платежных систем вообще нет тестового входа,
а документация сильно расходится с реальностью, так что даже написанный сложный mock будет полностью бесполезен.
Впрочем, тут многое зависит от конкретного выбранного языка )
Да, сейчас у нас есть тестовые имитаторы для некоторых наших контрагентов, но данные для этих тестов собирались
дорогой ценой - и в любой момент могут устареть.
А вот то, что делать обязательно - хранить появившийся технический долг.
Разработка в вакууме часто приводит к неточным решениям, когда нельзя выбрать оптимальный путь из-за нехватки информации
или когда проще было сделать "примерно" из-за "зачем" и "Бережем свой труд". Но все подобные места нужно документировать,
что-бы при уточнении постановок не забыать выплачивать технический долг.
И этот долг нужно фиксировать в месте, доступном для заказчиков/постановщиков/product owner.
Итак, вы закончили с предварительной разработкой и наконец начали запуск
Никакой план не выдерживает столкновения с реальностью, все будет не совсем так, как вы думали.
Контрагенты подведут, железо сломается, клиенты повалят валом в самые неподходящие моменты,
самый важный человек заболеет, а все инвесторы проявят талант тестеров от бога.
Слишком много суетиться. Будет много разных задач, все будут казаться очень важными.
Любой программист будет испытывать огромное давление, все "надо быстро, вчера, почему еще не".
В тяжелых случаях вас даже не сможет спасти ваш начальник и над вами будет нависать кто-то из топов.
Тут очень важно спокойно работать дальше, по приоритетам.
Обычно перед запуском проходит лихорадка последних доработок и кажется, что ну вот запустимся и отдохнем.
Это не так, после запуска первое время будет только сложнее. Так что нужно попробовать отдохнуть - договорится
о дополнительном отгуле с начальством (скорее всего вас поймут) или просто не планировать "доработать" на выходных
за день перед выпуском на продакшене.
Мы запускались почти сразу после Нового Года, так что все успели отдохнуть. Но не всегда так получается.
За время запуска вы понаделаете кучу костылей и нужно время и силы для их упорядочивания.
Да, нужны новые фичи, но если не перевести дух и не вернуть часть долга, то проект
не выйдет из вечного пике.
Нужно заранее об этом помнить, не брать на себя лишних обязательств, а хорошо бы и заранее
договориться об отпуске или паузе в задачах.
Самое важное, на мой взгляд, в процессе запуска - это организация процесса.
Да, по идее это ответственность менеджмента, тим-лидов, но многое могут программисты
сделать сами - что бы им самим было легче жить.
Например, составить график дежурств.
Во время запуска часто что-то ломается или нужно сделать выкладку поздно вечером.
Желательно заранее договориться, кто и когда может задержаться на работе. Тогда не выяснится, что
одному ведущему программисту именно сегодня нужно забирать ребенка со школы, а у другого годовщина свадьбы.
Просто на доске напишите, кто когда может на этой неделе задержаться.
В особо запущенных проектах можно не сообщать эти информацию менджменту, так как возможность задержаться
совсем не то же, что и желание это сделать.Мы вот такое не сделали, что привело пару раз к большому огорчению пары человек, которым пришлось менять планы
Гораздо проще внезапные проблемы в субботу вечером исправлять из дома, а не из офиса.
Так что стоит заранее обеспечить себя возможностью доступа из дома.
Договорится с службой безопасности, поднять удаленные рабочие столы и VPN, проверить работоспособность системы.
Заодно, раз уж и так из дома работать можно, сможете в будущем этим пользоваться - ну, когда вызвали сантехника.
Почему то об организации доступа из дома постоянно забывают до самого последнего момента
У вас будут довольно сложные дни и неплохо бы для себя решить, а зачем вам вообще надо спасать проект по вечерам.
Может, вы рассчитываете на премию? Или хотите накопить пару выходных к отпуску? Или вам важно уважение коллег.
Очень полезно довести это до вашего тим-лида или проджекта, просто что бы он заранее запланировал для вас
фонд на премии или подумал, как красиво презентовать ваш героизм для высокого начальства.
Да и вам будет проще работать по субботам, если вы понимаете, зачем вы это делаете.
Организация процесса затронет и используемые инструменты
Разработке надо уметь видеть, что происходит. Мониторинга недостаточно,
логи часто малодоступны и медлительны, к БД или сервисам прямого доступа нет (и правильно).
Нужен свой арм, который может показать важные для разработки "кишки" системы.
Лучше бы его начать делать заранее, но точно понятно, что нужно - обычно в тот момент, когда потребуется.
Поэтому АРМ должен быть простой для доработок, без изысков и без лишних выкрутасов.
И постоянно дорабатываться.
Наш, например, розовенький и с hello kitty, что бы было приятнее им пользоваться
В нем, например, можно посмотреть параметры операций as-is, в точности как они хранятся в СУБД,
состояние очередей и многое другое. И нас не пугает вывод данных прямо в json, чем меньше
преобразований - тем лучше.
И в нем ничего нельзя сделать, только read only.
Если раньше вы смотрели только на задачи для разработки и трекер использовался в основном для багов,
то сейчас появятся (или вы сами сделаете) отдельные трекеры для инцидентов и для эксплуатации.
И вам очень нужно заранее получить доступ к этим трекерам, что бы не узнавать о происходящем
из слухов.
Вам нужно будет оперативно обсуждать происходящее, причем зачастую из метро, на ходу и т.д.
Впрочем, зачем нужен Slack или Telegram особенно объяснять не нужно.
Но вот сделать чатик отдельно для обсуждения проблем без участия менеджеров - полезно, уменьшает
суету и спасает от нетехнических вопросов.
Ну и добавьте в свои контакт-листы всех, кто вам будет нужен заранее - поддержку, девопсов,
сетевиков - всех, кто может понадобиться.
Знать, что на самом деле он меряет и как.
Очень часто это не совсем очевидно.
Например, мы долго не могли понять, что у нас происходит с числом платежей, пока не вспомнили, что Prometheus усредняет и интерполирует значения и вместо прямой может быть гребенка
И как именно считается в вашем мониторинге доступная память или успешность операции.
Но главный инструмент (не только на этой стадии, но тут - особенно) это люди
Так что надо по мере сил заботится и беречь.
Запуск - именно то время, когда CTO бегает за кофе и пиццой для разработчиков,
пока они чинят проблемы на продакшене (и, кстати, да, у нас и СТO и начальник разработки ходили в магазин за едой для
программистов).
Но кроме этого помните и о всех, с кем общаетесь - о эксплуатации, поддержке, пользователях.
Запуск - очень нервное время, когда легко сорваться и поругаться. Лучше до этого не доводить.
В крайнем случае - попросите купить грушу или хотя бы дартс.
И почаще ходите вместе выпить пиво.
Еще забытые герои процесса запуска - поддержка
Те люди, что отвечают реальным пользователям и помогают с их проблемами
Узнайте, кто и как там работает, кто что умеет, у кого какие знания
Поддержка - это и важнейший инструмент понимания "зачем" и лучший индикатор проблем и
источник самых неприятных сообщениий о багах и инцидентах.
Заодно расскажите им о известных вам кусочках системы, что и как и почему работает.
Очень часто ваши рассказы откроют им глаза на многие проблемы.
Вроде бы вам это не важно, и скрипты общения с пользователями - не дело разработки, но лучше попробовать
с ними разобраться. Хотя бы вы будете уверены, что у пользователя спросят версию браузера или
модель смартфона и вам не придется через неделю поисков выяснить, что проблема была под старой оперой-мини
на мобильной джаве на телефоне 10-летней давности.
Не всегда будет время подробно разобраться, зачем нужно то или иное изменение, так что нужно
достаточно им поверить, что бы (иногда) просто быстро делать то, что просят. И чем больше вы им рассказываете
и с ними общаетесь, тем проще будет верить их данным по поведению пользователя или замеченной проблеме.
О процессе.
Процесс при процессе внедрения стоит подбирать под конкретную вашу специфику.
Обычно тут короткое планирование, четкие задачи.
У нас фактически был SCRUM, со всеми его атрибутами.
Но с размером спринта в один день.
Утром распределяли задачи, в середине дня делали демо, вечером выкладывали фикс и делали ретроспективу
И так несколько недель.
Разумеется, кто-то продолжал работать надо долгосрочными задачами, но в отдельных бранчах
И вот мы наконец запустились
Про эту стадию рядом целая конференция и куча книжек
И все, что я уже успел рассказать – вам опять пригодится
Но расскажу еще о нескольких практиках, которые мы у себя активно применяем
Почему-то, хотя все знают про этот принцип, его все время забывают и я много раз видел, как после долгого выпиливания отдельного проекта выясняется, что он уже мало совместим с общей кодовой базой и его надо полностью переделывать.
Особенно проблематично, когда большую задачу делают аутсорсеры.
Большие задачи делаем и выкладываем кусочками, в единицы человекодней.
Не всегда выходит, но минимальные риски для выживания системы.
Вот сейчас внедрение асинхронной шины на кафке начниаем с дальнего угла системы
Код должно быть удобно читать и ревьюить. Для этого должна работать навигация по коду из IDE.
Это довольно сильно ограничивает в использовании библиотек, как ни странно. И заставляет писать
внутри довольно сложные вещи. Но часто спасает.
Язык со статической типизацией вообще много что позволяет сделать до запуска кода )
Мы не доверяем технологиям, про которые непонятно, как они работают, никакой магии. В крайнем случае
наймем внешних профи (например, для присмотра за СУБД).
Кстати, именно поэтому мы не используем, например, ORM.
Все тестируется у программиста
А это значит, что система должна быть разворачиваема у программиста. Но не уверен, что
эта практика переживет еще год
Тот, кто отвечает за качество продукта только и может говорить, что и когда можно выкладывать.
YouTrack - это как раз слишком простой инструмент, выбранный в начале проекта. Думаем о миграции на Jira,
но процесс медленный
Git - грустно, но куда деваться
Confluence - наконец догнал по возможностям версию 3.5, хотя языка разметки не хватает. Но все еще лучшая wiki
TeamCity - пока устраивает как система сборки
Telegram - очень не хватает нормальной адресной книги