Pull to refresh

Синдром рефакторинга

Designing and refactoring *
image
Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.
Читать дальше →
Total votes 59: ↑53 and ↓6 +47
Views 8.8K
Comments 40

Паттерны поведения

Designing and refactoring *
(Эта заметка является завершением серии постов, в которую вошли «Технический долг», «Синдром рефакторинга» и «Эффект второй системы»)

В чем польза паттернов проектирования? (*) Это, прежде всего, повторное использование проверенных архитектурных решений, а также упрощение коммуникаций между разработчиками. Но ведь помимо паттернов проектирования существует и масса других паттернов: существуют паттерны кодирования, тестирования, модификации кода (a.k.a. рефакторинг), существуют архитектурные паттерны и многие другие. Поскольку мы, на самом деле, редко делаем что-либо по-настоящему новое, то проверенные типовые решения существуют для огромного количества областей. И поскольку большинство проблем, с которыми сталкиваются команды разработчиков, также не отличаются разнообразием, то и поведение этих людей также весьма однообразно.

«Технический долг», «синдром рефакторинга» и «эффект второй системы» — это типовые ситуации, с которыми периодически сталкивается команда разработчиков. И главная польза от них как раз и заключается в том, чтобы увидеть проблему и доказать ее существование нужным людям. Если вы сами поняли, что технический долг проекта слишком велик, то используя денежную метафору будет уже значительно проще доказать важность этой проблемы менеджеру или заказчику. А затем взвешенно показать ему альтернативные пути развития событий: (1) оставить все, как есть; (2) уменьшить технический долг путем разумного рефакторинга или (3) переписать все нафиг.
Читать дальше →
Total votes 34: ↑24 and ↓10 +14
Views 5.5K
Comments 8

Код в стиле «дамп потока сознания»

Perfect code *
Некоторое время назад в одной из своих статей я описал понятие пластилиновой архитектуры. В продолжение я бы хотел описать один из самых распространённых «стилей программирования», который, к сожалению, очень часто встречается у молодых и неопытных специалистов.

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

Всё бы ничего. Я ничего не имею против кофе, наушников или состояния потока. Более того, обычно это наиболее эффективный и, зачастую, единственный способ писать хороший код. Но мы рассматриваем типичный случай молодого и неопытного программиста, поэтому давайте посмотрим на результаты.
Читать дальше →
Total votes 103: ↑87 and ↓16 +71
Views 8.4K
Comments 119

Новый рекорд Хабра: статья с рейтингом +13 — среди лучших за 24 часа

Habr
В ночь перед последним выходным длинных зимних каникул замечена самая низкая температура посещаемости сайта. В ленте «Все — новые» — 10 статей (это число зависит от подписок на ряд закрытых блогов, но, всё же — показатель). Но главный показатель рекорда — это порог вхождения в список «Лучшие за 24 часа» из 10 статей. В эту тёмную зимнюю ночь порог вхождения в этот список «Топ10» спустился до 13 единиц! Скриншот, зарегистрировавший это событие в 6 часов утра, находится ниже.
Смотреть
Total votes 96: ↑38 and ↓58 -20
Views 454
Comments 11

Программирование в стиле русских романов

Инфопульс Украина corporate blog Programming *Perfect code *
Translation


Одна из вещей, которая делает классические русские романы столь тяжелыми для чтения (для иностранцев) это то, что главные герои имеют кучу имён. К примеру, в романе "Братья Карамазовы" один из персонажей — Алексей Фёдорович Карамазов (Alexei Fyodorovich Karamazov), которого по ходу текста называют также Алёша, Алёшка, Алёшенька, Алёшечка, Алексейчик, Лёша и Лёшенька (Alyosha, Alyoshka, Alyoshenka, Alyoshechka, Alexeichik, Lyosha и Lyoshenka)

«Программирование в стиле русских романов» — это антипаттерн, возникающий в ситуации, когда одна вещь имеет много имён. Для какой-нибудь программы у вас может быть путь в системе контроля версий, путь на диске, имя проекта, имя исполняемого файла и т.д. Все они могут иметь одинаковые (однокоренные) имена или наоборот — называться каждая по-своему. Например, синонимами. Или вообще разными словами. Так уж вышло по историческим причинам, что бинарник foo.exe получается при компиляции проекта bar, лежащего в папке baz и т.д.
Читать дальше →
Total votes 79: ↑56 and ↓23 +33
Views 27K
Comments 42

Что плохого в работе на результат

GTD *
Все чаще приходится слышать: "Работай на результат!"

"Работай на результат!" — кричит начальник подчиненному, чтобы заставить этого тупого неповоротливого кретина, принятого в команду по протекции, приносить хоть какую-то пользу общему делу.

"Мы работаем на результат!" — бахвалится бригада голодных гастарбайтеров, надеясь, что, если они будут кричать именно это, их предложение хотя бы немного выделится среди гула голосов тысяч голодных и безработных.

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

Культ карго. Мало кто из произносящих эту фразу может внятно объяснить, какой смысл в неё вкладывается. Люди верят в неё, как в волшебную формулу, заклинание, они пихают её куда ни попадя, надеясь, что она придаст им уникальность, выделит их из толпы таких же неудачников. Организации, Компании, конторы да и откровенные «шараги» не мыслят себя без этого лозунга. Как же это, «Рога и копыта» работают на результат, а мы, что, хуже?



А хуже ли?
Осторожно! Тентакли под катом!
Total votes 255: ↑227 and ↓28 +199
Views 110K
Comments 175

Читабельный тест

Programming *C++ *TDD *
Sandbox

Вступление

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

Юнит. Что это такое?

Unit testing принято переводить на русский язык как модульное тестирование. Однако слово «модуль» имеет несколько другой смысловой оттенок, ассоциирующийся со схемой развертывания. Поэтому во избежание ненужных ассоциаций будем использовать англицизм «юнит». Еще раз вспомним, что такое юнит в рамках терминологии юнит тестирования:

Юнит – это фрагмент кода, дающий в данном окружении при определенных входных данных определенные выходные данные.

определение юнита
Заметим, что кроме самого юнита остальные все компоненты этого определения могут быть вырождены в пустое множество, однако чем больше пустых участников в этой заварухе, тем меньше смысла (семантики) содержится в юните.
Читать дальше →
Total votes 11: ↑10 and ↓1 +9
Views 13K
Comments 10

Паттерны и антипаттерны Chef

EPAM corporate blog
Translation

Предисловие от переводчика


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

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

Статья будет полезна как для видавших виды «поваров», так и для новичков.
Читать дальше →
Total votes 14: ↑11 and ↓3 +8
Views 11K
Comments 38

Дизайн и архитектура в ФП. Часть 2

Designing and refactoring *Haskell *Functional Programming *
Tutorial
Восходящее проектирование в ФП. Идея — основа хорошего дизайна. Антипаттерны в Haskell.

Немного теории

В прошлой части мы построили высокоуровневую архитектуру приложения. Мы определили подсистемы и их связи, а также разделили программу на три слоя: Application, Game Logic, Views. По логике, следующий этап — дизайн приложения. По важности этот этап не уступает предыдущему, так как именно в ходе дизайна мы должны поддержать все функциональные требования, определить фактическую структуру подсистем, описать основные технические проблемы, применить какие-либо типовые решения или придумать другие. Но прежде попробуем ответить на вопрос: каков он, хороший дизайн ПО? По каким критериям мы определяем «хорошесть» дизайна?
Читать дальше →
Total votes 32: ↑28 and ↓4 +24
Views 12K
Comments 5

Антипаттерны проектирования: Poltergeists

Programming *Perfect code *Designing and refactoring *ООP *
Translation
«Я точно не знаю, что делает этот класс, но я уверен, что это важно!»

У паттернов проектирования — типовых решений, есть антиподы — типовые ошибки в проектировании. О паттернах проектирования написано достаточно книг, о антипаттернах — единицы. Вашему вниманию представлен вольный перевод статьи с сайта SourceMaking, описывающий один из таких антипаттернов (всего на сайте в разделе Software Development Antipatterns их представлено 14).

Наименование: Poltergeists (полтергейсты)
Другие наименования: Gypsy (цыган), Proliferation of Classes (рост количества классов), Big DoIt Controller Class
Масштаб: приложение
Рефакторинг: Ghostbusting (охота за привидениями)
Причина появления: непонимание концепций ООП, лень продумать архитектуру классов
Читать дальше →
Total votes 43: ↑30 and ↓13 +17
Views 34K
Comments 21

Дизайн и архитектура в ФП. Часть 3

Designing and refactoring *Haskell *Functional Programming *
Tutorial
Свойства и законы. Сценарии. Inversion of Control в Haskell.

