Tenho observado um fenômeno que tem consumido muitas empresas e pessoas, que simplesmente estão parando de dar resultado, e infelizmente isso é só a ponta do iceberg.

“Todas as estradas levam a Roma”, mas nem por isso todos conseguem chegar lá.

A fase acima é uma provocação, pois, quantas vezes deixamos de fazer algo simplesmente porque paramos no meio e mudamos de ideia, e vamos de galho em galho sem chegar no objetivo final.

Um dos fatores chave desse cenário é o excesso de opções, mas também, não podemos negligenciar ego de fazer o perfeito, e isso não se restringe apenas aos indivíduos, isso pode se espalhar pela empresa como ervas daninhas que prejudicam uma plantação.

Na prática, analysis paralysis no seu time é um sintoma de falta de agilidade e propósito, seja porquê seu time compete para estar sempre na hype, ou simplesmente porquê o “como” passa a ser mais importante que o “porquê”.

Nesse exato momento existe alguém fazendo uma solução melhor que a sua, e não há nada a ser feito a respeito, do mesmo modo que estão lançando uma tecnologia melhor do que a que você está usando, enquanto você corre o risco de ficar para trás, ao lançar aquele serviço que planejou no início do quarter…

Bom, a boa notícia é que você não precisa se cobrar para estar na hype o tempo todo, e o negócio não vai entregar menos em termos de produto porquê você usou uma versão menos atualizada daquele framework que você decidiu usar no início do ano.

Porém, existe um lado que é o da empresa e da liderança que precisa aceitar a senoide de ter um software em produção, que você lança, corrige bugs, normaliza, depois lança novas features, e casualmente pode ao longo do tempo até descontinuar o software, seja por ter ficado ultrapassado ou simplesmente não ter mais sentido funcional para o negócio, pois ele mudou ao longo do tempo.

Mas afinal, como é possível vencer a paralisia, visto que ela afeta indivíduos e grupos?

Basta seguir a primeira lei de Newton. Ou seja, a única forma de vencer a paralisia é continuar em movimento, continuar entregando produto em produção.

“Todo corpo continua em seu estado de repouso ou de movimento uniforme em uma linha reta a menos que seja forçado a mudar aquele estado por forças aplicadas sobre ele” Issac Newton.

Outra chave do sucesso é criar uma cultura forte de tecnologia, e fazer com que a linha entre tecnologia e outras áreas fiquem opacas, de modo que os times se preocupem com problemas reais, que em resumo é atender o cliente. Diga-se de passagem, o cliente não quer saber se você está usando Kafka com uma série de regras de mensageria, ou se está em um monólito. O cliente só quer ser atendido com eficiência e eficácia. que em engenharia se traduz em software funcionando, e é basicamente o que o Manifesto ágil já pregava, que é software funcionando mais do que uma documentação abrangente, indivíduos e interações mais que processos e ferramentas.

É preciso de mais profundidade, mais cultura, mais envolvimento e interações do que a maioria dos cursos, certificados, e consultorias em agilidade entregam, e talvez só assim seja possível tornar o processo de inovação mais eficiente e seguro do ponto de vista emocional do time, e que gere um impacto real para o seu cliente.

Referências

• Stop the Analysis Paralysis, Start Massive Momentum:
• RANT: Empreendendo com Software do JEITO ERRADO!
• Uma abordagem financeira para tratar engenharia de software e débito técnico

Há dois anos aproximadamente, lançava-mos nossa primeira versão do nosso motor de busca da Maxmilhas usando gRPC ( ficou curioso, fizemos um relato nesse artigo aqui). Com esse buscador, superamos algumas metas, entre elas não tivemos mais problemas com persistência de dados pois optamos usar o AWS S3 como storage, isso fez que superássemos nossos limites em relação a IOPS e disponibilidade. Entretanto, essa decisão de arquitetura nos deixou em média uns 10% mais caros em relação ao modelo anterior que era uma modelagem orientada a documentos, com o adicional de não termos mais restrições em relação a escrita e leitura.

Antes de prosseguir, acho importante entender o porquê decidimos usar o S3.

Quando entrei na Maxmilhas já estávamos esbarrando nos limites de IOPs de nosso banco Mongo do antigo motor de buscas e estávamos em estudos com outras soluções, mas sempre entrávamos em um impasse, podíamos ter elasticidade mas com um custo pouco maior, ou teríamos que gerenciar esse banco de dados mas lidaríamos com os riscos dessa decisão, que envolvia o famoso teorema de CAP, não apenas na perspectiva de custos. Com isso decidimos usar o S3, pois melhor se encaixava em nosso cenário e me garantia a maior disponibilidade em relação a qualquer outro modelo, mas isso tinha um custo.

Depois da decisão tomada, revisamos ela algumas vezes ao longo desses 2 anos, porém esbarrávamos sempre em Storage ou IOPS. E era algo até então insolúvel. Ao menos era até que começamos a estudar onde e como estávamos gastando com S3. E a partir disso, enxergamos que poderíamos economizar 2/3 do nosso custo apenas mudando a estratégia de persistência da aplicação.

Para efeito comparativo, nosso maior custo em S3, estava em Request Tier 1:

Isso queria dizer que, nosso maior custo não era storage como imaginávamos, ou leitura, e sim o como escrevíamos no S3.

Para entender a precificação do S3, resumidamente o quadrante Tier1, refere-se a escrita, Tier2, refere-se a leitura, DataTransfer-In/Out refere-se a custo de transferência pra internet e o TimedStorage-ByteHrs que refere-se a custo GB armazenado por hora. Para mais detalhes dessa classificação, recomendo explorar a documentação.

E essa informação borbulhou na minha cabeça, pois apenas mudando nosso modelo poderíamos gerar uma economia de 2/3, bastaria reduzir nossa escrita de novos arquivos sem mexer no volume de escrita. Ou seja revisando a modelagem que gerava mais de um arquivo, mudamos a modelagem pra usar um arquivo apenas.

