Качество кода *

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

Как я уже писал, мы взяли из DDD тактические шаблоны.

Если какое-то понятие предметной области является уникальным и отличным от всех других объектов в системе, то для его моделирования используется сущность.

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

Для этого используются уникальные идентификаторы.

Сущность в коде нашего проекта должна иметь:

Blade Runner 2049, Warner Bros. Pictures

Я видел не во сне, а наяву атакующие корабли, пылающие под четырьмя вложенными if-else, и лучи CI с кучей сканирований у ворот Тангейзера, вызывающие лютую боль разработчиков. Меня зовут Максим Морев, и я техлид в Газпромбанке.

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

Это вторая часть из серии статей про компонентный подход. Если вы не читали первую часть Компонентный подход. Боремся со сложностью в Android-приложениях, то рекомендую начать с нее.

Ранее мы обсудили, что компонентный подход — это способ организации приложения в виде иерархии компонентов: UI-элементы ➜ функциональные блоки ➜ экраны ➜ флоу ➜ приложение. Такая структура позволяет эффективно бороться со сложностью экранов и навигации.

Предлагаю опробовать этот подход на практике. Будем использовать библиотеку Decompose для создания простых и сложных экранов. Рассмотрим примеры из реальных приложений. Надеюсь, будет интересно.

Представьте, что вы начали разработку нового Android-приложения. Поначалу особых проблем не будет. Вы реализовали лишь самые базовые функции. Экранов немного, и все они простые. Вам легко ориентироваться в коде. Вы бодро добавляете одну фичу за другой. Но со временем разработка усложняется: кода становится много, главный экран обрастает большим количеством UI-элементов и логики, экраны образуют сложные цепочки переходов. Приходится ломать голову, чтобы добавить что-то новое, не сломав ничего из старого. Скорость разработки падает. Знакомая ситуация?

Существует эффективный способ борьбы со сложностью — компонентный подход. Мы в MobileUp применили его в трех крупных Android-приложениях и теперь не представляем, как жили без него раньше.

Меня зовут Артур, я тимлид в компании MobileUp. Я помогу вам освоить компонентный подход. Постараюсь сделать это как можно проще и увлекательнее.

Вас ждет серия статей. Это первая из них — теоретическая. В ней мы рассмотрим, какие сложности встречаются в Android-приложениях, и почему MVVM и Clean Architecture не панацея против них. Я расскажу, что такое компонентный подход и в чем его преимущества. А в конце статьи будут ссылки на материалы для углубленного изучения.

Низкий порог входа и строгость языка программирования — вещи обычно несовместимые. Потому что ты либо, как Rust, бьёшь по рукам borrow checker’ом — либо, как PHP, позволяешь не задумываться о типах и быстро прототипировать. 

На самом деле, если писать код грамотно, это становится неважным и язык перестаёт иметь значение. Архитектура важнее языка, и хороший код на PHP ничем не отличается от аналогичного кода на любом другом ООП-языке. Другое дело, что возможность «любой домохозяйке» писать на PHP сопровождается и риском наворотить полное неподдерживаемое безобразие. Поэтому нам нужны тайпхинты, линтеры, статические анализаторы и подобные инструменты. 

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

Наша новая open-source разработка называется Modulite и внедряет в PHP модули. Это сквозная технология: мы внедряемся в IDE, в PHPStan, в KPHP, в CI, в Composer — и делаем так, будто бы модули нативно есть в языке PHP.

Всё больше компаний переходят на микросервисы. Такой выбор вполне оправдан: при должной реализации они решают множество проблем монолита. За последние несколько лет микросервисная архитектура сильно эволюционировала и обросла вспомогательными технологиями, одна из которых service mesh. В статье разберём, какую роль service mesh играет в развёртываниях микросервисов и как помогает упростить работу разработчиков.  

Привет! Продолжим тему гексагональной архитектуры и DDD, первый пост — здесь. 

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

Гексагональная архитектура

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

Я приведу основные мысли.

Гексагональная архитектура имеет три фундаментальных блока:

{"__typename":"PageLikeAction","action_type":"LIKE","label":{"text":"Like"}

Каждая строка делает только одно действие

Привет, Хабр! Сегодня мне хотелось бы поговорить о такой интересной метрике, как Maintainability - возможность вести доработки и улучшения при создании сложных систем. Ведь при развитии любого программного продукта возникает вопрос, сколько будет стоить его поддержка и развитие. Мы в Киберпротекте разрабатываем линейку продуктов для защиты данных и сегодня это — миллионы строк кода, требующие ощутимых затрат как на поддержку, так и на расширение возможностей или исправление найденных ошибок. В этой статье я делюсь своими мыслями о том, как оценить Maintainability, из чего она состоит, можно ли ее измерить, и как принимать правильные решения при работе с кодом.

Contact us: [t.me/evaclick]

Подробнее с "eco-programming & VAOP", можно познакомиться здесь https://vaop.notion.site/eco-programming-VAOP-106f8ec4418d42bdbb5ec371e8ddada9

Когда в апреле 2021 года я опубликовал статью на хабре: Введение в v-agent ориентированное программирование, в которой сформулировал идеологию и заложил основной понятийный аппарат новой методологии программирования: v-agent, va-script, va-box, action, direction и т.п., то напомнил себе изобретателя радио - Сделал Маркони радио, включил, а слушать то нечего. Наверное подобное происходит со всеми пионерами новых методологий программирования.

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

Привет, Хабр!

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

Абстракции — естественная составляющая разработки программного обеспечения, и они вполне могут протекать.

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

В посте ниже я описываю личный и командный опыт, под который я постарался подвести теоретическую базу, опираясь на "Чистую архитектуру" Роберта Мартина. Да, этот пост - для новичков, хотя, эта тема жива и среди устоявшихся программистов, поскольку споры о компоновке приложения не утихают и среди сениоров.

Зайду я немного издалека и напомню, что такое луковичная архитектура.

Positive Technologies 24 и 25 ноября примет участие в конференции для разработчиков высоконагруженных систем HighLoad++ 2022.

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

Расскажу вам о моём вИдении правильного программирования любых систем.

Кратко о себе: программист самоучка, примерно в 1992 году начинал с ассемблера, крякая через HIEW (Огромное СПАСИБО автору этого замечательного дизассемблера) всякие DOS-игрухи-проги, и прогая всё, что в голову взбредёт - от игр до вирей (домашних и добрых).

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

Поэтому я люблю метрики — они помогают убедиться в том, что все идет хорошо. О метриках отношений микросервисов и будет этот пост. Меня зовут Алексей Лашнев, я продуктовый разработчик в QIWI.