Сегодня у нас в выпуске будет обсуждение книги «Tidy First?» – это о том, как небольшие изменения в коде могут существенно упростить его и подготовить к будущим изменениям. Мы поговорим о двух типах изменений: поведенческих и структурных.
Поведенческие изменения – это когда ты добавляешь новую фичу, оптимизируешь функции или меняешь логику, чтобы она работала быстрее. Структурные изменения – это просто изменение организации кода, например, когда ты делишь сложное выражение на несколько простых функций или переменных.
Представьте, у вас есть сложное вложенное выражение, которое сложно понять. Вы можете его упростить, добавив новую переменную с понятным именем. Это название поможет вам в будущем быстрее понять, что это за выражение. Тот же принцип можно применить к константам и функциям, а также добавить комментарии для ясности.
Есть еще одна крутая техника: держите связанное по смыслу рядом. Например, если у вас переменная объявляется в одном месте, присваивается значение в другом, а используется в третьем – это неудобно. Лучше, чтобы все это было рядом. То же самое касается функций и файлов – близкие по смыслу вещи должны быть рядом. Это облегчит чтение и понимание кода.
Еще одна интересная мысль из книги: стоит ли вообще заниматься рефакторингом? Одни считают, что это пустая трата времени, другие уверены, что это снижает технический долг и стоит того. Автор книги предлагает взглянуть на это через призму финансов. Сегодняшний доллар всегда ценнее завтрашнего. В программировании это означает, что поведенческие изменения приносят пользу сразу, а структурные – возможно, в будущем.
Но давайте посмотрим на это как на опционы. Представьте, вы продаете овощи для салата за 1 доллар. Я не уверен, понадобится ли мне этот салат завтра, но если погода будет хорошая, я куплю его. Поэтому я готов заплатить несколько центов за право купить его завтра, если захочу. Это и есть опцион, а те несколько центов – премия.
Так вот, рефакторинг – это как премия на опционе. Он может окупиться, если условия сложатся удачно. Так что, когда вы решаете потратить время на обновление кода, подумайте, выгоднее ли это, чем, скажем, разработка нового сервиса.
Когда-то ученые исследовали, почему одни ИТ проекты стоят дороже других при одинаковой сложности. Оказалось, что в дорогих проектах изменения в одном месте кода требовали изменений и в других местах, то есть был сильный каплинг. В успешных проектах изменения нужно было вносить только в одном месте.
Это подчеркивает важность изменений кода как ключевого момента в программировании. Рефакторинг помогает подготовить код к будущим изменениям. Код с меньшим каплингом более гибок и его легче адаптировать к новым задачам.
Конечно, нам бы хотелось написать код один раз и забыть, создать красивый дизайн, где все идеально сочетается. Но реальность такова, что со временем все изменяется, и это часть нашей работы. Правильная реакция – это подготовить код к этой изменчивости. В конце концов, программист получает деньги не только за то, что он делает сейчас, но и за возможность быстро адаптировать код в будущем.