Анализ программного кода на примере проектов Open Source (Code Reading. The Open Source Perspective)

Эта книга 2004 года выпуска за авторством Диомидиса Спинеллиса появилась у меня в 2005 году, когда я только начинал знакомиться с промышленной разработкой и тогда она показалась мне интересной. Концепт автора был в том, чтобы познакомить разработчиков с основными концепциями разработки на примерах из крупных open source проектов того времени. Для этого к книге прыл приложен CD диск с кодом тех open source систем, что разбирал автор в своей книге. С учетом того, что Github появился только в 2008 этот подход был достаточно здравым:)
Примеры в книге были преимущественно сфокусированы вокруг языков: C, C++ и Java. А сама книга состояла из следующих частей
- Предисловие - в предисловии речь идет о том, что код нам приходится читать чаще, чем писать его, поэтому есть смысл прокачать этот навык
- Общие сведения - здесь автор говорит более подробно о том, зачем нам учиться читать код и как это можно сделать с помощью этой книги
- Основные элементы программ - здесь приводится пример программы целиком, функции и глобальные переменные, циклы, условия, символьные и логические выражения, оператор goto
- Сложные типы данных в языке C - здесь идет речь про указатели, структуры, объединения и динамическое управление памятью
- Структуры данных в C - здесь автор показывает как в C сделать векторы, таблицы, стеки, очереди и так далее
- Сложные средства управления программами - здесь идет речь про рекурсию, исключения, параллелизм, сигналы и макроподстановки
- Анализ больших проектов - здесь автор размышляет про то, как изучать большие проекты: из каких логических блоков он состоит, как он собирается, как конфигурируется, как выглядит управление версиями и как устроено тестирование
- Стандарты стиля программирования - здесь обсуждаются вопросы, которые сейчас принято решать настройкой линтеров
- Документация - здесь идет речь про важность документации и как ее писать и читать
- Архитектура - здесь автор говорит про архитектурные стили, модели управления потоком исполнения (событийно-ориентированные, архитектры с наличием диспетчера, конечные автоматы), группировку кода (модули, пространства имен, библиотеки и так далее)
- Вспомогательные программные средства - темы из этого раздела сейчас закрываются хорошей IDE
- Практический пример - а здесь приведен сквозной пример про добавление в базу данных hqsqldb новой функции даты/времени PHASEOFMOON, которая будет вычислять фазу Луны по заданной дате:)

В итоге, книга в свое время была хорошей практической книгой для студентов, что только входили в мир разработки софта и могли посмотреть как на практике применяются многие изучаемые ими концепции. А вот в текущий момент она совсем потеряла актуальность - вы с легкостью можете зайти на Github и найти все, что потребуется. Но в то же время сама структура книги и подача материала мне кажется актуальной до сих пор и я бы не отказался почитать новое издание, в котором все примеры актуализированы и учтены новинки за последние 20 лет:)

#Software #SoftwareDevelopment

How to Read Complex Code • Felienne Hermans • YOW! 2021

Это выступление Felienne Hermans посвящено той же теме, что книга "Code Reading", про которую я рассказывал вчера. Забавно, что разработчики большую часть времени читают код (~ 60%), а не пишут его, но редко кого учат читать код, а не писать его:) Поэтому автор и решила исправить эту ситацию и выступить с темой про чтение кода, а также написать книгу "The Programmer's Brain", в которой эти же идеи изложены гораздо подробнее.

Если переходить к самому выступлению, то Felienne строит свои размышления на том, что мы знаем о мышлении людей сегодня. Она рассказывает про то, как работают Short Term Memory (STM), Long Term Memory (LTM) и Working Memory в общем, а потом приземляет это на разработку. Она приводит примеры кода и показывает как в разных ситуациях проявляются проблемы с чтением кода в APL, Java, Basic:) Потом она рассказывает как можно прокачать свои навыки чтения и объясняет какую это пользу принесет.

