O bsico (ou nem to bsico assim)

Desenvolver sistemas sobre pessoas.
Eu sei, parece contraditrio, afinal passamos o dia na frente de telas e escrevendo. Mas passamos o dia inteiro nos comunicando com colegas, fornecedores, clientes. Seja em reunies formais, ou nas salas de chat da empresa, pessoas esto sempre envolvidas. Converse com os colegas, troque informaes, d e receba feedback. Trabalhar em TI no sobre falar com mquinas por mais que possa parecer.

Somos pessoas trabalhando com sistemas complexos, atendendo demandas de clientes e do negcio, ento quero abordar alguns conceitos tcnicos que eu julgo bsicos e que ajudam muito no dia a dia dos times. So temas que vejo se repetirem em diversas empresas. Teriam mais temas como agilidade, viso holstica do produto, liderana , que so to importantes quanto esses que resolvi abordar, mas por hora deixo para uma prxima srie de posts.

Escolhas

Como pessoas adoramos fazer escolhas e dar a nossa opinio, quando criamos sistemas no seria diferente. Temos que escolher:

• Linguagem de programao
• Infraestrutura para execuo
• Bibliotecas e frameworks
• Ferramentas para testes, validaes, deploys
• Editores de texto / IDEs

Enquanto alguma dessas escolhas so totalmente pessoais (ou deveriam ser), algumas podem ter impacto nas pessoas que viro a trabalhar no projeto. Um exemplo disso organizar o cdigo em torno da escolha de IDE, e tornar difcil para outras pessoas por exemplo precisar alterar vrios caminhos em Makefiles sem a possibilidade de versionar a alterao para no quebrar os demais.

Pese o impacto que decises pessoais tem sobre o time, ou at sobre o produto. No escolha uma linguagem s porque voc quer aprend-la, pense que outras pessoas tero que dar manuteno ao sistema. Ser que todo mundo vai conhecer a ferramenta que estava em voga em 2015, ela ainda mantida?

O mesmo vale para infraestrutura, selecionar uma stack serverless pode fazer muito sentido para ganharmos velocidade na entrega, mas ser que quando o volume de acessos crescer o custo vai continuar competitivo? Os demais colegas entendem dessa stack? E se o fornecedor descontinuar o sistema onde estamos rodando? Qual o esforo cognitivo no time para manter diversas stacks diferentes de software? J vi times que rodavam coisas em: EC2, AWS Lambda, cluster kubernetes, cluster spark; era um time s, com todas essas infras diferentes. impossvel saber todas as boas prticas, os problemas, as solues de contorno para todas essas diferentes infraestruturas.

O desenvolvimento feito para atingir os objetivos do negcio, no metas pessoais de aprendizado - mas obviamente podemos (e devemos) aprender muito no processo. Pense sempre no seu eu futuro: ser que voc vai ficar feliz em revisitar esse projeto? ser que um colega novo ficar feliz em comear a trabalhar nesse projeto? Lembrando que no meio tempo aprendemos outras coisas, crescemos e amadurecemos. Dos diversos projetos que revisitei ao longo da carreira teria simplificado o cdigo, a infraestrutura e as linguagens usadas para facilitar o modelo mental que preciso ter para dar manuteno.

Cdigo

Um parte importante das tarefas dirias ler e escrever cdigos conforme a senioridade aumenta a quantidade de cdigo diminui, infelizmente. Se passamos tanto tempo lendo e escrevendo cdigos temos que priorizar escrever cdigos que sejam de fcil leitura e compreenso.

Fazer aquela expresso regular gigante em uma linda linha um desafio e tanto, super divertido, mas ser que o seu eu futuro vai ter facilidade de entender o que acontece l? Talvez adicionar dois pargrafos explicando tudo? Ou, para os que usam python, ser que aquela list comprehension com lambdas e trs nveis diferentes de dados valem a pena? Saber escrever cdigo compacto, ou complexo, no te torna um desenvolvedor melhor.

