Архитектура ПО это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение:
Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.
Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.
Снаружи для пользователя, внутри для команды разработки
Архитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.
Вдохновляет простое. К простым и красивым решениям не всегда возможно прийти с первого раза. Ошибка тоже результат.
Если система проста и удобна внутри, то она так же проста и удобна снаружи. У пользователей меньше проблем, а значит и у разработчиков тоже.
Если у команды разработки нет уверенности в последствиях их доработки, и они не могут точно сказать на что она повлияет, то это начало плохих решений: дублирование кода, неявная логика и другие причуда.
Монолиты плохо, микросервисы не всегда хорошо, наносервисы плохо. При проектировании нужно держать баланс и рисовать логические границы. Помогут сценарии использования.
Модель
Объектная модель должна быть понятна не только разработчикам, но и пользователям.
Модель должна быть гибкой: позволять масштабировать решение, не вызывать проблем при развитии. Нужно прогнать на ней все известные сценарии, которые будут реализованы сейчас и могут быть реализованы в будущем.
При реализации объектной модели клиентам рекомендуется ориентироваться на модель сервер-приложения.
Логика
Упрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте.
Сначала продумайте тесты для алгоритма, получите альтернативные сценарии и предусмотрите обработку, а потом пишите сам алгоритм.
Если какая-то часть алгоритма многократно повторяется, то скорее всего она должна быть выделена в отдельный модуль и переиспользоваться. Отдельный модуль отдельный алгоритм.
Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде.
Не прячьте за методами в коде неявную логику. Неявные связи в реализации логики ведут к усложнению решения.
Когда отдельные части программы нельзя перекомбинировать в новое целое, значит создан неэффективный монолит.
Нейминг решает
Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.
Имя объекта должно характеризовать его достаточно емко, не вызывать двусмысленности.
Метод должен реализовывать ровно то, о чем говорит его название. Название должно быть таким, чтобы другому разработчику не нужно было залезать внутрь и раскапывать, что еще здесь можно неожиданно встретить в реализации. Лучше, когда название метода описывает результат его работы, но не его реализацию.
Имена объектов и методов в конечном счете становится
языком команды разработки, заказчика ПО и даже
пользователей.
MVP и прототипы
MVP это быстро и просто, это способ сдвинуться с мертвой точки и начать показывать результат.
MVP лучше, чем волшебное ничего и долгое обсуждение, как же все-таки надо сделать. Это отличный способ собрать фидбэк и неявные требования от пользователей, от других команд разработки, которые будут использовать ваше решение.
Рефакторинг
Это придется делать. Это нормально и это важно. Даже для задач, выпущенных в продакшн совсем недавно.
Своевременный рефакторинг ускоряет разработку. Больше времени сегодня на задачу, в рамках которой надо сделать рефакторинг, меньше времени на будущие задачи.
Заботьтесь о том, чтобы в будущем код не вызывал страха и отвращения к рефакторингу. С ним должно быть приятно работать. Если нет четкой и понятной архитектуры, то программисты будут бояться даже заглянуть в код, чтобы понять как это работает.
Рефакторингу может быть подвергнуто все, что связано с системой: код, модель данных, алгоритмы, тест-кейсы.
Документация
Документация к системе должна дополнять программный код и хранить знания о причинах принятых архитектурных решений.
Документация к системе позволяет без доступа к коду понимать, как работает программа: реализацию алгоритма, покрытие альтернативных сценариев, обработку ошибок. Но разработчикам должен быть понятен код и без документации на него.
Выводы
Не усложнять.
Ничего не прятать.
Называть все своими именами.
Не стоять на месте.
Не поддаваться отчаянию, если не получилось.
Не забывать переосмысливать: смотреть через несколько дней свежим взглядом на готовое решение, если время позволяет.