Mas a tese de que era possível foi posta em prova, e não fosse o apoio e confiança do time, certamente não teríamos revisitado ou ao menos testado esse cenário que se confirmou. Hoje podemos dizer que não temos mais limites de IOPS e também em termos de eficiência de custos, estamos melhores que a versão anterior da nossa busca.

Lições aprendida:

• Revise sua arquitetura se algo te incomoda, seja por custo ou por performance;
• Tente entender como é precificado os serviços que você usa, isso pode influenciar em algumas decisões técnicas;
• Não desista, as vezes é preciso bater a cabeça algumas vezes até acertar, faz parte do jogo;

O Débito técnico é um mecanismo de alavancagem de negócio, assim como a alavancagem financeira mediante crédito. Pois em ambos os cenários, essa manobra aumenta o potencial de lucro ou prejuízo mediante crédito, trazendo o resultado no tempo presente com o compromisso de quita-la no futuro.

Pessoas de tecnologia, em especial com foco em arquitetura tem uma aversão natural a decisões deficitárias tecnicamente, pois sabe o custo sob o tempo dessas escolhas.

Essa visão é limitada, pois, o problema não é contrair dividas, e sim a capacidade de paga-las em dia, e mais do que isso, contrair as dividas certas em favor de alavancagem do negócio, ou seja que gerem o maior valor sem comprometer o caixa operacional da empresa, que no caso de software é o tempo e esforço gasto para manter a operação funcionando.
Por outro lado pessoas não técnicas tendem a minimizar a complexidade de algumas decisões e acabam assumindo riscos e pagando uma taxa de juros muito alta por essas decisões.

Vamos pensar em engenharia como um mecanismo de geração de valor onde o seu capital é o tempo/esforço/experiência. Ou seja, você tem um caixa limitado de capacidade para distribuir esse esforço, que na melhor das hipóteses estará gerando mais valor. Portanto se você gasta 75% de sua capacidade produtiva resolvendo problemas de débitos, seu potencial real de gerar valor é de apenas 25%, que na verdade pode ser ainda menor, se considerar o desgaste emocional do time.

O cenário acima é realidade em muitas empresas e times no Brasil e no mundo que em algum momento optaram criar alguns débitos em favor da alavancagem, porém negligenciaram os riscos ou o caixa.

O efeito colateral disso é que a capacidade de pagar esse débito no longo prazo pode se tornar impraticável pois existe uma tendencia a gerar novas dividas para continuar operando, como juros do rotativo do cartão de crédito, e quando se dão conta, já estão super endividados.

Empresas com muito capital, costumam compensar essa ineficiência com uma operação de engenharia cada vez maior, escalando o negócio com pessoas.

Nesse aspecto o advento da transformação digital e a velocidade que ela demanda de gerar novos negócios e oportunidades, causou uma nova crise do software, diferente da vivida na década de 70, mas com muitas semelhanças.

Uma das grandes diferenças é que hoje temos muito mais acesso a informação que há 50 anos, porém temos ciclos de inovação e crises em ciclos mais curtos, bolhas nascendo e estourando em 4 anos, tecnologias e arquiteturas ficando obsoletas em menos de 10 anos, um mundo mais conectado e uma concorrência cada vez maior, além de uma escassez de profissionais, que colabora com o aumento da demanda reprimida.

Talvez o somatório de todos os fatores acima traduzam o momento da engenharia de software hoje, mas não deveríamos esperar uma grande crise para reagirmos, seja como negócio ou como engenharia. Bastaria que tivéssemos uma reeducação de produto e engenharia, algo parecido com uma reeducação financeira.

Mas qual a solução

De forma resumida, com um bom planejamento, estruturando negociando suas dividas, e reorganizando seu caixa.

Devemos projetar software com base no seu e seu ciclo de vida de negócio, nesse caso, se a proposta é um MVP para explorar uma demanda inexplorada, sabe de antemão que não faz sentido construir um software extremamente resiliente e modular. Uma forma de medir isso é negociar o SLA e SLO que tolere mais indisponibilidade, afinal, soluções rápidas, riscos altos, portanto a melhor medida são os indicadores de disponibilidade e de erros que são toleráveis.

Vale lembrar que reduzir o prazo de um projeto necessariamente consiste em reduzir escopo, seja ele funcional ou não, portanto, ao optar pela alavancagem por débito, tenha em mente que a taxa de juros que seus indicadores de disponibilidade gerarão para sua operação diária, sobretudo os não funcionais.

Já do ponto de vista de negócio, contraia dividas sem comprometer todo o caixa, e assuma riscos de disponibilidade aceitáveis que não comprometa muito a experiência do cliente e nem sobrecarregue sua operação e atendimento.

Referências

Engenharia de Confiabilidade do Google (SRE)
https://www.amazon.com.br/Engenharia-Confiabilidade-Google-Administra-Sistemas/dp/8575225170/ref=asc_df_8575225170/?tag=googleshopp00-20&linkCode=df0&hvadid=379787347388&hvpos=&hvnetw=g&hvrand=16517087642200465451&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1001754&hvtargid=pla-809202560056&psc=1

Software Engineering at Google:
https://www.amazon.com.br/Software-Engineering-Google-Titus-Winters/dp/1492082791/ref=asc_df_1492082791/?tag=googleshopp00-20&linkCode=df0&hvadid=379795170134&hvpos=&hvnetw=g&hvrand=9274810583993729118&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1001754&hvtargid=pla-893850003581&psc=1

Lean Software Systems Engineering for Developers
https://www.amazon.com/Lean-Software-Systems-Engineering-Developers/dp/1484269322

Sim é possível, e mais do que isso, funciona, a pedra angular desse relacionamento está diretamente relacionada a cultura do time, e não é tão complicado mudar, desde que todos assumam que são vulneráveis, ou seja, todos sem exceção podem e vão falhar, e essas falhas não podem ter identidade, ou seja, não precisamos perseguir culpados, precisamos perseguir a solução e como não cometer os mesmos erros.

