Лига программистов

• 🧠 Лень — это миф. Нет ленивых людей, есть только недостаток мотивации.

• 📢 Социальный капитал решает. Публичное обещание или челлендж мотивируют в разы сильнее, чем тихое решение «начать с понедельника».

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

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

• 🧗 Масштаб пугает. Люди часто ставят гигантские цели, но спотыкаются, потому что не разбивают их на маленькие, понятные шаги и бросают всё при первой же неудаче.

И в своем приложении я постаралась учесть все эти моменты.

Итак, что же такое Ignite-me.app?

Ignite — это геймифицированная платформа, которая превращает процесс работы над собой и своими привычками в полноценный RPG-квест.

В приложении есть 2 варианта миссий: ЕЖЕДНЕВНЫЙ РИТУАЛ и ЭПИЧЕСКИЙ КВЕСТ. Каждая из этих миссий может быть как публичной, так и приватной.

Ежедневный ритуал создается на определенное количество дней и подразумевает ежедневное (либо через день) его выполнение. “Читать книгу 15 минут в день; Ходить 10 000 шагов или Делать утреннюю йогу”. Даже просто ”Начинать каждое утро со стакана воды”. Любое действие, которое вы хотите ввести в привычку, заслуживает место в списке ваших ежедневных миссий.

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

Ежедневные ритуалы - идеальный инструмент для личных и групповых челленджей.

Эпический квест работает по-другому. Здесь вы ставите определенную конечную цель, путь к которой разбиваете на любое количество небольших шагов. Выполнение каждого из шагов и приближает вас к глобальной цели. “Причитать 50 книг; Подготовиться и пробежать марафон; Научиться готовить 20 новых блюд” или любая другая вдохновляющая вас цель может стать Эпическим квестом.

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

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

И приятным бонусом к основной функциональности - список небольших дел (шагов дня) на сегодня/завтра, которые слишком малы для ежедневного ритуала или просто должны буть выполнены однократно. Например: записаться к стоматологу или забрать посылку. Куда же без нашего любимого To-Do листа? :)

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

Сейчас проект находится на стадии активного тестирования, и мне очень важен ваш фидбэк!

Буду рада и бесконечно благодарна, если вы попробуете Ignite-me.app, поделитесь своими впечатлениями, подсветите баги и подскажете, что, на ваш взгляд, можно было бы улучшить.

Так как приложение написано как PWA, его не нужно скачивать, а можно легко и быстро добавить как ярлык на телефон, будь у вас Android или iOS. Это позволит получать уведомления от приложения (только в том случае, если вы их хотите видеть и включите в настройках профиля) и всегда иметь его под рукой.

Присоединиться к героям-первопроходцам можно по ссылке https://ignite-me.app. Все пожелания, предложения, жалобы и негодования смело пишите сюда https://t.me/Ignite_support_team_bot

Заранее благодарю и посылаю лучики добра всем, кто не пройдет мимо!

Исходный код отрефакторенной версии выложен на Github.

Задача

Допустим есть некий софт, созданный еще «при царе Горохе» неким гордым но умным одиночкой, которого с тех пор никто не видел. Софт живой и с пользователями, которые приносят прибыль, поэтому его надо как‑то развивать и поддерживать.

В попытке расширить команду разработки, вы начинаете нанимать новых разработчиков, но раз за разом происходит одна и та же ситуация:

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

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

Так это обычно начинается.

Образец

В качестве образца для этой статьи был взят один интересный но малоизвестный широкой публике проект JPC:

The fast x86 PC emulator in 100% pure Java

Самый настоящий эмулятор старого x86-компьютера, реализованный без всяких нативных частей — на чистой Java!

Как-то так это выглядит у автора(ов) в работе:

Проект старый, но и интересный:

Read more about JPC - since it's launch at JavaOne 2007, JPC can now boot many more operating systems (including graphical linuxes) and it's much faster.

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

Еще к сожалению JPC немного заброшен, что для статьи только в плюс поскольку добавляет реалистичности — именно в таком состоянии чаще всего пребывают проекты, которые просят «привести в чувство».

Текущее состояние

После переезда проекта на Github, список коммитов выглядит следующим образом:

Никаких тестов в проекте нет, по всей видимости тестировалось все вручную с помощью молитвы, еще судя по исходному коду — далеко не весь функционал является рабочим, что также характерно для проектов в «пред‑рефакторинговом» состоянии.

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

Собирается сей чудо-проект с помощью.. Makefile, что для мира Java является дичью и извращением редкостью:

make application

Примерно как собирать проект на QT с помощью Gradle или (еще лучше) — sbt.

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

Для сборки необходимо указать путь к JDK в переменной PATH, при этом сборка проходит успешно даже с последними версиями (автор использовал OpenJDK 21).

Готовое приложение JPCApplication.jar появится в корне проекта после завершения сборки, но на этом хорошие новости заканчиваются:

Собранное приложение отказывается запускаться, что мы исправим чуть ниже.

Стадия первая: новый скелет

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

статические анализаторы — главный иструмент рефакторинга, крепко привязаны к структуре проекта и стандартным средствам сборки

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

перевел сборку проекта на Apache Maven, максимально широко поддерживаемый средствами анализа кода, CI-системами и средами разработки.

Реализовать такую миграцию в данном случае оказалось очень просто, поскольку JPC совсем не использует внешние библиотеки. Все что я сделал — раскидал ресурсы и исходный код в стандартную для Maven структуру каталогов:

Исходный код был перенесен из каталога src в src/main/java, ресурсы — в src/main/resources. Также был добавлен очень простой pom.xml, описывающий минимальные шаги сборки проекта:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.x0x08.samples</groupId>
<artifactId>jpc-refactored</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.4.2</version>
<configuration>
<archive>
<manifest>
<mainClass>
org.jpc.j2se.JPCApplication
</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>

Обратите внимание на куда более упрощенную генерацию манифеста:

<manifest>
<mainClass>
org.jpc.j2se.JPCApplication
</mainClass>
</manifest>

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

В оригинальной сборке происходит добавление еще и атрибута, отвечающего за параметры запуска «по-умолчанию»:

echo "Default-Args: -fda mem:resources/images/floppy.img -hda mem:resources/images/dosgames.img -boot fda" >> jpc.manifest

Это было убрано, поскольку точно такой же параметр запуска зашит еще и в код:

Наследие «былых времен», которое также достаточно часто встречается в устаревших проектах — во времена Java 1.5 и апплетов было модным использовать собственные атрибуты в манифесте.

Стадия вторая: удаление ненужного

Как в практически любом долгоживущем проекте, в JPC есть свои «внутренние утилиты» — отдельные программы, написанные для задач внутренней автоматизации.

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

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

В JPC внутренние утилиты реализованы в виде отдельных классов в пакете «tools» и нескольких шелл-скриптов в корне проекта.

И то и другое я просто не стал переносить в новую версию, также я убрал часть исходного кода эмулятора, отвечающего за отладку (пакет org.jpc.debugger) — по той же самой причине.

Что потребовало правок в классе org.jpc.emulator.PC.java:

был убран импорт класса org.jpc.debugger.LinearMemoryViewer а используемая статичная функция translateLinearAddressToInt перенесена в класс PC.

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

Стадия третья: критические проблемы

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

Первый запуск анализатора дает следующий результат:

24 критических ошибки и ~ 37 тысяч предупреждений — не так уж плохо, по сравнению с тем что бывает на свете.

Смотрим глубже и видим, что все 24 ошибки — действительно самые критичные, поскольку из-за них проект может перестать собираться в самом ближайшем будущем:

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

Есть и хорошая новость:

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

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

Но все несколько сложнее, поскольку еще есть вложенные классы, один из которых используется снаружи (org.jpc.j2se.JPCApplication):

JPCApplet.PlayPausePanel pp = new JPCApplet.PlayPausePanel(this);

Я просто перенес этот класс по месту использования, что позволило наконец удалить JPCApplet из проекта целиком.

Получилось минус 13 критических ошибок.

Еще один источник проблем — класс LinkBorder также можно удалить, поскольку он использовался лишь из удаленного JPCApplet.

Что дало еще минус три критических ошибки.

Дальше смотрим класс org.jpc.emulator.peripheral.Mixer, который забит предупреждениями от анализатора буквально через каждую строчку, однако вносить массовые правки пока не стоит — «всемогущая» Idea временами ошибается и это именно такой случай.