Отдельно отмечу, что Felienne является практикующим преподавателем CS для детей, одновременно исследователем, а также создателем языка программирования Hedy, который помогает ей обучать детей программированию:) Подробнее можно посмотреть в выступлении "Teaching Kids to Program with Hedy: A Gradual Programming Language", про которое я уже рассказывал раньше.

Кроме того, в конце автор рекомендовала несколько книг, одна из которых мне очень нравится - это книга Джона Остерхута "A Philosophy of Software Design", на которую я написал обзор в двух частях: 1 и 2.

#Software #PopularScience #Learning #Study #ComputerScience #SelfDevelopment

Разработка программного обеспечения (Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design)

Эту книгу написали Larry Constantine и Lucy Lockwood в далеком 1999 году и она была посвящена созданию практичного програмного обеспечения, которым было бы удобно пользоваться и оно соответствовало целям пользователя. На русском книга вышла в 2004 году под названием "Разработка программного обеспечения", что привело к тому, что в 2005 году я купил ее для себя, чтобы научиться писать софт лучше. Но тогда эта книга не нашла отклик у меня - потому что я не особо думал про продуктовый подход, удобство пользователя, а также я еще не раскурил тему человеко-ориентированного дизайна (это термин из книги Дона Нормана “Дизайн привычных вещей”, на которую я писал краткое саммари). С момента выхода книги прошло уже 25 лет и часть вещей в ней уже не актуально, а часть осталась верной и сейчас, например, можно вспомнить правила практичности автора:
1) Система должна быть настолько практичной, чтобы пользователь, имеющий знания в данной предметной области, но никогда ранее не работавший с системой, без помощи инструкций и руководств мог бы сразу начать ею пользоваться
2) Система не должна никоим образом препятствоватьс эффективной работе опытных пользователей, долгое время работающих с ней
3) Система должна способствовать непрерывному повышению уровня знаний, умений и навыков и приспосабливаться к меняющемуся опыту пользователей
4) Система должна способствовать более простому, быстрому или увлекательному решению задач, стоящих перед пользователями, предоставлять новые возможности
5) Система должна удовлетворять существующим реалиям и текущей среде эксплуатационного контекста, внутри которого она будет разворачиваться и применяться

Интересно, что в комментариях к книге на Amazon люди отмечают то, что авторы в своей книге не совсем следуюет своим принципам usage-centered design, так как книга слишком многословная, а также наполнена историями и байками, которые мешают следовать структуре размышлений автора:)

P.S.
Мне было интересно полистать книгу сейчас, спустя столько лет и сравнить свое текущее мнение о книге и прошлое, а заодно оценить насколько я лучше стал понимать тему проектирования программного обеспечения:) Но если сейчас хочется почитать что-то на эту тему, то лучше почитать книгу Дона Нормана - она недавно переиздавалась и вообще является классической:)

#Design #SoftwareDevelopment #Architecture #Processes

Материалы ко второму выпуску Code of Architecture по книге "Building Evolutionary Architectures"

Вчера у нас прошел второй стрим по книге и мы упоминали следующие источники
- Structurizr - средство для моделирования в формате "diagrams as code", который позволяет создавать множество диаграмм из одной модели
- Backstage - централизованный каталог сервисов от Spotify, что уже проект CNCF, и который позволяет продуктовым командам поставлять код хорошего качества, но одновременно не уменьшает их автономность. Вспоминали это как средство, где можно впиливать governance
- getport.io - другая developer платформа по типу backstage
- KubeVela - "KubeVela is a modern software delivery platform that makes deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable"
- Книга "Clean Architecture" и ее часть про дизайн модулей - мое краткое саммари этой части здесь
- Книга "Software Architecture: The Hard Parts" - в ней +/- те же авторы рассматривали +/- те же самые примеры fitness functions (мы ее рассматривали в прошлых сезонах Code of Architecture)
- Книга "Космологически" - простой экскурс в астрономию и main sequence, которая упоминается в принципах дизайна модулей наравне с abstractness, instability:)

