DEV Community: Diego Borges

Arquitetura Hexagonal... É arquitetura? É hexagonal?

Diego Borges — Thu, 14 Oct 2021 20:01:32 +0000

Nas últimas semanas estou vendo algumas discussões relacionadas a confirmação da arquitetura hexagonal e outros modelos como DDD como arquitetura ou não. Acredito que a discussão é bem válida, e achei pertinente dar meus 2 centavos sobre o assunto. Diferente de alguns outros posts, acredito que o conteúdo desse é mais um ponto de vista do que uma resposta definitiva sobre o assunto, portanto cabe a você que lê, guardar aquilo que faz sentido.

Só para contextualizar, a arquitetura hexagonal consiste em dividir a aplicação em camadas separando o código em categorias diferentes (são geralmente usadas as camadas de infraestrutura, aplicação e domínio). Ela é baseada no famoso desenho da arquitetura de cebola ou arquitetura em camadas muito usado para representar a Clean Architecture” ou no bom português “Arquitetura Limpa”, mas é chamada arquitetura hexagonal por causa dos primeiros desenhos usados em sua representação.

Leia o artigo na íntegra no meu (blog)[https://diegoborgs.com.br/blog/arquitetura-hexagonal-%C3%A9-arquitetura-%C3%A9-hexagonal].

[Mastering Swoole PHP] Parte I e II - Introdução e Background

Diego Borges — Thu, 14 Oct 2021 19:59:02 +0000

Olá mundo!

Estou lendo o livro Matering Swoole PHP PHP do Bruce Dou por indicação do @SwooLeoCavalcante. Como é um livro em inglês, estou tendo alguma dificuldade em assimilar os conteúdos que foram apresentados ali, por esse motivo resolvi escrever com minhas palavras um resumo de cada parte.

A ideia principal dessa série de artigos não é fazer uma tradução do livro ou reescrever com detalhes o que já está escrito lá, mas mostrar os pontos abordados em cada parte através da minha ótica. Recomendo a vocês a leitura deste livro para terem suas próprias ideias e opiniões.

Leia o artigo completo no meu blog.

[Semanal de quarentena] - Como definir um preço sólido para projetos ágeis?

Diego Borges — Thu, 14 Oct 2021 19:56:18 +0000

Olá seres humanos, hoje é o dia 397 desta quarentena insana e neste artigo resolvi contar pra vocês como eu faço para cobrar em projetos ágeis.

Se você não faz idéia do que é o ágil e porque trabalhar com projetos ágeis, dê uma olhada no manifesto ágil antes de continuar.

Antes de qualquer outra coisa, gostaria de deixar bem claro que eu não sou especialista em nenhuma metodologia ágil, acredito que por mais que uma metodologia ágil ajude na organização do trabalho, o ágil esta muito mais relacionado a um estilo de vida. Para entender um pouco melhor isso recomendo que assista este vídeo do Fábio Akita.

Veja o post completo no meu blog.

[Semanal de quarentena] - 8 Conceitos fundamentais para um bom desenvolvedor

Diego Borges — Thu, 14 Oct 2021 19:53:59 +0000

E aí galera, tudo bem? Eu espero que sim!

Dando sequência aos meus posts semanais de quarentena para vocês, hoje resolvi seguir o conselho de alguns amigos no twitter que me pediram para falar um pouco sobre alguns conceitos de desenvolvimento, além disso, faz um tempinho que eu quero escrever alguma coisa sobre carreira. Então, eu vou fazer uma abstração e reaproveitar esse código… ops, quero dizer post para fazer uma listinha com os conceitos que eu considero fundamentais para bons desenvolvedores.

Apesar de ter feito minhas primeiras linhas de HTML em 2011, e de lá pra cá já são 9 anos em que tive a oportunidade de trabalhar em muitos projetos com desafios diferentes e em times com muita gente boa, confesso que às vezes eu não acredito que minha carreira é tão longa assim para falar como outra pessoa deve lidar com a dela. O que eu vou deixar para vocês aqui são alguns conceitos que, depois que comecei a entender, me tornaram um desenvolvedor melhor, mas deixo com vocês a responsabilidade de decidir aplicar ou não eles em suas vidas profissionais.

Leia esse post na íntegra no meu blog.

Utilizando o princípio First para escrever testes unitários melhores

Diego Borges — Thu, 14 Oct 2021 19:51:07 +0000

Já não é novidade que sou fã da prática de TDD para desenvolvimento de softwares, acredito realmente que um bom código só é um bom código se tiver bem coberto por testes, afinal de contas, são os testes que terão a capacidade de medir a qualidade de um código.

Recentemente estive lendo o “Clean Code” do Tio Bob, um livro excelente pra quem busca uma maior sensibilidade à qualidade de um código. Neste livro existe um capítulo inteiro dedicado às boas práticas na escrita e execução de testes. Tio Bob afirma que um teste deve ser bem escrito para que assim os desenvolvedores possam evoluir tanto o teste quanto o código de maneira simples e que não deixem de praticar a escrita de testes por ser um fardo no projeto.

Leia o post completo no meu blog.

05 coisas sobre o TDD que você pode estar pensando errado

Diego Borges — Thu, 14 Oct 2021 19:47:46 +0000

Esses dias escrevi um post sobre a importância da cultura de TDD para desenvolvedores e não desenvolvedores, para dar continuidade sobre esse tema que eu acho extremamente relevante, vamos desmistificar algumas coisas sobre TDD e a cultura de testes.

Leia o post completo em meu site.

A importância da cultura de TDD na vida dos desenvolvedores e dos não desenvolvedores

Diego Borges — Thu, 14 Oct 2021 19:45:13 +0000

A maioria dos desenvolvedores são a favor dos testes, mas discordam completamente em como testar.

Era uma bela sexta-feira de outono, num clima ameno de fim de tarde de uns poucos anos atrás. O gerente de projeto entrou na sala informando que a incorreta formatação de um dado no sistema está causando alguns problemas, parece ser uma alteração simples e que vai causar um belo impacto positivo com o cliente. Neste momento a equipe engajada em agradar o cliente altera a formatação do dado, testa para ver se o dado está formatado corretamente e publica em produção.

O que ninguém sabia era que aquele valor era formatado daquela maneira para atender a um requisito de uma outra parte muito distante do sistema e sua alteração acabou causando um impacto enorme que só foi percebido uma semana depois. O resultado de tudo isso foi exatamente o contrário do esperado, um enorme desconforto com o cliente.Quem nunca passou por algo parecido?

O processo de automação com testes
Na disciplina de engenharia de software, existe uma area chamada de Automação em testes (ou apenas Testes como eu prefiro chamar). Essa disciplina consiste em inúmeras técnicas (Testes unitários, de interface, de contrato, de integração, e2e, etc) utilizadas para tornar o processo de testes automático e mais produtivo. Mesmo com a existência de algo tão relevante ainda existem muitas discussões sobre quando e como inserir essas técnicas em seu projeto. Perguntas como “Qual a melhor técnica de testes?”, “Quando devo testar?”, “Tenho que testar tudo?” ainda são muito recorrentes no dia a dia de uma equipe de desenvolvimento que está começando a trabalhar com testes.

Para te ajudar com tudo isso vou te apresentar o TDD, uma metodologia cujo objetivo é tornar a prática de testes essencial no desenvolvimento de um software.

O que é TDD?
TDD (Test-Driven Development ou Desenvolvimento Orientado a Testes) tem se tornado sem dúvidas uma prática recorrente entre bons desenvolvedores. Ao contrário do que alguns pensam, o TDD não é uma técnica de testes, mas uma metodologia ou cultura para desenvolvimento de um software e tem um conceito bem simples: os testes são desenvolvidos antes de escrevermos o código final. Para que o TDD dê certo é necessário trabalhar rigorosamente com um ciclo contínuo de ações sem pular nenhuma fase.

Calma ai que o palestrinha vai te explicar um pouco melhor como é esse ciclo…

O ciclo de desenvolvimento é chamado de Red, Green and Refactor, composto das seguintes fases:

Novo teste Nesta fase iremos escrever o código que irá testar o resultado da nossa nova funcionalidade, esta parte é muito importante, pois é a base do nosso teste. É importante ressaltar que é necessário especificar muito bem qual o escopo de entrada e de saída do código a ser testado. Se você não consegue entender o que seu código vai fazer e retornar, você não poderá fazer um teste assertivo.

No começo não é muito intuitivo, mas com a prática aprendemos a escrever e a prever melhor os resultados de nossas funções.

Nesta etapa o teste falha
Por ainda não existir uma função o seu teste não vai funcionar (se funcionar tem algo de errado aí rsrs). Com o teste falhando temos um objetivo a alcançar, fazer o teste funcionar através da nossa funcionalidade.

Criar funcionalidade Nessa fase iremos escrever o nosso código da maneira mais simples possível. O nosso objetivo é unicamente a aprovação nos testes. Agora não é necessário se preocupar com as boas práticas, design patterns ou coisas do tipo, o código só deve funcionar e passar pelo teste sem quebrar outros testes.

Nesta etapa o teste passa
Sinal verde! O código que você escreveu passou pelo teste e não quebrou os outros. É muito importante garantir que o seu código além de passar pelo teste desenvolvido, não está quebrando os testes que já existem.

Agora vamos para a última fase.

Refatorar Pensou que não ia precisar mais se preocupar com padrões e boas práticas né? Achou errado!

Não é porque o código já está escrito e funcionando que o trabalho acabou, agora é a hora de refatorar com a tranquilidade por já ter um teste que pode nos indicar qualquer problema na hora de refatorar.

O TDD nos obriga a escrever códigos menos acoplados e mais coesos para se tornarem mais “testáveis”.

Como conseguimos um código simples? Fazendo um Teste passar
Como conseguimos um código claro? Refatorando o código após ele passar
Como conseguimos um código seguro? Com Testes

Vantagens de usar TDD
Qualidade mais proativa e menos reativa
Na maioria dos projetos só pensamos na qualidade do resultado de suas funcionalidades em sua fase final, onde o projeto está sendo homologado. Para o desenvolvimento do produto isso é muito ruim, comunicação é um problema grande na maior parte das equipes e é muito difícil garantir que as coisas são interpretadas da mesma forma por todo mundo.

Imagine agora que no momento de homologar um projeto descobre-se que a equipe de desenvolvimento, por uma falha de comunicação tomou alguma decisão errada na base do projeto (sim, isso acontece). Não seria muito mais fácil evitar isso se tivessemos desde o princípio o profissional de qualidade envolvido, desenhando cenários de testes e analisando os processos e os resultados de cada feature?

Código mais legivel
Como vamos testar uma função de 1.000.000 de linhas que faz 547 coisas ao mesmo tempo? É impossível. Por este motivo escrever testes nos obriga a escrever códigos limpos que façam somente uma coisa.

Documentação do código
Uma das vantagens que acho mais legal é essa, a suite de testes (local onde seus códigos de testes ficam dentro do projeto para os menos familiarizados) serve como uma documentação, facilitando o onboarding de novas pessoas no projeto e sem aquele efeito colateral que é atualizar o código e não atualizar a documentação por que com o TDD o teste é atualizado antes da mudança no código em si e só funciona se ambos estiverem atualizados.

Prevenção de bugs em partes desconhecidas do projeto em alterações simples
Quem nunca passou por uma situação parecida com a historinha do começo deste artigo? Pois é, situação complicada. A ampla cobertura de testes que é um resultado claro do TDD nos ajuda a previnir esse tipo de situação.

Além disso, a alteração do comportamento de um código em um projeto que usa TDD é muito mais simples, você altera primeiro o teste que valida o cenario que você quer alterar para o novo resultado esperado e roda a suite, ela vai te apontar os lugares que estão diferentes do esperado, você corrige e roda a suite novamente para ver se não houve nenhum efeito colateral, se não houver, acabou e você tá livre para o seu próximo desafio.

Deploy a qualquer hora, momento ou lugar
Imagine um mundo onde você pode fazer um deploy na sexta, às 17:59, ir para o meio da amazonia conhecer as belezas da nossa floresta sem sinal de internet ou celular e voltar na segunda feira para trabalhar sem se preocupar? A existência da suite de testes é uma garantia que as coisas que funcionavam antes vão continuar funcionando e isso nos ajuda a alcançar este estado de utopia.

Código sem testes é código ruim. Não importa o quão bem escrito, nem se ele é bonito, orientado a objetos ou se foi bem encapsulado. Com testes, podemos alterar o comportamento de nosso código de maneira rápida e verificável. Sem eles, não temos como saber se nosso código está melhorando ou piorando. - Michael Feathers (Working Effectively with Legacy Code [2004]).

Os testes são tão importantes para a saúde de um projeto quanto o código de produção. Talvez até mais, pois eles preservam e aumentam a flexibilidade, capacidade de manutenção e reutilização do código de produção. - Uncle Bob (Clean Code [2008])

Conclusão
Por muito tempo eu ouvi falar no TDD como uma utopia, que era algo lindo no papel mas impossível de ser alvançado. Só que não! Depois de algum tempo trabalhando com o TDD aprendi que realmente não é uma bala de prata, não resolve todos os problemas da humanidade, mas também não é uma lenda, cabe ao profissional de desenvolvimento analisar o seu uso, e pra ser sincero, encontrei poucos casos onde não fazia sentido o uso do TDD.

Menos é melhor… Como a simplicidade, o foco e a objetividade podem te auxiliar a criar o layout de um site.

Diego Borges — Thu, 14 Oct 2021 19:42:26 +0000

Antes que me critiquem rsrs… “Menos é melhor” foi um termo utilizado por um grande mestre pra mim, Mateus Neves (General de WEB da Quartel Design), para descrever como eu deveria conduzir o desenvolvimento de um site, e sim na hora ele queria dizer “Menos é mais”.

Bom, pra quem não me conhece, meu nome é Diego Borges e eu não sou um designer, sou desenvolvedor front-end, mas este artigo é destinado para aqueles que querem se aventurar no desenvolvimento de layouts de web sites. Neste artigo você não encontrará códigos, nem técnicas, apenas dicas para conseguir construir um design mais usual. Então… Segue o baile!

Antes de qualquer coisa vamos entender o que diabos é UX e UI, e qual a diferença entre as duas coisas.
Basicamente falando User Experience (UX) é a maneira como você vai se sentir ao usar algo e User Interface (UI) são todas as coisas visualmente perceptíveis em alguma plataforma e que podem conduzir o usuário até uma determinada ação. Mas por que diabos isso é importante? Quando vamos desenvolver um site (seja no design ou no código) temos que pensar que pessoas vão usar ele e por (seu cliente e um cliente final).

Portanto é nosso dever facilitar as coisas para ambos. Não devemos criar um layout que seja complexo para seu cliente alimentar com seu conteúdo e nem muito menos que dificulte o usuário final a acessar aquilo que ele precisa acessar. No fim das contas o seu layout deve conduzir ambos os usuários a ter uma boa convivência com o site.

Agora vamos as dicas…

Meu site não é um banner na internet…
Apesar de um site também ser um material de divulgação, ele não deve ser tratado da mesma maneira que um banner, um card ou fly. Não pense num site como algo estático e com texto fixo, mas algo que pode ser adaptável ao dispositivo que acessa e ao conteúdo que será inserido. Este é o conceito básico de responsividade.

Um layout responsivo não é o mesmo que um layout diferente pra cada tela… Esquece isso, você pode criar um único layout para um site, basta fazer de maneira que ele consiga ser fluido, ou seja, que acompanhe o tamanho da tela aumentando, diminuindo ou mudando a sua orientação de acordo com o tamanho da tela do usuário.

Para ter um layout fluido evite ao máximo estas ações:

Uma imagem background que ocupe o site inteiro pois com o crescimento do conteúdo você pode ter problemas com a resolução ou quebra da imagem;

Tente sempre trabalhar com um background diferente para cada sessão (não precisa ser uma imagem, pode ser cor ou até mesmo um fundo branco);

Mantenha as sessões isoladas de maneira que mesmo que o site perca uma sessão não quebre a sua proposta, tente sempre imaginar o comportamento das sessões em diferentes tamanhos de tela.

Conheça as ferramentas usadas por sua equipe no desenvolvimento do site…
Agora você deve estar pensando assim… Poxa, mas eu sou fera no Photoshop e no Illustrator do que esse cara está falando? Neste caso não estamos falando apenas de você e conhecer as ferramentas que a sua equipe usa pode ser muito produtivo para o projeto no final das contas.

Tente responder essas perguntas:

Qual a ferramenta utilizada para criar prototipos/wireframes pela sua equipe?
Qual os softwares utilizados para desenho do layout?
Quais as tecnologias/frameworks utilizados no desenvolvimento do layout?
Se você não soube responder as 3 com total certeza e assertividade, tá na hora de bater um papo com sua equipe para entender melhor o processo de desenvolvimento.

Dentro do contexto da minha equipe, nós usamos o Sketch para prototipação, Photoshop para elaboração dos layouts e usamos bootstrap/jQuery para o desenvolvimento do layout.

PS: Uma dica de desenvolvedor

Se na sua equipe também é usado um framework para desenvolvimento, tente entender ele um pouco melhor, geralmente existe em todo o framework uma styleguide explicando quais as características do framework e na duvida peça o desenvolvedor pra te explicar um pouco sobre como o framework funciona.

A melhor ferramenta é o dialogo… Converse com sua equipe!
É sempre bom pra um projeto escutar TODAS as partes envolvidas, desde o cliente até a equipe. Enquanto desenvolver o layout de um site peça um feedback de sua equipe e tente tirar sempre as coisas positivas desta conversa.

É claro que não dá pra mudar todo o layout por causa de uma opinião sem fundamentos.

Simples, focado e objetivo…
Hoje a maior parte de acessos em um site são feitos por conexões de baixa qualidade e tendo isso em vista todos nós temos a responsabilidade de economizar banda para nossos clientes.

Para isso tenho algumas dicas:

Tente não abusar das imagens com transparências (Elas são muito mais pesadas que as sem transparência);

Animações são bem vindas em um site, mas animações demais podem atrapalhar totalmente o seu projeto;

Se algo não é importante pro layout é melhor tirar;

Sempre busque referências.

Considerações finais…
Mais do que bonito, um site deve ser funcional. Eu não sou um expert em UX ou UI, mas estas foram duvidas e divergências que encontrei durante minha caminhada como desenvolvedor e gostaria de dividir com vocês.

No mundo do desenvolvimento não existe uma bala de prata, algo que funcione para todos os projetos, vocês estão livres para aderir ou não estas práticas no dia-a-dia de vocês.