Рубрика «Проектирование и рефакторинг» - 64

Введение

В мире функционального программирования есть один большой пробел, а именно почти не освещена тема высокоуровневого дизайна больших приложений. Я решил для себя изучить этот вопрос. Есть ли существенные отличия дизайна приложений в ФП-мире от оного в мире императивном? Что такое «каноничный ФП-код»? Какие существуют идиомы разработки, есть ли смысл вообще говорить о паттернах проектирования в применении к ФП? Эти и другие важные вопросы часто вспыхивают то там, то здесь, но покамест мне не известно ни одной книги, аналогичной книге Банды Четырех. Вероятно, мои изыскания уже кто-то повторил, однако тем лучше: схожие результаты подтвердят правильность, иные — укажут на место в теории, которое необходимо доработать.
Читать полностью »

Шпаргалка по шаблонам проектирования
Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Читать полностью »

Перевод книги Эдди Османи «Паттерны для масштабируемых JavaScript приложений» В какой-то момент меня очень удивило что потрясающая и понятная книга о проектировании JavaScript приложений от известного автора до сих пор не переведена на русский язык. Вместе с единомышленниками мы перевели все главы. Сейчас мы внимательно вычитали 5 из них и хотим их показать всем, кто интересуется JS. Каждую неделю мы обещаем публиковать по 2 главы.

Прочитать книгу можно на сайте, который мы специально для нее создали, следить за обновлениями можно по RSS и в твиттереЧитать полностью »

Luxoft Training приглашает Вас на мастер-классы одного из лучших тренеров в области архитектуры и разработки ПО – Евгения Кривошеева!
Читать полностью »

Если спросить у десяти разработчиков о лучшей (или достойной) книге о проектировании, то как минимум 6 из них назовет книгу Боба Мартина «Принципы, паттерны и методики гибкой разработки». Если же после этого показать им на некоторые интересные моменты писанины «дядюшки» Боба, то большая часть из них с недоумением почухает лоб и несколько изменит свое мнение.

При чтении этой заметки стоит включить здравый смысл и не рассматривать ее, как нападки на святое. Ведь вполне возможно вы читали ее несколько лет назад, когда рубцов на руках от заваленных проектов было меньше, а при слове «паттерны» немного дрожали колени. Так может стоит посмотреть на «классику» с высоты нового опыта?

Читать полностью »

Обработка ошибок в RESTful приложениях
За последнее время очень многие веб-фреймворки обзавелись RESTful роутингом. Более того, REST стал де-факто стандартом проектирования архитектуры веб-приложений. Практически все более-менее значимые сервисы обзавелись RESTful API с представлением данных через xml и json форматы. Такой популярности REST помогло как появление большого количества руководств, так и горячие обсуждения REST среди специалистов.

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

Читать полностью »

Перевод статьи LOSING LOOSE COUPLING

монстр-трак велосипед Когда меня просят присутствовать на собеседованиях, я обычно задаю один вопрос кандидату: «Что такое хороший код?». Тревожит, что часто можно услышать от недавних выпускников: «Наличие хороших комментариев». Это неправильный ответ. Кто учит их этому? Пугающе. Но я отвлекся… Не думаю, что есть правильный ответ на мой вопрос, однако я бы принял что-нибудь вроде «сильное сцепление (high cohesion) и слабая связанность (loose coupling)». По крайней мере это что-то говорит о коде. Но если это собеседование Java разработчика, я не дам бедняге уйти без нескольких дополнительных вопросов. Потому что Java разработчики полностью обезумели. Они одержимы желанием порубить код на супер-пупер мелкие кусочки. Мы рубим и рубим до тех пор, пока практически ничего не останется. Как только маленькие дорогуши разделены мы начинаем беспокоиться о том, чтобы они не трогали друг друга. Ох, малышки! Мы должны защитить их друг от друга любой ценой. Каждый маленький кусок кода получает свой собственный интерфейс, чтобы он не мог замарать свои руки дотянувшись до других частей напрямую. Мы связываем их магическими фреймворками. Которые используют абстрактные прокси, создающие фабрики и так далее.

Представьте велосипед, сделанный по таким принципам. Рама порублена на кусочки, длиной 1 сантиметр, соединенных по типу позвоночника. Будет ли она более гибкой? Определенно — да. Будет ли она практичной? Конечно, нет. Она будет дороже в производстве в сотни раз. Она также будет ломаться в сотни раз чаще. Такой велосипед приведет к большему количеству несчастных случаев, и не в последнюю очередь, будет странно выглядеть и на нем будет трудно ездить. Наша спина должна быть гибкой, поэтому позвонки имеют смысл. Велосипеды — нет.
Читать полностью »

Вещи, которые мы хотим сделать «потом»
Известно, что ошибки проще не допускать, чем исправлять и чем позже найдена ошибка, тем сложнее ее исправить. Не смотря на это у всех нас есть менеджеры дедлайны и тот кусок кода, который надо бы исправить после релиза.

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

Если не хоите ходить по моим граблям, добро пожаловать под кат.Читать полностью »

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

Архитектурные слои

К сожалению на хабре нет статей описывающих что такое слои, но снаружи есть статья читателя primepix

Паттерн не привязан к языкам программирования.

Картинка для привлечения внимания:

Паттерн «VIP сервис»

Читать полностью »

Недавно я написал:

Для программных продуктов еще не придумали адекватные инструменты визуализации. Об этом говорил еще Брукс, почти 40 лет назад. Поэтому разработчики ПО часто уподобляются слепым монахам из буддийской притчи.

Следствие #5. Необходимость постоянных коммуникаций участников разработки.

Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени. У нас это называется «синхронизация ментальных моделей».

И вот, как это обычно выглядит.


Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js