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

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

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

Вот цитата дяди Боба:

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

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

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

Более ранние этапы

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

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

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

На стадии роста вы, вероятно, не захотите использовать код, который «волшебным образом» работает, пока вы не добавите комментарий, а потом он каким-то образом сломается. Вероятно, код, созданный в поздние (или ранние?) часы дня, подпитывался либо кофеином, либо алкоголем. Вы уловили суть, верно?

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

Последние этапы

Помимо стадии снижения, большинство из нас будет работать на стадии зрелости.

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

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

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

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

Главная проблема

Все мы знаем, что когда мы что-то пишем, мы идем от А к Б, к F, затем к U, Z и, наконец, к С.

Некоторые люди говорят: «Это работает, отправьте это» только для того, чтобы вернуться через несколько дней и произнести эти мемные фразы, такие как «Когда я это написал, только Бог и я знали об этом. Теперь… одному Богу известно». Мне нравятся мемы, но когда ты постоянно ими живешь… тогда твоя жизнь — всего лишь шутка.

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

Из этого беспорядка вы иногда можете заставить его идти A → B → C (а иногда вы даже можете сократить некоторые ненужные шаги), это не должен быть самый совершенный фрагмент кода, просто чтобы иметь смысл для вас и любой, кто читает это, будь то сегодня, на следующей неделе или позже.

Виновник: Учебники YouTube

Если вы думаете: «Но это базовые вещи», да, это так! Но некоторые люди видят свой беспорядок и думают: «Да, это хорошо» и отправляют его. Я виню в этом учебники.

Времени нет, и никто не стал бы часами смотреть, как люди занимаются отладкой. Итак, они обычно просто показывают, что вы начинаете с A и «логически» переходите к B, а затем фактически переходите к C. Лучшие делают одно дело за раз, прыгая вверх и вниз и добавляя что-то, а другие в основном « думая»: «Все это нам, конечно, понадобится» в начале, а затем сверху вниз копируя то, что у них на втором экране.

Решение: неустанный рефакторинг

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

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

Заключение

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

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

Устаревший код — это немного нагруженный термин, люди всегда думают о нем как о чем-то плохом, но я много работал с унаследованными проектами, и легко увидеть фрагменты, где о нем действительно заботились, и места, сделанные с принципом «работает, выпускайте». " склад ума. Можете ли вы угадать, какие из них лучше понять и с которыми работать? Итак, какой унаследованный код вы оставляете?

Фото на обложке Marvin Meyer на Unsplash