Assim como em postmortem, uma análise de código ou funcionalidade deve ser impessoal, sugiro inclusive não se atentar a quem fez e sim o que foi feito, porquê foi feito e como foi feito. Isso é fundamental para uma cultura saudável de qualidade, seja no code review ou na correção de um bug da feature que foi criada.

Estabeleça acordos!

“Tudo é negociável. Se é ou não uma negociação fácil, é outra coisa.”, Carrie Fisher

Fiz uma lista de acordos e recomendações que vivenciei e que fizeram a diferença aos longos desses anos para estabelecer uma cultura de qualidade. Veja abaixo processos e acordos que podem ajuda-los a construir essa cultura:

Em sequência alguns dos acordos mais importantes que adotamos:

1. Todos passam pelos mesmos crivos de validação e isso é irrevogável;
2. Todo Code review tem que explicar o que, porquê e como;
3. Um Pull Request deve ter apenas uma correção ou melhoria;
4. Não tente avaliar algo que uma máquina avaliaria melhor que você;
5. Faça testes unitários, isso pode ser mais barato do que você imagina;
6. De autoridade e espaço para os QAs.

Todos passam pelos mesmos crivos

Não tão óbvio mas extremamente importante para estabelecer uma cultura de confiança e qualidade em primeiro lugar.

Isso reforça o senso de que todos são donos do projeto, e que todos são guardiões desse código, afinal, nem o mais sênior, arquiteto ou o papa do time tem o direito de violar essa regra.

Essa abordagem em primeira análise evita decisões prematuras ou problemas estruturais nos projetos, digo isso pois a maioria dos problemas que vivenciei se deram justamente por pessoas que se julgavam superiores às outras e entregava o seu sem avaliação do time, e o preço disso a longo prazo é alto d+, além disso, um bom processo de análise de código ou entrega tende a reduzir o esforço de repasse, visto que todos veem e colaboram com a evolução desse projeto, e em último análise isso economiza um tempo valioso na hora de redistribuir os projetos, além de reforçar uma tendência de padronização natural dos códigos e bibliotecas, ou seja, menor tempo também na criação de novos projetos, pois naturalmente o time se preocupa com o reuso do que faz.

Todo Code review tem que explicar o que, porquê e como

Sempre digo que um bom PR deve ser auto explicativo, deve contar uma história com 3 atos, onde descrevo inclusive minhas motivações e pontos relevantes para quem vai analisar. Por aqui adotamos o modelo abaixo.

Esse modelo deve responder 3 coisas:

1. Qual problema estou resolvendo?
2. Por que decidi seguir com o caminho X sendo que o Y também seria possível?
3. O que é importante ressaltar?

Qual problema estou resolvendo?

Descrição do problema que pode ser de negócio, de falta de indicador ou ainda por critérios técnico como performance, falhas etc.

Essa descrição não pode deixar dúvida sobre o que você está resolvendo e mais do que isso, induz naturalmente a ter PRs incrementais, pois fica muito difícil justificar um ajuste muito grande em um único PR.

Por que decidi seguir com o caminho X sendo que o Y também seria possível?

Essa pergunta é muito difícil de ser respondida se quem fez o PR não analisou todas as opções antes de tar uma decisão, ou ainda se a pessoa compreendeu o problema que está resolvendo.

Claro que você não vai discorrer num PR de atualização de versão de segurança de um pacote, mas é importante que se esforce em analisar e por as justificativas da decisão técnica, isso ajuda a avaliar muitos pontos, antes mesmo de revisar o código em si.

O que é importante ressaltar?

Esse trecho deixo para colocar alguma restrição, risco ou ainda urgência desse código, e isso ajuda a negociarmos a entrega.

Afinal o fato de termos regras e guardiões do código, temos que negociar, mas isso de forma democrática e com acordos de próximos passos, caso seja uma violação das regras previamente definidas, como por exemplo cobertura de teste vs pressão do solicitar para entrega, nesse caso não deixamos de entregar, mas damos o risco na mão de quem solicitou, e obviamente se torna um acordo consensual e transparente.

Um pull request deve ter apenas uma única correção ou implementação

Uma regra importante que temos é sobre um PR deve resolver apenas um problema, ainda que pra resolver um problema maior exija um conjunto de mais ajustes e consequentemente mais PRs, e isso é possível releases maiores ou feature branches âncoras.

Esse acordo nos ajudou a fazermos entregas menores e mais fáceis de validar, pois restringimos um PR por problema, reduzindo o acoplamento da solução, e ajudando o time em toda trajetória de uma entrega maior, e isso de modo geral nos ajudou a nos tornarmos mais ágeis, expondo mais o quanto cada um contribuiu numa sprint, coisa que antes disso era muito subjetivo, quando não, impedia a gestão de saber ao certo em que passo esse projeto está, ou o quão complexo esse ajuste foi.

Não tente avaliar algo que uma máquina avaliaria melhor que você

Automatize o que você pode automatizar, isso economiza um tempo considerável, pois nada será tão justo quanto uma análise automatizada, seja para indicar code smells ou cobertura de testes, e hoje existem dezenas de integrações com serviços de análise estática como o code climate ou o Sonar, que já cobrem boa parte desse tipo validação, isso te dá mais tempo e foco na revisão da implementação e na regra em sí.

Faça testes unitários, isso é mais barato que você imagina

Esse é sem dúvida onde você ganha qualidade na implementação e segurança, embora seja também o ponto de maior atrito cultural, pois se o time não está habituado, haverá resistência das mais diversas formas, a primeira é sobre urgência e cobrança, que nem sempre é inegociável, isso ocorre pois o time tende a por empecilhos em algo que vai num primeiro momento aumentar o tempo de análise e desenvolvimento e é natural nesse momento surgirem atritos.