#CoA #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management

Code of Architecture — Recap of "Software Architecture: The Hard Parts"

В прошлом году в книжном клубе Code of Architecture мы разобрали книгу “Software Architecture: The Hard Parts”, вышедшую в конце 2021 года. У нас получилось шесть насыщенных выпусков где-то по часу каждый. В этой статье я решил собрать все материалы в одном месте. Эти материалы потребовались мне в разрезе обсуждения книги "Evolutionary Architecture", так как там есть большое пересечение по темам fitness functions и architecture governance.

#ExternalReview #SoftwareArchitecture #Architecture #SystemDesign

Just-in-time Architecture • Macklin Hartley • YOW! 2022 (Рубрика #Architecture)

Хорошее выступление про архитектуру, где автор рассказывает простую мысль о том, что нет универсальной архитектуры, которая подойдет всем. Выступление строится на примере системы для покупки пользователями картинок-аватаров, а в качестве наглядной метафоры используется работа кофейни. В этой метафоре кофейна постепенно растет и ей треубется эволюционировать, а в ходе этой эволюции автор успевает пройти по темам
1) Старта с монолита, а дальше переход на microservices, что становится скорее distributed monolith с availability coumpling
2) Потом распределенный монолит автор чинит с использованием event-driven architecture, где рассматривается два типа событий: event notification и event carried state transfer и 3 варианта генерации событий: transaction logs, transaction outbox pattern, event sourcing
3) И под конец автор доходит до communication patterns, где рассмотрели хореографию и оркестрацию. В хореографии события используются для общения сервисов между собой, децентрализованно и элегантно, но сложно для понимания что именно происходит, а в оркестрации у нас централизованный workflow

#Conference #Architecture #SoftwareArchitecture #SystemDesign #Software #DistributedSystems

Встреча CTO-CPO клуба Авито 25 мая

Вчера прошла очередная встреча CTO встреча от Avito, на которой нас собралось порядка 50 человек.
Мы сыграли в интересную игру "Бизнес-прорыв", в которой мы поделились на команды и искали решения для двух ситуаций. Для придумывания решений в рамках игры нам был выдан фреймворк, который подкидывает креативные идеи, которые можно попробовать применить для решения задачи. В итоге, наша команда отрешала эти две ситуации так:
1) В случае неопределенности, когда никто и ничего не понимает, мы решили честно рассказать сотрудникам компании про отсутствие стратегии и понимания, сказать что у нас стратегия становится continuous, горизонт планирования сжимается до дня и дальше мы быстро и эффективно реагируем на изменения дружной командой, что уже прошла до этого огонь, воду и медные трубы:) Здесь мы применили подсказку из карты "Сила хаоса" и просто признали его наличие и подстроились;
2) В случае обеспечения качества разработки, мы воспользовались подсказками из карточек "Принять жизнь" и "На дне" и пришли к идее с девизом "Купи качество, которого ты ддостоин" и решили разрабатывать продукт с разными тарифными планами с разным уровнем качества, начиная с продакта, что зачитывает свои пожелания GPT-4 и получает какой-то продукт, до полноценной команды разработки:)
Оба решения были креативно сгенерированы командой как бизнес-прорывные идеи, а потом мы их презентовали в форме стендапе:)
После игры мы общались и обсуждали разные темы на терассе с видом на Кремль, а потом ушли группой поменьше продолжать обсуждение в кальянной:)

P.S.
Такие камерные встречи позволяют получить гораздо больше инсайтов, чем стандартные конференции, чем они мне так и нравятся.
Спасибо всему Авито за организацию встречи клуба и лично Екатерине Загуменновой.

P.P.S.
На снимке одна из карточек, которая входит в этот фреймворк и предлагает перевернуть логику, поиграться с антонимами и получить безумную формулировку и попробовать достать из нее смысл.

#Leadership #Management