Совсем немного теории

В прошлой части мы убедились, что очень легко запутаться в плохо спроектированном коде. К счастью, с древних времен нам известен принцип “разделяй и властвуй”, — он широко применяется при построении архитектуры и дизайна больших систем. Мы знаем разные воплощения этого принципа, как-то: разделение на компоненты, уменьшение зависимости между модулями, интерфейсы взаимодействия, абстрагирование от деталей, выделение специфических языков. Это хорошо работает для императивных языков, и надо полагать, что будет работать в функциональных, за тем исключением, что средства реализации будут другими. Какими же?
Читать дальше →
Total votes 20: ↑17 and ↓3 +14
Views 12K
Comments 6

Немного креатива — календарь с антипаттернами

НТЦ Метротек corporate blog Website development *LaTeX *
Всем привет!

Пост повышенной несерьёзности, ибо пятница.
Хочу рассказать про антипаттерны, которые выкристаллизовались в нашей компании. Just For Fun.

Каждый раз, когда разработчики/монтажники/схемотехники применяли повторяющуюся отмазу, её фиксировали и заносили в список. Когда список вырос и в нём появилось почти 12 отмазок, нам пришла в голову идея сделать свой календарь с антипаттернами (поскольку отмазки иллюстрируют то, как не стоит думать и делать, приравниваем их к антипаттернам). Для этого нам предстояло осилить вёрстку календаря и к каждому анти-паттерну «родить» соответствующую картинку. Вёрстку делали в LaTex'е, а картинки — в inkscape, в svg-формате. В-общем, получилось вполне open-source'но. Но пост всё-таки больше не о технической реализации, а о самих анти-паттернах. Кому интересно, добро пожаловать.
Читать дальше →
Total votes 60: ↑40 and ↓20 +20
Views 28K
Comments 37

Null, великий и ужасный

Programming *.NET *Designing and refactoring *C# *ООP *

Ошибка дизайна


Именно так и никак иначе: null в C# — однозначно ошибочное решение, бездумно скопированное из более ранних языков.


  1. Самое страшное: в качестве значения любого ссылочного типа может использоваться универсальный предатель — null, на которого никак не среагирует компилятор. Зато во время исполнения легко получить нож в спину — NullReferenceException. Обрабатывать это исключение бесполезно: оно означает безусловную ошибку в коде.
  2. Перец на рану: сбой (NRE при попытке разыменования) может находится очень далеко от дефекта (использование null там, где ждут полноценный объект).
  3. Упитанный пушной зверек: null неизлечим — никакие будущие нововведения в платформе и языке не избавят нас от прокаженного унаследованного кода, который физически невозможно перестать использовать.

Этот ящик Пандоры был открыт еще при создании языка ALGOL W великим Хоаром, который позднее назвал собственную идею ошибкой на миллиард долларов.

На самом деле все не так плохо
Total votes 56: ↑45 and ↓11 +34
Views 118K
Comments 290

Наследование реализаций: закопайте стюардессу

Programming *.NET *Designing and refactoring *C# *ООP *

Ключевое противоречие ООП


Как известно, классическое ООП покоится на трех китах:


  1. Инкапсуляция
  2. Наследование
  3. Полиморфизм

Классическая же реализация по умолчанию:


  1. Инкапсуляция — публичные и приватные члены класса
  2. Наследование — реализация функционала за счет расширения одного класса-предка, защищенные члены класса.
  3. Полиморфизм — виртуальные методы класса-предка.

Но еще в 1986 году была обозначена серьезнейшая проблема, кратко формулируемая так:


Наследование ломает инкапсуляцию

Как такое может быть?
Total votes 71: ↑52 and ↓19 +33
Views 45K
Comments 349

Большой комок грязи

System Analysis and Design *Designing and refactoring *Development Management *
Sandbox
Привет, Хабр! Представляю вашему вниманию перевод статьи "Big Ball of Mud" авторов Brian Foote и Joseph Yoder.

От переводчика: Статья Big Ball of Mud написана Брайаном Футе и Джозефом Йодером летом 1999 года. Она рассказывает о наиболее распространённых антипаттернах разработки ПО, причине их возникновения и развития. Несмотря на то, что с момента публикации прошло больше 18 лет, описанные проблемы никуда не пропали, так что большая часть написанного актуальна и по сей день. Это первая часть статьи из трёх, остальные я надеюсь выложить в ближайшее время.