Recomendo fazer muitas rodadas de treinamento, definir um padrão de teste e uma cobertura mínima é um bom ponto de partida, por exemplo, hoje em código legado, exigimos que ao menos a implementação da feature ou bug tenha cenário de teste e cobertura, ainda que originalmente o projeto não tenha teste unitários, e isso reduz problemas de mais inclusive em projetos mais legados, pois naturalmente o código ficará menos acoplado, pois força o desenvolvimento a fugir de armadilhas de classes com muitas responsabilidades, ainda que em um projeto legado. Esse foi um dos segredos que nos fez ter sucesso nas mudanças que adotamos no time.

Há práticas por exemplo de PR onde o avaliador faz um commit de um cenário de teste que quebraria, melhorando a contribuição e colaboração nesse momento. E com o tempo algumas das discussões técnicas começarão com revisão dos cenários mapeados, antes mesmo da implementação, mas isso não é do dia pra noite, mas insista pois do ponto de vista de código, isso gera menor acoplamento, que por sua vez facilita a manutenibilidade do código, outro ponto relevante é que terá menos riscos nas entregas, visto que força a compreensão e revisão dos cenários de negócio, que por sua vez reduz o risco de falhas em produção.

De autoridade e espaço para os QAs

Sobre o papel do QA no time, esse papel é muitas vezes subestimado, e se não tratado com o devido protagonismo e tempo pra fazer as coisas, sempre fará testes manuais.

No nosso time, passamos a ter na sprint projetos de automação correndo em paralelo com as entregas, e aos poucos foi tomando forma até que tivemos uma cobertura funcional que nos fez gastar menos tempo com testes e cenários massivos, além disso hoje podemos nos orgulhar de ter 80% dos bugs descobertos e tratados ainda em homologação. Isso por si só é uma entrega de valor inestimável, em última análise evita um desgaste com nosso cliente final.

Outro ponto relevante é que optamos por testes integrados usando a mesma linguagem que usamos nos projetos no caso JS e TS, então é algo que os devs também fazem code review, e podem contribuir, além de aprenderem com a implementação.

Considerações finais

Implantar uma cultura de qualidade não é fácil, é um processo longo, que vai passar muitas resistências, por vezes do negócio, dos gestores, até mesmo dos devs. Por isso recomendo por mudanças estratégicas e progressivas, igual, a primeira mudança que fizemos foi ter um guia de avaliação de código é um template, depois nos projetos novos passamos a exigir testes unitários mas sem um padrão definido, para que todos pudessem fazer, e depois adotamos um padrão, fizemos treinamentos é mais treinamentos, trocas e pairs a perder de vista até se tornar algo maduro, o mesmo pra automação de testes integrados, onde foi preciso abrir mão de testes manuais em alguns momentos, de ter a automação como projeto, e agora colhemos os frutos disso, e queremos ir além, já vemos algumas oportunidades antes imperceptíveis de melhorias significativas no processo.

Dicas de leitura:

