Envie ou morra (com ou sem qualidade, embora?)

Uma das ideias que me intrigam é a mentalidade “ship it or die". Em relação ao nome, existem variações, mas a ideia por trás da frase é simples:

Se você tem uma ideia, leve-a do conceito ao produto o mais rápido possível.

Claro, a ideia de chegar ao conceito de um produto também pode ser chamada de “conceito ao dinheiro”, mas nunca há garantia de que você vai gerar dinheiro, certo? Há uma garantia de que você pode obtê-lo em um produto tangível, no entanto.

E nos círculos de desenvolvimento de software, sempre há muito que uma pessoa pode argumentar a favor ou contra a ideia. De cabeça, os dois prós e contras que vêm imediatamente à mente são:

1. Profissional. Fazer algo rápido que funcione e que [potencialmente] gere receita.
2. Con. Arquitetura fraca, manutenção, escalabilidade, testabilidade e assim por diante.

Em suma, pode haver uma troca entre a rapidez com que você pode enviar algo para um mercado e a arquitetura por trás do projeto. Às vezes há, às vezes não há. De um modo geral, porém, acho que é seguro assumir o primeiro.

Além disso, alguns podem ver o primeiro como a saída mais fácil, alguns podem ver o último como um exercício de YAGNI ou, ainda mais simplesmente, que o problema pode ser resolvido sempre que surgir.

Mas o que isso tem a ver com qualquer coisa no momento?

Enviar ou morrer?

A razão pela qual estou gastando tempo escrevendo sobre isso é que é algo que eu, e suspeito que outros em nosso campo, pensamos pelo menos um pouco. Tudo isso é muito bom quando se fala sobre isso no sentido abstrato, mas deixe-me tentar vinculá-lo a algo um pouco mais realista.

Era uma vez…

Alguns anos atrás, o desenvolvimento front-end consistia em agrupar conteúdo em elementos inline ou em nível de bloco e estilizá-los com CSS básico?

Tínhamos ferramentas avançadas para trabalhar com nosso código de back-end, mas o front-end era relativamente simples, exceto talvez pelos padrões de codificação impostos pela empresa ou equipe com a qual trabalhávamos.

Mas então…

Nossos aparelhos avançaram (o que, para constar, considero uma coisa boa e até natural em tecnologia). Junto com esse avanço, agora temos ferramentas de construção específicas para desenvolvimento front-end que são tão avançadas em alguns aspectos quanto aquelas que usamos para software back-end.

Claro, temos alguns que são “desenvolvedores full stack”, mas fico feliz em admitir que me sinto muito mais confortável trabalhando no lado do servidor do que no front-end. Se eu trabalho no front-end, costumo ficar com as ferramentas com as quais estou familiarizado e tento ficar dentro dos guarda-corpos definidos pela pista em que opero.

Ele ajuda a manter o desenvolvimento focado, rápido e consistente em todos os projetos.

Ok, então qual é o ponto?

Por si só, esta seção pode ser um post longo, mas não estou interessado em ir tão longe. Em vez disso, vou pegar uma única fatia de como o desenvolvimento front-end funciona agora e ver se não posso usá-la para deixar meu ponto de vista claro.

Ficando atrevido

Tomemos, por exemplo, o que o CSS se tornou. Temos linguagens em cima de linguagens (como Sass que fica em cima de, ou adiciona, CSS básico).

E temos processadores que compilam, minificam, soltam lint e nos impedem de ver nosso trabalho antes que certos erros e avisos sejam corrigidos por uma questão de qualidade. (Não considero isso uma coisa ruim, mas mostra o crescente nível de complexidade – ou talvez maturidade – de nossas ferramentas de front-end).

O desenvolvimento front-end é muito fácil, vamos torná-lo mais complexo para que possamos nos sentir mais inteligentes entre aqueles de nossos pares que aparentemente estão lidando com aspectos mais “críticos” do negócio. Lembre-se que isso é uma competição.

Este artigo tem uma visão humorística sobre a coisa toda.

Um grau razoável de qualidade

Para ser claro, não estou dizendo que isso é uma coisa ruim, mas estou dizendo que coisas que antes eram relegadas ao lado do servidor ou a linguagens compiladas agora estão se estendendo por toda a pilha de desenvolvimento de um aplicativo da web.

Para ser o mais claro possível: sou a favor da qualidade. Enviar coisas sem qualquer grau disso pode ser visto como um exercício de irresponsabilidade.

Mas também acredito que há um equilíbrio a ser alcançado entre escrever o código mais otimizado, funcional e com melhor desempenho possível sob as restrições de tempo e orçamento.

Não acredito, não importa o quanto tentemos nos impor, que vivemos em uma utopia de desenvolvedor onde podemos otimizar, arquitetar e implementar sistemas primitivos em cada projeto.

Parece, no entanto, que tentamos ao máximo criá-lo, não é?

Mas em algum momento, não vale a pena perguntar se todas as ferramentas que estamos criando e todas as coisas que estamos adicionando aos nossos projetos removem exatamente o que nos levou à indústria em primeiro lugar? Concedido, para alguns de nós, isso é provavelmente diferente. É justo perguntar que ter uma ideia, escrever código para dar vida a ela e vê-la resolver um problema foi o que nos trouxe ao redil?

Neste ponto, porém, introduzimos tantas ferramentas que colocar um ambiente de desenvolvimento em funcionamento para um aplicativo da Web executado do banco de dados até o navegador é uma tarefa intimidadora.

Tantas coisas precisam acontecer antes de estarmos realmente prontos para começar a escrever código que pode se tornar tedioso e até um pouco cansativo apenas dar os passos iniciais para fazê-lo.

Uma opinião pessoal e final

Eu gravito em torno da aplicação de práticas e ferramentas orientadas a objetos fortes em muitos dos projetos em que trabalho com minha equipe e que envio para outros porque sei, por experiência, que o tempo, dinheiro e dados que podem ser perdidos de algo não é t abordada de todos os lados.

Isso não quer dizer que enviar algo rapidamente nega isso. Mas o processo e a organização do código por trás de um projeto é algo que tenho muita dificuldade em ignorar tanto que parece quase paralisante enviar algo que não foi testado e aprovado no mais alto grau possível (e mesmo assim, existem problemas).

Por outro lado, porém, há uma parte de mim que quer experimentar uma ou duas ideias por trás da mentalidade “envie ou morra” apenas para ver o quão rápido algo pode ser construído, enviado e gerando qualquer tipo de receita, independentemente de quão impecável a base do código é.

E talvez eu tente isso com alguns projetos futuros.