As pessoas tem uma certa capacidade de entender coisas, ideias simples so de fcil entendimento, j ideas complexas e compostas precisam de mais tempo para serem processadas. Em linhas gerais isso o esforo cognitivo necessrios para compreender (e manter) algo no crebro. Quando gastamos muito tempo processando as ideias acabamos no fazendo o que importante para o negcio: gerar valor. Ento, se o esforo cognitivo para entender o cdigo for grande as chances de que algum, ou voc mesmo, adicione um bug so altas. Ou mesmo se no for adicionado um bug, compreender o que o cdigo e suas nuances faz se torna difcil. Tem uma linha de pensamento que fala que escrever cdigos como escrever prosa, isto , precisamos que ele seja legvel, de fcil entendimento por humanos. Os compiladores e otimizadores de cdigo so timos em transformar qualquer cdigo em um binrio executvel, no vivemos mais em 1970 em que escrever cdigo de uma certa maneira era requisito.

Nomear coisas

Nomear coisas (e pessoas e pets) algo extremamente difcil. As possibilidades so enormes, posso usar todos os personagens do meu livro favorito, posso usar o nome dos filmes que amo, os jogadores do meu time do corao, os nomes cientficos das flores que mais gosto. Se voc identificou algum sistema que tenha nomes assim, bom, esses sistemas no dizem nada para ningum, somente para as pessoas que criaram ele originalmente muitas vezes, pessoas que j no trabalham mais na empresa e o nome ficou ainda mais sem sentido.

Os sistemas evoluem, os times mudam, as empresas crescem, adquirem outras empresas, e muitas vezes os sistemas permanencem. Como uma pessoa nova na empresa vai saber que MartyMcFly faz tracing do sistema afinal no filme ele viaja no tempo, nada melhor para um sistema que deixa tu olhar o que aconteceu em algum momento do passado. Ou que o Ego um sistema distribudo de fofoca ok esse talvez mais gente entenda. O ponto no devemos dar nomes que simplesmente achamos legais, ou que so divertidos ou uma piada interna. Nomes precisam fazer sentido, deixar claro o seu propsito, isso facilita entender em que parte da arquitetura o sistema se encontra.

Arquitetura de sistemas so quebra-cabeas (ou Legos) gigantes, dando nomes com significado faciltamos a montagem do quebra-cabea na cabea de cada um.

Fazer o mnimo

O objetivo de todo o desenvolvimento entregar valor para os usurios. Uma arquitetura complexa, cdigo dficil de entender, emaranhado de dependncias podem at entregar valor em um momento inicial. Mas sistemas crescem, usurios tm desejos diferentes, regras mudam, e quando temos algo extremamente complexo adicionar ou trocar as partes se torna um exerccio muito mais complicado. Queremos entregar o mximo de valor sempre, no ficar oscilando entre entregas e dbitos tcnicos (que se no forem pagos se tornam grandes bolas de neve).

Faa o mnimo para atender os requisitos de negcio, sem abrir mo de testes, qualidade e segurana. Testes so o melhor jeito de documentar o sistema, qualquer um consegue ler os testes e entender o comportamento. Com eles voc tambm ganha velocidade para refatorar e no ter medo de quebrar uma parte no correlacionada. Tente simplificar o cdigo e a arquitetura conforme o sistema for crescendo. Quanto mais simples mais fcil manter na cabea um modelo de como funciona todo o sistema.

Segurana deve ser criada desde o primeiro momento. Por exemplo: j comece utilizando HTTPS para todas as chamadas. No coloque senhas e outros dados sensveis no cdigo fonte. Veja segurana como parte de qualidade do software, no espere um incidente para focar em segurana.

Portanto, leve como lema Keep It Simple, mantenha o sistema simples - faa o exerccio de tentar explicar o sistema para uma criana ou para seus avs. Ou, para os fs de arquitetura, adotem Less is more.

Qualidade

Se voc quer ter velocidade de entrega jamais abra a mo de qualidade. Qualidade o que permite os times e a empresa acelerarem. No livro Accelerate h diversos dados e comprovaes das hipteses de que qualidade essencial. Recomendo fortemente a leitura para todos que querem entender as relaes entre cdigo, times e retorno para a empresa.

