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

Рефакторинг приложения с десятилетним легаси за три месяца. Опыт Яндекс Музыки - 1

Однажды ты просыпаешься и понимаешь: избыточность компонентов и рассинхронизация в твоём приложении начинают вредить пользователям. Однажды ты смотришь на написанное давным-давно ядро, плачешь горькими слезами, и приходит это некомфортное, но вместе с тем немного соблазнительное ощущение — что рефакторинг назрел. Добро пожаловать на экскурсию по рефакторингу Музыки, начиная с ресёрча и заканчивая эксплуатацией! Я покажу вам реальный код и постараюсь в деталях вспомнить, как мы формировали требования к механизмам и разрабатывали их, рисовали у себя в голове и в коде границы ядра, по одной переделывали очереди и внедряли то, что получилось, в SDK.
Читать полностью »

Хаос всегда возрастает. Возрастает непрерывно и неотвратимо. Так гласит второй закон термодинамики: в любой замкнутой системе энтропия – мера хаоса – увеличивается, пока та не достигнет термодинамического равновесия – состояния полной неопределённости, когда ничего нельзя предвидеть и всё ведёт себя предельно беспорядочно. Мы, живые организмы, не являемся замкнутыми системами, и сдерживаем рост энтропии внутри себя за счёт увеличения его снаружи – пока можем. И программные проекты имеют с нами много общего: они тоже вынуждены тратить внешние ресурсы (силы разработчиков, CPU на оверхед абстракций), чтобы сдерживать непрерывно растущую энтропию – иначе в какой-то момент они теряют способность достаточно быстро адаптироваться к изменяющейся действительности и умирают.

Программист и энтропия - 1
Какаду воспринимают тезис про увеличение энтропии снаружи слишком буквально.

Что такое энтропия в контексте программного кода? Википедия приводит восемь разных определений энтропии в разных науках и все они ограниченно применимы в нашем случае, так что я не берусь дать формализованный ответ на этот вопрос. Но при принятии архитектурных решений и написании кода я всё чаще задумываюсь о последствиях в терминах энтропии, так что приглашаю и вас в свой чудный мир сомнительных аналогий.Читать полностью »

Для тех, кто читает не далее второго абзаца: я не говорю, что любое ООП - это плохо! ООП, особенно классическое полиморфное ООП, заслуженно имеет своё место в реальных проектах. Ниже речь поидёт про частный случай (анти)паттерна, который я периодически встречаю: использование классов там, где могли быть простые свободные функции.

Начало

Довольно часто у студентов, изучающих C++ в определённых учебных кругах, складывается мировоззрение о том, что всё должно быть объектами. Попросите их написать программу, которая считает некоторое значение - и они начнут с создания объекта ValueComputer и метода vc.computeResult()Читать полностью »

SOLID – это не правила, а гайдлайны - 1

В этой статье автор высказывает личное мнение, сформулированное на основе его собственного опыта и вкуса. Поэтому просьба не обижаться, если вы с ним не согласны. Конечно, оно может быть ошибочным – но это и стоит обсудить. 

Что такое SOLID ?

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

Как гласит Википедия:

«Спецификация» в программировании  — это шаблон проектирования, посредством которого представление правил бизнес логики может быть преобразовано в виде цепочки объектов, связанных операциями булевой логики.

Реализация и преимущества данного шаблона уже были описаны в нескольких статьяхЧитать полностью »

В статье "Пережить великую нехватку переменных" (Outliving the Great Variable Shortage) Тим Оттингер формулирует закон Кёрли:

«Переменная должна означать только что-то одно. Она не должна означать "что-то при таких-то условиях" и иметь разный смысл в разных обстоятельствах. Также она не должна иметь два смысла одновременно. "За двумя зайцами погонишься – ни одного не поймаешь". Переменная должна означать что-то одно все время своего существования»

Седого ковбоя Кёрли Уошбурна в комедии 1991 года "Городские пижоныЧитать полностью »

Всем привет! Меня зовут Игорь Савин, я frontend-разработчик в компании Домклик. На текущий момент у нас около 100 различных команд разработки, из которых большая часть создает какой-либо фронтенд на HTML, CSS и Javascript. Но когда так много команд, непременно возникают ситуации, при которых в проект одной команды нужно встроить какую-то функциональность, разрабатываемую другой. И не просто встроить, но и потом поддерживать её работу, исправлять ошибки и внедрять новые фичи.

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

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Я рекомендую сначала ознакомиться с Базовыми видео, от основателя этого термина Эрика Эванса, чтобы понять его философию и причины возникновения.

Основы DDD от основателя. Видео.

Прим. перев.: в этом материале, опубликованном прошлой весной в блоге Dropbox, инженеры компании рассказывают о том, какие проблемы были у их монолита, жившего аж с 2007 года, что они предприняли для их решения и какой результат это принесло.

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

Зарубежный опыт: как избавиться от 80% кода, увеличить скорость разработки и уменьшить количество ошибок - 1

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


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