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

В этой статье я хочу поделиться своим личным опытом, связанным с правильной организацией кода (архитектурой). Правильная архитектура существенно упрощает долгосрочную поддержку.
Это очень философская тема, поэтому я не могу предложить ничего более, чем мой субъективный анализ и опыт.

Проблемы, симптомы

Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.
Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.
У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.
Читать полностью »

Если вы уже не первый год ведете какой-то проект, поверьте не похож ли он на нож мясорубки из истории №1 или на тарелку из истории №2

Это поможет вам оптимизировать свой проект выкинув из него все лишнее, что только тормозит его.

История №1

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

Дело в том, что по технологии нож затачивался с двух сторон, во-первых, со стороны, которая прилегает к сетке (параллельно сетке), во-вторых, с тыльной стороны под углом к сетке. И если с первой частью проблем не было (на наждак укладывали сразу несколько ножей и точили), то вот вторая операция выполнялась исключительно вручную, что было низкопроизводительно и крайне опасно для рабочего.

В 1987 году отдел роботизации и автоматизации завода «Электросила» разработал безумно дорогого супер-робота, который точно повторял движение рук рабочего (напоминаю, что это было 30 лет назад (!)), но его производительность оказалась столь малой, что рабочего вернули на заточку, чуть ли не на следующий день.

Для решения проблемы, был вызван внешний консультант из одного НИИ. Консультант начал свою работу, естественно с анализа….
Читать полностью »

Привет!

Сегодня мы вернемся к одной из тем, затрагиваемых в нашей замечательной книге "Реактивные шаблоны проектирования". Речь пойдет об Akka Streams и потоковой передаче данных в целом — в книге Роланда Куна этим вопросам посвящены главы 10 и 15-17.
Читать полностью »

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

Вместе с Игорем Беспальчуком постараемся посмотреть на этот тренд с трех разных ракурсов, что очень полезно для понимания природы того, с чем мы имеем дело, и, как следствие, для того, чтобы сделать правильные выводы и принять правильное решение.

Микросервисы — одна из самых важных и значимых составляющих Web-scale архитектуры, имеющая наибольшие последствия для переделки устройства техник и паттернов в Enterprise. Трудно сейчас сказать, на каком участке сейчас находится сама технология — может быть, на самом верхнем пике, и нам предстоит еще десять раз разочароваться. Но, тем не менее, это не повод не изучать её прямо сейчас.
Читать полностью »

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

Держим дизайн системы под контролем, используя изолированное юнит-тестирование - 1

Сегодня мы поговорим о том,

  • Как делать тестирование сложными зависимостями?
  • Как добиться большого тестового покрытия?
  • Как тесты влияют на дизайн?
  • Что делать, когда много логики в базе?
  • Как соблюсти компромисс между дизайном и «не дизайном».

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

Продолжение перевода статьи «Big ball of Mud».

ОДНОРАЗОВЫЙ КОД

он же
QUICK HACK (быстрый хак)
KLEENEX CODE (код на салфетке)
DISPOSABLE CODE (утилизируемый код)
SCRIPTING (скрипт)
KILLER DEMO (демо-убийца)
PERMANENT PROTOTYPE (постоянный прототип)
BOOMTOWN (быстро выросший город)

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

То же самое происходит и с прототипированием системы — вы не сильно переживаете о том, насколько красив и эффективен ваш код. Вы знаете, что код нужен вам только для того, чтобы показать работающий прототип. Как только он готов, код будет выброшен и прописан заново уже более тщательно. Когда подходит время демонстрации, возникает непреодолимое желание нагрузить его крутыми, но, по сути, бесполезными функциями. Иногда такая стратегия бывает “принести успешной”. Клиент, вместо того чтобы спонсировать разработку следующего этапа проекта, остается доволен прототипом.
Читать полностью »

Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомиться в оригинале). Перевод второй — по ссылке. И так как он вызвал БЕШЕННЫЙ ажиотаж(целых ДВА человека подискутировали со мной в комментах), то не перевести третью было бы преступлением.

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

  • Домен
  • Прикладной слой
  • Инфраструктура

