Olá a todos, comunidade JavaRush! Um pouco sobre mim: trabalho como engenheiro de software Java desde a primavera de 2016. Adoro vir aqui e resolver problemas que não resolvi durante meus estudos. Hoje vou falar sobre a biblioteca - Comparação de imagens . Esta é uma biblioteca de código aberto que está disponível publicamente no GitHub . O objetivo deste artigo é transmitir que criar um produto open source não é apenas perda de tempo, não! Esta é uma experiência rica que se tira de diferentes lados, quando você tem controle sobre todo o processo de desenvolvimento, quando precisa se aprofundar em cada detalhe. Open Source é o mundo ao seu redor. Não estou brincando, durante a existência desta biblioteca me comuniquei com pessoas de diversos países, como EUA, Índia, China, Egito, Rússia, Alemanha, Ucrânia, Suécia, Nova Zelândia, Noruega. Ou seja, esta é uma experiência real de desenvolvimento conjunto, busca de compromissos, verificação de código e assim por diante. Essa foi a introdução, agora vamos começar pela ordem:
Teste. Início de agosto de 2017
Tudo começou com uma entrevista em uma das empresas, onde o primeiro passo foi escrever uma tarefa de teste. A tarefa era escrever um código que comparasse duas imagens do mesmo tamanho, encontrasse as diferenças entre elas, agrupasse-as e desenhasse um retângulo ao redor delas. Aí está a primeira foto:
Há uma segunda foto:
Foi necessário encontrar as diferenças e circulá-las conforme mostrado abaixo:
Como você pode ver, há uma diferença no campo Nome de usuário , que está circulado por um triângulo vermelho. Descrição mais detalhada da tarefa . Decidi que queria fazer isso não só corretamente do ponto de vista funcional, mas também bonito, para que não fosse constrangedor. Para fazer isso, decidi publicar isso como um projeto no GitHub . Há muito tempo eu queria estudar o GitHub e ganhar experiência trabalhando com ele. Após uma rápida olhada, descobri que seria bom adicionar serviços de terceiros para analisar a qualidade do código, gerar cobertura de código com testes, etc. Adicionadas as seguintes ferramentas:
Codacy - qualidade do código. Realmente vale a pena prestar atenção.
Travis CI é uma ferramenta de CI (integração contínua) que constrói um projeto, executa testes e informa se o projeto foi construído com sucesso. Por exemplo, se um dos testes não foi aprovado como resultado das novas alterações, ele dirá que a construção do projeto não foi bem-sucedida e o colorirá de vermelho.
Coveralls é uma ferramenta que mostra qual porcentagem do seu código é coberta por testes.
BetterCode Hub é outra ferramenta para analisar a qualidade do código. Uma coisa muito útil que não só lhe dirá o que é ruim, mas também descreverá o porquê e fornecerá um link para um livro onde você poderá obter conhecimento sobre o assunto.
Cada um desses serviços possui seu próprio emblema com resultados de dados, como um projeto de cobertura de código. E este emblema pode ser adicionado na descrição principal do projeto - arquivo README. A tarefa estava pronta - enviei para revisão. Após a revisão, eu imediatamente, de memória fresca, criei um problema no Github para cada comentário , o que me ajudaria a melhorar este projeto. Não houve tarefa de melhoria por parte do empregador, então esqueci do projeto por um tempo...
Caminho da Biblioteca. Julho de 2018
Logotipo
A certa altura, descobri que as pessoas visitam meu projeto com frequência, e isso acontece todos os dias. Fiquei surpreso com isso, e ainda mais surpreso com o fato de que cerca de um ano depois eles criaram um NÚMERO, no qual estava escrito que um certo designer gráfico estava me oferecendo a criação de um logotipo para o meu projeto. Dizem que ele adora fazer isso para produtos Opensource e fará isso de forma totalmente gratuita. Começamos a colaborar. Várias opções foram propostas, mas finalmente decidimos por esta:
Eu ainda era jovem e não estava familiarizado com a comunidade de código aberto, e o próprio fato de tal oferta foi uma loucura para mim e perguntei: por que ele está fazendo isso? Ao que ele respondeu: "Lolz, ah, só porque adoro contribuir para projetos de código aberto. Uma espécie de objetivo de vida..." ( a questão em si está aqui ). Foi quando senti pela primeira vez como é ótimo quando diferentes pessoas encontram você por meio de projetos de código aberto e oferecem coisas tão interessantes!
Defeito do primeiro lado
Percebi que um certo desenvolvedor da China criou um problema para mim , no qual descreveu que havia encontrado um defeito no funcionamento da biblioteca, que se você usar imagens grandes, obterá um StackOverflowError . O homem decidiu aproveitar e encontrou um erro. E eu não apenas encontrei. e também escreveu sobre ela. Este é um novo passo no desenvolvimento da biblioteca. Além disso, eu realmente não tinha uma solução. A certa altura, um dos testadores da Rússia propôs uma solução. Mas estava cru e não foi feito direito e eu não aceitei. E na hora de publicar a biblioteca no Maven Central foi preciso resolver alguma coisa com esse defeito, não queria publicar junto com ela. Além disso, teve outro defeito que nunca consertei e que também trouxe muitos transtornos.
Uso de linha de comando. Outono 2018
A próxima etapa do desenvolvimento foi a comunicação com um sueco (Renato Athaydes), que queria utilizar a biblioteca via linha de comando e para isso foi necessário fazer algumas alterações e acréscimos. Fiquei novamente impressionado e surpreso com isso. Depois que o designer gráfico me escreveu, minha surpresa foi um pouco menor, mas ainda muito grande. A ideia de que alguém realmente precisava do meu código me encheu de sentimentos incríveis. Ele fez as alterações necessárias e preparou o código. Fiz uma revisão de código, ou seja, olhei as alterações, havia comentários que foram alterados e as alterações já estavam na biblioteca. Designei essas alterações como versão v2.0. O próximo passo foi adicionar a biblioteca ao Maven Central - um repositório central, de onde você pode baixá-la para qualquer projeto e usá-la como dependência. Naquela época eu não tinha ideia de como fazer isso, nem remotamente, então disse que estava ocupado e pedi para ele realizar todos os passos necessários para montar o projeto. Mas isso acabou não sendo suficiente e o mais interessante foi estabelecer uma conexão com o Maven Central. Isso é uma chatice, o que não consegui fazer da primeira vez, e foi somente no dia 15 de abril que consegui publicar o projeto no Maven Central. Não foi fácil, mas como outros gostam de dizer, “todo mundo que quer publicar seu código Java passa por isso”. Antes de publicar a biblioteca, finalmente descobri o que e como fazer com os defeitos que já existiam há muito tempo e lancei uma nova versão v2.0.2 , na qual agradeci a todos que me ajudaram, descrevi o que e como fiz .
Publicando no Maven Central. Primavera de 2019
Para publicar uma biblioteca corretamente, você precisa ter um bom conhecimento de controle de versão e de como definir versões corretamente. Vou seguir este esquema:
XX.YY.BBBB , onde XX é uma atualização importante da versão, que acarreta alterações incompatíveis com a anterior (por exemplo, uma alteração no resultado retornado nos métodos);
YY é uma pequena atualização – uma mudança interna ou expansão que não altera o que é BBBB – são defeitos que foram corrigidos.
Por exemplo, a versão 2.0.2 significa que a versão principal é 2, não houve atualizações secundárias e há duas atualizações para defeitos.
A seguir, foi importante descobrir como definir corretamente groupId e artefatoId . Eles tiveram que ser selecionados uma vez e usados posteriormente. E eles compõem o pacote no qual o código está armazenado. Era: ua.comparison.image Agora: com.github.romankh3.image.comparison E isso é claramente melhor, pois todos sabem que este é um projeto do GitHub e pode ser encontrado por uma pessoa com o apelido romankh3. Quando fiz tudo isso, lancei uma nova versão v2.1.0 .
Comunicação com os suecos. Maio de 2019
Depois que publiquei a biblioteca, outro sueco (Mika Kytöläinen) me enviou um e-mail e pediu ao amigo que fizesse alterações em minha biblioteca. Ele diz que precisa muito disso e que ficará muito feliz se fizermos isso e rápido. É claro que não fui contra as mudanças que eram necessárias. Ele sugeriu adicionar uma configuração de espessura de linha que desenha um retângulo. Tipo, para quem tem visão deficiente, esta será uma mudança útil. Preparou o código . Depois de adicionar mais algumas alterações, lancei a versão v2.2.0
Comunicação com um alemão. Maio de 2019
Depois disso, um alemão criou um problema no qual diz que quer usá-lo para testes, mas falta funcionalidade. Ele fez muitas propostas que foram muito interessantes, sugeriu que ao invés de retornar apenas a imagem resultante com o resultado da comparação, retornasse um conjunto de dados: o que foi comparado, o resultado (se necessário) e o estado em que houve será MATCH, MISMATCH, SIZE_MISMATCH . Até fiz as alterações. Mas eles não levaram em consideração o código anterior e foram feitos às pressas. Eu os rejeitei e me ofereci para realizá-los como achasse adequado. Apesar disso, ele respondeu mais e eu decidi que faria isso sozinho e lançaria uma nova versão. Ao mesmo tempo, Mika Kytöläinen propôs outra funcionalidade interessante - adicionar áreas que não seriam incluídas na comparação. Este é um caso real. E tudo isso foi lançado na v3.0.0
Use em um projeto real
No final de maio, um testador de automação de Kiev me escreveu, que se interessou pela biblioteca e quer usá-la em um projeto real que gere dinheiro. Foi um avanço! Usá-lo em algum lugar de um projeto de estimação é uma coisa, mas usá-lo em um projeto real é uma questão completamente diferente. Discutimos o que e como funciona. O aplicativo é muito interessante: no aplicativo deles têm cheques que são impressos e foi necessário verificar se os cheques são criados de acordo com um determinado modelo e ele não muda. Mas havia um problema: seções como data e hora sempre mudavam e tinham que ser ignoradas. Já havíamos adicionado funcionalidade para ignorar algumas áreas, mas ainda era muito cru para uso real e ainda trabalhamos juntos de forma frutífera por várias semanas nisso. O resultado foi o lançamento da versão v3.1.1
Encontrando um nicho
Depois disso, percebi que o verdadeiro nicho da minha biblioteca era utilizá-la em testes. Para fazer isso, decidi encontrar algum tipo de fórum para testadores e escrever para eles sobre isso, a fim de obter feedback e aumentar a fama. Encontrei um fórum em russo e publiquei um artigo lá: Organização de imagens de teste - comparação de duas semelhantes . Nele recebi feedback real sobre o código e funcionalidade, que apliquei e lancei uma nova versão v3.2.0 e depois v.3.3.0 .
Agora
A biblioteca atualmente possui 60 estrelas no Github e 33 forks. Acho isso muito legal, considerando que não promovi de forma alguma a não ser por um artigo no fórum de automatizadores. Obrigado a todos que leram até o fim. Na verdade, acabou sendo um artigo muito mais longo do que eu esperava. Um artigo sobre como publicar uma biblioteca no Maven Central. Se você tiver algo a acrescentar, escreva! Se você tem alguma sugestão para melhorar a biblioteca, escreva! Vou ler tudo e dedicar o tempo adequado a isso. Quem gostou do artigo e achou útil - avalie e escreva nos comentários. Além disso, assine minha conta do github romankh3. Veja também meus outros artigos:
GO TO FULL VERSION