Ограничимся лишь одним методом:

private void ShowVolume(String name,FloatRef vol0,FloatRef vol1) {
System.out.printf("%-8s %3.0f:%-3.0f %+3.2f:%-+3.2f \n",new Object[] {name,
new Float(vol0.value*100),new Float(vol1.value*100),
new Float(20*Math.log(vol0.value)/Math.log(10.0f)),new Float(20*Math.log(vol1.value)/Math.log(10.0f))}
);
}

Анализатор ругается (в первую очередь) на конструктор new Float(), поскольку его прямое использование объявлено устаревшим, а в новых версиях Java стоит использовать Float.valueOf() в качестве замены.

Но как только вы замените конструктор, анализатор подскажет еще несколько оптимизаций, так что конечный вариант будет достаточно сильно отличаться:

System.out.printf("%-8s %3.0f:%-3.0f %+3.2f:%-+3.2f \n",
name,
vol0.value * 100, vol1.value * 100,
20*Math.log(vol0.value)/Math.log(10.0f),
20*Math.log(vol1.value)/Math.log(10.0f));

Следующий класс для изучения org.jpc.j2se.PCMonitorFrame, где анализатор ругается на два места с критическими ошибками.

Первое место характерно для устаревших проектов и встретится еще не раз:

catch (AccessControlException e)
{
LOGGING.log(Level.WARNING, "Not able to add some components to frame.", e);
}

Дело в том что класс ошибки, которая тут обрабатывается объявлен устаревшим в новых версиях:

'java. security. AccessControlException' is deprecated since version 17 and marked for removal

Поскольку исключение AccessControlException в новых версиях не выбрасывается, весь блок try-catch можно спокойно удалить.

Следующее место, код в этом же классе:

if (runner.isAlive())
{
try
{
runner.stop();
}
catch (SecurityException e) {}
}

Ругается анализатор на уникальный метод stop(), который был отмечен как устаревший еще до того как я начал писать на Java:

'stop()' is deprecated since version 1.2 and marked for removal

Примерно до версии 1.8 использование данного метода еще можно было как‑то оправдать наличием устаревших библиотек, в нынешних реалиях этот метод — просто еще один способ «выстрелить себе в ногу»:

Stopping a thread causes it to unlock all the monitors that it has locked.

Так что в коде использование этого метода точно стоит заменить на стандартный .interrupt() :

if (runner.isAlive())
{
runner.interrupt();
}

Блок try-catch также можно спокойно убрать, поскольку SecurityException не выбрасывается в новых версиях Java при попытке остановки нити.

На этом все критические проблемы в проекте решены и получен минимальный практический смысл от всей затеи:

убраны места, которые могут сломать сборку проекта в новых версиях Java

Стадия четвертая: ошибки выполнения

Пришло время наконец попробовать запустить нашего «франкенштейна».

Сборка разумеется завершится успешно (не зря же старались), но при запуске будет выбрасываться все та же ошибка поиска ресурсов:

В оригинальной версии JPC, часть ресурсов (например образы биоса) загружались только из jar‑файла, часть (образы дисков) — только снаружи, из каталога resources, при этом каталог с ресурсами был общим.

Сию дичь необходимо пресечь и сделать в более адекватном стиле, например как это реализовано в движке знаменитого Quake:

сначала ищем внешний файл, если не найден — ищем в ресурсах, если не найден в ресурсах — падаем с ошибкой

За чтение образа BIOS отвечает вот такой метод в классе org.jpc.emulator.motherboard.Bios:

private static final byte[] getBiosData(String image) throws IOException {
InputStream in = Bios.class.getResourceAsStream(image);
if (in == null) {
throw new IOException("resource not found: " + image);
}
try {
ByteArrayOutputStream bout = new ByteArrayOutputStream();

while (true) {
int ch = in.read();
if (ch < 0) {
break;
}
bout.write((byte) ch);
}

return bout.toByteArray();
} finally {
try {
in.close();
} catch (IOException e) {
}
}
}
}

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

Конечный вариант после всех чисток выглядит так:

private static byte[] getBiosData(String image) throws IOException {

File f = new File(image);
if (f.exists() && f.isFile() && f.canRead())
return Files.readAllBytes(f.toPath());

f = new File("resources",image);
if (f.exists() && f.isFile() && f.canRead())
return Files.readAllBytes(f.toPath());

final URL u = Bios.class.getResource(image);
if (u == null)
throw new IOException("resource (bios) not found: %s".formatted(image));

try (InputStream in = u.openStream()) {
return in.readAllBytes();
}
}

Логика переделана на возможности современной Java 17, поэтому кода стало сильно меньше, также были добавлены проверки на наличие ресурса:

• по полному пути,

• по частичному (предполагается что файл находится в каталоге resources),

• поиск внутри jar приложения.

Но при следующей попытке запуска получаем еще одно исключение, уже в другом месте:

Причиной является искусственная проверка:

if (!(cl instanceof URLClassLoader))
throw new IllegalStateException();

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

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

Однако одним лишь удалением проверки дело не ограничилось — необходимо почистить еще один метод, реализующий «закат солнца вручную»:

private static final Iterator<String> getResources(String directory)
{
ClassLoader context = Thread.currentThread().getContextClassLoader();

List<String> resources = new ArrayList<String>();

ClassLoader cl = JPCApplication.class.getClassLoader();
if (!(cl instanceof URLClassLoader))
throw new IllegalStateException();
URL[] urls = ((URLClassLoader) cl).getURLs();

int slash = directory.lastIndexOf("/");
String dir = directory.substring(0, slash + 1);
for (int i=0; i<urls.length; i++)
{
if (!urls[i].toString().endsWith(".jar"))
continue;
try
{
JarInputStream jarStream = new JarInputStream(urls[i].openStream());
while (true)
{
ZipEntry entry = jarStream.getNextEntry();
if (entry == null)
break;
if (entry.isDirectory())
continue;

String name = entry.getName();
slash = name.lastIndexOf("/");
String thisDir = "";
if (slash >= 0)
thisDir = name.substring(0, slash + 1);

if (!dir.equals(thisDir))
continue;
resources.add(name);
}

jarStream.close();
}
catch (IOException e) { e.printStackTrace();}
}
InputStream stream = context.getResourceAsStream(directory);
try
{
if (stream != null)
{
Reader r = new InputStreamReader(stream);
StringBuilder sb = new StringBuilder();
char[] buffer = new char[1024];
try
{
while (true)
{
int length = r.read(buffer);
if (length < 0)
{
break;
}
sb.append(buffer, 0, length);
}
} finally
{
r.close();
}

for (String s : sb.toString().split("\n"))
{
if (context.getResource(directory + s) != null)
{
resources.add(s);
}
}
}
}
catch (IOException e)
{
LOGGING.log(Level.INFO, "Exception reading images directory stream", e);
}

return resources.iterator();
}

Тут происходит поиск доступных образов дисков путем последовательного перебора всех файлов внутри .jar с приложением.

С учетом того что .class файлов внутри ~6500 — такое решение мягко говоря «не оптимально».

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

Поскольку в проекте используется очень небольшое количество образов диска и нет вариантов по резкому увеличению их количества, я просто зашил названия в код:

private static final String[] IMAGES = {
"images/dosgames.img",
"images/floppy.img",
"images/linux.img",
"images/odin070.img",
};

private static Iterator<String> getResources(String directory)
{
final List<String> resources = new ArrayList<String>
(Arrays.stream(IMAGES).toList());
final File f = new File(directory);

if (!f.exists() || !f.isDirectory()) {
return resources.iterator();
}

final File[] files = f.listFiles();

if (files == null) {
return resources.iterator();
}
for (File ff: files) {
resources.add(directory + ff.getName());
}

return resources.iterator();
}

Метод getResources() используется для отображения списка доступных образов дисков через меню приложения, все внутренние образы (зашитые в.jar) добавляются в этот список автоматически.

После столь примитивной правки, приложение стало запускаться визуально быстрее даже на мощном современном ноутбуке, так что не стоит недооценивать силу простых решений ;)

Хотя всех правок выше оказалось недостаточно, следующая остановка — класс org.jpc.support.ArrayBackedSeekableIODevice, который (внезапно) играет ключевую роль в проекте.

