Недавно я опубликовал статью, в которой представил новый социальный подход к программированию под названием SOSAL. Несмотря на её краткость, она сыскала большое количество внимания и конструктивной критики, что позволяет более подробно проработать подход.

Эта статья посвящена исправлению ошибок прошлой статьи: корректировка некоторых принципов, применение их на практике, а также ответы на многочисленные вопросы. Каждому принципу и теме будет выделена отдельная тема с подробным описанием.

SOSAL (Socially-Oriented Software Architecture & Logic) – это подход программирования, основанный на социальном взаимодействии членов команды, а также способствующий их развитию и обучению.

Основываясь на прошлой статье, SOSAL состоит из пяти принципов:

• Socially-Conscious Code (Социально-осознанный код)

• Open by Default (Открытость по умолчанию)

• Simple Scalability (Сбалансированная/простая масштабируемость)

• Agile Adaptivity (Адаптивность выше догм)

• Learning-Driven Logic (Логика, основанная на обучении)

Ниже последует более подробный обзор каждого из принципа, дополненных примерами и актуализированных критикой.

Socially-Conscious Code

Принцип Socially-Conscious Code способствует самому главному процессу работы в команде: кооперации. Для продуктивной кооперации в команде, кодовая база проекта должна быть простой, чистой и понятной.

Качество кодовой базы достигается посредством различных мер, от базовых принципов программирования до комплексных методов.

Примером базовых принципов программирования является понятное именование переменных (и одним из самых сложных наряду с инвалидацией кэша). Следует избегать не интуитивные или не задекларированные сокращения, однобуквенные имена (за исключением случаев, когда это полезно).

// плохо, назначение переменной неясно
const f = 42;

// пожалуйста, НЕ ИСПОЛЬЗУЙТЕ ВЕНГЕРСКУЮ НОТАЦИЮ
const g_nSpeed = 69;

// слишком подробно, хотя довольно забавно
const __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = 1337;

// приемлемо
for (let i = 0; i < 5; i++) {}

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

// плохо
function pow(x,n)
{
  let result=1;
  for(let i=0;i<n;i++) {result*=x;}
  return result;
}

// хорошо
function pow(x, n) {
    let result = 1;

    for (let i = 0; i < n; i++) {
        result *= x;
    }

    return result;
}

Анти-примером этого подхода можно назвать переусложнение кода разного рода однострочниками или цепями вызовов. Лучше всего разделить этот код на несколько строк, но так, чтобы он был понятен.

// плохо
const r=[1,2,3,4].map(x=>x*2).filter(x=>x>3);

// хорошо
const doubledValues = [1,2,3,4].map(x => x * 2);
const filtered = doubledValues.filter(x => x > 3);

Также не забывайте оставлять комментарии в тех местах, где это больше всего необходимо, например при особо сложной логике или для объяснения аргументов и результатов функции.