Сейчас, подробно рассмотрим инфраструктурный слой.

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

Размышлял как-то о коде, программировании и всём таком; бродили всякие мысли. А что если взять, например, и заставить двух разработчиков написать несложные программы по одному ТЗ. Программисты одинакового уровня. Пишут независимо друг от друга. Код у них, естественно, получится разный. Однако если вытащить из кода каждой программы строчки, выполняющие реальную работу (преобразования исходных данных в необходимый результат), и свалить их в две большие «кучи», то эти «кучи» вроде бы должны оказаться сильно похожими. Потому что исходя из поставленной задачи оба программиста, наверное, применят похожие вычисления и преобразования данных. (На самом деле это маловероятно, так как и алгоритмы тоже, скорее всего, будут выбраны разные.)

Тогда и появилась эта безумная аналогия.

Весь код, который выполняет реальную работу: производит вычисления, преобразует данные, проверяет условия и т. д. — это «мясо». «Мышцы» программы. Код, который отвечает за структуризацию — «сухожилия». То, с помощью чего мышцы крепятся к костям. Начало и конец мышцы, альфа и омега. То, благодаря чему каждый отдельный мускул остаётся самостоятельным, а не слипается в бесформенный фарш. А что тогда «кости»? Кости, подумалось мне, — это, наверное, архитектура программы.

Анатомическая метафора кода. Где у кода мускулы - 1

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

Не все позиции, представленные на витрине Crossover однозначно понятны потенциальным партнёрам. И если вакансии C++ Software Engineer или Java Software Engineer вопросов не вызывают, то с Chief Software Architect всё не так и просто. Вообще, кто такие архитекторы ПО чёткого определения нет и от компании к компании их функции и описания разнятся. Сферический Software Architect (SA) в вакууме определяет архитектурный шаблон/парадигму, отвечает за разбиение на технические подсистемы/слои/компоненты/модули, выбирает средства исполнения и занимается разработкой технических сценариев. От места к месту функции могут добавляться или исчезать, но в целом работа Software Architect заключается именно в этом.

Из точки А в точку Chief - 1

Хоть общие принципы и существуют, проекты обычно так сильно отличаются друг от друга, что из раза в раз Software Architect приходится заново изучать спецификации, используемые технологии и решения, определять подзадачи и искать способы их выполнения.

Если вам вдруг показалось, что к этому меню не хватает разве что щепотки менеджмента, то Chief Software Architect (или если сокращенно, то просто CA) — это для вас. Туда входят уже такие ингредиенты, как создание масштабируемых решений, контроль процесса разработки, контроль работы команды и персональная ответственность за результат в целом. Многим хотелось бы знать, откуда такие люди берутся. В случае Crossover: из вагонов метро и магазинов меховых изделий. По крайней мере, если судить по трудовым биографиям двух действующих Chief Software Architect компании Optiva Руслана Пещука и Евгения Конурбаева.
Читать полностью »

Возможно, вы уже слышали про компанию Booking.com, что они много экспериментируют и часто деплоятся без тестирования. И еще, что есть один большой репозиторий на 4 Гб, в нем 4 миллиона строчек перлового кода, и вообще монолитная архитектура.

В то же самое время Booking.com меняется. Нельзя сказать, что это кардинальное скачкообразное изменение, но медленное и уверенное преображение. Меняется стек, постепенно внедряется Java в тех местах, где это актуально. В том числе термин сервис-ориентированная архитектура (SOA) слышится все чаще и чаще во внутренних дискуссиях.

Далее рассказ Ивана Круглова (@vian) об этих изменениях с точки зрения взаимодействия внутренних компонентов на Highload Junior ++ 2017. Попав в западню циклически зависимых воркеров пришлось качественно разобраться, что к чему, и какими средствами можно все это исправить.

SOA: послать запрос на сервер? Что может быть проще? - 1
Читать полностью »


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