Метод configure() отвечает непосредственно за загрузку образов дисков и дискет:

public void configure(String spec) throws IOException
{
resource = spec;
imageOffset = 0;

InputStream in = ArrayBackedSeekableIODevice.class.getClassLoader().getResourceAsStream(resource);
if (in == null) {
LOGGING.log(Level.SEVERE, "resource not found: {0}", resource);
throw new IOException("resource not found: " + resource);
}
try {
byte[] buffer = new byte[1024];
ExposedByteArrayOutputStream bout = new ExposedByteArrayOutputStream(32*1024);

while (true) {
int read = in.read(buffer);
if (read < 0)
break;
bout.write(buffer, 0, read);
}

imageData = bout.getBuffer();
length = bout.getPosition();
} catch (IOException e) {
LOGGING.log(Level.SEVERE, "could not load file", e);
throw e;
} finally {
try {
in.close();
} catch (IOException e) {
}
}
}

Переделываем с учетом современных реалий:

public void configure(String spec) throws IOException {
resource = spec;
imageOffset = 0;

File f = new File(spec);
if (f.exists() && f.isFile() && f.canRead()) {
imageData = Files.readAllBytes(f.toPath());
length = imageData.length;
return;
}

f = new File("resources",spec);
if (f.exists() && f.isFile() && f.canRead()) {
imageData = Files.readAllBytes(f.toPath());
length = imageData.length;
return;
}
final URL u = ArrayBackedSeekableIODevice.class.getResource(spec);
if (u == null)
throw new IOException("resource (image) not found: %s"
.formatted(spec));

try (InputStream in = u.openStream()) {
imageData = in.readAllBytes();
length = imageData.length;
}
}

Тут тоже три последовательные проверки на поиск образа диска и использование современного API для минимизации кодовой базы.

Эта доработка оказалась финальной и наконец можно успешно запустить эмулятор:

java -jar target/jpc-refactored-1.0-SNAPSHOT.jar -hda src/main/resources/images/linux.img

Будет запущен Qemu Linux Test Distribution:

Или так:

java -jar target/jpc-refactored-1.0-SNAPSHOT.jar -fda mem:images/odin070.img

запустится FreeDOS ODIN:

На этой стадии была проведена самая настоящая «коммерческая оптимизация» — доведен до ума функционал актуальный конечным пользователям.

Так что вас за такое-то скотство, проведенное с рабочим проектом уже точно не уволят ;)

Стадия пятая: массовые правки

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

массовые и сквозные правки исходного кода, во всем проекте целиком

Рабочая область выглядит как-то так:

Собственно все «желтенькое» на скриншоте ниже — места для рефакторинга, заботливо подсказанные средой разработки:

К сожалению на практике все несколько сложнее чем подсказывает Idea и просто нажимать «Alt + Shift + Enter» на каждую подсказку не стоит:

Все потому, что в проекте активно используется Reflection API для загрузки и обращения к методам класса необычными способами:

try {
Method valueOf = type.getMethod("valueOf", String.class);
return valueOf.invoke(type, value);
} catch (NoSuchMethodException e) {
System.err.println(type + " :No suitable method");
}

Что сводит анализаторы исходного кода с ума, поэтому примерно половина методов в проекте десктоп-приложения, не использующего никакие IoC-контейнеры отмечено как неиспользуемые:

Скотство?

Конечно скотство, но и в реальных больших и старых проектах такое тоже будет в обязательном порядке — когда‑то использование Reflection API считалось модным и молодежным явлением, убрать которое "под капот" смогли только те самые IoC‑контейнеры вроде Spring.

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

Лямбды появились еще в Java 8 и с тех пор уже нет никакого здравого смысла их игнорировать — они здорово сокращают объем кода:

В любом legacy-проекте, особенно если это приложение для десктопа такого будет очень и очень много:

Следующий повод для массовых правок — прямой результат ручной разработки, без использования средств проверки и анализа кода:

Хороший пример, подсказанный анализатором:

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

Следующие две проблемы — также частые гости устаревших проектов:

Точно также как и с ненужными модификаторами в интерфейсе, всего лишь занимают место и увеличивают объем кода.

