O Centro de Treinamento da Fran TT é reconhecido internacionalmente por ter uma estrutura e corpo técnico capaz de atender todos os níveis na prática do Tênis de Mesa, da iniciação ao alto rendimento.
Centro de Treinamento privado com 1500 m², contando com o ginásio, sala de palestra, alojamentos e refeitório.
Dentre tantos atletas formados pela Fran TT, destaca-se o cearense Thiago Monteiro, que trabalhamos desde a base (por volta dos 10 anos) até ele ser encaminhado por nós para morar na Europa (por volta dos 20 anos).
Com toda essa estrutura, conseguimos atender os participantes das nossas Clínicas com 100% de aproveitamento, já que não temos desgastes de deslocamento.

Quando uma abstração está exercendo seu papel, seu código tende a cada vez parecer mais simples. Ao olhar desatento pode parecer até simplista. O problema é que essa simplicidade ao mesmo tempo que aumenta a produtividade, produz ansiedade e afeta quem depende de complexidade para programar.
No post anterior, Abstrações e seu ciclo evolutivo, eu abordei uma ideia que até cheguei a colocar em prática, mas não tive tempo usando-a para tirar conclusões mais elaboradas sobre o que acontece no dia-a-dia. Mas dessa vez eu vou falar sobre algo que tive de lidar em ~2013.
Eu havia trazido o Oragon para dentro do projeto principal que estava construindo e que chamei de iMusica Enterprise. Diferente da proposta do que defendo em Abstrações e seu ciclo evolutivo, nesse projeto eu havia um fork e trouxe para dentro da iMusica. Vale lembrar que o Oragon é meu, naquela época era resultado de mais de 10 criando abstrações e mais abstrações que facilitavam o dia-a-dia. Mas, como aquilo era novo para aquele time, eu resolvi trazer o código como meio de tornar esse mindset de abstrair a complexidade algo cotidiano.
Eu estava inspirado a criar um novo monolito, dessa vez bem modelado e consistente. Um passo prévio para a identificação da delimitação dos contextos, visando mais à frente em alguns anos, quebrar o projeto em coisas menores. Não estava claro se seria microsserviço ou não, mas na prática eu nem entendia o que microsserviço era de fato.
Aliás, em MonolithFirst @ Fowler, artigo comentado de 2016, eu encontro amparo para a minha própria intuição que apontava que não tinha tinha consciência e maturidade para decidir sobre onde quebrar o projeto, por conta de não conhecer o domínio o suficiente para isso. E por isso criar um monolito desenhado para ser quebrado posteriormente.
De qualquer forma o que estava claro era que merecia, futuramente, quebrar o projeto. Mas nem o grafo de dependências estava muito claro para ninguém que estava lá há anos, muito menos para mim com meses.
Precisava de uma nova base de código que fosse modelada “da forma certa”, já que até então o que existia era uma colcha de retalhos em que se buscou fazer da forma que dava, em vez de fazer o que precisava ser feito. Um arroz com feijão bem feito, só!
Eu achava que trazendo o código do Oragon para esse projeto, eu estaria facilitando o dia-a-dia do time, porque na minha cabeça, uma vez que o código estivesse embarcado na mesma solution, magicamente se alguém quisesse entender e estudá-lo, seria prático de ler, prático de debugar, prático de entender o fluxo. Quem não quisesse, ok, você tinha exemplos suficientes de como usar. Então você poderia ser usuário da arquitetura e se quisesse, poderia ser colaborador também! Eu estava completamente equivocado. Lembro de apenas 2 ou 3 pessoas terem algum interesse em como as coisas funcionavam.
Mas uma terceira pessoa queria a todo custo participar daquela complexidade. Queria construir uma nova abstração. Mas o problema era que não havia fundamento algum, exatamente porque não só havia uma abstração para aquela finalidade, como a tal abstração estava com um bom nível de maturidade, resistindo intacta à novas demandas, resistindo aos novos requisitos que chegaram nos meses anteriores.
Outra abstração, madura, pré-existente deveria ser usada ou refatorada para atender á nova demanda/requisito.
Se eu pudesse resumir, a intenção era garantir que cada um soubesse o que precisa ser feito e o que é considerado correto. Se uma abstração que está funcionando precisa ser refatorada, ela será. Não importa se ela é usada em 1 lugar ou em 100. Sem mimimi, sem ressentimento. Vamos alterar coisas que estão funcionando e partes do sistema que já estavam testadas para garantir que a base de código não fosse corrompida com abstrações dúbias, que confundem mais do que resolvem problemas.
Em um projeto em que toda ou pelo menos a maior parte da complexidade arquitetural é delegada à mecanismos e abstrações, o código de negócio parece algo ridiculamente simples e muitas até parece burro. Embora a frase da imagem abaixo se faça presente: