{"id":26665,"date":"2020-10-30T20:01:59","date_gmt":"2020-10-30T20:01:59","guid":{"rendered":"https:\/\/building.nubank.com\/the-value-of-canonicity\/"},"modified":"2024-03-21T13:08:25","modified_gmt":"2024-03-21T13:08:25","slug":"o-valor-da-canonicidade","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/pt-br\/o-valor-da-canonicidade\/","title":{"rendered":"O valor da canonicidade"},"content":{"rendered":"\n

Quando as pessoas perguntam sobre a pilha de tecnologia do Nubank<\/a>, a resposta \u00e9 bem curta. Usamos as mesmas poucas tecnologias para a maioria dos nossos sistemas de back-end: Clojure<\/a>, para servi\u00e7os de produ\u00e7\u00e3o, Kafka, para comunica\u00e7\u00e3o ass\u00edncrona, Datomic<\/a>, como base de dados para dados de neg\u00f3cios de alto valor, Scala<\/a>, para nosso ambiente anal\u00edtico e Flutter<\/a>, para nosso aplicativo m\u00f3vel.<\/p>\n\n\n\n

Ap\u00f3s sete anos desenvolvendo produtos, agora com mais de 600 engenheiros, algu\u00e9m pode nos perguntar como nos firmamos com essas tecnologias espec\u00edficas. Contudo, a pergunta que queremos responder aqui \u00e9:<\/p>\n\n\n\n

O que acontece quando restringimos a quantidade de ferramentas de uma empresa de engenharia \u201cpara o bem maior\u201d?<\/em><\/p>\n\n\n\n

Mais especificamente, se preferimos ter menos variedade em nossa escolha e nosso uso de tecnologias, favorecendo abordagens can\u00f4nicas, isso resultaria em uma empresa de engenharia mais eficiente?<\/p>\n\n\n\n

O que \u00e9 variedade de tecnologia? \u00c9 t\u00e3o ruim assim?<\/h2>\n\n\n\n

\u201cTer menos variedade\u201d pode ser lido mais precisamente como \u201cevitar variedades n\u00e3o essenciais\u201d. Portanto, queremos incentivar mudan\u00e7as quando uma nova situa\u00e7\u00e3o demanda o uso de tecnologias diferentes, que fornecem um valor melhor para determinada tarefa, ou seja, variedade essencial. Por outro lado, n\u00e3o queremos escolher uma nova tecnologia apenas pelo desejo de usar uma diferente, ou seja, variedade n\u00e3o essencial. Em outras palavras, preferimos ter formas can\u00f4nicas de tratar as coisas.<\/p>\n\n\n\n

Quando o assunto \u00e9 \u201cpoucas tecnologias\u201d, alguns engenheiros poderiam se deparar com algo do tipo: \u201cvoc\u00ea concordaria em continuar usando uma linguagem antiga, como COBOL, pelo resto da sua vida?\u201d H\u00e1 um argumento v\u00e1lido aqui: em v\u00e1rias situa\u00e7\u00f5es, limitar as op\u00e7\u00f5es pode parecer, bom, limitante, principalmente quando os benef\u00edcios s\u00e3o de longo prazo e dilu\u00eddos pela empresa.<\/p>\n\n\n\n

Mas a prefer\u00eancia por menos variedade n\u00e3o \u00e9 o mesmo que evitar a evolu\u00e7\u00e3o ou ignorar alternativas. Isso significa que na troca do \u201cCOBOL pelo resto da sua vida\u201d para \u201ctecnologia nov\u00edssima em folha toda semana\u201d, nossa tend\u00eancia \u00e9 ir para o lado de solucionar problemas consistentemente em toda a empresa (nessa analogia, mais para o lado do COBOL provavelmente).<\/p>\n\n\n\n

\u201cEscolher o lado do COBOL\u201d \u00e9 uma frase curiosa em 2020, mas desvendar o que isso significa na pr\u00e1tica \u00e9 crucial. Queremos usar uma ferramenta excelente para cada trabalho; se o que temos agora atende os requisitos e as alternativas n\u00e3o apresentam um benef\u00edcio claro, preferimos n\u00e3o adicionar novas tecnologias.<\/p>\n\n\n\n

Se a situa\u00e7\u00e3o for diferente, n\u00e3o temos medo de aprimorar nossa caixa de ferramentas e come\u00e7ar a usar uma nova. Por exemplo, quando desenvolvemos a primeira vers\u00e3o dos nossos trabalhos de ETL, decidimos usar Spark com Scala<\/a> em vez de Clojure. Ou quando come\u00e7amos a desenvolver servi\u00e7os envolvendo Aprendizado de M\u00e1quina<\/a>, escolhemos Python, outra vez no lugar de Clojure.<\/p>\n\n\n\n

N\u00f3s as vimos como ferramentas muito melhores para essas situa\u00e7\u00f5es no contexto da \u00e9poca. Foram decis\u00f5es estrat\u00e9gicas e ponderadas. \u00c9 isso o que buscamos cada vez que pensamos em nos desviar no nosso uso de tecnologias.<\/p>\n\n\n\n

Varia\u00e7\u00e3o Interna<\/h2>\n\n\n\n

Outro aspecto relevante \u00e9 que a varia\u00e7\u00e3o n\u00e3o est\u00e1 presente apenas quando escolhemos uma tecnologia nova, por exemplo, uma nova base de dados ou estrutura. Isso tamb\u00e9m se relaciona com o uso das tecnologias que j\u00e1 temos. Ao escolher uma linguagem de programa\u00e7\u00e3o, por exemplo, podemos ver o estilo do c\u00f3digo, caracter\u00edsticas, estruturas e bibliotecas<\/a> como fontes de varia\u00e7\u00e3o. V\u00e1rias delas s\u00e3o t\u00e3o flex\u00edveis que \u00e9 poss\u00edvel fazer com que dois trechos de c\u00f3digos escritos com a mesma tecnologia sejam estranhos um para o outro. A maioria dessas diferen\u00e7as ocorre de forma org\u00e2nica, principalmente com uma quantidade crescente de engenheiros, como \u00e9 natural que as opini\u00f5es sejam diferentes quanto ao uso de uma tecnologia. Por isso, evitar varia\u00e7\u00f5es n\u00e3o essenciais se faz necess\u00e1rio n\u00e3o apenas em um n\u00edvel mais alto (como linguagens de programa\u00e7\u00e3o e base de dados), mas tamb\u00e9m em um n\u00edvel interno (como estilos de c\u00f3digo e caracter\u00edsticas de linguagem) quando nos esfor\u00e7amos para manter a canonicidade no n\u00edvel organizacional.<\/p>\n\n\n\n

Quando avaliamos nosso uso de tecnologias no Nubank, vemos um alto n\u00edvel de consist\u00eancia em como as usamos.<\/h2>\n\n\n\n

Por exemplo, se selecionarmos dois c\u00f3digos-base do Clojure para produ\u00e7\u00e3o aleat\u00f3ria, a estrutura do c\u00f3digo (arquivos e pastas) seria muito semelhante para ambos. Eles usariam as mesmas bibliotecas e estruturas provavelmente. E, por fim, h\u00e1 a pr\u00f3pria linguagem do Clojure. Ele \u00e9 flex\u00edvel, e os programadores podem us\u00e1-lo de diferentes formas (ol\u00e1, macros!), mas tamb\u00e9m \u00e9 simples e incentiva abordagens can\u00f4nicas para problemas comuns. Ao observar esses dois servi\u00e7os aleat\u00f3rios, voc\u00ea provavelmente pensaria que a mesma equipe escreveu os dois c\u00f3digos.<\/p>\n\n\n\n

N\u00e3o \u00e9 f\u00e1cil alcan\u00e7ar ou manter a padroniza\u00e7\u00e3o do uso; \u00e9 preciso ter inten\u00e7\u00e3o, revis\u00e3o de c\u00f3digo difundido, supervis\u00e3o s\u00eanior e automa\u00e7\u00e3o (como modelos para novos servi\u00e7os). Esses s\u00e3o apenas alguns exemplos.<\/em><\/p>\n\n\n\n

Embora toda essa consist\u00eancia e homogeneidade na escolha e uso de tecnologias pare\u00e7a convincente, os verdadeiros benef\u00edcios podem n\u00e3o estar expl\u00edcitos. Por que se importar com isso?<\/p>\n\n\n\n

Mitiga\u00e7\u00e3o de depend\u00eancia<\/h2>\n\n\n\n

O Nubank se divide em grupos de pequenas equipes multifuncionais. Queremos que elas sejam autossuficientes ao desenvolver novas coisas com o m\u00ednimo de depend\u00eancia das outras. Uma equipe deve ser capaz de codificar, testar e implementar algo para a produ\u00e7\u00e3o sem esperar (depender) que outra equipe fa\u00e7a algum trabalho como implementar recursos, executar pipelines, criar novas infraestruturas etc. Conseguimos eliminar v\u00e1rias depend\u00eancias com a automatiza\u00e7\u00e3o incessante, mas com uma quantidade de sistemas em constante crescimento, \u00e9 inevit\u00e1vel que as equipes comecem a se especializar e deter pequenas partes do c\u00f3digo-base. Nesse contexto, em algum momento, os engenheiros enfrentar\u00e3o tarefas que exigem trabalhar fora do dom\u00ednio de suas equipes e c\u00f3digos-base. Uma situa\u00e7\u00e3o t\u00edpica \u00e9 quando um grupo precisa acessar dados em um servi\u00e7o de outra equipe (dados que ainda n\u00e3o tenham sido expostos por uma API pr\u00e9-existente). Um poss\u00edvel resultado seria os engenheiros dependerem, ou seja, aguardarem, que a outra equipe crie um novo ponto final para o acesso aos dados.<\/p>\n\n\n\n

Conseguimos mitigar bastante esse tipo de depend\u00eancia usando um princ\u00edpio<\/a> simples: todos os softwares no Nubank devem estar abertos para colabora\u00e7\u00e3o. Isso significa que todo engenheiro deve ter permiss\u00e3o e ser capaz de propor uma altera\u00e7\u00e3o em qualquer servi\u00e7o. Obviamente, o ideal \u00e9 expor a proposta e combinar os detalhes com os propriet\u00e1rios do servi\u00e7o. As contribui\u00e7\u00f5es ser\u00e3o revisadas, aprovadas e mescladas por eles, que ser\u00e3o respons\u00e1veis por essa opera\u00e7\u00e3o confi\u00e1vel. Na pr\u00e1tica, isso funciona melhor do que esperar que os propriet\u00e1rios mudem suas prioridades para acomodar as demandas de uma equipe separada. Portanto, qualquer engenheiro tem a habilidade de criar o novo ponto final por conta pr\u00f3pria.<\/p>\n\n\n\n

Isso \u00e9 \u00f3timo na teoria, mas ser\u00e1 que \u00e9 f\u00e1cil codificar em um c\u00f3digo-base estranho que voc\u00ea conheceu h\u00e1 cinco minutos? Ele pode estar em uma linguagem de programa\u00e7\u00e3o diferente; uma que voc\u00ea n\u00e3o costuma usar. Ou talvez use uma nova base de dados NoSQL que foi lan\u00e7ada no ano passado, sobre a qual voc\u00ea apenas leu no Hacker News. Ele pode at\u00e9 usar as mesmas tecnologias que voc\u00ea conhece, mas de uma forma totalmente diferente, como um c\u00f3digo com caracter\u00edsticas OO em vez de funcional. Qualquer uma dessas possibilidades pode criar barreiras tecnol\u00f3gicas para a colabora\u00e7\u00e3o.<\/p>\n\n\n\n

Quando isso acontece, ter menos itens em nossa caixa de ferramentas ajuda bastante. No Nubank, h\u00e1 uma chance muito alta de que a sua equipe e uma equipe distinta usem Clojure para servi\u00e7os de back-end. E de ambas usarem Kafka. E de ambas usarem Datomic. E de ambas terem estilos de c\u00f3digos semelhantes.<\/p>\n\n\n\n

Portanto, voc\u00ea pode focar em entender o dom\u00ednio, o problema dos neg\u00f3cios a ser solucionado, o status quo do c\u00f3digo-base e como ele precisa evoluir.<\/em><\/p>\n\n\n\n

Essa facilidade para alterar servi\u00e7os alheios pode causar problemas (geralmente, semelhantes ao c\u00f3digo aberto, quando as contribui\u00e7\u00f5es n\u00e3o est\u00e3o seguindo na dire\u00e7\u00e3o desejada de evolu\u00e7\u00e3o do c\u00f3digo-base), mas a revis\u00e3o do c\u00f3digo e o excesso de comunica\u00e7\u00e3o s\u00e3o prote\u00e7\u00f5es eficientes contra eles. Afinal, n\u00e3o estamos eliminando a depend\u00eancia entre as equipes completamente; estamos apenas otimizando a resolu\u00e7\u00e3o pr\u00e1tica de um potencial bloqueador. Estamos mantendo nossas depend\u00eancias expl\u00edcitas entre os servi\u00e7os, em vez de deix\u00e1-las entre cartas em backlogs diferentes. N\u00f3s alteramos essa depend\u00eancia em busca de processos mais leves: alinhamento e revis\u00e3o de c\u00f3digos.<\/p>\n\n\n\n

No Nubank, essa natureza de c\u00f3digo colaborativa tem sido essencial para que as equipes fiquem em seu fluxo o m\u00e1ximo poss\u00edvel. Isso tamb\u00e9m ajudou a criar uma mentalidade de propriedade de c\u00f3digo em toda a empresa, a qual tem sido f\u00e1cil evoluir com a nossa estrutura organizacional (mitigando ligeiramente a lei de Conway<\/a>). Tudo isso foi poss\u00edvel pelo fato de n\u00e3o termos barreiras tecnol\u00f3gicas entre as equipes.<\/p>\n\n\n\n

Transfer\u00eancias entre as equipes s\u00e3o menos complicadas<\/h2>\n\n\n\n

No megacrescimento que o Nubank vivenciou nos \u00faltimos anos, algo ficou evidente: as prioridades mudam. Uma consequ\u00eancia \u00e9 que n\u00f3s geralmente temos que formar novas equipes ou alterar as atuais, e isso envolve transferir engenheiros.<\/p>\n\n\n\n

Ent\u00e3o, o que acontece quando um engenheiro \u00e9 transferido para outra equipe? Al\u00e9m de se acostumar com novas pessoas e din\u00e2micas, o principal desafio \u00e9 aprender um novo dom\u00ednio t\u00e9cnico e de neg\u00f3cios: O que \u00e9 o produto? Quem \u00e9 o cliente? Quais servi\u00e7os n\u00f3s temos? Quais tecnologias n\u00f3s usamos?<\/p>\n\n\n\n

N\u00e3o podemos afirmar que fomos capazes de tornar essa transi\u00e7\u00e3o irrelevante ou que ela n\u00e3o foi dif\u00edcil. Mas se um engenheiro de um grupo pode ir rapidamente para o servi\u00e7o de outra equipe, entender o c\u00f3digo e propor mudan\u00e7as, isso provavelmente significa que ele pode entender o contexto t\u00e9cnico da nova equipe muito mais r\u00e1pido.<\/p>\n\n\n\n

Embora nosso desejo seja evitar confus\u00f5es ao transferir pessoas entre grupos e contextos com rapidez, ao longo dos anos, os engenheiros foram capazes de se mudar rapidamente, sem muita preocupa\u00e7\u00e3o em aprender novas tecnologias. Eles podem focar em entender o dom\u00ednio de neg\u00f3cios espec\u00edfico da nova equipe, e isso n\u00e3o \u00e9 uma tarefa f\u00e1cil. A facilidade de transferir engenheiros nos d\u00e1 mais flexibilidade para coloc\u00e1-los em prioridades mais altas ou em posi\u00e7\u00f5es melhores para crescerem em suas carreiras, sem perturbar demais a produtividade.<\/p>\n\n\n\n

Melhorias t\u00e9cnicas de alto impacto<\/h2>\n\n\n\n

Em grande escala, tudo d\u00e1 problema em algum momento<\/a>, e queremos consertar cada coisa apenas uma vez, de prefer\u00eancia. No mesmo sentido, at\u00e9 pequenas melhorias na produtividade da engenharia podem ter impactos enormes.<\/p>\n\n\n\n

Suponhamos que voc\u00ea tenha uma empresa com cinco engenheiros; todos usam servi\u00e7os baseados em Java. Se voc\u00ea decide melhorar a vida deles com, digamos, um linter no pipeline de constru\u00e7\u00e3o, pode ter certeza de que melhorou a produtividade de todos os seus engenheiros. Imagine que, al\u00e9m dos cinco engenheiros da primeira equipe, voc\u00ea tenha outra equipe de cinco engenheiros que usa Clojure em vez de Java. Investir tempo para implementar o linter de Java n\u00e3o trar\u00e1 benef\u00edcios para os engenheiros que usam Clojure.<\/p>\n\n\n\n

Toda \u201cdivis\u00e3o virtual\u201d (como linguagem de programa\u00e7\u00e3o, estruturas, base de dados) indica que voc\u00ea est\u00e1 diminuindo o impacto ao melhorar as ferramentas. <\/strong>O uso do que voc\u00ea est\u00e1 alterando limita o raio de impacto da sua melhoria. Se ampliarmos o exemplo anterior para 200 ou 1000 engenheiros, as diferen\u00e7as ficam ainda mais evidentes. Peter Seibel explica<\/a> concisamente:<\/p>\n\n\n\n

\u201cQuando sua organiza\u00e7\u00e3o de engenheiros atinge um certo tamanho, os benef\u00edcios obtidos ap\u00f3s voc\u00ea ter investido em aumentar levemente a produtividade dos engenheiros come\u00e7a a ultrapassar os pequenos ganhos que uma equipe pode ter ao atuar sozinha, de uma forma um pouco diferente.\u201d<\/em><\/p>\n\n\n\n

Quando observamos equipes horizontais (por exemplo, infraestrutura, produtividade de engenharia, seguran\u00e7a), a situa\u00e7\u00e3o fica ainda mais aparente. Toda \u201cdivis\u00e3o virtual\u201d significa que voc\u00ea est\u00e1 colocando mais trabalho nos backlogs deles, pois as melhorias e ajustes para uma tecnologia n\u00e3o passam necessariamente para outra.<\/strong>

Um exemplo real dessa situa\u00e7\u00e3o \u00e9 a seguran\u00e7a de servi\u00e7o. N\u00f3s o implementamos para servi\u00e7os de Clojure, e toda nova melhoria ou ajuste relacionados \u00e0 seguran\u00e7a podem ser facilmente estendidos para todos os nossos servi\u00e7os. Por exemplo, se tiv\u00e9ssemos servi\u00e7os Node.js, primeiro precisar\u00edamos reimplementar toda a l\u00f3gica de seguran\u00e7a nessa nova plataforma; depois, cada vez que quis\u00e9ssemos uma melhoria, a equipe de seguran\u00e7a da informa\u00e7\u00e3o precisaria implementar tanto no c\u00f3digo de Clojure (baseado em JVM) quanto no c\u00f3digo Node.js.<\/p>\n\n\n\n

Outra forma de ver isso \u00e9 pelas bibliotecas em comum. Trechos de c\u00f3digo que costumam ser usados em v\u00e1rios servi\u00e7os s\u00e3o normalmente extra\u00eddos para bibliotecas (ou servi\u00e7os de plataforma, dependendo do caso). Temos bibliotecas padr\u00e3o para comunica\u00e7\u00f5es com Datomic, DynamoDB, para produzir e consumir do Kafka, para fazer solicita\u00e7\u00f5es HTTP para outros servi\u00e7os, processar arquivos posicionais, gerar PDFs e muito mais. Para cada tempo de execu\u00e7\u00e3o diferente para os quais temos suporte oficial, aumentamos o esfor\u00e7o necess\u00e1rio para manter e evoluir os padr\u00f5es comuns.<\/p>\n\n\n\n

Construindo a estrada e saindo dela ao mesmo tempo<\/h2>\n\n\n\n

A normalidade \u00e9 uma estrada pavimentada: \u00c9 confort\u00e1vel para caminhar, mas flores n\u00e3o crescem por l\u00e1<\/em><\/p>\n\n\n\n

Vincent van Gogh<\/em><\/p>\n\n\n\n

Os benef\u00edcios podem ser diretos, mas como e quando devemos nos desviar das abordagens can\u00f4nicas e introduzir varia\u00e7\u00f5es? Nossa escolha de selecionar menos tecnologias e melhor\u00e1-las ativamente \u00e9 como construir uma \u201cestrada pavimentada\u201d<\/a>, o que significa fazer uma viagem tranquila e com o m\u00ednimo de esfor\u00e7o poss\u00edvel enquanto programamos no Nubank, com ferramentas refinadas e eficientes para os trabalhos mais comuns. Mas ter uma boa estrada pavimentada n\u00e3o quer dizer que ficamos nela o tempo todo. Como Van Gogh disse: \u201cA normalidade \u00e9 uma estrada pavimentada: \u00c9 confort\u00e1vel para caminhar, mas flores n\u00e3o crescem por l\u00e1.\u201d

Ent\u00e3o, enquanto nossa estrada principal deve ser o caminho de menor resist\u00eancia, acelerando nosso loop interno para problemas comuns, \u00e0s vezes, precisamos \u201csair da rota\u201d e procurar as flores.<\/strong> Isso deve acontecer quando uma ferramenta que j\u00e1 usamos: (1) n\u00e3o \u00e9 ideal e h\u00e1 op\u00e7\u00f5es melhores; ou (2) \u00e9 in\u00fatil para o trabalho. Por\u00e9m, n\u00e3o basta sair da rota. Se continuarmos abrindo novos caminhos, arriscamos nunca ter tempo, energia e poder para pavimentar nossa estrada principal, deixando-a sempre melhor.<\/p>\n\n\n\n

Continuando com a met\u00e1fora das flores, Peter Seibel abordou o mesmo conceito de forma memor\u00e1vel no t\u00edtulo de seu artigo<\/a> de 2015: \u201cLet a 1,000 flowers bloom. Then rip 999 of them out by the roots\u201d (Deixe 1000 flores florescerem. Depois, arranque 999 delas pelas ra\u00edzes). Isso quer dizer que as equipes devem ser incentivadas a experimentar com ideias de forma aut\u00f4noma, ou seja, flores florescendo longe da estrada pavimentada, sabendo que a maioria n\u00e3o ter\u00e1 \u201csucesso\u201d; elas sabem que ser\u00e3o reprovadas e n\u00e3o ser\u00e3o mantidas ativamente, isto \u00e9, ser\u00e3o arrancadas.  Mas quando obt\u00eam sucesso, investimos nelas e as tornamos parte da nossa estrada pavimentada.<\/p>\n\n\n\n

Nossas tecnologias m\u00f3veis s\u00e3o um bom exemplo disso. No come\u00e7o do Nubank, em 2014, us\u00e1vamos Java (Android) e Objective-C (iOS). Quando surgiram ferramentas melhores, come\u00e7amos a us\u00e1-las e migramos para Kotlin (Android) e Swift (iOS). Em algum momento, nossa equipe de contas banc\u00e1rias experimentou o React Native, uma nova tecnologia multiplataforma na \u00e9poca. Embora a maior parte da funcionalidade do aplicativo relacionada ao cart\u00e3o de cr\u00e9dito tenha permanecido a mesma, as telas de contas banc\u00e1rias estavam todas no React Native.<\/p>\n\n\n\n

A equipe aprendeu muito com isso e, ent\u00e3o, decidiu experimentar o Flutter para ver se este apresentaria uma experi\u00eancia aprimorada para os desenvolvedores e uma melhor solidez na cadeia de ferramentas. Ent\u00e3o, alguns recursos foram codificados no Flutter. Algumas flores floresceram e, devido \u00e0 fragmenta\u00e7\u00e3o insalubre que estava ocorrendo, tivemos que escolher em qual flor investir. Leia mais sobre isso neste artigo<\/a>, mas estragando a surpresa, o Flutter agora \u00e9 a nossa \u201cestrada pavimentada m\u00f3vel\u201d, embora ainda esteja em constru\u00e7\u00e3o.<\/p>\n\n\n\n

O florescimento e o descarte de flores n\u00e3o s\u00e3o necessariamente decis\u00f5es \u00fanicas ou marcos no tempo. Eles costumam ser um processo que ocorre ao longo de meses, ou at\u00e9 anos. Aqui est\u00e3o alguns exemplos do Nubank:<\/p>\n\n\n\n