[Анализ и проектирование систем, Проектирование и рефакторинг, Алгоритмы] Маленькими шагами к красивым решениям
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Архитектура ПО — это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение: Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.
Снаружи — для пользователя, внутри — для команды разработкиАрхитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.Вдохновляет простое. К простым и красивым решениям не всегда возможно прийти с первого раза. Ошибка — тоже результат. Если система проста и удобна внутри, то она так же проста и удобна снаружи. У пользователей меньше проблем, а значит и у разработчиков тоже.Если у команды разработки нет уверенности в последствиях их доработки, и они не могут точно сказать на что она повлияет, то это начало плохих решений: дублирование кода, неявная логика и другие причуда.Монолиты — плохо, микросервисы — не всегда хорошо, наносервисы — плохо. При проектировании нужно держать баланс и рисовать логические границы. Помогут сценарии использования.
МодельОбъектная модель должна быть понятна не только разработчикам, но и пользователям. Модель должна быть гибкой: позволять масштабировать решение, не вызывать проблем при развитии. Нужно прогнать на ней все известные сценарии, которые будут реализованы сейчас и могут быть реализованы в будущем.При реализации объектной модели клиентам рекомендуется ориентироваться на модель сервер-приложения.
ЛогикаУпрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте. Сначала продумайте тесты для алгоритма, получите альтернативные сценарии и предусмотрите обработку, а потом пишите сам алгоритм. Если какая-то часть алгоритма многократно повторяется, то скорее всего она должна быть выделена в отдельный модуль и переиспользоваться. Отдельный модуль — отдельный алгоритм.Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде. Не прячьте за методами в коде неявную логику. Неявные связи в реализации логики ведут к усложнению решения.Когда отдельные части программы нельзя перекомбинировать в новое целое, значит создан неэффективный монолит.
Нейминг решает
Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.
Имя объекта должно характеризовать его достаточно емко, не вызывать двусмысленности.Метод должен реализовывать ровно то, о чем говорит его название. Название должно быть таким, чтобы другому разработчику не нужно было залезать внутрь и раскапывать, что еще здесь можно неожиданно встретить в реализации. Лучше, когда название метода описывает результат его работы, но не его реализацию.Имена объектов и методов в конечном счете становится языком команды разработки, заказчика ПО и даже пользователей.
MVP и прототипыMVP — это быстро и просто, это способ сдвинуться с мертвой точки и начать показывать результат.MVP лучше, чем волшебное ничего и долгое обсуждение, как же все-таки надо сделать. Это отличный способ собрать фидбэк и неявные требования от пользователей, от других команд разработки, которые будут использовать ваше решение.
Рефакторинг Это придется делать. Это нормально и это важно. Даже для задач, выпущенных в продакшн совсем недавно.Своевременный рефакторинг ускоряет разработку. Больше времени сегодня на задачу, в рамках которой надо сделать рефакторинг, меньше времени на будущие задачи.Заботьтесь о том, чтобы в будущем код не вызывал страха и отвращения к рефакторингу. С ним должно быть приятно работать. Если нет четкой и понятной архитектуры, то программисты будут бояться даже заглянуть в код, чтобы понять как это работает. Рефакторингу может быть подвергнуто все, что связано с системой: код, модель данных, алгоритмы, тест-кейсы.
ДокументацияДокументация к системе должна дополнять программный код и хранить знания о причинах принятых архитектурных решений. Документация к системе позволяет без доступа к коду понимать, как работает программа: реализацию алгоритма, покрытие альтернативных сценариев, обработку ошибок. Но разработчикам должен быть понятен код и без документации на него.
ВыводыНе усложнять.Ничего не прятать.Называть все своими именами.Не стоять на месте.Не поддаваться отчаянию, если не получилось.Не забывать переосмысливать: смотреть через несколько дней свежим взглядом на готовое решение, если время позволяет.
===========
Источник:
habr.com
===========
Похожие новости:
- [API] YANG — это имя для вождя
- [Алгоритмы, Управление персоналом, Интернет вещей, Транспорт] Алгоритм оценки стиля вождения водителя грузового (коммерческого) автомобиля
- [Программирование, Анализ и проектирование систем, Проектирование и рефакторинг, Управление разработкой, TypeScript] Чем меня не устраивает гексагональная архитектура. Моя имплементация DDD – многоуровневая блочная архитектура
- [Алгоритмы, Мозг] Что такое алгоритм… Часть ⁴He «Физика»
- [Анализ и проектирование систем, Графические оболочки, Работа с 3D-графикой, CAD/CAM] Термический анализ в SOLIDWORKS Simulation на примере микрочипа
- [Алгоритмы, Машинное обучение] Что такое графовые нейронные сети
- [Программирование, Алгоритмы, Учебный процесс в IT, Карьера в IT-индустрии] Вебинар от Яндекс.Практикума «Открытое алгоритмическое собеседование»: 12 мая в 19.30
- [Проектирование и рефакторинг] Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
- [Децентрализованные сети, Сетевые технологии] Завершен перевод систематизированного обзора литературы по военным SDN-сетям (перевод)
- [Системное программирование, Программирование микроконтроллеров, Распределённые системы, Робототехника, Транспорт] Разработчики встраиваемых систем не умеют программировать
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_algoritmy (Алгоритмы), #_arhitektura_po (архитектура по), #_refaktoring (рефакторинг), #_modelirovanie (моделирование), #_prototipirovanie (прототипирование), #_sistemnyj_analiz (системный анализ), #_arhitektura (архитектура), #_model (модель), #_proektirovanie_sistem (проектирование систем), #_mvp, #_prostota_v_kode (простота в коде), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_algoritmy (
Алгоритмы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 15:33
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Архитектура ПО — это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение: Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.  Снаружи — для пользователя, внутри — для команды разработкиАрхитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.Вдохновляет простое. К простым и красивым решениям не всегда возможно прийти с первого раза. Ошибка — тоже результат. Если система проста и удобна внутри, то она так же проста и удобна снаружи. У пользователей меньше проблем, а значит и у разработчиков тоже.Если у команды разработки нет уверенности в последствиях их доработки, и они не могут точно сказать на что она повлияет, то это начало плохих решений: дублирование кода, неявная логика и другие причуда.Монолиты — плохо, микросервисы — не всегда хорошо, наносервисы — плохо. При проектировании нужно держать баланс и рисовать логические границы. Помогут сценарии использования.  МодельОбъектная модель должна быть понятна не только разработчикам, но и пользователям. Модель должна быть гибкой: позволять масштабировать решение, не вызывать проблем при развитии. Нужно прогнать на ней все известные сценарии, которые будут реализованы сейчас и могут быть реализованы в будущем.При реализации объектной модели клиентам рекомендуется ориентироваться на модель сервер-приложения.  ЛогикаУпрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте. Сначала продумайте тесты для алгоритма, получите альтернативные сценарии и предусмотрите обработку, а потом пишите сам алгоритм. Если какая-то часть алгоритма многократно повторяется, то скорее всего она должна быть выделена в отдельный модуль и переиспользоваться. Отдельный модуль — отдельный алгоритм.Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде. Не прячьте за методами в коде неявную логику. Неявные связи в реализации логики ведут к усложнению решения.Когда отдельные части программы нельзя перекомбинировать в новое целое, значит создан неэффективный монолит.  Нейминг решает Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.
 MVP и прототипыMVP — это быстро и просто, это способ сдвинуться с мертвой точки и начать показывать результат.MVP лучше, чем волшебное ничего и долгое обсуждение, как же все-таки надо сделать. Это отличный способ собрать фидбэк и неявные требования от пользователей, от других команд разработки, которые будут использовать ваше решение.  Рефакторинг Это придется делать. Это нормально и это важно. Даже для задач, выпущенных в продакшн совсем недавно.Своевременный рефакторинг ускоряет разработку. Больше времени сегодня на задачу, в рамках которой надо сделать рефакторинг, меньше времени на будущие задачи.Заботьтесь о том, чтобы в будущем код не вызывал страха и отвращения к рефакторингу. С ним должно быть приятно работать. Если нет четкой и понятной архитектуры, то программисты будут бояться даже заглянуть в код, чтобы понять как это работает. Рефакторингу может быть подвергнуто все, что связано с системой: код, модель данных, алгоритмы, тест-кейсы.  ДокументацияДокументация к системе должна дополнять программный код и хранить знания о причинах принятых архитектурных решений. Документация к системе позволяет без доступа к коду понимать, как работает программа: реализацию алгоритма, покрытие альтернативных сценариев, обработку ошибок. Но разработчикам должен быть понятен код и без документации на него.  ВыводыНе усложнять.Ничего не прятать.Называть все своими именами.Не стоять на месте.Не поддаваться отчаянию, если не получилось.Не забывать переосмысливать: смотреть через несколько дней свежим взглядом на готовое решение, если время позволяет. =========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_algoritmy ( Алгоритмы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 15:33
Часовой пояс: UTC + 5