Quando abrimos mo da qualidade comeamos um ciclo vicioso. Entregamos algo rpido, mas talvez sem testes. Cdigo funciona por um tempo, at que quebra em produo. Como no tnhamos testes, fica dficil encontrar o problema e garantir que no acontea novamente. No meio tempo j estvamos lanando outras features, tambm sem testes e no modo "funciona na minha mquina". Quando tudo isso vai para a produo, ficamos algumas horas fora do ar. O impacto com nossos usurios enorme. Paramos tudos (ie. deixamos de entregar valor) para tentar arrumar o problema. No pagamos o dbito tcnico da falta de testes, fazemos outro paliativo, e a complexidade do software vai crescendo.

Eventualmente chegamos em um momento em que no d mais. Adicionar funcionalidade est levando meses, porque qualquer alterao esbarra em milhares de problemas. Ningum entende como o sistema funciona. Nossa entrega de valor, que era rpida, est pssima; passamos meio ano s pagando dbito tcnico. Quando finalmente voltamos a ter velocidade, o mercado j nos abandonou, e s perdemos dinheiro. Claro, isso o pior cenrio possvel, existem outros menos piores mas que geram muitos problemas nos times. Evite o dbito tcnico priorizando qualidade.

Lembrando que existem diversos tipos de dbito tcnico, nem todos so possveis de identificar de forma simples. Alguns so sutis, ficam escondidos dentro do cdigo com testes funcionais. Mas, na hora de trocar alguma pea da arquitetura, acabamos abrindo a caixa de pandora. Nem todos os dbitos tcnicos so previsveis, alguns simplesmente aparecem nas horas mais inoportunas.

Prioridades

No dia a dia do time sempre temos muitas decises a tomar e devemos pensar como priorizar, tendo em vista que queremos garantir os requisitos do negcio. s vezes os requisitos no so to fceis de saber. Por exemplo: se o sistema atende usurios internos ento dar suporte faz parte do negcio (claro, em alguns lugares teremos um time de suporte, mas mesmo assim vamos ter que ensinar esse time). Manter os usurios satisfeitos e criar uma cultura de colaborao fundamental.

Eu gosto sempre de priorizar dbitos tcnicos toda a vez que encontro um, mesmo que isso no esteja no escopo da sprint. Alguns dbitos tcnicos podem ser enormes e precisam ser negociados com o resto do time. Tente sempre fazer com que o time compre a ideia de eliminar dbitos.

Resolvido os dbitos, o foco o negcio, como eu maximizo o valor entregue. Fazer cinco mil tarefas simultneas no leva a nada, s stress e burnout. E as tarefas (seguindo o pensamento gil) so do time. Divida as tarefas entre todos, aprenda junto ou ensine o que voc j sabe. Se o time tem um backlog para mais de ano, provavelmente no um backlog pois o negcio vai mudar de hoje at l. Aqueles vrios cards parados vo deixar de fazer sentido. Minimize o backlog, mas garanta que o time tenha uma viso a longo prazo (construda junto com os clientes).

Ter um panorama de onde estamos e para onde estamos indo ajuda muito o time para saber o que priorizar. Torna fcil pegar as tarefas de maior valor do backlog e divide a carga de priorizao com todos. O importante todos estarem a par do que se passa no time, e entenderem qual o momento do grupo.

Realimentao

Feche o ciclo de desenvolvimento observando as mtricas do sistema em produo e colhendo feedback dos usurios. O comportamento est como o esperado? As mtricas atendem? O que voc pode aprender sobre o sistema observando ele rodando? O que os usurios esto falando?

O trabalho de desenvolvimento vai alm de s escrever as linhas de cdigo e mandar para produo. Temos que acompanhar os sistemas, entender se temos melhorias tcnicas para fazer. A partir do momento em que o software est em produo precisamos desse acompanhamento. J vi sistemas que no ambiente de testes funcionavam perfeitamente com latncias mnimas, quando foi para produo, e teve um alto volume de acesso, parou de funcionar. Ter mtricas, logging, tracing qui fazer um profiling trar as respostas para os problemas tcnicos encontrados em produo, ou talvez s um caminho para onde devemos explorar.

Livros

Alguns livros que trazem muita informao boa para o dia adia. Sem ordem de preferncia. Sem julgamentos aos autores.

1. Code Complete
2. Clean Code
3. The Pragmatic Programmer
4. Design Patterns
5. Refactoring