Há 20 anos trabalhei na área de tecnologia, dez anos depois fui para a posição gerencial e agora voltei à área de tecnologia, desta vez na função de consultor. Algumas das mudanças me deixaram muito feliz, enquanto outras me surpreenderam da mesma forma. Abaixo, falarei brevemente sobre as principais coisas que quase me mataram no auge da vida.
Bom primeiro: Unix e desenvolvedores reunidos
Ao longo da década de 1980 e início de 1990, a maior parte do desenvolvimento de software profissional era feita em estações de trabalho Unix caras, como Sun Sparc ou NeXT. Nos anos noventa, o mercado foi capturado pelo WinTel e todos começaram a codificar no Windows usando ferramentas de grandes fornecedores como o MS Visual Studio, ou algumas opções gratuitas como o Eclipse. O Linux naquela época ainda era considerado algo mais para entusiastas do mundo dos desktops.
Em 2001, trabalhei em uma startup. Havia apenas um desenvolvedor Linux para toda a nossa equipe, e ele teve dificuldade em cortar o acesso às ferramentas de controle de versão e ao cliente de e-mail Outlook. Ele geralmente nos enviava um código por letras e pedia para preenchê-lo. Eu me lembro que eu mesmo usava o XEmacs naquela época - eh, nos bons velhos tempos.
Avance até o presente. O Unix se tornou uma plataforma muito popular entre os desenvolvedores, especialmente aqueles no Mac, devido ao fato de utilizar o kernel Unix. Além disso, existe algo como Linux no Windows. Nesse sentido, ao contrário de muitos outros, meu retorno às TI não foi repleto de dificuldades. É engraçado que muitos dos meus jovens colegas agora mal gerenciam o Windows e no Linux eles se sentem muito mais confiantes.
Gerenciamento de liberação não é mais uma profissão
Era uma vez, ramificar, mesclar e resolver conflitos era um trabalho péssimo que muitas vezes exigia a intervenção de um especialista em lançamento dedicado. Na época em que o ClearCase reinava no mercado de controle de versão, havia bastante trabalho de fork, merge e release para uma grande equipe - pelo menos em minha experiência na HP em 2002.
A ideia de que um desenvolvedor pode enviar solicitações de mudança por conta própria é, na verdade, muito jovem. Aparentemente, ela teve o início da transição do desenvolvimento para o Linux e uma nova onda de sistemas de controle de versão distribuídos: BitKeeper, Git e assim por diante. Sistemas legados como ClearCase, CVS, SVN ou PerForce não tinham a capacidade de fazer suas próprias alterações para que fossem refletidas em todos os envolvidos no fluxo de trabalho. Ou o proprietário do repositório fez isso, ou a pessoa responsável pelo gerenciamento de liberação, ou cada desenvolvedor organizou tudo por si mesmo. Agora o processo foi bastante simplificado e agora é possível estabelecer um trabalho conjunto em uma equipe sem participantes adicionais.
Onde estão as equipes de controle de qualidade? Teste de unidade e integração contínua
Eu ouvi pela primeira vez sobre teste de unidade e integração contínua com Kent Beck, um dos autores do Manifesto Ágil e criador da metodologia de programação extrema . Vinte anos atrás, suas ideias eram revolucionárias, mas não alcançaram imediatamente o status de um padrão em desenvolvimento que têm agora.
Na minha opinião, é uma pena que não haja mais ênfase na integração contínua em Agile e Scrum. Mas já estou feliz que essa prática tenha se tornado bastante popular hoje. Participei dessa conferência e lembro-me de que Joshua Bloch, autor de Java Collections, subiu ao palco para falar sobre integração contínua e disse: "Obrigado (Agile ou JUnit) por oferecer um charme à integração contínua." E ele estava certo. Antigamente, escrever testes era considerado chato e poucas pessoas o faziam. Portanto, os chefes contrataram pessoas especiais, engenheiros de controle de qualidade, que procuravam erros para os desenvolvedores! Enlouquecer, aquele lafa era ...
Os testes de unidade e a integração contínua quase eliminaram a necessidade dessas pessoas - agora os desenvolvedores são responsáveis por escrever os próprios testes, e a infraestrutura de integração contínua inicia tudo no prazo e relata os erros. Isso torna o software mais confiável e encurta o ciclo de desenvolvimento. Além disso, as inovações ajudaram os desenvolvedores a obter uma visão mais holística das coisas e aprender como escrever código para que possa ser testado facilmente.
Docker: chega de desordem no caminho para a produção
Os contêineres, nomeadamente o Docker, removeram todas as coisas desnecessárias do gerenciamento de pacotes e minimizaram os problemas ambientais que surgem quando o código passa nos testes e entra em produção. Anteriormente, no entanto, você terá que obter um bom engenheiro de DevOps para configurar o ecossistema Docker.
Antigamente, acontecia que o sistema era criado em um ambiente completamente diferente no qual deveria ser implantado (bem, isto é, por exemplo, eles escreveram código no Windows e implantaram no Unix). Isso inevitavelmente causava bugs e acumulava trabalho adicional em cada ciclo de lançamento de teste.
Além disso, no passado, um especialista em lançamento, teste ou DevOps pegava o código de uma tag no controle de origem e decidia o que fazer com a compilação, teste e migração. Normalmente, isso revelaria um monte de caminhos e variáveis embutidos em código, bibliotecas e arquivos ausentes que precisavam ser retrabalhados ou ajustados para funcionar corretamente.
O Docker simplificou o processo e criou condições para integração e implantação contínuas, mais uma vez, colocando as funções relevantes nas mãos dos programadores.
Código aberto: muitas possibilidades
No mundo do software livre, a escolha agora é, francamente, em abundância. Eu estava configurando o Jenkins aqui e queria integrá-lo ao BitBucket. Uma busca por plug-ins para “bitbucket” rendeu mais de quatrocentos resultados, muitos dos quais são de código aberto.
Isso cria dois problemas:
- É mais difícil escolher entre um grande número de opções
- Com tanta abundância, alguns dos instrumentos definitivamente morrerão e seu suporte cessará.
Mas também há vantagens: quase não há necessidade de fazer você mesmo a infraestrutura e as ferramentas básicas - encontre o que você precisa já pronto e use-o. Vinte anos atrás, você tinha que escrever bibliotecas e estruturas de dados para as operações mais comuns, e era até divertido em algum lugar. Hoje, existem tantas bibliotecas e estruturas diferentes para cada linguagem que 99% dos desenvolvedores podem viver sem escrever uma única árvore B, ou tabela de hash, ou mesmo um conector OAuth.
Agile e Scrum dominaram o mundo
Vinte anos atrás, o Agile já estava vivo e bem (o Manifesto Agile foi lançado em 2001), mas sua popularidade começou a crescer mais tarde - inclusive fora da TI, e às vezes de forma distorcida. Ele se tornou um ditado favorito nos círculos executivos: "Os negócios devem permanecer ágeis, caso contrário, não sobreviverão."
Lembro-me dos tempos em que o ciclo de lançamento durava bastante tempo (três meses, e isso está em uma inicialização). Depois de retornar da reunião, na qual analisou as especificações linha por linha, o desenvolvedor poderia sentar-se à mesa e jogar discretamente por várias semanas, sem se preocupar se teria que relatar como as coisas estavam indo. E agora, todos os dias, ralis em pé, sprints a cada duas semanas - você não consegue realmente relaxar!
O Agile também redistribuiu funções administrativas - agora os desenvolvedores se comunicam diretamente com os usuários ou gerentes de produto. Sente-se em silêncio não funcionará mais. Conseqüentemente, a capacidade de se comunicar tornou-se muito mais valiosa do que antes.
Finalmente, o ritmo de desenvolvimento foi acelerado com o Agile. Não se trata nem mesmo de reuniões stand-up e outros empreendimentos Scrum. As próprias ferramentas começaram a economizar tempo: quadros brancos no Jira, solicitações de mudança, ferramentas para desenvolvimento e implantação contínuos - tudo o que permite trabalhar com mais rapidez. Por um lado, isso aumenta as preocupações do dia a dia e, por outro, você sente o retorno pelo fato de lançar os produtos em um curto espaço de tempo e realizar as tarefas de forma abrangente.
Finalmente
Se você também saiu e está pensando em voltar, eu lhe apoio e desejo boa sorte. Pessoalmente, atualizei minhas habilidades com prazer (embora quase tenha morrido no meio do caminho). Os princípios fundamentais da programação permaneceram os mesmos, então acho que vou superar de alguma forma. Mas o kit de ferramentas mudou muito e isso afeta a produtividade.
Você provavelmente captou um tema recorrente no artigo: um desenvolvedor moderno tem uma gama muito mais ampla de tarefas do que há vinte anos. Ele escreve código, faz controle de versão, testa o que escreveu, trabalha com contêineres e assim por diante. Claro, o cérebro às vezes ferve, mas você não precisa mais fazer listas vinculadas.