Meet For Charity

Сегодня стартовал благотворительный аукцион Meet For Charity, где в качестве лота предлагается встреча со мной:)

Формат аукциона следующий
- для победителя аукциона я проведу небольшую экскурсию по офису Тинькофф и дальше мы пообщаемся за обедом в нашем ТЦ Водный
- собранные по итогам аукциона средства будут направлены в фонд «Нить добра»

В принципе, я готов обсудить разные темы, например, такие:
- почему сейчас бизнес и IT должны быть на одной волне;
- как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта;
- как выстроить архитектурные процессы в компании;
- как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.);
- как появление искусственного интеллекта изменило расклад на рынке разработки.
Но если у победителя будет своя тема на обсуждение, то я попробую обсудить и ее:)

P.S.
Ну и немного формальной части про меня:
- я работаю в Тинькофф почти семь лет и являюсь техническим директором юнита клиентские интерфейсы, маркетинг и вовлечение в Тинькофф
- до этого успел побыть руководителем группы разработки в Банки.ру и Woman.ru
- когда-то был software development engineer, а до этого успел закончить Физтех (МФТИ)

P.P.S.
Плюс победителю я подарю книгу Олега Тинькова "Революция. Как построить крупнейший онлайн-банк в мире", в одной из глав которой рассказывается про машину привлечения клиентов, к строительству которой я приложил руку:)

#Charity #Software #Management #Leadership

Frontend Architecture for Design Systems. A modern blueprint for scalable and sustainable websites

Лет 5 назад я прочитал эту книгу с интригующим названием "Frontend Architecture for Design Systems", ожидая от нее многого.
Книга написана Micah Godbolt на основании его многолетнего опыта работы в качестве фронтендера на разнообразных проектах. Один из последних проектов был в том, чтобы переделать сайт RedHat.com, которая славилась тем, что научилась зарабатывать на open source решениях, но особых достижений во фронтенде раньше отмечено не было.
Что особенно радует в книге, что автор не скатывается до выбора одной из библиотек и фреймворков и не объявляет его/ее серебрянной пулей, например, говоря, что Angular/React/Vue животворящий поможет решить вам все проблемы:) Фактически, автор борется за то, чтобы фронтенд-архитектура тоже была жителем первого класса в проекте разработки программного обеспечения. Для этого автор выделяет 4 столпа, а именно:
- Код (сладкое трио html, css, javascript)
- Процессы (инструменты и процессы для создания эффективного workflow)
- Тестирование (создание устойчивого решения)
- Документация

В первой части книги, а именно во вступлении автор поднимает интересный вопрос того как мы оказались в текущем положении, от появления www до появления понятия фронтенд-архитектура. Дальше он расматривает составные части этого понятия, а именно:
- Design ("By designing a system all frontend developers are going to work within, the architect sets a clear vision of what the end product, the code, will look like")
- Planning
- Oversight ("Frontend architecture is never a “set it and forget it” proposition ... A key talent of a frontend architect is the ability to continually make needed adjustments")

Вводная часть завершается мыслью о роли фронтового архитектора: "Without the early input of a frontend architect, projects run the risk of having to choose between reworking designs, platform, or infra‐ structure and telling the frontend developers to make do"

Вторая часть содержит главы относительно того, как надо структурировать код, а именно писать html, css и javascript'а. Но забавно, что в этой книге я в первый раз увидел изложение принципа единственной ответственности (Single Responsibility Principle) в переложении на фронт, а именно в главе, где рассматривались правила работы с CSS:)
Следующая часть относится к процессам. В ней рассказывается про старый и новый workflow. Также обсуждаются вопросы CI/CD в общем и сборки asset'ов в частности.
В главе 10, где обсуждается процесс Red Hat, где раскрывается schema-driven design система, в которой имеются:
- JSON schema - схема компонентов
- Template file - шаблон компонента
- Sass partial - стили компонента
- Visual regression tests - тесты для визуального регресса
- Testing data - тестовые данные
- Documentation - документация компонента
- Documentation data - данные для документации
В общем, этот подход "schema-driven design system" мне до боли знаком:) И по опыту могу сказать, что он работает куда лучше, чем альтернативные варианты.

В части, относящейся к тестрованию рассматривались:
- юнит-тесты
- performance-тесты
- визуальное регресс-тестирования
- интеграция всего этого в процесс тестирования в Red Hat:)

В части, относящейся к документированию основной акцент идет на том, как организовать в модульной дизайн системе набор компонентов, доступных для переиспользования.
Опять идет отсылка к Brad Frost’s Atomic Design principles (хоть это и убогое название для стандартного компонентого подхода от автора, который не разбирается ни в химии, ни в биологии).

В итоге, книга действительно неплохая и хорошо раскрывает подход к рендерингу фронтового отображения семилетней давности:) Но книга явно не дотягивает до рассказа об архитектуре всего приложения и если вы делаете изоморфное приложение, одновременно отвечая за бекенд (даже довольно тонкий), то одной этой книги вам не хватит.

#Architecture #Software #SoftwareArchitecture #SoftwareDevelopment #Engineering