Как тестовое задание на собеседование превратилось в open-source библиотеку

Всем привет, JavaRush сообщество! Немного о себе: с весны 2016 года работаю в качестве Java Software Engineer. Люблю сюда заходить и решаю задачи, что не решил еще во время учебы. Сегодня расскажу вам о библиотеке - Image Comparison. Это open source библиотека, которая хранится в открытом доступе на GitHub. Цель данной статьи донести, что создание open source продукта — это не просто трата времени впустую, нет! Это богатый опыт, который черпается с разных сторон, когда в твоей власти весь процесс разработки, когда нужно вникать в каждую деталь. Open Source — это мир вокруг вас. Я не шучу, за время существования этой библиотеки, общался с людьми с разных стран, таких как: США, Индии, Китая, Египта, России, Германии, Украины, Швеции, Новой Зеландии, Норвегии. То есть это реальный опыт совместной разработки, нахождения компромисcов, проверки кода и так далее. Это было вступление, теперь начнем всё по порядку:

Тестовое задание. Начало августа 2017 года

Началось все с того, что я собеседовался в одну из компаний, где первым этапом нужно было написать тестовое задание. Задача состояла в том, чтоб написать код, который бы сравнивал две картинки, с одинаковыми размерами, находил отличия между ними, группировал их и рисовал прямоугольник вокруг них. Есть первая картинка: Есть вторая картинка: Нужно было найти отличия и обвести их как показано ниже: Как можно заметить, в поле Username есть отличие, которое и было обведено красным треугольником. Более детальное описание задачи. Я решил, что хочу сделать не только правильно с точки зрения функционала, но еще и красиво, чтобы было не стыдно. Для этого решил, что опубликую это как проект на GitHub. Давно хотел изучить GitHub, получить опыт работы с ним. После быстрого просмотра, нашел что хорошо бы добавить сторонние сервисы по анализу качества кода, по генерации покрытия кода тестами и тд. Добавил такие инструменты:

• Codacy — качество кода. Действительно стоит обратить на него внимание.

• Travis CI — это CI(continuous integration) инструмент, который собирает проект, прогоняет тесты и говорит, успешно ли собран проект. Например, если какой-то из тестов не прошел в следствии с новыми изменениями, то он скажет, что сборка проекта неудачная и окрасит ее красным цветом.

• Coveralls — это инструмент, который показывает какой процент кода покрыт тестами.

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

Каждый из этих сервисов имеет свой бейджик с результатами данных, например проект покрытия кода. И этот бейджик можно добавить в главном описании проекта — README файл. Задание было готово — отдал его на ревью. После ревью сразу же по свежей памяти создал на каждое замечание Github Issue, которые потом помогли бы мне улучшить этот проект. Задачи от работодателя по улучшению не было, поэтому на некоторое время я забыл о проекте...

Путь Библиотеки. Июль 2018 года

Логотип

В один момент я обнаружил, что на мой проект заходят часто люди, причем это происходит каждый день. Меня это поразило, еще больше поразило то, что где-то через год создали ISSUE, в котором было написано, что некий графический дизайнер предлагает мне создать логотип моего проекта. Мол он любит делать это для Opensource продуктов и сделает это абсолютно бесплатно. Мы начали сотрудничать. Было предложено несколько вариантов, в конечном счете остановились на этом: Я тогда еще был молод и незнаком с opensource сообществом и сам факт такого предложения мне был диким и я спросил, а зачем он это делает? На что он мне ответил: "Lolz oh, just cause i love contributing to open source projects. Kind of a life goals thing..." (само issue здесь). Вот тогда то я и ощутил впервые как это здорово, когда через opensource проекты тебя находят разные люди и предлагают такие интересные вещи!

Первый Дефект со стороны

Я заметил, что некий разработчик из Китая, создал мне issue, в котором он описал, что нашел дефект в работе библиотеки, что если использовать большие картинки, то получается StackOverflowError. Человек решил воспользоваться и нашел ошибку. Причем не просто нашел. а еще и написал о ней. Это новый шаг в развитии библиотеки. Причем реально решения у меня не было. В определенный момент, один из тестировщиков из России предложил решение. Но оно было сырое и сделано не как полагается и я не принял его. А когда уже нужно было публиковать библиотеку в Maven Central, нужно было что-то решать с этим дефектом, не хотелось выкладывать вместе с ним. К тому же был еще один дефект, который я так и не починил и он тоже приносил много неудобств.

Command Line Usage. Осень 2018 года

Следующим этапом в развитии было общение с шведом (Renato Athaydes), который захотел использовать библиотеку через командную строку и для этого нужно было внести некоторые изменения и дополнения. Я опять был поражен и удивлен этим. После того, как мне писал графический дизайнер удивление мое было несколько меньше, но все еще очень высоко. От мысли, что мой код кому-то реально нужен меня переполняли невероятные чувства. Он сделал необходимые изменения, подготовил код. Я провел code review, то есть просмотрел изменения, были комментарии, которые были изменены и изменения были уже в библиотеке. Эти изменения я обозначил как версию v2.0 Следующим этапом было добавление библиотеки в Maven Central — центральное хранилище, откуда можно будет скачать его для любого проекта и использовать как зависимость (dependency). На тот момент я понятия не имел как это сделать, даже отдаленно, поэтому я сослался на занятость и попросил выполнить его все действия, которые необходимы для настройки на проекте. Но этого оказалось вовсе не достаточно и самое интересное было как раз в том, чтоб настроить связь с Maven Central. Это дикая боль, которую с первого раза я так и не смог, и реально только 15 апреля у меня получилось опубликовать проект на Maven Central. Это было нелегко, но как любят говорить другие: "через это проходят все, кто хочет опубликовать свой код на Java". До того, как я опубликовал библиотеку я таки нашел что и как делать с дефектами, которые тянулись уже давно и выпустил новую версию v2.0.2, в которой я поблагодарил всех тех, кто помог мне, описал что и как я сделал.