// хорошо
// Exists это функция, которая показывает существует объект или нет
// Возвращаемое значение exists показывает существует ли объект, ok равен false если не удалось получить объект
func Exists(x any) (exists, ok bool) {

// плохо
// взято из https://github.com/xelaj/mtproto/blob/main/internal/aes_ige/ige_cipher.go#L162
// generateAESIGE ЭТО ЕБАНАЯ МАГИЧЕСКАЯ ФУНКЦИЯ ОНА НАХУЙ РАБОТАЕТ ПРОСТО БЛЯТЬ НЕ ТРОГАЙ ШАКАЛ ЕБАНЫЙ
//nolint:godox ты че ебанулся // TODO: порезать себе вены
func generateAESIGE(msg_key, auth_key []byte, decode bool) ([]byte, []byte) {

Перечислю менее важные, но всё равно значимые критерии качества кодовой базы: следование шаблонам проектирования, отсутствие “магических чисел”.

Open by Default

Принцип Open by Default гласит о том, что ваш проект должен быть открыт по умолчанию. Открытость заключается не только в открытости исходного кода, но также в документации и настраиваемости (customizability): наличие внутренней документации важно как для закрытого, так и для открытого проекта. В случае открытости проекта рекомендую вам создать README с подробными инструкциями по запуску и настройке. Для настраиваемости проекта рекомендуется иметь конфиг или обширный список флагов командной строки.

Simple Scalability

Принцип Simple Scalability призывает вас писать код с осознанием его масштабируемости.

Самым простым типом масштабируемости является вертикальная масштабируемость, то есть увеличение мощности отдельно взятого узла. Вы, конечно, можете накинуть на сервер больше оперативной памяти и процессор пожирнее, но это идёт против идей подхода SOSAL. Для увеличения мощности приложения на отдельно взятом узле вы можете использовать кэширование часто запрашиваемых данных, асинхронность (или вовсе архитектуру, завязанную на событиях (event)), а также, в крайних случаях, оптимизацию асимптотической сложности критически важных алгоритмов.

Горизонтальная масштабируемость подразумевает увеличение количества узлов приложения. Самым простым методом является деплой приложения на множестве узлов и использования распределителя нагрузки (load-balancer), но это лишь бегство от реальных оптимизаций. Популярным сегодня методом горизонтальной масштабируемости является микросервисная архитектура: она позволяет сузить зону ответственности отдельно взятого сервиса, одновременно позволяя прозрачную горизонтальную масштабируемость и эффективность за счёт частого использования в ней брокеров сообщений, что подразумевает event-driven architecture. Прошу обратить внимание, что если ваш монолит ещё справляется с нагрузками, перепись всего на раст на микросервисы может подождать.

Сложной темой масштабируемости являются highload паттерны, они позволяют создать более отказоустойчивую, расширяемую, и производительную систему, рекомендую вам ознакомиться с ними самостоятельно.

Agile Adaptivity

Принцип Agile Adaptivity рекомендует писать код с учётом возможных кардинальных изменений кодовой базы или требований.

Для кодовой базы, этот принцип предполагает использование таких средств, как: шаблоны проектирования, использование интерфейсов, разделение логики.

Шаблоны проектирования это общепринятые пути решения проблем, они делают приложение более гибким, а также позволяют новым читателям кода быстрее понять суть. Прошу заметить, что паттерны так же просто применить как применить их неправильно, рекомендую более подробно с ними ознакомиться перед использованием. Примером гибкого шаблона проектирования является Репозиторий (если ваш тимлид любит менять базу данных каждые две недели, но справедливости ради это упрощает мок-тестирование).

Интерфейсы позволяют сохранить один интерфейс, то есть слой взаимодействия двух частей, и в то же время полностью менять внутреннюю логику по требованию. Несколько реализаций, к примеру, Репозитория, помогут сохранить одно поведение при абсолютно разных внутренних условиях, чёткое разграничение логики помогает при необходимости переиспользовать кусок программы отдельно от другой

Если отойти от одной только кодовой базы, то прекрасным подходом является настройка CI/CD (Continuous Integration, Continuous Delivery). CI поможет вам выявить проблемы с проектом на стадии принятия изменений (если вы постарались и написали тесты), а CD позволит быстрее выпустить обновления в продакшн. Одной из техник CD является Canary-развёртывание, то есть постепенное развёртывание изменений для доступа пользователям, пример такого в Kubernetes:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 1h }  # Мониторинг ошибок
      - setWeight: 100

Learning-Driven Logic

Принцип Learning-Driven Logic призывает писать код так, чтобы в процессе написания он учил как вас, так и других. Рекомендую при решении новых или подзабытых задач прошерстить материалы на предмет наличия элегантного, эффективного и читабельного примера. Рефакторинг – это не пытка, а возможность сделать свой код лучше и научиться новому в процессе. При проведении ревью будет очень кстати оставлять ссылки на материалы, которые помогут в решении задачи, что сделает ревью быстрее, проще, и приятнее для всех участников. Отдельной темой для LDL является создание пет-проектов в нерабочее время, хотя некоторые компании выдают на это рабочее время. Пет-проекты дают вам свободу самовыражения при решении задачи, вы можете использовать лучшие решения, не оглядываясь на возможную кучу легаси в вашем проекте.

Часто задаваемые вопросы

В комментариях под прошлой статьёй множество людей задавали важные вопросы, и я постараюсь ответить на самые важные из них.

А как этот ваш SOSAL будет работать в парадигме GOVNO (https://govno.works/)? Противоречий не возникнет?)

Из-за общей природы SOSAL, каждый волен адаптировать этот подход под себя любыми методами, в пределах данных принципов. Подход GOVNO, например, более подробно раскрывает такие принципы SOSAL как Socially-Conscious Code и Open by Default, SOSAL только выигрывает от взаимодействия с другими подходами и идеологиями.

Как-то режет ухо название…

Для меня название – это не самое важное в подходе, более важным критерием оценки является эффективность и возможность оптимизации процессов в команде. Были также предложены различные варианты названия, такие как LASSO и LASOS. Надеюсь что читатель простит мне некоторую ассоциацию на фоне этого названия, но я считаю что описанные тут принципы действительно позволят улучшить качество разрабатываемых таким образом систем, каким бы не было название этого подхода.

Опять под видом хитрых методологий и заумных аббревиатур, нам подсовывают то, что каждый разработчик умеет со старта.

И правда, принципы подхода SOSAL могут быть очевидными и интуитивными для опытных разработчиков, но мы не можем забывать про только начинающих свой путь в программировании. Посредством формализации подхода SOSAL, мы можем распределить популярные знания между всеми участниками команды для более эффективной работы.

Зачем этот SOSAL, когда уже есть более простой и понятный LIZAL (Loose Interface, Zero Abstraction Layer)?

SOSAL – социальная идеология программирования, тогда как LIZAL и подобные (SOLID, DRY, KISS) более сосредоточены на конкретном коде и на конкретных аспектах программирования.

Лояльны ли компании из ОБОСРАЛСЯ* (Озон, Билайн, Окко, Сбер, Рамблер, Авито, ЛамодаТех, Сколково, Яндекс) к SOSAL?

Я не располагаю данными о введении данного подхода в популярных российских компаниях, но думаю что SOSAL останется непопулярным ещё некоторое время, но я очень надеюсь что данный подход сможет оставить свой след и в технических гигантах нашей страны.

Автор если и SOSAL, то сильно не имплементировал. Чисто так, по злому и без удовольствия попрограммировал и всё.

В моих мыслях, SOSAL – это идея, которой нужно придерживаться осознанно, искренне, со стремлением упростить работу своей команды, хотя я не порицаю вас если вы держитесь в программирования “чисто так по злому, без удовольствия”, чтобы получить деньги.

Заключение

В заключение хочу сказать, что SOSAL – это больше чем сухой свод правил. Я изложил своё видение определения принципов социального взаимодействия в области разработки IT-систем, их осознание и применение может наполнить мир разработки тем, чего нам в нём не хватает: дружбой, кооперацией, развитием и коллективным духом. Благодаря достаточно общей натуре этого подхода, каждый может использовать SOSAL в своих командах и проектах, и я надеюсь что после этой статьи, я смогу воодушевить большее количество людей на использование моего подхода.