Mais um pacote?! É claro que estou a fim

Essa semana estava assistindo um vídeo onde o Guilherme Blanco falava que o composer (getcomposer.org) havia dividido a história do PHP em duas partes (antes e depois do composer). Pois bem, passados alguns anos da introdução dessa ferramenta no dia-a-dia das equipes de desenvolvimento, qual o balanço que podemos fazer de tudo isso?

A primeira coisa que vou afirmar é: use composer! Indiferente do que eu disser ou do que outras pessoas disserem, continue usando. É fantástico o que você pode fazer com ele. Os pontos negativos que estou para citar não estão relacionados a uma ferramenta, mas a um estilo de programação: CBSE (Component Based Software Engineer).

Não é difícil acharmos textos que ilustrem as vantagens no uso de pacotes “(…)packages make it easier to reuse and share code (…)” ou “(…) accelerating software development and decreasing development costs, by building software systems from prefabricated building blocks (components).” são máximas que nos rodeiam e que se apossaram de vagas cativas no senso-comum dos desenvolvedores. Não há mentiras nessas afirmativas, elas são totalmente verdade. Pacotes vão sim acelerar o seu processo e vão sim melhorar a sua produção de software. O que não se fala muito são sobre os detalhes que devem ser analisados e das arapucas que nós mesmo preparamos para nós mesmos se não nos atentamos aos detalhes. Vamos tratar deles agora.


Nem todos os blocos de montar são iguais

Variações métricas entre duas peças de jogos de montar

Todos os dias incontáveis linhas de código são escritas por desenvolvedores em todo o mundo. Ainda que fossem todas as linhas escritas na mesma linguagem de programação haveria variações de diversos fatores. Um exemplo que podemos citar em relação a essas variações seria ver como cada região desenvolveria um estilo parecido (algo como os sotaques na linguagem oral), além de muitas outras possibilidades. Pois bem, considerado a heterogeneidade de linguagens, plataformas, ambientes, paradigmas e “et cetera“ não há como prever quantas variações poderiam haver na implementação de um mesmo requisito por dois desenvolvedores diferentes.