Публикация в Maven Central. Весна 2019

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

• XX.YY.BBBB, где XX — это мажорное обновление версии, которое влечет изменения несовместимые с предыдущим.(например изменение возвращающего результата в методах);
• YY — это минорное обновление — изменение внутреннее или расширение, которое не изменяет то, что есть BBBB — это дефекты, которые были починены.
• Например версия 2.0.2 — значит ,что мажорная версия 2, минорных обновлений не было, и есть два обновления по дефектам.

Далее было важно разобраться как правильно поставить groupId, artifactId. Их нужно было выбрать один раз и использовать далее. А из них состоит пакет, в котором хранится код. Было: ua.comparison.image Стало: com.github.romankh3.image.comparison И это явно лучше, так как всем известно, что это проект из GitHub и можно его найти у человека с ником romankh3. Когда все я это сделал, выпустил новую версию v2.1.0.

Общение со Шведами. Май 2019 года

После того как я опубликовал библиотеку, мне написал на почту другой швед (Mika Kytöläinen) и попросил, чтоб его знакомый сделал изменения в моей библиотеке. Говорит, что это ему очень нужно и он будет очень рад, если мы это сделаем и сделаем быстро. Я конечно был не против изменений, которые нужны. Он предложил добавить конфигурацию толщины линии, которая рисует прямоугольник. Мол, для тех кто плохо видит — это будет полезное изменение. Подготовил код. Добавив еще несколько изменений, выпустил версию v2.2.0

Общение с немцем. Май 2019 года

После этого один немец создал issue, в котором говорит, что хочет использовать для тестирования, но ему не хватает функционала. Он сделал много предложений, которые были очень интересные, он предложил вместо того, чтоб в результате сравнения возвращать только создающуюся картинку с результатом, возвращать набор данных: то, что сравнивалось, результат(если нужно) и состояние в котором будет MATCH, MISMATCH, SIZE_MISMATCH. Даже выполнил изменения. Но они совсем не учитывали предыдущий код и были сделаны наспех. Я отклонил их и предложил выполнить так, как я считаю нужным. Несмотря на это, он больше отвечал и я решил, что сам сделаю это и выпущу новую версию. Вместе с тем, Mika Kytöläinen предложил еще интересный функционал — добавить области, которые бы не участвовали в сравнении. Это реальный кейс. И все это было выпущено в v3.0.0

Использование в реальном проекте

В конце мая мне написал тестировщик-автоматизатор из Киева, который заинтересовался библиотекой и хочет ее использовать в реальном проекте, который приносит деньги. Это был прорыв! Использование где-то в pet-project это одно, а использовать в реальном проекте — это совсем другое дело. Мы обсудили что и как работает. Применение очень интересное: у них в приложении есть чеки, которые печатают и нужно было проверять, что чеки создаются по определенному шаблону и он не меняется. Но была проблема, что такие секции как дата и время всегда менялись и их нужно было игнорировать. У нас уже был добавлен функционал на игнорирование некоторых областей, но он оказался еще очень сырым для реального использования и мы еще плодотворно поработали вместе несколько недель над этим. Результатом стал выпуск версии v3.1.1

Поиск ниши

После этого я понял, что реальная ниша для моей библиотеки — использование ее в тестах. Для этого я решил найти какой-то форум для тестировщиков и написать им об этом, чтоб получить какой-то отзыв и увеличить известность. Нашел русскоязычный форум и там опубликовал статью Организация тестирования картинок — сравнение двух похожих. В ней я получил реальный отзыв о коде и функционале, который я применил и выпустил новую версию v3.2.0, а затем и v.3.3.0.

Сейчас

Сейчас библиотека имеет 60 звезд на Github, у нее 33 форков. Я считаю, что это очень здорово с учетом того, что я его никак не пиарил кроме статьи на форуме для автоматизаторов. Спасибо всем, кто дочитал до конца. Реально оказалось намного больше статья, чем я ожидал. Статья о том, как опубликовать библиотеку в Maven Central. Если есть что добавить — пишите! Если есть что предложить по улучшению библиотеки — пишите! Я все прочту и должным образом уделю на это время. Всем кому статья понравилась и была полезна — оценивайте и пишите в комментариях. Также, подписывайтесь на мой гитхаб аккаунт romankh3 Смотрите также мои другие статьи:

• Технические вопросы на собеседовании
• Как найти работу? Советы по рассылке резюме
• Профессиональное выгорание. Как устоять?
• История Успеха. 20 часов программирования в неделю, магистратура и личная жизнь
• Создание системы мониторинга цен на авиабилеты: пошаговое руководство [Часть 1]
• Гайд по созданию клиента для Skyscanner API и его публикации в jCenter и Maven Central [Часть 1]
• Логирование: что, как, где и чем?
• Debug в Intellij IDEA: гайд для новичков