• Engenharia de Confiabilidade do Google — Livro (https://www.amazon.com.br/Engenharia-Confiabilidade-Google-Administra-Sistemas/dp/8575225170/ref=asc_df_8575225170/?tag=googleshopp00-20&linkCode=df0&hvadid=379787347388&hvpos=&hvnetw=g&hvrand=349625280668673966&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1031984&hvtargid=pla-809202560056&psc=1)
• SRE — Página (https://landing.google.com/sre)
• As Leis Fundamentais do Projeto de Software: a Ciência do Desenvolvimento de Software (https://www.amazon.com.br/As-Leis-Fundamentais-Projeto-Software/dp/857522302X)
• Refatoração: Aperfeiçoando o Projeto de Código Existente (https://www.amazon.com.br/Refatora%C3%A7%C3%A3o-Aperfei%C3%A7oando-Projeto-C%C3%B3digo-Existente-ebook/dp/B019IZK89A)
• Microsserviços Prontos Para a Produção: Construindo Sistemas Padronizados em uma Organização de Engenharia de Software (https://www.amazon.com.br/Microsservi%C3%A7os-Prontos-Para-Produ%C3%A7%C3%A3o-Padronizados/dp/8575226215)
• Reinvente Sua empresa — ReWork (https://www.amazon.com.br/Reinvente-empresa-David-Heinemeier-Hansson/dp/8575427636)
• ReWork — Discussão sobre o livro (https://www.grokpodcast.com.br/series/rework/)

Bom, primeiro vamos lembrar que agilidade é a conjunção entre eficiência, eficácia e qualidade. Então sendo assim, ser ágil não é ser rápido, afinal da pra entregar bugs em velocidades recordes, ou ainda entregar rápido e não entregar o que foi pedido, ou não menos importante, entregar o que a área pediu, sem bug, mas devagar.

É importante lembrar que não importa se você segue Kanban, Scrum, XP ou Lean, o que importa no fim é o bom e velho PDCA, e que um indicador de performance sozinho não tem valor algum.

Agora voltando sobre arquitetura de solução/tecnologia ágil:

Existem diversos frameworks de arquitetura, e há um grande esforço de empresas sérias tentando tornar algo que por natureza não é ágil, visto que é a área que tem um dos maiores potenciais de botar tudo a ganhar ou a perder na empresa, apenas com algumas decisões.

Mas fugindo um pouco do By The Book, não pretendo discorrer sobre metodologias, e sim sobre boas práticas, sobre tudo, de como decisões são valiosas nessa posição, e por serem valiosas não devem ser tomadas por critérios exclusivamente técnicos.

Primeiro vamos relembrar do livro Arquitetura Limpa , quando se trata de decisão de arquitetura:

“Resumindo, estabelecer limites nos ajudou a adiar decisões e, em última análise, nos fez economizar uma enorme quantidade de tempo e um monte de dores de cabeça. É isso que uma boa arquitetura deve fazer.” Martin, Robert C.. Arquitetura Limpa (Robert C. Martin).

Para mim é talvez a maior contribuição do Uncle Bob nesse livro sobre arquitetura ágil, quando ele sugere adiar decisões a partir do capitulo 17, onde fala sobre limites. Pois tomar decisões despende muito tempo de análise em geral, além disso, tomar decisões com muitas incertezas é antes de mais nada desperdício de tempo, além de gerar um custo muito alto no futuro, pois depois de tomada, voltar atrás pode até inviabilizar um projeto como um todo.

Digo isso pois vi grandes projetos fracassarem (nem irem pra produção) ou não pararem de pé, exigindo um alto custo de operação (correções e melhorias) justamente por que em algum momento tomaram uma decisão prematura.

E como diz o ditado: Cada decisão, uma renúncia.

Decisões sobre tecnologia, topologia, framework, banco de dados, nível de abstração, regra de negócio, etc., devem ser tomadas com base em dados, se falta dado falta maturidade e se falta maturidade até uma simples modelagem de banco de dados pode ser equivocada como decisão técnica.

Então voltando um pouco sobre arquitetura ágil. Arquitetura ágil é sobre saber quando tomar uma decisão, e sobre como essas decisões são tomadas.

Não adianta montar uma grande estrutura de CQRS, com uma nível alto de sofisticação com Kafka, é uma infra robusta, se estamos nas fase de validação ou reconhecimento do negócio ou conceito.

Quando se toma uma decisão de arquitetura leve em conta 3 grandes princípios orientadores:

• Nível de maturidade do processo de negócio a ser resolvido
• Nível de maturidade técnica da empresa e área
• Custo da solução

Nível de maturidade do processo de negócio a ser resolvido
O primeiro princípio é sobre o quanto você sabe e a área solicitante sabe sobre o negócio ou problema a ser resolvido.

Lembre-se sempre que nesse momento não basta experiência, é preciso ter clara a visão de passado, presente e futuro, pois as vezes o que você sabe sobre, pode não se aplicar nos próximos anos dada uma visão estratégica, ou ainda, pode ser uma experiência de inovação dentro de uma área conhecida, então nem tudo que você sabia, será crucial para esse novo projeto.

Nível de maturidade técnica da empresa e área
O segundo princípio é sobre conhecer sua engenharia, pois não adianta sair do monólito (nada contra e em breve devo escrever um artigo sobre) pro CQRS em uma empresa ou equipe que sempre deram manutenção a um monólito, essa mesma analogia serve para linguagem de programação ou tecnologia .

Pense em estratégias de evolução contínua, um bom exemplo é o trabalho que realizamos no time que trabalho, onde saímos de um monólito para diversos micro serviços que no fim otimizaram processos e reduziram custo, e tudo isso em 4 meses.

mas para isso ser possível levou um ano, onde no monólito quebramos os repositórios de dados, depois entendemos as unidades de negócio e domínio, e por fim comandos e executores, e por último pub/sub. (Quem ficou curioso fiz um relato sobre: https://www.linkedin.com/pulse/porqu%C3%AA-maxmilhas-utiliza-grpc-gustavo-da-silva-rodrigues/)

Nesse período focamos em entregar valor e nos preparar tecnicamente. Eu sabia que essa revolução não se daria do dia pra noite, e que se começasse com uma visão fechada sobre alguns pontos, tomaria decisões equivocadas e nunca chegaríamos lá.

Custo da solução
O último princípio orientador é sobre o custo da solução, e nessa hora, não é só projeção de custo de cloud vs tráfego. É também saber projetar o custo de manutenção dessa solução, seja pelo nível técnico exigido, como também da complexidade, e não menos óbvio o custo de tomar uma decisão ou adiá-la, e esse indicador é possível validando o Rói das entregas anteriores para justificar ou não a evolução dessa solução.

Agora para finalizar vamos refletir um pouco sobre sua visão de entrega ágil!

Você faz pequenas entregas e de forma recorrente?

Conseguir entregar valor de forma recorrente e com melhoria contínua, ou seja de forma faseada, e quando digo faseada não é sobre POC -> parte 1 -> parte 2 -> correção de bugs e produção, pois isso é uma cascata ainda que seja feito em forma de sprint.

Quando digo faseado é sobre PDCA, onde temos ciclos contínuos de entrega de valor, como por exemplo fazer uma experiência de processo de ponta a ponta primeiro, talvez até um monólito se for algo onde o grau de incerteza é muito grande. Depois coletar dados, sejam eles indicadores de receita, sistêmicos ou ainda de satisfação, e aí sim siga para próxima fase, talvez na próxima rodada você opte por um banco de dados X, que seja mais performático e mais barato, ou ainda, pense em quebrar a sua solução em mais uma aplicação especializada em um dos problemas que você resolveu, pois tem requisitos de performance e disponibilidade diferenciados, ou ainda encontre uma necessidade dê assincronismo entre esses sistemas, para reduzir o acoplamento e também o tempo médio de resolução de um dos problemas de negócio. É possível também que o projeto não gere receita, ou não seja exatamente o que pensaram na concepção da ideia inicial.

A principal contribuição que quero deixar é para você refletir se está ou não tomando boas decisões, afinal, como arquiteto sou responsável pelo que decido e também pelo que não decido, bem como sou responsável pelo sucesso ou fracasso da solução, portanto acho importante não apenas desenhar e especificar, mas também acompanhar os indicadores do projeto e também colaborar com o desenvolvimento do time envolvido no projeto, para tomar as decisões em conjunto no momento mais adequado.

Referências

• https://www.amazon.com.br/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
• https://www.devmedia.com.br/como-conciliar-agilidade-e-arquitetura-de-software/33281
• http://www.metodoagil.com/metricas-ageis/#:~:text=M%C3%A9tricas%20%C3%81geis%20existem%20para%20gerar,mesmo%20que%20j%C3%A1%20esteja%20bom.
• https://www.linkedin.com/pulse/porqu%C3%AA-maxmilhas-utiliza-grpc-gustavo-da-silva-rodrigues/

Há aproximadamente 15 anos eu comecei a trabalhar, desses 15 anos, 9 foram especialmente na área de tecnologia. Pude acompanhar de pequenos a grandes projetos sendo orçados, planejados, desenvolvidos, implantados e sustentados, além de ter passado por diversas áreas do desenvolvimento de um produto digital.

Já atuei dês da sua análise inicial de um projeto, fazendo propostas comerciais, acompanhando follow-up, fechando negócios, depois como analista de requisitos, ajudando a traduzir necessidades em especificações, pude nessa época também colaborar no plano de reestruturação de processos da empresa, identificando processos falhos ou criando rotinas estruturadas para melhor entrega de demandas, após esse período, durante um período também atuei diretamente com o processo de atendimento publicitário digital, coletando briefings e pondo no fluxo de desenvolvimento, no entanto, em um dado momento identificamos um sério problema relacionado a processos de qualidade, e assim me tornei analista de testes, estudei fluxos e mais fluxos de teste, linguagens de programação, etc. para melhor desempenhar esse processo, e em um dado momento eu já estava codificando e corrigindo erros simples do projeto, ou ao menos apontando onde tecnicamente deveria ser ajustado, até que um belo dia eu me tornei programador e pude desenvolver projetos, tudo com o amparo da equipe.

Dês de então sigo me desenvolvendo e galgando posições, passando por empresas onde pude aprender de tudo um pouco, dês do que se fazer até o que não se fazer em um projeto, seja tecnicamente ou na forma de gestão. Posso dizer que já fiz muitas coisas, trabalhei em agência, empresa com seu próprio portfólio de produtos digitais, empresas de outras áreas porém com ativos digitais próprios, consultorias e startup.

As lições que aprendi

Acredito que a maior lição que aprendi foi que não existe projeto bem sucedido sem comunicação, acredito que o maior fator de sucesso e insucesso de um projeto está diretamente ligado a comunicação, seja ela interna ou externa, portanto, sempre que você identificar divergências de entendimento, busque sempre ser o embaixador da paz e boa convivência, busque unir essas pessoas e não separa-las ainda mais, para que todos estejam sempre alinhados.

Outra grande lição que aprendi, seja substituível, faça o seu melhor, mas faça de um jeito que todos entendam, ensine e dissemine o que você sabe. Talvez isso vá de encontro com a famosa frase do Bill Gates, mas seja insubstituível enquanto pessoa, nunca enquanto técnica.

“Quer saber como sobrevive? Faça com que precisem de você. Você sobrevive porque os faz precisar do que você tem . E então eles não têm mais para onde ir.” Bill Gates

Seja honesto, talvez o mais básico seja o mais difícil, mas saiba assumir erros, pois é lamentável ver outras pessoas pagando o pato por algo que você fez ou omitiu, seja por insegurança, medo ou rivalidade. Jogue limpo acima de tudo.

Você nunca saberá tudo, e isso é bom. Já tive a experiência de liderança técnica cujo todos faziam code review, a regra era só ter dois aprovadores independente do nível. O mais interessante é que mesmo um Jr pode fazer questionamentos e sugestões pertinentes e mais, ver coisas que um Sr não pensou. Acho que aprendi muito com isso, e acredito que independente de posição, todos sendo uma equipe, todos ganham, basta botar o ego de lado e fazer acontecer.

Não leve pro pessoal, mas sempre saiba que no fim, fazer projeto é sobre pessoas e relações. Sabendo disso, pessoas tem problemas, pessoas tem aspirações e inseguranças e entende-las é uma arte. Eu particularmente tenho duas regras, que são:

Eu sou seu espelho, se você nunca me ofender eu nunca te ofenderei, se você me ajudar eu o ajudarei.

Cada tema seu tom, ou o bom e velho da porta pra fora tá tudo certo, continua a amizade. Digo isso pois aprendi com o tempo que não vale a pena levar pra outras esferas e projetos problemas com uma pessoa em específico, é saber separar as coisas e não levar para o pessoal.

Tudo posso mas nem tudo me convém, e isso é sobre liberdade de expressão, é sobre lidar com opiniões divergentes das suas e respeitar a dos outros, seja ela por uma preferência por tecnologia ou religião.

Seja claro, sempre seja claro, ainda que você seja o chato questionador, pois o entendimento só é atingido após o amadurecimento e perguntas chaves, e quanto mais perguntas você tiver, mais perto de resolver você está.

Não jogue war com outros setores, não é sobre ilhas um projeto, é sobre um projeto, todos tem responsabilidades, todos temos contas pra pagar e problemas, e vejo que em um ambiente produtivo não podemos ter fronteiras, não podemos falar isso não é de minha responsabilidade, quando você é um dos afetados caso não saia como o planejado.

Assuma responsabilidade, assuma riscos. Isso é sobre trazer pra si as coisas, é sobre fazer o que precisa ser feito, não apenas aquilo que você assinou ao entrar na empresa.

Não santifiquem pessoas nem crie heróis, pois todos falham, sem exceção. E saber disso é importante, ainda que você a tenha como referência, saiba que a sua diferença entre ela é que talvez os erros que você comete, são os erros que ela já cometeu, e ela ainda cometerá erros, e é normal, não se frustrem por isso.

Saiba perder uma discussão. Saiba que por mais que você goste de uma coisa, ela pode estar errada ou não se aplicar ao caso posto. Dito isso, no fim é sobre ser humilde e por os projetos a frente do seu ego.

Seja flexível e resiliente. O mundo muda, a tecnologia muda, as pessoas mudam, e você deve aceitar isso de algum modo, pois na lei da sobrevivência só quem se adapta sobrevive, e é normal ter medo de sair da zona de conforto, mas numa guerra sobrevive quem mais se move, movimento é vida, então estude, e não tenha medo de recomeçar, e saiba que conhecimentos anteriores o influenciarão em decisões chaves no futuro com outra tecnologia, quando você tiver maturidade o suficiente em não tratar uma determinada tecnologia como religião.

Tenha um mentor e seja um mentor. Ainda que sua empresa não tenha um processo formalizado, faça esse exercício. Sou muito grato pelas pessoas que me conduziram até aqui, pois sem elas eu não saberia o que sei, sem suas orientações, reviews, sem seus livros que me emprestaram, sem seus desafios. E eu faço o mesmo hoje, pois tudo passa, mas o conhecimento fica.

Escreva artigos, faça ou contribua com projetos open-surce. Se você além de fazer, souber explicar, está a um passo de ser um dev melhor, e mais legal que isso, você está ensinando outras pessoas e aprendendo 2x. Sobre open-surce, talvez não seja fácil contribuir, mas é o lugar que mais você vai aprender na sua vida, pois terá reviewers do mundo todo criticando coisas que você fez, e melhor, colaborando com algo que de fato muda o mundo e a forma que você trabalha, seja traduzindo, documentando, testando, codificando, abrindo issues, ou respndendo-as, faça isso. Outra coisa importante, faça pocs, faça boilerplates, faça libs e projetos abertos, pois você estará ajudando pessoas e buscando fazer o seu melhor, pois sabe que alguém estará vendo, e ter isso é bom, ter um amigo comentando sua pr no projeto ou abrindo issues, por mais que vc sinta vergonha, é assim que se aprende, botando a cara pra bater. Além do plus de ter um portfólio aberto quando for procurar novas oportunidades.

Não seja o Neymar do time. Um time saudável é mais eficiente e produtivo do que um time com um herói, porque no fim o dev mais talentoso, deve ser aquele que decide tocar a bola quando vê alguém bem posicionado, pois mais vale o resultado do que a glória.

Disclaimer

Não sou o exemplo a ser seguido, mas com base no que vivi até agora no mercado de tecnologia, tudo isso que pontuei fizeram a diferença.

Até a próxima!

É importante lembrar que não é recomendável fazer operações desse tipo sem uma interrupção ainda que parcial da aplicação, mas, nem sempre temos uma janela para isso, então temos que por a mão na massa e cruzar os dedos.

Antes de chegar nessa solução, houveram duas tentativas de scripts de banco para resolver tamanho volume de dados, mas em ambas eu cai no problema de memória do banco ou em um script muito complexo que não podia ser paralelizado ou que se tivesse algum deadlock e pra piorar, ele não era capaz de reexecutar automaticamente, então pensei, já que o banco tem limite de alocação de memória para processar cada processo, por que não fazer com que ele trabalhe em um fluxo keep alive com processamento assíncrono, e assim eu fiz

Antes de qualquer mistificação, essa rotina não foi finalizada em 10 min, ou segundos, mas foi muito mais rápida do que qualquer outra tentada por mim e pela equipe (cerca de 3h).

O Problema

Temos 5 tabelas relacionais que possuem registros que se relacionam, e mais, temos alguns parâmetros extras de índices, que nem sempre eram respeitados, tornando a consulta cada vez mais custosa, o que me obrigou a fazer uma correção top down usando a tabela pai para replicar dados para as filhas, e assim corrigir a relação. Então, eu tinha uma tabela com cerca de mais de dois milhões de registros com filhas que chegavam a 20 milhões cada.

A Solução

Sabendo que eu tenho x = 4*(x*2), onde num processo tradicional eu só poderia rodar uma tabela por vez sem estourar a memória do banco ou ter deadLock, o que me levou a uma conta rápida, que era: quantos registros eu consigo fazer por transação e quantas transações eu consigo fazer em paralelo, e isso me levou de volta a um calculo onde seria possível fazer lotes de até 10.000 registros por transação e até 4 transações em simultâneo para tabelas distintas. Mas ainda assim, eu tinha um problema, e se travar?, como eu posso fazer o banco continuar executando de onde parou, então cheguei a conclusão, isso pode ser feito com js via bash e de quebra com um script simplista mas extremamente eficaz.

Requisitos:

1. Preciso saber quantos registros eu quero rodar por transação
2. Quantos dados eu tenho a registrar
3. Quantos registros já foram corrigidos
4. Em caso de falha, preciso retomar a execução do script de onde ele parou
5. cada rotina deve ser isolado por seu próprio domínio

Então, chegamos a esse domain de base:

Então para cada correção eu tenho um mini modulo que resolve uma única rotina, onde eu convencionei seguindo a seguinte estrutura:

app/

— /domain/

— — /database/

— — — /routineDescription.js

— /controllers

— — /DomainControllerScript.js

— config.js

— datasource.js

— index.js

Com essa estrutura eu poderia chama-la por http ou usar um processo de chamada por bash, como optei por bash usando o Commander e então fiz o controller usando o Commander e cada controller tinha seus de comandos ao invés de rotas, e a index eu fazia apenas as chamadas dos módulos e controllers.

Desse modo cada comando era uma espécie de rota, e bastava eu executar cada rota em janelas diferentes acompanhando o trafego do banco.

Nota final

Acredito que independente de ser uma rotina de banco, ou uma rotina de correção de arquivos, ou dados em geral, essa estrutura para bash, com controladores com camadas de domínios pode te ajudar a montar soluções cada vez mais modularizadas. Assim como definir um processo com limites de execução paralelizável.

Nesta série de posts abordarei um velho problema entendimento no comportamento do processamento assíncrono em Javascript, na verdade, esse já é um assunto recorrente no stackoverflow e em comunidades para desenvolvedores novatos (ou não tão novatos assim) que não estão tão familiarizados com Javascrip por conta do sub-entendimento da natureza assíncrona da linguagem, no qual demanda uma forma um pouco diferente de se pensar e construir um sistema.

Para entender o problema, primeiramente devemos entender como o javascript interpreta suas instruções e o que são valores futuros, ou seja, dados que dependem de um processo assíncrono, no qual você não tem controle do tempo de resposta.

Comportamento do Javascript sobre a ordem das coisas

O Javascript, ao contrario do PHP, Ruby, C#, etc. não é preemptivo, traduzindo, ele não espera um determinado processo ou retorno de uma função pra dar continuidade ao bloco, e em termos de performance isso é bom, pois, ele é capaz de continuar a execução de outras tarefas, mesmo que ele não termine de executar uma determinada função anterior, e isso torna o javascript ainda mais atraente, embora traga com sigo uma outra forma de pensar no seu código.

Em PHP se você observar, a execução do trecho acima, o carregamento ocorrerá em ordem, mesmo com a função sleep() que adia o processo do próximo bloco. Esse comportamento vale também pra comunicação com o banco de dados e outras coisas, nas quais não se tem o controle de tempo de resposta. Embora seja um processo que não temos o controle do tempo de resposta, o PHP interpreta como um processo síncrono, ou seja, não precisamos nos preocupar com o que vem depois, pois uma pilha só é executada após a execução do método anterior. Porém esse cenário é um pouco diferente em Javascript, pois exceto que você use alguma estratégia pra lidar com dados assíncronos, seu comportamento não será top down linear quanto aos retornos, com exceção as novas especificações de de Sync mode no Node Js, que gerou uma grande polêmica.

Em javascript pra você ter esse resultado não basta fazer isso:

Porque o javascript não espera a chamada assíncrona pra te dar o retorno de uma função, ou seja, mesmo que você tenha uma ação assíncrona, o sistema tenta interpretar o que ele já tem, em resumo, embora seja uma leitura top down também, ao contrario do PHP e outras linguagens, ele não espera o termino de uma operação pra continuar a outra.

O Problema do setTimeout pra adiar o processamento assíncrono:

Toda vez que você usa um setTimeout para esse tipo de coisa, você está jogando na loteria, pois, está usando uma suposição para adivinhar o tempo que a máquina do seu cliente vai demorar para trazer o resultado da operação ou requisição. Com isso, você não ganha apenas um problema, você leva logo dois problemas para casa, que são os clientes que vão demorar mais do que você tinha previsto, e adiamento da interação ou navegação de um usuário que processou a operação antes da sua estimativa.

“Toda vez que você usa um timeout pra adiar um processo assíncrono, um programador se mata!”

Como computação é uma ciência exata e não esotérica, você deve assumir que não é um adivinho. Deixa as previsões para o João Bidu e comece a usar os recursos da linguagem, diga-se de passagem, ela te proporciona muitas alternativas para lidar com esse tipo de cenário.

Uma luz no fim do túnel

Para lidar com esses problemas, basicamente existem duas saídas, que são trabalhar com eventos ou com callbacks, ambos possuem caraterísticas muito diferentes entre si, mas, ambas resolvem algo em comum que é prover o controle sobre a execução das suas operações assíncronas.
No caso do callback, esse controle se dará pela passagem de funções como parâmetro para controlar a ordem de execução do seu script, já os eventos, funcionam como uma estação de rádio que emite um sinal onde outras funções podem escutar e acompanhar as suas atividades e mudanças de estado. Extrapolando um pouco o conceito, e ainda nessa linha de raciocínio, temos o conceito de observer, que é um pattern, onde temos objetos emissores e observadores de estado, ou seja, um listener, no caso de evento, um listener é um observer por definição, mas, para se trabalhar com observers, você não precisa necessariamente da interface de eventos, assim como você pode utilizar outros conceitos pra lidar com comportamento assíncrono como os paterns Chain of Responsibility para encadeamento de ações ordenadas; O patern pub/sub para lidar com emissores e receptores de ações, onde você quer ter agentes que reagem as mudanças que o emissor emite; os signals pra lidar com comunicação bidirecional entre objetos, onde um emissor é também um receptor e vice versa; E as conhecidas Promises que são objetos com valores conhecidos mas não no momento que são criadas, ou seja, ele representará a promessa. que em algum momento trará uma resposta de sucesso ou falha. Mas calma, irei explicar cada um dos conceitos individualmente acima, suas vantagens e desvantagens, quando e como usar.

No meu próximo post abordarei tudo sobre Callbacks, e depois darei continuidade na explicação dos demais conceitos para que você entenda de uma vez por todas como trabalhar com comportamento assíncrono!

Chain of Responsibility é um patern cuja principal função é evitar a dependência entre um objeto receptor e um objeto solicitante. Consiste em uma série de objetos receptores e solicitantes, onde cada objeto de solicitação possui uma lógica interna que separa quais são tipos de objetos receptores que podem ser manipulados. O restante é passado para o próximo objeto de solicitação da cadeia. Ou seja, assim que instanciado o objeto, os métodos ou conjunto de métodos após sua operação têm como retorno a própria instância this, permitindo assim o encadeamento de métodos de forma sequencial e com baixo acoplamento por permitir que outros objetos da cadeia tenham a oportunidade de tratar uma solicitação.

Show me the code

Resumo

Chain of Responsibility nada mais é do que um método que retorna a própria instancia da classe, ou seja, ele sempre retorna ele mesmo de modo que você possa encadear as chamadas, pois você estará sempre lidando com um objeto “conhecido”.

Mas onde eu vejo isso?

É importante destacar esse patern, pois você o encontrará em diversos locais, inclusive no jQuery e em outra bibliotecas e frameworks, onde existe o conceito de cadeia de ações.

Ex:

$(‘.list’).addClass(‘active’).append(‘<li>test</li>’).show(200).hide(400);

Referências

• http://www.dofactory.com/javascript/chain-of-responsibility-design-pattern
• https://imasters.com.br/artigo/24337/javascript/padrao-de-projeto-de-software-javascript-chain-of-responsibility?trace=1519021197&source=archive
• https://books.google.com.br/books/about/Secrets_of_the_JavaScript_Ninja.html?id=vxbUjwEACAAJ&source=kp_cover&redir_esc=y&hl=pt-BR

Notas finais

Esse é o meu primeiro artigo no medium, pretendo começar uma serie sobre boas praticas e formas de se lidar com problemas de projeto em javascript, sobretudo sobre como lidar com a natureza assíncrona do javascript. Estou retomando meu projeto de compartilhar conhecimento, que comecei a alguns anos no meu blog http://gustavobeavis.github.io/ .