Когда вы не понимаете цели чего-либо, подумайте, прежде чем действовать
«Очень многие люди думают, что они думают, когда просто перестраивают свои предубеждения». — Уильям Джеймс.
Всякий раз, когда разработчик изменяет код, его изменение может исправить одну часть и сломать другую. Сложность изменения кода заключается в понимании его цели и требований, стоящих за его созданием.
Если код существует, вероятно, для этого есть причина.
Чтобы удалить или изменить код, сначала нужно понять, почему разработчик его создал. Трудно найти назначение кода, потому что даже требования обновляются и устаревают.
Весь код, который вы видите, был добавлен по какой-то причине, по какой причине и действителен ли он?
Забор Честертона
«Никогда не сноси забор, пока не узнаешь, по какой причине он был поставлен». ― Г. К. Честертон
Про забор Честертона я читал с Фарнам-стрит — Забор Честертона. "Г. К. Честертон» был английским писателем, написавшим около 80 книг и 4000 эссе и любившим использовать пословицы, аллегории и любые другие средства, чтобы донести свою точку зрения. Самый известный его рассказ — Человек, который был Четвергом.
В одной из своих книг он обсуждал забор и его назначение, две цитаты ниже:
«Скажем, для простоты, забор или ворота, воздвигнутые через дорогу. Более современные реформаторы весело подходят к этому и говорят: «Я не вижу в этом пользы; давайте уберем его». На что более интеллигентный реформатор вполне может ответить: «Если вы не видите в этом пользы, я уж точно не позволю вам убрать это. Уйди и подумай. Затем, когда ты сможешь вернуться и сказать мне, что видишь в этом пользу, я могу позволить тебе уничтожить его.
и
Этот парадокс опирается на самый элементарный здравый смысл. Ворота или забор там не росли. Его не создали сомнамбулы, которые построили его во сне. Крайне маловероятно, что его положили сбежавшие сумасшедшие, которые по каким-то причинам оказались на улице. У кого-то были какие-то причины думать, что это будет хорошо для кого-то. И пока мы не узнаем, в чем была причина, мы действительно не можем судить, была ли причина разумной. Крайне вероятно, что мы упустили из виду какую-то сторону вопроса, если что-то, установленное людьми, подобными нам, кажется совершенно бессмысленным и таинственным. Есть реформаторы, которые преодолевают эту трудность, полагая, что все их отцы были дураками; но если это так, то мы можем только сказать, что глупость кажется наследственной болезнью. Но правда в том, что никто не имеет права разрушать социальный институт, пока он действительно не увидит его как исторический институт. Если он знает, как оно возникло и каким целям оно должно было служить, он действительно мог бы сказать, что это были плохие цели, что с тех пор они стали плохими целями или что эти цели больше не служат. Но если он просто смотрит на вещь как на бессмысленное чудовище, каким-то образом возникшее на его пути, то это он, а не традиционалист, страдает от иллюзии».
Честертон использует забор и его цель, чтобы заставить людей думать, прежде чем что-то менять, например, процессы, правила и код. Люди быстро предполагают, что понимают, но они потратили время только на то, чтобы понять это на поверхностном уровне, например, они бегло пробежали глазами.
Чтобы убрать забор, нужно понять его назначение. Задайте себе эти вопросы о заборе
- Этот забор удерживает что-то внутри или не пропускает?
- Зачем кто-то поставил этот забор здесь?
- Что может случиться, если мы уберем забор
Если вы хотите изменить правило, вам нужно понять цель правила, существует ли оно для того, чтобы заставить нас что-то сделать или помешать нам сделать что-то?
Это вопросы о заборе. Что, если бы это было удаление или изменение чего-то действительно важного, например КОДА!
Кодекс Честертона
Как и в случае с забором, легко посмотреть на код и подумать, что вы его понимаете и можете безопасно обновлять/удалять этот код.
Много раз разработчики смотрели на код и думали, какой идиот написал этот ужасный код, должно быть, они дураки. Прежде чем понять, что на самом деле это были вы и быстро обвинили в этом разработчика, который недавно ушел.
Легко поверить, что все предыдущие разработчики были неуклюжими дураками, которые писали ужасный код, когда им вздумается. Чтобы игнорировать код, можно было написать и исправить ошибку много раз, при этом каждое обновление исправляло ошибку или добавляло новые необходимые функции.
Вам будет сложно просмотреть все пользовательские истории и исправления ошибок, чтобы проверить, соответствует ли код требованиям.
Взгляд на код не дает вам бизнес-контекст или контекст требований, которые его создали.
Код сам по себе не дает полной картины, он дает представление. Разработчику сложно понять, какой код зависим и как он взаимодействует с другими частями системы.
Разработчики редко понимают полное решение или то, как этот фрагмент кода вписывается во всю систему. Без знания решения в целом трудно зарядить небольшую часть, не нарушив часть всего решения.
Не удаляйте код, пока не поймете, что он делает и зачем был добавлен
Когда вы видите какой-то код или настройку, которую нужно обновить, спросите себя, какой идиот создал этот ужасный код.
- Какова цель этой настройки или кода?
- Что это дает? Какова его цель?
- Чего он пытается избежать?
- Какие функции связаны с этим кодом/настройкой?
- Что от этого зависит?
- эта цель все еще действительна?
Небольшое знание дает вам много слепых зон и достаточно места для совершения ошибок, которых вы не ожидаете.
«Не то, чего вы не знаете, доставляет вам неприятности. Это то, что вы точно знаете, что это не так. " - Марк Твен
Системное мышление смотрит на это по-другому, сегодняшние решения — это проблемы завтрашнего дня. Когда вы меняете код, у вас есть возможность добавить ошибку в прямой код и зависимый код.
Модульные тесты могут не спасти вас, потому что соответствующий код может быть удален далеко и для него может не быть модульных тестов.
Прежде чем что-то удалять, нужно понять, зачем это было создано.
Восстановить
Разорвите его и начните снова
Привлекательно отказаться от старого и воссоздать функциональность с использованием новейших технологий, сред и методов.
Когда вы смотрите на существующую систему, в которую внесены исправления ошибок, изменения и оптимизации за годы. Трудно понять цель всего.
При перестройке разработчики выбрасывают непонятные им фрагменты, которые, как они узнают позже, были нужны.
Подобно проектам программного обеспечения, разработчики недооценивают сложность и время, которые потребуются для перестройки функциональности. Потенциальные выгоды должны быть большими, примерно в 10 раз лучше, чем существующая функциональность, и с перспективными преимуществами.
Стандарты, процессы, рекомендации
Стандарты, процессы и лучшие практики создаются не просто так, легко подумать, что это глупо и не имеет смысла.
Лучшие практики не имеют смысла, потому что вы не понимаете их цели или того, что они пытаются остановить. Это не проблема процесса/стандарта, это проблема образования.
Спросите себя — почему этот процесс существует? Какова его цель?
Лучше сначала подумать и сделать паузу, прежде чем нажимать клавишу удаления или вносить изменения. Легче передумать, чем отменить измененный код.
Плотники говорят: «Семь раз отмерь, один раз отрежь».
Разработчики должны сказать
«Подумай дважды, обнови код один раз»
Нам нужно быть осторожными, это не то, что делалось всегда, и именно поэтому мы это делаем. Вещи должны быть обновлены, если их причина больше не действительна, но вы должны понять и подтвердить это, прежде чем вносить изменения.
Мы знаем лучше
Есть подозрение, что предыдущие разработчики были ковбоями и толком не знали, что делают. Мы часто критически относимся к их решениям, но гораздо более великодушны к своей работе.
«Каждое поколение воображает себя более разумным, чем предыдущее, и мудрее, чем следующее». Джордж Оруэлл
Каждый разработчик считает себя лучшим разработчиком, чем разработчики, которые работали над кодом до него.
Часто предыдущие разработчики были ковбоями (если это не были я или вы), но у них была веская причина для создания кода. Подумайте, прежде чем изменить или удалить какой-либо код.
Не удаляйте код, пока не поймете, что он делает и почему он был добавлен, и будьте осторожны, чтобы не удалить код Chesterton.
дальнейшее чтение
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Получите эксклюзивный доступ к возможностям написания и советам в нашем сообществе Discord.