Хотя пример выше это совсем уж старый код, поскольку метод Arrays.asList () появился еще в Java 7 — былинные времена далекого прошлого, как можно было его сохранить до сих пор — загадка.

Эпилог

Если вы никогда не видели JPC то стоит посмотреть, поскольку он в свое время несколько расширил мнение о возможности Java, в первую очередь в плане производительности — тема о которой много и сильно шутили еще 10 лет назад.

Ну а если перед вами стоит задача провести подобный рефакторинг — стадии с первой по четвертую фактически являются руководством к действию.

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

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

P.S.

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

Все началось когда автор наткнулся на одну интересную статью где эксперт по 3D-технологиям вместил специально оптимизированный и обфусцированный код рейтрейсера на C++ в размеры своей визитки.

Вот такой код:

#include <stdlib.h> // card > aek.ppm
#include <stdio.h>
#include <math.h>
typedef int i;typedef float f;struct v{
f x,y,z;v operator+(v r){return v(x+r.x
,y+r.y,z+r.z);}v operator*(f r){ return
v(x*r,y*r,z*r);}f operator%(v r){return
x*r.x+y*r.y+z*r.z;}v(){}v operator^(v r
){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r.
y-y*r.x);}v(f a,f b,f c){x=a;y=b;z=c;}v
operator!(){return*this*(1/sqrt(*this%*
this));}};i G[]={133022, 133266,133266,
133022, 254096, 131216, 131984, 131072,
258048,};f R(){return(f)rand()/RAND_MAX
;}i T(v o,v d,f&t,v&n){t=1e9;i m=0;f p=
-o.z/d.z; if(.01<p)t=p, n=v(0,0,1),m=1;
for(i k=19;k--;)for(i j=9;j--;)if(G[j]&
1<<k){v p=o+v(-k,0,-j-4);f b=p%d,c=p%p-
1,q=b*b-c;if(q>0){f s=-b-sqrt(q);if(s<t
&&s>.01)t=s,n=!(p+d*t),m=2;}}return m;}
v S(v o,v d){f t;v n;i m=T(o,d,t,n);if(
!m)return v(.7,.6,1)*pow(1-d.z,4);v h=o
+d*t,l=!(v(9+R(),9+R(),16)+h*-1),r=d+n*
(n%d*-2);f b=l%n;if(b<0||T(h,l,t,n))b=0
;f p=pow(l%r*(b>0),99);if(m&1){h=h*.2;
return((i)(ceil(h.x)+ceil(h.y))&1?v(3,1
,1):v(3,3,3))*(b*.2+.1);}return v(p,p,p
)+S(h,r)*.5;}i main(){printf("P6 512 "
"512 255 ");v g=!v(-6,-16,0),a=!(v(0,0,
1)^g)*.002,b=!(g^a)*.002,c=(a+b)*-256+g
;for(i y=512;y--;)for(i x=512;x--;){v p
(9,9,9);for(i r=64;r--;){v t=a*(R()-.5)
*99+b*(R()-.5)*99;p=S(v(17,16,8)+t,!(t*
-1+(a*(R()+x)+b*(y+R())+c)*16))*3.5+p;}
printf("%c%c%c",(i)p.x,(i)p.y,(i)p.z);}}

После компиляции:

c++ -O3 -o card card.cpp

Генерировал у автора вот такую картинку:

Мы позеленели от зависти тоже захотели себе что-то такое, но поскольку занимаемся все же серверами а не 3D-графикой и больше Java, чем C++ — решили что будет круто уместить на обратной стороне нашей визитки простейший HTTP-сервер на Java.

Вместе с запуском и компиляцией.

Еще при наличии графического окружения будет запущен браузер.

Плюс немного криптографии для защиты от подделки.

Весь код уместился в 18 строк, выровненных по ширине так чтобы влезть в размеры визитки:

Вбиваете код с визитки в любимый редактор, сохраняете файл как vcard.sh и запускаете:

chmod +x ./vcard.sh
./vcard.sh

Результат:

Локально запустится простейший HTTP-сервер, который отдаст текстовую страничку с нашими контактами. При наличии GUI  — запустится еще и браузер по-умолчанию, с автоматическим открытием страницы этого сервера.

