Под моим столом есть ящик, который я использую для хранения всех мелочей, которые я случайно накапливаю, редко использую, но на самом деле не хочу избавляться. Но содержимое этого ящика также имеет дурную привычку покидать это пространство, а затем быстро распространяться по моему столу, офису и, в конечном счете, по всей квартире.
В идеальной вселенной я бы нашел способ эффективно хранить весь этот хлам. Тем не менее, нет необходимости быть слишком догматичным в этом вопросе. Это реальный мир. Иногда вам просто нужно запихнуть половину содержимого вашей гостиной в шкаф, потому что к вам приходят гости.
В нашей жизни кодирования это называется рефакторингом: внесение небольших изменений в наш код, чтобы улучшить наш дизайн без изменения основной функциональности. И все же, рефакторинг? Я нахожу это слово немного холодным, почти математическим – оно дает мне ощущение научного, научного процесса. Я думаю, что это звучит точно и клинически, и, ну, как будто в этом нет абсолютно никакого удовольствия. Это похоже на работу .
Конечно, есть фантастические причины, по которым многие умные люди помогли создать общий язык вокруг запахов кода и шаблонов рефакторинга, и это не только для того, чтобы вы могли попытаться выглядеть умно, когда пишете сообщения в блоге. Наличие общих соглашений означает, что вы можете обсуждать их в командах, а общая рубрика для информирования об этих приливах и отливах при перемещении кода создает комфортную надежность контекста. Я невероятно рад, что существует дискуссия о разработке программного обеспечения, что современные инженеры-программисты могут стоять на плечах гигантов, и я мечтаю иметь возможность оказать хотя бы малую толику положительного влияния на этих светил.
Иногда, однако, все эти необработанные умственные способности могут быть немного утомительными. С таким количеством формальных и сложно звучащих названий даже приближение к обсуждению шаблона рефакторинга может быть пугающим для начинающих программистов. Затем они часто объясняются некоторыми примерами, слишком хорошими, чтобы быть правдой, которые трудно контекстуализировать в рамках вашей текущей работы, что всегда приводило меня в замешательство – как мне применить этот красивый шаблон к моему фактическому коду? Я также думаю, что действительно трудно понять, почему вы должны использовать шаблон рефакторинга, пока он вас не ужалил. Мне намекают на явную нерешительность.
Но, на самом деле, рефакторинг – это просто небольшая уборка. Это решение помыть посуду до того, как вы дойдете до своей последней большой тарелки, или убедиться, что вы загрузили посудомоечную машину перед сном, чтобы вам не пришлось разбираться с этим утром.
Я ужасно разбираюсь в примерах, поэтому позвольте мне буквально изложить то, над чем я работаю, когда пишу это. Я спешил реализовать функцию для прохождения теста (если Java сможет найти системное свойство “app.port”, тогда сервер будет привязан к этому номеру порта) и добавил следующее:
public static void main(String[] args) throws IOException {
Connection connection;
if(System.getProperty("app.port") == null) {
connection = new Connection();
} else {
int port = Integer.parseInt(System.getProperty("app.port"));
connection = new Connection(port)
}
Server app = new Server(connection);
app.start();
}
Тесты проходят. Потрясающе. Я не буду притворяться, что 75% меня не были супер готовы просто git commit и иди обедать. Но нет! Было время для небольшой уборки.
Итак, во-первых, мне не нравится делать что-либо в main , кроме настройки классов, поэтому я решил, что извлечение большей части инструкции if облегчит чтение кода для меня в будущем.
public static void main(String[] args) throws IOException {
var connection = makeConnection();
var app = new Server(connection);
app.start();
}
Конечно, это просто перемещение кода по кругу. Но разбиение нашего кода на более мелкие функции обычно имеет побочный эффект, заключающийся в том, что нашу работу легче тестировать, поддерживать и расширять. Теперь мой следующий шаг состоял в том, чтобы сделать всю эту логическую логику немного более выразительной и более информативной для наших намерений.
private makeConnection() throws IOException {
if (hasSpecifiedPort()) {
int port = getPort();
return new Connection(port);
}
return new Connection();
}
private static int getPort() {
return Integer.parseInt(System.getProperty("app.port"));
}
private static boolean portIsSpecified() {
return !Objects.isNull(System.getProperty("app.port"));
}
Мы только что извлекли кое-что в нашей добыче! Вау. Мучительно мета. Но теперь make Connection на самом деле не нужно беспокоиться о том, какое системное свойство Java мы ищем, или о специфике его получения. Это просто… справляется с этим.
Наш оператор if также был изменен, чтобы просто выйти из игры раньше, если он совпадает. Это небольшой рефакторинг, который мне действительно нравится, потому что он избавляет нас от ваших скобок, что – как кто-то на полпути к Invisalign прямо сейчас – действительно хорошо.
Это всего лишь пара простых шагов, и, если честно, IntelliJ выполнил там большую часть работы. Но, сделав всего пару небольших шагов, я был готов к git commit . Потом я съел бутерброд. Это было восхитительно, спасибо.
“Подождите” , возможно, вы думаете. “Нет ли у вас более экстравагантных примеров, скажем, рефакторинга модуля Elixir с использованием структур и протоколов для достижения полиморфизма?” ты умоляешь со слезами на глазах, случайно подумав о последнем проекте, над которым я работал. “Пожалуйста”, – умоляете вы, – “Нет ли каких-нибудь более сложных шаблонов, которые вы могли бы применить?”
И, ну, конечно. Есть множество примеров из них, большинство из которых родились из тома Рефакторинг . И все же я утверждаю, что иногда дело не в этом. Особенно когда в игру вступают крайние сроки, руководители проектов и необходимость перерывов на обед. Мы должны праздновать каждую из наших маленьких побед, а не слишком беспокоиться о том, что несколько десятков таких побед станут увлекательным примером до и после.
Я бы сказал, что всегда стоит делать маленькие хитрости и хитрости, которых мы можем достичь сегодня , вместо того, чтобы пытаться приучить себя к более масштабным, более плотным и интересным рефакторингам, которые мы обещаем сделать завтра – завтра, которое, если мы будем честны, может никогда не произойти.
Рефакторинг – это широкая область, но я думаю, стоит помнить, что все всегда сводится к тому, чтобы просто снять один предмет со стула в вашем доме, который вы используете для складывания вещей; тот, который, как вы говорите себе, просто используется для временного хранения этой стопки книг.
Небольшие изменения? Вот как мы зажигаем радость.
Оригинал: “https://dev.to/martingaston/the-life-changing-magic-of-refactoring-4mk1”