Как вы объясните рефакторинг нетехническому человеку?

Как вы объясните рефакторинг (и технический долг) нетехническому человеку (обычно PHB или клиенту)? («Что, это будет стоить мне месяц вашей работы без видимой разницы ?!»)

ОБНОВЛЕНИЕ Спасибо за все ответы до сих пор, я думаю, что этот список предоставит несколько полезных аналогий, на которые мы можем указать соответствующих людей (хотя редактирование ссылок на PHB может быть мудрым!)

Когда у вас большой домашний кинотеатр, и вы добавляете вещи, медленно, но верно гнездятся большие крысы сзади.

Если вы часто заменяете детали, иногда стоит исправить все это.

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

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

Рефакторинг подобен процессу переупаковки чемодана, пока все не уместится аккуратно. Иногда, в процессе, вы удивляетесь, почему вы пытаетесь получить так много мусора для начала.

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

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

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

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

Однако, если вы платите 25% по такому кредиту, вы ставите себя на неустойчивую позицию. Это то же самое с техническим долгом. Иногда имеет смысл взять на себя некоторые технические долги. Однако наступает момент, когда проценты слишком высоки, и их нужно окупать. Некоторый технический долг похож на домашний заем, а некоторые - на кредитную карту. В чрезвычайных ситуациях задолженность по кредитной карте является важным и ценным активом. Тем не менее, это может также сломать банк (или домохозяйство, если вы выберете), если используется неразумно.

Другой пример: вы можете заплатить 10 000 долларов за рекламную рассылку, чтобы в будущем получить больше потенциальных клиентов. Вы расплачиваетесь "долгом по продажам". Это расходы с долгосрочной выплатой. Приравнивайте это к тому, почему вы хотите «тратить» деньги на рефакторинг фрагмента кода. В обоих случаях нет немедленной отдачи, но вы настраиваетесь на лучшую производительность в будущем.

Я склонен использовать термин «долг хххх» в качестве аналогии при общении с целевой аудиторией. Например, операционная задолженность. Теперь у нас есть хорошо работающая печатная машина, но, остановив производство на один день (или одну неделю) и перейдя на новую машину, мы можем увеличить производительность на 25%.

РЕДАКТИРОВАТЬ - Вот еще один взгляд на это

Весенняя уборка.

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

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

Вы можете удивиться, почему мы позволяем ему начать выглядеть как Mouse Trap в первую очередь:

• Иногда что-то сделать прямо сейчас означает, что мы должны пожертвовать элегантностью и эффективностью, чтобы просто «заставить это работать».
• Языковые возможности и другие технологии, доступные нам как программистам, часто меняются. Иногда новые функции позволяют нам заменять одну из шести движущихся частей одной.
• Часто, когда мы добавляем функцию C к функциям A и B, мы не знаем, что B в конечном итоге будет удалено, а D добавлено. Один из способов достижения C может очень хорошо работать с B, но не очень хорошо с D.

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

Это немного более графическая версия аналогии с домашним кинотеатром.

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

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

Но при каждом добавлении становится все труднее найти решение. И вы подвергаете себя риску ¹ пожара [он-лайн жучки], и вам придется вытащить большие деньги, чтобы заплатить кому-то, чтобы он вставил новые розетки в стену, что вполне может перерасти до самого главного печатная плата, или даже дальше.

¹ Другое дело PHBs не обращал внимания на очень хорошо: «Ну , если это только может случиться, что вы беспокоиться о?»

Рефакторинг - это все равно что организовать свой шкаф для одежды / ящик для инструментов.

• Вы не выбрасываете свою одежду / инструменты только потому, что они повсюду.

• Можно утверждать, что они никогда не должны быть дезорганизованы. Но они делают.

Так же, как и код. Тем более, что со временем оно растет.

И если вы не очистите его, вы будете удивляться, что случилось с той футболкой, которую вы любили, или с тем гаечным ключом, который вам нужен всегда, но вы никогда не найдете!

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

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

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

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

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

Через месяц он возвращается, на этот раз ему нужна система освещения, и он хочет, чтобы новые динамики повредили старые в начале недели.

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

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

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

Программное обеспечение то же самое, за исключением того, что программисты могут играть с цифровой клейкой лентой ОЧЕНЬ долгое время, прежде чем клиенты и менеджеры почувствуют эффект. К сожалению, к тому времени стоимость повторного выполнения правильных действий возрастает в геометрической прогрессии в зависимости от количества клейкой ленты и ее среднего возраста.

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

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

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

Вот ваше программное обеспечение, все готово, надеюсь, вам понравится .... Хо, кстати, я исчерпал вашу кредитную карту, надеюсь, вы не против ... cya

Смысл перефакторинга заключается в упрощении конструкции и устранении недостатков. Это облегчает исправление ошибок и добавление новых функций в будущем.

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

Если вы продолжите добавлять новые функции в код, рефакторинг быстро окупится. Это будет видно по более низкому уровню ошибок, более быстрой отладке и более быстрым исправлениям.

Написание программного обеспечения во многом похоже на написание большой научной фантастики или энциклопедии.

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

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

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

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

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

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

Ключевым моментом является то, что оригинальное решение в основном работало. В этом и заключается рефакторинг: с самого начала он работает, но вам нужно изменить то, что уже существует, чтобы легко вносить изменения в будущем (перемещая колонки).

Это похоже на уборку дома после дикой и сумасшедшей вечеринки прошлой ночью.

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

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

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

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

Относитесь к своему коду так же.

Легко!

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

Итак, у вас есть текст, ... значение будет проходить в любом случае, но вы хотите, чтобы все звучало хорошо! Правильно?

Рефакторинг, то же самое ... те же фрагменты информации, более или менее, но состав лучше. И это, вероятно, приведет к лучшему обзору читателем.

Другой пример - написание статьи для журнала. Два писателя, оба знают «свое дело», единственное отличие состоит в том, что один знает «как писать», а другой пишет так, будто он научился писать по таким ответам.

Чью статью вы будете помнить?

Все аналогии с вещами в физическом мире - как, например, строительство театра, - IMO, ужасны.

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

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

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

Рефакторинг - это то же самое, что очистить что-то и дать персоналу новое место для «пребывания».

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

Я подумал о другом примере, который, по-видимому, никто здесь не упомянул: рефакторинг - это почти то же самое, что и перестановка уравнения в математике (хотя это, возможно, выходит за рамки «нетехнического человека»).

Когда вы переставляете уравнение, вы просто «перемещаете вещи», чтобы сделать его более читабельным и более удобным, без изменения значения .

Дайте им простое математическое уравнение. Например:

Что проще?

y = x + x

или же

y = 2x

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

Самый простой рефакторинг, который можно сделать, это переименование.

doX() { ... }
{
   doX()
}

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

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

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

Картина говорит тысячу слов. Например, рефакторинг имеет два варианта использования:

• Когда все не сделано правильно с первого раза:

• Когда все утомительно:

Рекомендации

• xkcd: хороший код

• xkcd: стоит ли это времени?

Рассмотрите ответ, данный в Рефакторинге , и не объясняйте его нетехническому человеку. Рефакторинг - это техническая деятельность, о которой им не нужно знать:

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

Подрывной? Я так не думаю. Разработчики программного обеспечения являются профессионалами. Наша задача - как можно быстрее создавать эффективное программное обеспечение. ... Управляющий расписанием менеджер хочет, чтобы я делал все как можно быстрее; как я это делаю это мое дело. Самый быстрый способ - это рефакторинг; поэтому я рефакторинг.

(Рефакторинг, Мартин Фаулер, 2000, стр. 61)

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