И все это в 18 строк кода.

Да, еще будет нужен любой Linux/BSD/MacOS/Solaris и любая версия JDK начиная с 1.8 на машине.

Поддержку запуска на Windows делать не стал (хотя это и возможно технически), но можно спокойно запустить в WSL .

Чтобы вы не мучились с вводом кода с картинки, вот текстовая версия:

#!/bin/sh
t=$(mktemp -d);e=$(realpath $0);sed '1,4d' $0|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java
cd $t;javac -XDignore.symbol.file -cp . Yo.java && java -cp . Yo $e;exit 0
i com.sun.net.httpserver.*;i j.awt.Desktop;i j.io.*;i j.util.*;i j.net.*;i j.nio.file.*;
i java.security.MessageDigest;i javax.crypto.Cipher;i javax.crypto.spec.SecretKeySpec;
p class Yo{p static void main(String[]args)throws E!{Cipher dcipher=Cipher.getInstance("AES");
dcipher.init(2,new SecretKeySpec(Arrays.copyOf(MessageDigest.getInstance("SHA-1").digest(
new String(Files.readAllBytes(Paths.get(args[0]))).replaceFirst("ED=\"([^<]*)\";","")
.trim().getBytes()),16),"AES"));String ddata=new String(dcipher.doFinal(Base64.getDecoder()
.decode(ED)),"U8!");int p=8000;String h="0x7f000001";HttpServer s=HttpServer.create()
.createContext("/",(HttpExchange t)->{String r=String.format(ddata,System.nanoTime());t.getRE?()
.set("Content-type","text/plain;charset=U8!");t.sendRE?(200,r.getBytes("U8!").length);
try(OutputStream os=t.getResponseBody()){os.write(r.getBytes("U8!"));}}).getServer();
s.bind(new InetSocketAddress(p),1);new Timer().schedule(new TimerTask(){public void run(){
if(!Desktop.isDesktopSupported()){System.out.println(ddata);return;}try{Desktop.getDesktop()
.browse(new URI("http://"+h+":"+p));}catch(E! e){throw new RuntimeE!(e);}}},2000);s.start();}
static String ED="TfPrCIlXEUInGJPpr4++hQfa2Whq4RFzdbFP5C4s/s8=";}

Ну разве не прелесть?

Как это работает

Тут используется связка из заголовочного shell-скрипта и слегка обфусцированного кода на Java. Еще я не стал кодировать весь блок на Java полностью в HEX-строку, чтобы визуально оставалось ощущение исходного кода.

Начнем с заголовочного скрипта:

#!/bin/sh
t=$(mktemp -d);e=$(realpath $0);sed '1,4d' $0|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java
cd $t;javac -XDignore.symbol.file -cp . Yo.java && java -cp . Yo $e;exit 0

Самая первая строчка:

#!/bin/sh

Это shebang, стандартное для Unix указание на используемый интерпретатор, про него и так все знают. Дальше происходит создание временного каталога в /tmp и присваивание его имени переменной в скрипте:

t=$(mktemp -d);

Затем получение скриптом собственного имени с полным путем:

e=$(realpath $0);

Чтение скриптом самого себя, с отрезанием первых 4х строк - чтобы получить блок кода на Java:

sed '1,4d' $0

Дальше начинается pipe, в котором результат предыдущей команды передается на вход следующей:

|sed -e 's/p /public /g ; s/i /import /g' \
-e 's/j\./java./g ; s/E!/Exception/g ; s/U8!/UTF-8/g ; s/RE?/ResponseHeaders/g'>$t/Yo.java

Результат всех преобразований записывается в файл Yo.java, в том самом временном каталоге.

Малоизвестная опция -XDignore.symbol.file отключает предупреждение об использовании системных классов JDK (com.sun.net.httpserver.*) в проекте — в 1.8 версии классы встроенного в JDK HTTP-сервера еще считались системными.

Запуск с передачей полного пути оригинального скрипта для последующего его чтения из Java-кода:

java -cp . Yo $e

Сам код после деобфускации и форматирования выглядит уже вот так:

