Совершенный код *

Привет, Хабр! В прошлый раз мы с вами создавали «Игру жизни» на Godot. Движок показал себя отлично, но для такой простой задачи это всё равно что забивать микроскопом гвозди. Особенно когда речь идёт о веб‑экспорте.

В последнее время стоит заикнуться про генерацию изображений, как все сразу вспоминают про нейросети. Stable Diffusion, Midjourney и прочие модели впечатляют, не спорю. Но давайте взглянем на другую сторону генеративного искусства. Ту, где картинки создаются не гигабайтами весов нейронной сети, а несколькими килобайтами JavaScript-кода.

И кстати раз уж речь зашла про красоту в коде: мы как раз запустили «Конкурс красоты кода 2.0». Самое время показать, что даже простые алгоритмы могут создавать нечто впечатляющее. Именно такие работы, где за внешней простотой скрывается математическая элегантность, часто оказываются самыми интересными.

«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям», — сказал культовый британский разработчик программного обеспечения Мартин Фаулер и в этом утверждении присутствует доля правды. То есть, когда разработчик пишет код, он должен фокусироваться не только на том, чтобы тот был рабочим, но и понятным будущим «читателям».

Кстати, сейчас у нас проходит «Конкурс красоты кода». Регистрируйтесь и покажите, как должен выглядеть по‑настоящему чистый код — лаконичный, эффективный и понятный. 

Привет, Хабр! Сегодня мы поговорим о том, как сделать код не просто красивым, но и живым. Звучит как научная фантастика, либо вы уже подготовились к очередной банальности про искусственный интеллект, но не в этом посте. В 1970 году британский математик Джон Хортон Конвей показал миру, что даже простейшие алгоритмы могут порождать сложные, живые системы, которые ещё и к тому же полные по Тьюрингу. И что код может быть не только красивым, но и живым.

Думаю, многих из нас охватывает тёплое чувство ностальгии, когда речь идёт о PSP. Эта портативная консоль, выпущенная в 2004 году, стала настоящим прорывом для своего времени. Она подарила нам возможность наслаждаться полноценными игровыми проектами в дороге, что было невероятно новаторским для того периода. У вас словно была маленькая частичка домашней консоли в кармане.

В стремительно развивающейся индустрии разработки программного обеспечения появляется новое измерение идентичности: оно сосредоточено вокруг экологической ответственности и устойчивого развития. Как инициатор Eco-Programming Alliance, я обнаружил, что программисты всё чаще сталкиваются с необходимостью интеграции экологически осознанных практик в свою работу, что порождает этические дилеммы, связанные с влиянием их кода на окружающую среду.

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

Приняв эко-программирование, разработчики не только следуют лучшим практикам, но и формируют новую идентичность, ориентированную на глобальную устойчивость. Как человек, который продвигает Eco-Programming Alliance, я считаю важным подчеркнуть, как программные технологии непосредственно влияют на окружающую среду и как мы, как глобальное сообщество, можем работать над созданием более экологичных практик разработки программного обеспечения.

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

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

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

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

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

Разработку модуля начнем с определения цели, очень тривиально, но правильно поставленная цель, значительно упрощает реализацию. Основной целью модуля будет создание инструмента удобного для пользователя. Легко добавлять, изменять значения аргументов, легко перебирать значения.

Опишем функционал модуля.

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

Вот такое сложное определение. Где, «Проще говоря», только больше запутывает чем поясняет, хотя все передает верно. Этот принцип пожалуй самый сложный для объяснений, хотя его суть очевидна.

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

Конструкторы разделили светильник на части, в программировании они называются модулями. Каждую из этих частей снабдили интерфейсами. Для лампы сделали интерфейс — патрон. Для плафона интерфейс — держатели и так далее. Теперь есть возможность извлечь лампу и заменить ее на другую, если у этих ламп интерфейсы совместимые. А что если светильник не разборный. Нам придется его разрушить, или выкинуть и купить новый.

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

Как и почему компания Shopify перешла от монолитной архитектуры к модульно-монолитной.

Что важнее — производительность или гибкость кода? Стоит ли отказаться от философии чистого кода ради перфоманса? Отвечаем на эти и многие другие вопросы вместе с командой разработчиков PVS-Studio.

int safeDiv(int a, int b) {
   if (b == 0)
      throw Div0(); // Исключения передаются особым образом
   return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}

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

Этот принцип пожалуй самый простой для понимания, но важный при реализации. С разделением интерфейсов мы встречаемся постоянно, правительство любой страны имеет интерфейсы, которые называются министерствами, компании - интерфейсы в виде отделов, материнская плата - интерфейсы для подключения памяти, процессоров и другой периферии. Тоже самое логично делать и в программировании.

В чем суть принципа разделения интерфейсов. Если перефразировать простыми словами, не нужно делать два дела сразу. Сознание человека так и построено, вспомните детскую задачку, когда просят одновременной дотянуться пальцем до кончика носа и гладить живот по часовой стрелке.

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

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

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

Первая часть серии - Проект «Статистика дрифта». Часть 1. Настройка
Паблик во ВКонтакте с новыми сериями без задержек выпуска на habr - Пихта DEV

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

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

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

Разработка PHP/VueJS пет-проекта "Статистика дрифта" в формате лайф-тайм блога.
Первая часть лфай-тайм блога написана про базовую настройку будущего приложения.

При работе над поддержкой незнакомой мне кодовой базы я трачу кучу времени на поиск строк при помощи grep. Даже в проектах, полностью написанных мной, мне нужно много искать: имена функций, сообщения об ошибках, имена классов и тому подобное. Если я не могу найти нужное, то я буду как минимум расстроен, а как максимум могу создать опасную ситуацию, если предположу, что какой-то элемент больше не нужен, ведь я не могу найти ссылок на него в кодовой базе. На основании этих ситуаций я выработал правила, которые позволяют повысить греппабельность кода.