Введение


В последние годы сразу несколько авторов [Garlan и Shaw, 1993] [Shaw, 1996] [Buschmann и другие, 1996] [Meszaros, 1997] представили паттерны, которые характеризуют архитектуру ПО высокого уровня, например, PIPELINE (конвейер) и LAYERED ARCHITECTURE (многоуровневая архитектура).

В идеальном мире все системы были бы образцом одного или более подобных шаблонов высокого уровня. Тем не менее, в реальной жизни все не так. Архитектура, которая на данный момент является доминирующий, до сегодняшнего дня ещё не обсуждалась. Речь идет о BIG BALL OF MUD или БОЛЬШОМ КОМКЕ ГРЯЗИ.
Читать дальше →
Total votes 16: ↑15 and ↓1 +14
Views 14K
Comments 4

Большой комок грязи, часть 2

System Analysis and Design *Designing and refactoring *Development Management *
Продолжение перевода статьи «Big ball of Mud».

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


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

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

То же самое происходит и с прототипированием системы — вы не сильно переживаете о том, насколько красив и эффективен ваш код. Вы знаете, что код нужен вам только для того, чтобы показать работающий прототип. Как только он готов, код будет выброшен и прописан заново уже более тщательно. Когда подходит время демонстрации, возникает непреодолимое желание нагрузить его крутыми, но, по сути, бесполезными функциями. Иногда такая стратегия бывает “принести успешной”. Клиент, вместо того чтобы спонсировать разработку следующего этапа проекта, остается доволен прототипом.
Читать дальше →
Total votes 13: ↑13 and ↓0 +13
Views 7.4K
Comments 2

Вредные советы: как превратить автоматизацию UI-тестов в кошмар

Badoo corporate blog IT systems testing *Programming *Web services testing *Mobile applications testing *
Translation


Привет! Меня зовут Артём, и я занимаюсь автоматизацией тестирования. Антипаттерны в разработке — довольно популярная тема. Но ведь в тестировании тоже есть свои "плохие советы", и они довольно забавно пересекаются с разработкой. Недавно мне на глаза попалась ироничная статья про антипаттерны в тестировании. Вашему вниманию!


Мы стараемся как можно скорее доказать, что неправы, потому что только таким образом можем развиваться.
Ричард Фейнман

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


Ну, а если вы добрая душа и уважительно относитесь к чужому труду, то можете рассматривать эту статью как набор антипаттернов.


Итак, поехали.

Читать дальше →
Total votes 35: ↑33 and ↓2 +31
Views 13K
Comments 11

Открытый вебинар «Как не нужно писать на Python»

OTUS corporate blog Python *Programming *
Всем привет! В рамках нашего курса «Разработчик Python» мы провели ещё один открытый урок на тему «Как не нужно писать на Python». Занятие вёл преподаватель и создатель курса Станислав Ступников, имеющий большой опыт промышленной и научной разработки. Рассматривались антипаттерны программирования, bad practice и прочее зло, о котором нужно знать и которого следует избегать в процессе написания кода.

Подробности смотрите в видео и кратком изложении. Внимание: некоторые примеры кода не рекомендуется запускать на своём компьютере!

Total votes 19: ↑15 and ↓4 +11
Views 14K
Comments 10

Архитектура как бремя

System Analysis and Design *Perfect code *Designing and refactoring *ERP-systems *Project management *
Translation

За время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.


Разумеется, часто главной проблемой было низкое качество программного обеспечения (отсутствие модульных тестов, отказ от использования принципов чистого кода…), но были также и трудности, чьим источником являлись архитектурные решения, принятые в начале работы над проектом или даже в период зарождения корпоративной системы. На мой взгляд, этот класс проблем является причиной наибольшей боли для многих проектов.


В сущности, улучшение кода — дело довольно простое, особенно сейчас, когда движение за мастерство разработки ПО (software craftsmanship) продвигает хорошие практики в командах. Однако изменение стержневых частей систем, ограничений, введенных в самом начале их жизненного цикла, является чрезвычайно сложной задачей.


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


Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 7.1K
Comments 35

ООП мертво, да здравствует ООП

Programming *Designing and refactoring *ООP *
Translation
image

Источники вдохновения


Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).
Читать дальше →
Total votes 55: ↑50 and ↓5 +45
Views 55K
Comments 45
1