import com.sun.net.httpserver.*;
import java.awt.Desktop;
import java.io.*;
import java.util.*;
import java.net.*;
import java.nio.file.*;
import java.security.MessageDigest;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
public class Yo {
public static void main(String[] args) throws Exception {
Cipher dcipher = Cipher.getInstance("AES");
dcipher.init(2,
new SecretKeySpec(Arrays.copyOf(
MessageDigest.getInstance("SHA-1").digest(
new String(Files.readAllBytes(Paths.get(args[0])))
.replaceFirst("ED=\"([^<]*)\";", "")
.trim().getBytes()), 16), "AES"));
String ddata = new String(dcipher.doFinal(Base64.getDecoder()
.decode(ED)), "UTF-8");
int p = 8000;
String h = "0x7f000001";
HttpServer s = HttpServer.create()
.createContext("/", (HttpExchange t) -> {
String r = String.format(ddata, System.nanoTime());
t.getResponseHeaders()
.set("Content-type", "text/plain;charset=UTF-8");
t.sendResponseHeaders(200, r.getBytes("UTF-8").length);
try (OutputStream os = t.getResponseBody()) {
os.write(r.getBytes("UTF-8"));
}
}).getServer();
s.bind(new InetSocketAddress(p), 1);
new Timer().schedule(new TimerTask() {
public void run() {
if (!Desktop.isDesktopSupported()) {
System.out.println(ddata);
return;
}
try {
Desktop.getDesktop()
.browse(new URI("http://" + h + ":" + p));
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}, 2000);
s.start();
}
static String ED = "1AtzGU0uq7J7DHPdjdJJ5JJDiwQi8mElIDOjuRK0DEU=";
}

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

Криптография

Когда я только начинал думать над реализацией этой штуки, уже было ясно что нужен какой-то неочевидный контроль целостности:

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

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

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

static String ED = "1AtzGU0uq7J7DHPdjdJJ5JJDiwQi8mElIDOjuRK0DEU=";

Именно тут находится текст:

We write software. @alex0x08

На каждую попытку как-то подменить содержимое (включая заголовок) будет выдаваться вот такая ошибка:

Exception in thread "main" javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at java.base/com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:981) at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1062) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at Yo.main(Yo.java:6)

Получается код сам себя защищает от подделки.

0x7f000001

Вторым неочевидным моментом является вот такой странный адрес хоста:

String h = "0x7f000001";

Который используется при формировании ссылки для открытия браузером:

Desktop.getDesktop().browse(new URI("http://" + h + ":" + p));

Такое применение однозначно говорит о том что адрес очень даже стандартный, поскольку проходит как стадию валидации на стороне Java при формировании объекта URI, так и валидацию на стороне запускаемого браузера.

Это просто нотация, вариант написания IP-адреса 127.0.0.1, обозначающего loopback (петлю) — внутренний интерфейс, к которому можно подключиться локально, а не из сети.

Вот тут больше примеров различных вариантов написания IP-адресов, уверен — удивит даже бывалых админов.

P.S.

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

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

Новые модели от Hisense

На презентации продемонстрировали несколько моделей новой линейки — UR8S, UR9S и флагманский Hisense 116UX.

Особенность новинок — технология RGB MiniLED. Теперь телевизор точнее управляет цветом и светом, поэтому изображение выглядит ярче, контрастнее и естественнее.

Менеджер по продуктам ТВ- и аудиокатегории Hisense Шон Ли:

«Запуск технологии RGB Mini-LED на российском рынке является новым этапом в развитии Hisense. Мы задали новый стандарт визуального опыта, который уже получил признание на глобальном уровне».

Больше всего внимания собрал Hisense 116UX. Это телевизор с трехметровой диагональю. На таком экране особенно хорошо заметны детали: яркие сцены остаются насыщенными, темные — глубокими, а изображение выглядит объемным и живым. За качество картинки отвечает фирменный процессор Hisense, а встроенная многоканальная акустика создает эффект домашнего кинотеатра без дополнительных колонок.

Вместо лекций — живое общение

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

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

Линейка уже поступила в продажу. Доступны модели UR8S в нескольких размерах экрана, серия UR9S и флагманский 116UX. Телевизоры можно приобрести у крупных российских ритейлеров и на популярных маркетплейсах.

высылаю скрином из за некорректного отображения кода текстом в Пикабу