Pull to refresh
142
0
Андрей Хитрин @zloddey

Человек-оркестр

Send message

Принципы непрерывного рефакторинга

Level of difficulty Hard
Reading time 23 min
Views 11K

Работа со старым кодом для многих команд является частью повседневных обязанностей. За свою карьеру я видел и применял разные способы борьбы с тяжестью легаси. Они обычно сводились к одному из трёх основных сценариев:

«Работает — не трогай!»: вообще забить на чистки и ничего не менять. В некоторых случаях валидный подход. Но в коде, который приходится менять хотя бы даже эпизодически (фиксы багов, мелкие доделки, смена окружения и т. п.), со временем неизбежно приводит к катастрофе. Вам надо что‑то поменять в коде, и это оказывается невозможно сделать легко. Даже за тривиальные изменения приходится платить большой кровью.

«Я прочитал Роберта Мартина»: включаем чистки в обычный код. Надеваем галстук бойскаута и чистим код прямо по ходу работы над текущими задачами. Отправляем его коллегам на ревью и ждём несколько дней, покуда они не разберутся, где заканчиваются рефакторинги и начинаются непосредственно изменения по задаче. Или же уходим по кривой дорожке рефакторингов в тёмный лес и продалбываем к чертям все изначальные сроки. Когда начинаешь приводить код к идеалу, не всегда бывает так легко остановиться!

«Нужен порядок и учёт»: делаем отдельные коммиты с чистками, но нерегулярно — только когда в дело берётся соответствующий тикет. Правда, тикеты на рефакторинг почему‑то регулярно получают самый низкий приоритет во время планирования и маринуются в беклоге месяцами. Но что уж тут поделать?

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

За прошедший год я нащупал и отточил ещё один подход, который лишён указанных недостатков. И теперь готов поделиться им с вами.

Читать далее
Total votes 22: ↑22 and ↓0 +22
Comments 20

Рабочий дневник программиста

Reading time 6 min
Views 53K

boat_journal
wikipedia.org


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

Читать дальше →
Total votes 37: ↑31 and ↓6 +25
Comments 90

Цели против ограничений

Reading time 4 min
Views 23K

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


Команды часто ошибочно принимают ограничения за цели. Типичнейший пример: команда принимает требования к продукту за свою цель, теряя из виду реальные потребности, которые изначально породили эти требования.


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


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

Читать дальше →
Total votes 41: ↑32 and ↓9 +23
Comments 32

Старая псина учит новые трюки: Code Kata с использованием QuickCheck

Reading time 13 min
Views 13K
Когда я агитирую коллег-программистов создавать больше различных автотестов на их код, они часто жалуются, что это сложная и унылая работа. И в чём-то они правы. При использовании классических юнит-тестов, действительно, нередко приходится писать уйму кода, чтобы проверить каждый отдельный случай поведения. Да и к качеству тестирования порой возникают вопросы, особенно в сложных системах, когда тривиальные сценарии использования проходят на ура, но на каких-то более сложных сценариях, на которые никто не подумал писать тесты, возникают неприятные проблемы.

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

В чём заключается QuickCheck-подход


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

Звучит многообещающе? Вполне.

Вот только с какого бока подойти к этому чуду...
Total votes 26: ↑22 and ↓4 +18
Comments 12

Изучение TDD через интенсивную практику

Reading time 11 min
Views 26K
Примечание от переводчика: мой опыт знакомства с разработкой через тестирование во многом схож с тем, что описывает автор (хотя и начался на несколько лет позже). Я начинал изучать TDD самостоятельно, на работе, исправляя баги и создавая новые модули с нуля. Эффект от применения TDD произвёл на меня настолько мощное впечатление, что породил желание делиться умением применять эту технику с другими. Я также проводил Code Retreat-ы внутри и вне своей компании. И я вижу те же проблемы в своих тренингах — очень сложно взять и «впихнуть» понимание сути TDD в чужие головы.

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


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

TL;DR?


Многие сторонники TDD рекомендуют подход под названием «интенсивная практика», но я догадываюсь, что у Вас не будет возможности тратить много рабочего времени на практику. Я советую людям «применять TDD осознанно», но до сих пор не знал хорошего способа достаточно доступно объяснить смысл этих слов, что снижало ценность моего совета. Вы можете начать применять оба подхода (интенсивный и осознанный) одновременно, если начнёте исправлять баги через тесты. Даже если Вы до сих пор не умеете проектировать софт на экспертном уровне, то, по крайней мере, Вы уже можете учиться как эксперт. И исправление багов через тесты даст Вам естественную и не слишком рискованную возможность делать это. У Вас будет возможность практиковаться в TDD усердно и осознанно. Если у Вас есть возможность исправлять баги на работе в одиночку, то Вы можете использовать эти практики, не привлекая лишнего внимания, которое обычно возникает при разговорах об «интенсивной практике». Просто говорите всем, что Вы исправляете баги. Это всем понравится.

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

Подробности
Total votes 25: ↑18 and ↓7 +11
Comments 9

Удачная модель ветвления для Git

Reading time 10 min
Views 975K
Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Читать дальше →
Total votes 180: ↑171 and ↓9 +162
Comments 105

Мысли вслух о протоколе X

Reading time 8 min
Views 18K
Два года назад, работая над Awesome, я присоединился к разработке XCB, который является частью инициативы Freedesktop. Мне пришлось изучить тайны протокола X11 и весь древний и таинственный мир, окружающий его.

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

Читать дальше →
Total votes 294: ↑283 and ↓11 +272
Comments 144

Information

Rating
4,321-st
Location
Екатеринбург, Свердловская обл., Россия
Date of birth
Registered
Activity