Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Vladimir Obrizan "Ecosystem for reliable Python programming"Fwdays
With the increasing complexity of applications, the likelihood of software errors increases significantly. There are about ten tools in the Python programming ecosystem that can significantly reduce the risk of errors: unittest, pytest, unittest.mock, Freeze Gun, Webtest, Factory Boy, tox, retrying, Cosmic Ray, BitBucket Pipelines.
In the talk we will discuss the advantages and disadvantages of these technologies, as well as recommendations on what stage of development to apply.
64 бита для Си++ программистов: от /Wp64 к Viva64Tatyanazaxarova
Развитие рынка 64-битных решений поставило новые задачи в области их верификации и тестирования. В статье говорится об одном из таких инструментов - Viva64. Это lint-подобный статический анализатор Си/Си++ кода, предназначенный специально для выявления ошибок, связанных с особенностями 64-битных платформ. Освещены предпосылки для создания данного анализатора и отражена его связь с режимом "Detect 64-Bit Portability Issues" в Си++ компиляторе Visual Studio 2005.
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Vladimir Obrizan "Ecosystem for reliable Python programming"Fwdays
With the increasing complexity of applications, the likelihood of software errors increases significantly. There are about ten tools in the Python programming ecosystem that can significantly reduce the risk of errors: unittest, pytest, unittest.mock, Freeze Gun, Webtest, Factory Boy, tox, retrying, Cosmic Ray, BitBucket Pipelines.
In the talk we will discuss the advantages and disadvantages of these technologies, as well as recommendations on what stage of development to apply.
64 бита для Си++ программистов: от /Wp64 к Viva64Tatyanazaxarova
Развитие рынка 64-битных решений поставило новые задачи в области их верификации и тестирования. В статье говорится об одном из таких инструментов - Viva64. Это lint-подобный статический анализатор Си/Си++ кода, предназначенный специально для выявления ошибок, связанных с особенностями 64-битных платформ. Освещены предпосылки для создания данного анализатора и отражена его связь с режимом "Detect 64-Bit Portability Issues" в Си++ компиляторе Visual Studio 2005.
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
Забытые проблемы разработки 64-битных программTatyanazaxarova
Хотя история развития 64-битных систем составляет более десятилетия, появление 64-битных версий операционной системы Windows поставило перед разработчиками новые задачи в области разработки и тестирования программных решений. В статье рассмотрены некоторые ошибки связанные с разработкой 64-битного Си/Си++ кода под операционную систему Windows. Объяснены причины, по которым данные ошибки не нашли отражения в статьях, посвященных задачам миграции и неудовлетворительно выявляются большинством статических анализаторов.
*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Плюсы и минусы Go для разработчиков на C++, Вячеслав БахмутовYandex
В докладе речь пойдёт о языке Go. Вячеслав расскажет о внутреннем устройстве языка (структуре, оптимизации, сборщике мусора и т.д.), о том, как и почему Go используют в Яндексе и что о нём говорят разработчики на С++. Отдельно Вячеслав остановится на многопоточном программировании и особенностях отладки и профилирования в Go.
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Когда мы пишем код, наши мысли почти всегда заняты исключительно правильностью его работы. Мы очень редко обращаем внимание на то, как именно его пишем. Выбор оформления и применения определенных элементов языка может влиять на восприятие вашего кода коллегами. Поэтому для эффективной работы в команде необходимо поддерживать единый стиль кода. В этом докладе я постараюсь рассказать, какие средства для этого можно использовать и что делать, если их не хватает.
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Комплексное использование анализаторов для повышения качества кодаAndrey Karpov
Нет смысла искать серебряную пулю, которая одновременно найдёт потенциальные уязвимости, проверит оформление кода, предупредит о запахах кода и вообще сделает "хорошо". Однако есть возможность собрать коллекцию инструментов, которая будет решать те задачи, которые стоят перед разработчиками. Однако, собрать коллекцию мало, нужно ещё иметь возможность единообразно работать со всеми отчётами, предоставляемыми разнородными инструментами, такими как статические анализаторы кода, санитайзеры, компиляторы, инструменты анализа покрытия кода и так далее. Поэтому, поговорим о SonarQube, который может стать такой обобщающей платформой и посмотрим на примерах, как осуществляется интеграция различных средств.
Забытые проблемы разработки 64-битных программTatyanazaxarova
Хотя история развития 64-битных систем составляет более десятилетия, появление 64-битных версий операционной системы Windows поставило перед разработчиками новые задачи в области разработки и тестирования программных решений. В статье рассмотрены некоторые ошибки связанные с разработкой 64-битного Си/Си++ кода под операционную систему Windows. Объяснены причины, по которым данные ошибки не нашли отражения в статьях, посвященных задачам миграции и неудовлетворительно выявляются большинством статических анализаторов.
*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Плюсы и минусы Go для разработчиков на C++, Вячеслав БахмутовYandex
В докладе речь пойдёт о языке Go. Вячеслав расскажет о внутреннем устройстве языка (структуре, оптимизации, сборщике мусора и т.д.), о том, как и почему Go используют в Яндексе и что о нём говорят разработчики на С++. Отдельно Вячеслав остановится на многопоточном программировании и особенностях отладки и профилирования в Go.
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Когда мы пишем код, наши мысли почти всегда заняты исключительно правильностью его работы. Мы очень редко обращаем внимание на то, как именно его пишем. Выбор оформления и применения определенных элементов языка может влиять на восприятие вашего кода коллегами. Поэтому для эффективной работы в команде необходимо поддерживать единый стиль кода. В этом докладе я постараюсь рассказать, какие средства для этого можно использовать и что делать, если их не хватает.
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Комплексное использование анализаторов для повышения качества кодаAndrey Karpov
Нет смысла искать серебряную пулю, которая одновременно найдёт потенциальные уязвимости, проверит оформление кода, предупредит о запахах кода и вообще сделает "хорошо". Однако есть возможность собрать коллекцию инструментов, которая будет решать те задачи, которые стоят перед разработчиками. Однако, собрать коллекцию мало, нужно ещё иметь возможность единообразно работать со всеми отчётами, предоставляемыми разнородными инструментами, такими как статические анализаторы кода, санитайзеры, компиляторы, инструменты анализа покрытия кода и так далее. Поэтому, поговорим о SonarQube, который может стать такой обобщающей платформой и посмотрим на примерах, как осуществляется интеграция различных средств.
Облегчаем процесс разработки с помощью статического анализа кода: Наш опытAndrey Karpov
Статический анализ кода является очень полезным DevOps-средством, помогающим программистам при разработке крупных (и не только) проектов. К сожалению, с ним знакомы далеко не все программисты, а те, кто знаком — часто вспоминают их как «старые добрые lint'еры».
В своем докладе автор покажет, на что на самом деле способен современный статический анализ, а также расскажет о опыте внедрения анализатора в процесс разработки Unreal Engine 4.
Доклад будет полезен программистам всех уровней, руководителям, а также DevOps-специалистам, желающим повысить качество их проектов.
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
Yandex Mobile Camp в Санкт-Петербурге, 30 мая 2012
Юрий Василевский, ведущий разработчик EPAM Systems, Mobile Solutions
Тема: Автоматизация в XCode
Тезисы:
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач.
Мы рассмотрим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Юрий Василевский «Автоматизация в XCode»
Yandex Mobile Camp в Санкт-Петербурге 2012
http://events.yandex.ru/events/yamobcamp/spb-may-2012/
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач. Мы обсудим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Николай Сивко "Хорошо поддерживаемое в продакшне приложение"Tanya Denisyuk
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Разница в подходах анализа кода компилятором и выделенным инструментомTatyanazaxarova
У компилятора и сторонних инструментов статического анализа кода есть общая задача - выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Компонентный веб. Проникновение в дизайн / Антон Виноградов (АО "Альфа-Банк",...Ontico
По-моему, всем давно надоело, что дизайнеры и разработчики интерфейсов дублируют работу друг друга, причем постоянно. У каждого свой набор компонентов для сборки интерфейса, свои понятия о принципах его построения, и компоненты каждый делает, как знает, лишь бы выглядели хорошо.
Компонентный веб, современные методологии, такие как БЭМ, и инструменты, такие как Sketch и AI, вкупе с передовыми фреймворками, такими как React и Angular, а также шагающий по миру стандарт ES6, могут решить насущные проблемы создания интерфейсов.
Я покажу, как дизайнер может использовать компоненты в Sketch, сделанные разработчиком. Редактировать и изменять их. А также расскажу, насколько сильно это упрощает жизнь в команде, создающей невероятные продукты каждый день ;)
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Поговорим о микрооптимизациях .NET-приложенийAndrey Akinshin
Доклад для Middle и Senior .NET-программистов о микроптимизациях приложения, из которого Вы узнаете:
О том, как важно понимать IL и ASM код, соответствующий вашей C#-программе;
О различных уровнях микрооптимизаций начиная от C# и JIT компиляторов, заканчивая CPU;
Об особенностях оптимизаций под различные процессорные архитектуры;
Об отличиях разных версиях JIT-компиляторов, включая RyuJIT;
О том, как правильно замерять время выполнения приложений и оценивать эффективность оптимизаций.
Доклад будет полезен всем разработчикам, которые хотят хотят сделать свои и без того быстрые программы ещё на 5-10% быстрее.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Григорий Петров "WebRTC в мобильных приложениях при помощи React Native"IT Event
Последние несколько лет в индустрии активно развивается WebRTC — технология, которая позволяет делать голосовые и видеозвонки прямо из браузеров. Но мало кто знает, что эта же технология может быть использована в нативных мобильных приложениях и основанных на них SDK. В своем докладе я хочу рассказать про опыт заворачивания существующих Android и iOS SDK в React Native:
— Как поддерживать несколько разных архитектур
— Как работать с нативными виджетами, такими как «вывод видео»
— Синхронизация event loop между C-реализацией и — JavaScript движком React Native
— Планы на будущее: React Native WebRTC
Similar to Как не подавиться большим старым проектом (20)
Здесь вы найдёте 60 вредных советов для программистов и пояснение, почему они вредные. Всё будет одновременно в шутку и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
In this article, you're going to find 60 terrible coding tips — and explanations of why they are terrible. It's a fun and serious piece at the same time. No matter how terrible these tips look, they aren't fiction, they are real: we saw them all in the real programming world.
Ошибки, которые сложно заметить на code review, но которые находятся статичес...Andrey Karpov
Есть ошибки, которые легко прячутся от программистов на обзорах кода. Чаще всего они связаны с опечатками или недостаточным знанием тонких нюансах языка/библиотеки. Давайте посмотрим интересные примеры таких ошибок и как их можно выявить с помощью статического анализа. При этом анализаторы не конкурируют с обзорами кода или, например, юнит-тестами. Они отлично дополняют другие методологии борьбы с ошибками.
PVS-Studio analyzes source code and finds various errors and code quality issues across multiple languages and frameworks. The document highlights 20 examples of issues found, including uninitialized variables, unreachable code, incorrect operations, security flaws, and typos. PVS-Studio is able to find these issues using techniques such as data-flow analysis, method annotation analysis, symbolic execution, type inference, and pattern-based analysis to precisely evaluate the code and pinpoint potential bugs or code smells.
When should you start using PVS-Studio? What can PVS-Studio detect? Supported standards: MISRA, CWE, CERT, OWASP, AUTOSAR. What about analysis options? What about legacy code?
Двойное освобождение ресурсов. Недостижимый код. Некорректные операции сдвига. Неправильная работа с типами. Опечатки и copy-paste. Проблемы безопасности. Путаница с приоритетом операций.
Make Your and Other Programmer’s Life Easier with Static Analysis (Unreal Eng...Andrey Karpov
George Gribkov presented on how to introduce static analysis to make programmers' and QA engineers' lives easier. Static analysis automatically checks code for bugs without executing it. While initial attempts to analyze Unreal Engine 4 failed, monitoring compiler calls directly succeeded in finding over 1800 warnings. Epic Games now uses continuous static analysis to receive early warnings. The best practices are to start analysis early and regularly in development and CI/CD pipelines, and to gradually fix old warnings using suppression files to ratchet down reported issues over time. Static and dynamic analysis complement each other to thoroughly check for errors.
Best Bugs from Games: Fellow Programmers' MistakesAndrey Karpov
George Gribkov will present on errors found in the code of popular games like System Shock, Doom 3, and osu!. He will discuss how his tool searches for code errors, provide examples of bugs detected, and conclude his presentation. The examples will showcase issues like unused variables, incorrect increment variables in for loops, null pointer dereferences, and misunderstandings of operators like ??. Corrections will be proposed to address the bugs.
Does static analysis need machine learning?Andrey Karpov
This document discusses whether static analysis needs machine learning. It begins with an introduction to static analysis and outlines existing static analysis solutions like DeepCode, Infer, SapFix, Embold, Source{d}, Clever-Commit, and CodeGuru. It then addresses problems with learning manually or from real large code bases, like outdated code and lack of documentation. Finally, it discusses promising approaches like analyzing code style, collecting additional metrics, and best practices for specific frameworks.
Typical errors in code on the example of C++, C#, and JavaAndrey Karpov
Objectives of this webinar
How we detected error patterns
Patterns themselves and how to avoid them:
3.1 Copy-paste and last line effect
3.2 if (A) {...} else if (A)
3.3 Errors in checks
3.4 Array index out of bounds
3.5 Operator precedence
3.6 Typos that are hard to spot
How to use static analysis properly
Conclusion
Q&A
How to Fix Hundreds of Bugs in Legacy Code and Not Die (Unreal Engine 4)Andrey Karpov
How to fight bugs in legacy code?
Should you do it at all?
What to do if there are hundreds or even thousands of errors?(that’s usually the case)
How to avoid spending a plethora of man-hours on this?
And still, how did you work with Unreal Engine?
C++ Code as Seen by a Hypercritical ReviewerAndrey Karpov
We all do code reviews. Who doesn't admit this – does it twice as often. C++ code reviewers look like a sapper. .. except that they can make a mistake more than once. But sometimes the consequences are painful . Brave code review world.
The Use of Static Code Analysis When Teaching or Developing Open-Source SoftwareAndrey Karpov
The document discusses using static code analysis when teaching or developing open-source software. It outlines how static analysis can help instructors check student homework and projects more efficiently, and help students learn about error patterns. When using static analysis for open-source projects, it recommends integrating it into developers' workflows locally and via continuous integration systems. Regular use is key to maximizing its benefits for finding and fixing bugs.
Static Code Analysis for Projects, Built on Unreal EngineAndrey Karpov
Why Do You Need Static Analysis? Detect errors early in the program development process. Get recommendations on code formatting. Check your spelling. Calculate various software metrics.
Are С and C++ Alive? Even More, IBM RPG Is! C and C++ Are Not Just for Old Systems. Are С and C++ Alive? Summary for C, C++. Embedded: C and С++ Are on the Rise.
Zero, one, two, Freddy's coming for youAndrey Karpov
This post continues the series of articles, which can well be called "horrors for developers". This time it will also touch upon a typical pattern of typos related to the usage of numbers 0, 1, 2. The language you're writing in doesn't really matter: it can be C, C++, C#, or Java. If you're using constants 0, 1, 2 or variables' names contain these numbers, most likely, Freddy will come to visit you at night. Go on, read and don't say we didn't warn you.
4. Что же произошло?
4
Если проект живет долго, в него
постоянно добавляется новый
код
Этот код пишут разные люди
Код наслаивается на код, как
геологические слои
Эпохи проходят незаметно
7. Немного статистики
7
Linux 1.0.0 March 14, 1994 176250 LOC
Linux 4.11.7 June 24, 2017 18373471 LOC
Photoshop 1.0 February 19, 1990 128000 LOC
Photoshop CS 6 May 7, 2012 10000000 LOC
Windows Calculator 35000 LOC
8. Легаси
8
Legacy Code - source code inherited from someone
else and source code inherited from an older
version of the software.
11. Как оно выглядит
11
Glorious modern
C++ code
Core module
leaking abstractions
Third-party library nobody
remembers about
Crutches to keep the
bloody thing from falling Some ancient code from
the Legendary Guru*
*unmaintainable
Bicycle Factory*
*because reasons
Tactical dirty fix*
*todo: make a proper one
16. А так можно было?
16
A return statement with an expression of type “cv void”
can be used only in functions with a return type of
cv void; the expression is evaluated just before
the function returns to its caller.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf#subsection.6.6.3
20. К чему это ведет
20
Отладка затягивается
Правки сделать трудно из-за
нагромождения костылей малых
архитектурных решений
Часто приходится вставлять заплатку
типа "потом нормально сделаем"
Чувствуешь себя как ---->
21. Every time you write new code, you should do so reluctantly,
under duress, because you completely exhausted all your
other options.
Code is only our enemy because there are so many of us
programmers writing so damn much of it.
Jeff Atwood. The Best Code is No Code At All
Лирическое отступление
21
https://blog.codinghorror.com/the-best-code-is-no-code-at-all/
23. СЦЕНА ПЕРВАЯ. Разраб и Главный в офисе.
Разраб: Что-то проект сложно стало поддерживать, надо в порядок
привести
Главный: Некогда, давайте фичи добавлять
Разраб: OKAY
Пример из жизни
23
24. СЦЕНА ВТОРАЯ. Главный уходит. Входит NEW KILLER FEATURE!!1
NEW KILLER FEATURE!!1: Привет
Проект: Ой, что это? Мне нехорошо (отворачивается и издает
странный звук)
Разраб: Терпи, не такое выносили
Проект: буэээээ.... (затихает)
Пример из жизни
24
25. СЦЕНА ТРЕТЬЯ. Те же, входит Главный
Главный: Что это вы тут устроили?
Разраб и Проект: .... (плачут обнявшись)
Главный: тааак, понятно...
Пример из жизни
25
29. Безопасность – это сейчас модно
Большинство проблем с безопасностью происходят из
программных ошибок
Профилактика лучше лечения
И вообще – Автоматизируй Это
Про безопасность
29
32. Суть в движении
32
#include <stdlib.h>
int main()
{
char* x = (char*)malloc(10 * sizeof(char));
free(x);
return x[5];
}
33. Суть в движении
33
==9901==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5 at pc 0x45917b
bp 0x7fff4490c700 sp 0x7fff4490c6f8
READ of size 1 at 0x60700000dfb5 thread T0
#0 0x45917a in main use-after-free.c:5
#1 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
#2 0x459074 in _start (a.out+0x459074)
0x60700000dfb5 is located 5 bytes inside of 80-byte region [0x60700000dfb0,0x60700000e000)
freed by thread T0 here:
#0 0x4441ee in __interceptor_free projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x45914a in main use-after-free.c:4
#2 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
previously allocated by thread T0 here:
#0 0x44436e in __interceptor_malloc projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
#1 0x45913f in main use-after-free.c:3
#2 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: heap-use-after-free use-after-free.c:5 main
34. Code review – это хорошо
Но:
Лень
Нет времени
Глаз замылен
Свой вариант
А что если заставить робота?
Статический анализ
34
35. Code review по-быстрому
35
void CBaseCamera::GetInput(....)
{
....
if( m_GamePad[iUserIndex].wButtons ||
m_GamePad[iUserIndex].sThumbLX ||
m_GamePad[iUserIndex].sThumbLX ||
m_GamePad[iUserIndex].sThumbRX ||
m_GamePad[iUserIndex].sThumbRY ||
m_GamePad[iUserIndex].bLeftTrigger ||
m_GamePad[iUserIndex].bRightTrigger )
{ .... }
V501 There are identical sub-expressions .... to the left and
to the right of the '||' operator.
36. Code review по-быстрому
36
void CAdvancedSettings::SetExtraArtwork(
const TiXmlElement* arttypes,
std::vector<std::string>& artworkMap)
{
if (!arttypes)
return
artworkMap.clear();
const TiXmlNode* arttype = arttypes->FirstChild("arttype");
....
}
V504 It is highly probable that the semicolon ';' is missing after
'return' keyword.
38. SonarQube
38
SonarQube is an open-source platform developed by
SonarSource for continuous inspection of code quality
to perform automatic reviews with static analysis
of code to detect bugs, code smells,
and security vulnerabilities
39. Open source
Что-то умеет сам, что-то можно прикрутить
Настраиваем один раз и потом гоняем в CI
???
ГРАФИКИ!!11
SonarQube
39
44. Первый запуск – это больно
Наберется очень много
ошибок
Отчет может выглядеть так
---->
Первый запуск
44
45. Почему так и что делать
45
Старый код == много шума
Да, даже если он хорошо протестирован
Нет, это не проблема анализаторов
Так что делать?
Давить. И в технический долг
Вы же будете делать рефакторинг, правда?
47. Экстрим
47
MISRA тоже может принести пользу
Если использовать ее выборочно
Например, если надо проверить, что соблюдается code style
if (someCondition)
return;
V2507 The body of the 'if' statement should be enclosed in braces.
48. Не все лицензии одинаково полезны
Некоторые из них похожи на вирусы
Нужно аккуратно затаскивать чужой
код в свой проект
Хорошая новость: подстраховаться
можно
GPL virus
48
49. GPL virus
49
/*
* This file is part of the MySuperLibrary distribution
* Copyright (c)
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, version 3.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
V1042 This file is marked with copyleft license, which requires you to open the
derived source code.
50. Подведем итоги
50
Не подавиться старым проектом
сложно, но можно
Нужно помнить про легаси
Инструменты для анализа помогают
облегчить страдания
Автоматизация. Просто автоматизация