Nesse contexto se formos tentar relacionar dois softwares feitos por duas pessoas que não se conhecem e que nunca conversaram pessoalmente a coisa vai ficar complicada. Nesse turbilhão de “e se’s” surgem os pacotes que são exatamente isso: o relacionamento de dois softwares feitos por duas pessoas diferentes. Recentemente escrevi sobre frameworks, escopos e as dificuldades que existem de se desenvolver para web (respectivamente https://goo.gl/gp1lIN, https://goo.gl/s0BONn e https://goo.gl/SkQtGd) e esse assunto é uma ponta solta dos demais. Este tópico se materializa como um spin-off gigante porque a qualidade do meu projeto será impactada pelo que eu instalo ou deixo de instalar nele.

É de máxima importância que você estude o pacote que está considerando usar. Se você não tem autoridade sobre a tecnologia que vai consumir saiba que estará assumindo um risco que pode não ter volta. Problemas geralmente surgem quando os impactos são os mais profundos que se pode obter.


Qualidade deve ser prioridade

Diagrama de Ishikawa

Se você ler por ai coisas como “BUILD APPLICATIONS QUICKLY”, “THE MOST COMPLETE TOOL” ou “ZERO TO PRO IN 5 WEEKS” não fique todo animado e saia usando, comprando ou se embrenhando sem saber exatamente em que porto está atracando. Todos queremos fazer coisas rápidas, ter as ferramentas mais completas ou nos tornamos profissionais e ganharmos muito dinheiro da noite para o dia. Não é totalmente errado pensar isso, exceto sobre a parte do dinheiro que provavelmente vai envolver coisa ilícita.

O máximo que uma ferramenta pode garantir é compatibilidade com um contexto, seguir um dado padrão ou ter uma grande quantidade de recursos; mais que isso é exagero. Nenhuma ferramenta pode se autointitular a mais isso ou aquilo. Claro que devemos ter prioridade em um desenvolvimento ágil, mas qualidade tem que ser prioridade. Você tem que fazer o melhor software no menor tempo possível. Não adianta tentar fazer software com o menor tempo possível ou fazer o melhor software possível.

Neste momento, enquanto escrevo este artigo eu não tenho conhecimento sobre um guia de estilo para desenvolvimento de pacotes para o composer. Sendo assim fica a seu critério avaliar o que está de acordo com o que você julga adequado ao seu projeto. Eu, particularmente, fico incomodado com pacotes de teste e arquivos README de outros projetos misturados aos meus projetos.


Dependências são dependências

http://slides.seld.be/

Ainda que o composer (enquanto estivermos falando de PHP) tenha que fazer o trabalho quase todo sozinho é o desenvolvedor está dando comandos para ele executar, logo a gestão de dependências tem no responsável pelo desenvolvimento a visão de um comandante. Quando você diz ao seu projeto que ele depende de algo, ele passa a depender realmente desse algo.

É prudente que você faça um fork da dependência caso julgue que ela pode desaparecer de uma hora para outra. Se você não confia em um “vendor” não deveria usar seu pacote, mas se não tiver opção essa acaba sendo uma boa saída. Não se esqueça de versionar o “composer.lock” para evitar que sejam instaladas versões erradas dos pacotes na hora do “deploy” da sua aplicação. O arquivo .lock que o composer gera é uma trava a determinada versão que ele instalou por último.

Não tem tanto tempo assim um outro gerenciador de dependência já sofreu com a quebra de um pacote que era usado em muitos projetos. O npm protagonizou um crash na internet quando um pacote de manipulação de strings simplesmente foi removido pelo seu desenvolvedor rebelado. Milhares de sites apresentaram o mesmo problema e alguns serviços ficaram indisponíveis até a traquinagem ser descoberta e corrigida.

A palavra depender remete a uma necessidade pungente da existência de um outro algo. Certifique-se que é isso mesmo que você quer para o seu projeto e para a sua vida.


Colisões de interesses

Mês passado ou retrasado, ou antes disso, não sei, de vez em quando eu perco a noção do tempo; para evitar problemas nesse sentido vou começar diferente. Era uma vez eu estava mexendo com umas integrações doidas entre GLPI e GITLAB quando eu instalei alguns pacotes. Futica daqui olha dali eu fiquei com dois pacotes que era abstrações de CURL no meu projeto. Eles vieram como dependências dos pacotes e como cada pacote tinha sua dependência eu agora tinha dois códigos “iguais” no meu projeto. No meu caso estava funcionando e era uma colisão pequena de algo de baixo impacto. Não valia a pena investir tempo para pensar em algo relativo a isso, mas ainda assim eu pensei. Pensei que eu nunca tinha me preocupado com isso que já deve ter rolado esse tipo de problema várias vezes; pensei ainda que isso poderia ser um problema geral e que não há maneira simples de escapar desse problema. A minha opção seria selecionar um dos projetos e enviar um “pull request” para ele sugerindo desacoplar o pacote de CURL e usar ele como uma espécie de driver (escrevendo códigos, claro).

Um gerenciador de dependência é capaz de avaliar se uma troca de versão de alguns dos pacotes referenciados quebra alguma compatibilidade, mas ele não tem como adivinhar que dois pacotes fazem a mesma coisa. Nesse sentido o papel do responsável pelo projeto se torna ainda mais importante porque ele que vai ter que se preocupar em analisar o que está agregando ao projeto de forma bem profunda.


O Efeito Sanfona

Toda ferramenta que acelerar o seu desenvolvimento vai muito provavelmente te fazer agarrar em um determinado ponto. Essa afirmação está sendo feita com base na lógica dos processos. Quando uma ferramenta acelera seu desenvolvimento é porque ela faz parte do trabalho que você deveria fazer. Só que ela faz isso com base na forma de uma outra pessoa trabalhar, o que te leva a ter de trabalhar como ele. No mundo do software as mudanças são coisas altamente comuns. As necessidades de um projeto são voláteis e clientes & chefes não se apegam muito a racionalidade disso. Muitas vezes você vai começar um projeto com uma promissa absoluta em relação a uma ideia e essa pode simplesmente ser modificada a ponto de se tornar o inverso do que era na concepção do software.

Vamos uma linha férrea como analogia para essa história. Imagine que uma ferramenta CASE ou RAD que você adote seja uma linha de trem para que seja feito o transporte de algo de forma maciça. Um trem pode carregar muitas toneladas por vez, o que aumenta a sua capacidade de escoar a produção. Se o seu projeto muda os rumos você pode precisar de novos caminhos para seguir, ou seja, você vai precisar de novos trilhos que te guiem para atender essas novas necessidades. Porém, nesse momento não é só você que usa os trilhos; toda uma região do seu país os usa, inviabilizando a troca dos trilhos. A empresa que gerencia a estrada está sobrecarrega cuidando do escoamento da produção de todos os outros usuários que não precisam da nova estrada. Não sei se você percebeu, mas agora você está sozinho. Não importa o quão alto você possa gritar e quantos tuítes de xingamentos consiga escrever: ou fecham-se as portas, ou novos trilhos terão de ser criados.

Quando um projeto se depara com esse tipo de desafio a produção se retrai, dai a analogia com a sanfona. Tem ainda a versão da sanfona por conta da falta de conhecimento da ferramenta onde pequenos variações dos exemplos usados como referência criam grandes gargalos de tempo. Este outro tipo de efeito sanfona é bem comum. A falta de conhecimento sobre uma certa tecnologia leva a escolhas erradas e escolhas erradas são sempre traiçoeiras porque começam parecendo as mais corretas.


O mais interessante sobre os projetos de software é que o que parece ser o mais trivial é quase sempre o mais importante. Os problemas surgem como fantasmas. Se escondem sob formas decadentes de modo a nos tentar a coisas sombrias. Tão certo quanto “;” é diferente de “;” seu projeto terá problemas e você deverá estrar pronto para resolvê-los.