Uma das ideias que me intrigam \u00e9 a mentalidade “ship it or die". Em rela\u00e7\u00e3o ao nome, existem varia\u00e7\u00f5es, mas a ideia por tr\u00e1s da frase \u00e9 simples:<\/p>\n
Se voc\u00ea tem uma ideia, leve-a do conceito ao produto o mais r\u00e1pido poss\u00edvel.<\/p>\n
Claro, a ideia de chegar ao conceito de um produto tamb\u00e9m pode ser chamada de “conceito ao dinheiro”, mas nunca h\u00e1 garantia de que voc\u00ea vai gerar dinheiro, certo? H\u00e1 uma garantia de que voc\u00ea pode obt\u00ea-lo em um produto tang\u00edvel, no entanto.<\/p>\n
E nos c\u00edrculos de desenvolvimento de software, sempre h\u00e1 muito que uma pessoa pode argumentar a favor ou contra a ideia. De cabe\u00e7a, os dois pr\u00f3s e contras que v\u00eam imediatamente \u00e0 mente s\u00e3o:<\/p>\n
Em suma, pode haver uma troca entre a rapidez com que voc\u00ea pode enviar algo para um mercado e a arquitetura por tr\u00e1s do projeto. \u00c0s vezes h\u00e1, \u00e0s vezes n\u00e3o h\u00e1. De um modo geral, por\u00e9m, acho que \u00e9 seguro assumir o primeiro.<\/p>\n
Al\u00e9m disso, alguns podem ver o primeiro como a sa\u00edda mais f\u00e1cil, alguns podem ver o \u00faltimo como um exerc\u00edcio de YAGNI ou, ainda mais simplesmente, que o problema pode ser resolvido sempre que surgir.<\/p>\n
Mas o que isso tem a ver com qualquer coisa no momento?<\/p>\n
A raz\u00e3o pela qual estou gastando tempo escrevendo sobre isso \u00e9 que \u00e9 algo que eu, e suspeito que outros em nosso campo, pensamos pelo menos um pouco. Tudo isso \u00e9 muito bom quando se fala sobre isso no sentido abstrato, mas deixe-me tentar vincul\u00e1-lo a algo um pouco mais realista.<\/p>\n
Alguns anos atr\u00e1s, o desenvolvimento front-end consistia em agrupar conte\u00fado em elementos inline ou em n\u00edvel de bloco e estiliz\u00e1-los com CSS b\u00e1sico?<\/p>\n
T\u00ednhamos ferramentas avan\u00e7adas para trabalhar com nosso c\u00f3digo de back-end, mas o front-end era relativamente simples, exceto talvez pelos padr\u00f5es de codifica\u00e7\u00e3o impostos pela empresa ou equipe com a qual trabalh\u00e1vamos.<\/p>\n
Nossos aparelhos avan\u00e7aram (o que, para constar, considero uma coisa boa e at\u00e9 natural em tecnologia). Junto com esse avan\u00e7o, agora temos ferramentas de constru\u00e7\u00e3o espec\u00edficas para desenvolvimento front-end que s\u00e3o t\u00e3o avan\u00e7adas em alguns aspectos quanto aquelas que usamos para software back-end.<\/p>\n
Claro, temos alguns que s\u00e3o “desenvolvedores full stack”, mas fico feliz em admitir que me sinto muito mais confort\u00e1vel 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.<\/p>\n
Ele ajuda a manter o desenvolvimento focado, r\u00e1pido e consistente em todos os projetos.<\/p>\n
Por si s\u00f3, esta se\u00e7\u00e3o pode ser um post longo, mas n\u00e3o estou interessado em ir t\u00e3o longe. Em vez disso, vou pegar uma \u00fanica fatia de como o desenvolvimento front-end funciona agora e ver se n\u00e3o posso us\u00e1-la para deixar meu ponto de vista claro.<\/p>\n
Tomemos, por exemplo, o que o CSS se tornou. Temos linguagens em cima de linguagens (como Sass<\/a><\/strong> que fica em cima de, ou adiciona, CSS b\u00e1sico).<\/p>\n 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\u00e3o de qualidade. (N\u00e3o considero isso uma coisa ruim, mas mostra o crescente n\u00edvel de complexidade \u2013 ou talvez maturidade \u2013 de nossas ferramentas de front-end).<\/p>\n O desenvolvimento front-end \u00e9 muito f\u00e1cil, vamos torn\u00e1-lo mais complexo para que possamos nos sentir mais inteligentes entre aqueles de nossos pares que aparentemente est\u00e3o lidando com aspectos mais “cr\u00edticos” do neg\u00f3cio. Lembre-se que isso \u00e9 uma competi\u00e7\u00e3o.<\/p>\n<\/blockquote>\n\n