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

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

Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.

У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.

Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.

Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.

Начнём.

Как и многие, я, как мог, сопротивлялся Test-Driven Development. Я не понимал, почему тесты нужно писать перед реализацией. Почему мы должны выворачивать разработку наизнанку и переворачивать естественный, как мне тогда казалось, процесс, с ног на голову.

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

И об этом мы поговорим в статье ниже.

Мы разберём страхи, останавливающие разработчика перед тем, чтобы начать, наконец, писать тесты. Выявим очевидные преимущества. Обсудим основные правила разработки через тестирование. И подкрепим всё это реальными примерами.

С чего начинать писать новое приложение? Когда приложение должно заработать? Когда оно должно быть покрыто тестами? Зачем использовать интерфейсы? Что важнее - бизнес-сущность или табличка в базе данных?

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

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

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

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

"Идеальный программист" Роберта Мартина давно стал руководством по профессионализму в сфере IT и одним из основополагающих трудов в современной разработке, наравне с "Чистым кодом", "Чистой архитектурой" и "Чистым эджайлом".

В посте ниже собраны наиболее значимые тезисы из "Идеального программиста".

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

Меня зовут Вячеслав. Я разработчик в Сбере.

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

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

От автора перевода: в Google вместо PR (Pull Request) принято использовать аббревиатуру CL (ChangeList — список изменений). Остальные термины, на мой взгляд, понятны и без пояснений. Чтобы разбавить кучу текста, в качестве разделителей разделов использованы генерации на тему "код-ревью от разных мультипликаторов" от нейросети Kandinsky.

От автора поста: ниже представлен Kotlin Code Style на 2 мая 2023 года. Конвенция постоянно меняется, но основные принципы уже заложены и неизменны. Перевод предоставлен без комментариев, как есть.

В какой ветке вести разработку? Из какой ветки деплоить на PROD? В какой ветке чинить багу, выявленную на IFT? Многие команды закрыли для себя этот вопрос, но для многих он остаётся открытым.

Этот пост не будет содержать каких-то особых ноу-хау и киллер-фич. В нём я расскажу наиболее простую и понятную (лично мне) практику релизных циклов на основе git flow. И постараюсь объяснить каждое своё решение и каждый подход.

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

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

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

В этой статье описан принцип "Fail Fast!". Что это? Зачем он нужен? Как этот принцип поможет нам писать лучший код?

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

Ignore! - ошибка попросту игнорируется, приложение продолжает свою работу как ни в чём не бывало

Fail Fast! - приложение завершается с ошибкой

Fail Safe! - приложение учитывает ошибку в своей работе и продолжает свою работу по наилучшему сценарию из возможных

Какой подход является лучшим? Какой из них следует применять в приложении?

При всём разнообразии фреймворков для работы с базой данной, стоящих и постоянно развивающихся не так уж и много. И если про Hibernate знают все, а про JOOQ знают очень многие, то слабая популярность Exposed скорее связана с его ориентацией на Kotlin. Если Вы только-только пришли в Kotlin из Java, Вам архитектурные подходы, заложенные в Exposed (переполнение лямбдами и функциями-замыканиями, к примеру) могут показаться дичью, но пугаться не стоит: чем дальше Вы будете осваивать Kotlin, тем привычнее для Вас будут конструкции Exposed.

Какое-то время назад здесь уже была статья про Exposed, от компании Otus, но с тех пор прошло больше года и многие практики пользования фреймворком нужно освежить - даже пока я писал эту статью, многое поменялось!