За 15 лет работы разработчиком я обнаружил, что ложные убеждения о человеческой природе — основные враги хорошей декомпозиции. Если знать о них и стремиться не угодить к ним в ловушку, со временем можно сформулировать советы по созданию качественной декомпозиции. Так произошло со мной, и я спешу поделиться этим знанием.
На определенном этапе изучения новой технологии начинаешь задаваться вопросом, как правильно организовать архитектуру проекта. Мне в свое время повезло - попались опытные наставники, которые дали мудрые советы. Однако я считаю, что знания не должны лежать мертвым грузом, поэтому пишу эту статью в помощь начинающим (и не только) flutter-разработчикам.
Чистая архитектура - это концепция построения архитектуры систем, предложенная Робертом Мартином - в миру "дядюшка Боб". Концепция предполагает построение приложения в виде набора независимых слоёв, что облегчает тестирование, уменьшает связность и делает приложение более простым для понимания.
Flutter - стремительно набирающий популярность фреймворк для разработки кроссплатформенных приложений. В списке поддерживаемых платформ - iOS, Android, web, в бете находится поддержка десктопа.
Под катом - рассказ о том, как построить flutter-приложение с использованием идей чистой архитектуры.
Это расшифровка выступления на TechLeadConf 2020-06-09. Прежде чем начнем, попробуйте ответить для себя на вопрос какие у вас ожидания от взаимодействия с инфраструктурой? Например сколько времени займет:
А теперь умножьте свои ожидания на двое, и вы получите суровую реальность. Не приятненько как-то, да?
Рассказываем о самых распространенных шаблонах в архитектуре ПО. Разбираемся с контекстом и решаемыми задачами, обсуждаем достоинства и недостатки.
- Многоуровневая архитектура
- Каналы и фильтры
- Клиент — сервер
- Модель — представление — контроллер
- Управляемая событиями архитектура
- Архитектура на основе микросервисов
В Яндексе я руковожу службой общих интерфейсов. О них и поговорим. О том, как трудно (но приходится) делать что-то для всех. Позволю себе аналогию: сидишь, пишешь код и захотел пить. Налил себе сразу три стакана из одной бутылки, даже от клавиатуры не отрываясь. А если, к примеру, бутылка оказалась пустой, можно не пить. И по стаканам не разливать. Но если кто-то другой попросит, то придётся идти, ставить чайник, спрашивать: чай или кофе, чёрный или с молоком, нужен ли сахар, — если нужен, то сколько, резать бутерброды… Это намного сложнее. А когда задача — разработать общие компоненты, всё становится совсем сложно. Но мы попробуем разобраться.
Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.
В этой статье автор предложил написать свои книги, которые относятся к разряду неувядающей классики. Если в оригинальной статье был сделан упор на электронику, то у меня будет упор на разработку программ.
Disclaimer: это мой личный топ из тех книг, которые я лично прочитал, и у которых первое издание было в прошлом веке, даже если она переиздавалась недавно (при условии актуальности именно того издания, которое было в прошлом веке).
В данном топе книги не упорядочены по важности, они все очень хорошие, но есть одна книга, которая равнее других.
Это продолжение текста про архитектуры интерпрайз-систем. Рассуждения это хорошо, но какой в них толк без практического применения. Я покажу свой фреймворк в деле.
Всё началось с того, что я рассказывал про проблематику проектирования приложений на .NET и ныл про нелёгкую жизнь в кровавом интерпрайзе. Затем я описал решение, которое сам придумал и реализовал — Reinforced.Tecture. То была теория, концептуальные рассуждения, визионёрство и снова нытьё. На этот раз о том, что на дворе 2020 год, а HKT в C# так и не завезли.
Сегодня я продемонстрирую свой подход в действии на примере простенького проекта и покажу профиты, которые он даёт: от сокращения количества кода до автоматизации тестирования и оригинального подхода к документации. Как советовал старина Торвальдс: "Болтовня ничего не стоит, покажите мне код".
