"E aí, quanto tempo leva pra fazer?"

Essa deve ser uma das perguntas que mais ouvi em toda a minha carreira. Começa sempre com uma pessoa interessada em montar um sistema do zero, ou modificar um sistema que já existe (sendo essa última motivação o que fez minha empresa prosperar nos primeiros anos). É engraçado como as pessoas que nos procuram esperam que nós, profissionais de desenvolvimento de software, tenhamos uma resposta na ponta da língua. Que, magicamente, pelo fato de lidarmos com isso todos os dias, fôssemos capazes de antever toda a estrutura de um sistema, a arquitetura, as telas, o banco de dados, a experiência do usuário e a performance, e num cálculo rápido, conseguíssemos viajar no tempo e ver a última linha do sistema sendo escrita, para logo após termos uma publicação de versão, perfeita e imaculada.

Essa pergunta tem uma irmã, que é "quanto custa para fazer?", que é ainda pior por uma série de motivos, mas darei dois de natureza bem prática. O primeiro tem a ver com o compromisso assumido entre o desenvolvedor e seu cliente. Atrasar uma entrega tem um ônus enorme ao desenvolvedor, que pode ver seu cliente simplesmente desistir do projeto e não pagar nada, ou ainda receber seus proventos muito depois do esperado, já que o projeto continuou por muitos dias além do que era previsto. O segundo existe em um mesmo problema da primeira pergunta, que é quando a estimativa está errada - normalmente, abaixo do que seria o tempo total real para o projeto - trazendo ônus para o time inteiro, e algumas vezes para a empresa inteira. O fenômeno é bem conhecido, e tem até um nome: Falácia do planejamento.

O resultado é clichê considerando o Brasil: desenvolvedores trabalhando várias horas a mais depois do horário normal, em finais de semana, feriados, algumas vezes chegando a inacreditáveis 16 horas por dia. Uma estimação errada pode tornar a vida de muitas pessoas bem miserável.

Na Design Líquido, seguimos o modelo de contrato fechado por pouco tempo, abandonando-o rapidamente, e usando ao invés apenas o modelo do taxímetro: o cliente paga pelo caminho que percorremos. Se o caminho não atingiu seu objetivo, a responsabilidade fica com o cliente. Algumas pessoas me perguntam se existem clientes que topam esse tipo de modelo, e a resposta é sim. Eu diria, todos eles.

"Mas como é isso, você entrega um projeto sem terminar e ainda cobra por ele?". Bom, não é tão simples assim. Já tivemos clientes em que o fim nunca chega. Funciona da seguinte forma: o cliente pede um sistema pequeno, com poucos requisitos e telas. Montávamos o sistema e entregávamos conforme combinado. A devolutiva do cliente era algo como "mas agora precisamos disso:", e vinham mais itens que não estavam acordados no início. Em outras palavras, o cliente queria mudar as regras do jogo no meio dele.

Software muda o tempo inteiro. Basta ver o que você tem instalado no seu telefone agora mesmo. Quantas vezes já não aconteceu de você abrir um aplicativo no dia seguinte, e um botão sumir, uma opção de menu aparecer em outro lugar, ou a aparência de uma tela ficar diferente? Com clientes, é a mesma coisa: eles mudam de ideia o tempo todo sobre o Software, mas querem manter o mesmo orçamento. No modelo de contrato fechado, isso é uma armadilha.

Por melhor que seja o desenvolvedor, ou engenheiro, ou arquiteto de software, prover uma estimativa acurada de uma aplicação feita do zero é impossível. As estimativas que vejo dar certo são dadas em cima de soluções que já existem, que o resultado é pegar uma massa comum de software, modificar alguns comportamentos e entregar. Nesse caso específico, o volume de modificações é bem conhecido, então o roteiro delas é executado sem grandes surpresas.

No entanto, boa parte da minha vida profissional foi lidando com clientes que queriam projetos do zero, que eu estimasse início, meio e fim, e o custo. E, para todos eles, minha resposta inicial é pragmática e bastante frustrante: "não tenho previsão".

É claro que eu não posso ficar sem dar previsão de coisa alguma. O que eu faço logo em seguida é dar uma previsão para algo menor e bem tangível. Uma tela, por exemplo. Um campo a mais. Uma validação. Uma mudança de comportamento. Esses são itens fáceis de ver o fim deles, sobretudo se já foram feitos antes em algum momento.

É aí que se baseiam os métodos de estimação mais complexos. Eles mudam completamente a cada 10 anos. Quando eu estava na faculdade, se falava em pontos de função, contagem de linhas, COCOMO e etc. Nunca vi qualquer um deles funcionar na prática. Os melhores líderes de projeto com quem já trabalhei usam alguns métodos de estimação baseados no Scrum e no Kanban, sendo alguns bem pitorescos, como um joguinho de poker com cartas de valores da sequência de Fibonacci, estimação por "tamanho da camiseta", ou mensurações arbitrárias com cálculo de velocidade do time. A maioria deles são irreais, mas funcionam bem como cabides de emprego (especialmente falando de quem gosta demais do Scrum).

Voltando às estimações que vi funcionar, posso definir uma sequência de passos que permite uma estimação até razoável:

1. Estimar cada tarefa do Backlog - a lista de itens pendentes do projeto - entre pequenas, médias, grandes e enormes. Para as enormes, quebrar a atividade em partes menores quando possível;
2. Distribuir as atividades para o time e medir a quantidade de tarefas entregues no período de duas semanas. Alguns líderes de projeto usam valores da sequência de Fibonacci para ter um valor final. Por exemplo, 1 para uma atividade simples, 2 para mediana, 3 para grande e 5 para enorme. Ao final das duas semanas, somam-se os valores das atividades, e o total é chamado de "velocidade do time";
3. Após dois meses, já é sabida a variação da velocidade do time, então, ao alocar atividades para duas semanas, o time sabe o quanto (não) consegue entregar, tendo a lista de atividades um valor total menor ou igual à velocidade média do time.
4. Por exemplo, se meu time teve 4 períodos de 2 semanas entregando 40, 42, 38 e 41 pontos, respectivamente, naturalmente vou adicionar um tanto de atividades para o próximo período cujo total de pontos esteja entre 38 e 42.
5. Por fim, agrupar as atividades por funcionalidade. O resultado é algo muito próximo de uma estimação confiável.

Devem aparecer atividades no período que já vi serem chamadas de Spikes: atividades de descoberta. É quando precisamos mergulhar no desconhecido e descobrir como uma determinada biblioteca ou API funcionam. A descoberta pode levar horas, dias ou até mesmo semanas, dependendo do nível de documentação e suporte a desenvolvedores.

Essas atividades são colocadas numa categoria chamada "Impedimentos", ou seja, uma atividade que bloqueia outras, e são as principais razões pelas quais qualquer estimativa falha. É muito difícil não ter Spikes em um projeto. A estratégia que melhor funciona é investir tempo no Spike o mais cedo possível, com o máximo de prioridade, para então ter o funcionamento daquela biblioteca ou API completamente entendido, e assim ter itens mais previsíveis no Backlog do projeto.

Voltando ao problema com os clientes

A estimativa dentro de um projeto com Scrum ou Kanban funciona, com certas limitações, mas não temos como fazer isso pra um projeto que nem sequer começou. E, de novo, no Brasil temos um problema adicional.

Clientes adoram ter a ideia do preço fechado, e quanto mais barato, melhor. Conversas iniciais comigo normalmente são banhos de água fria. Já aconteceu diversas vezes: um cliente vem com uma ideia e um wireframe - um modelo gráfico, algumas vezes já com as transições de uma tela para outra já funcionando -pronto, e querem ouvir que leva cinco vezes menos tempo para fazer do que estimo, e custa 10 vezes menos pra fazer do que o que estimo. Logo após, eles até acham alguém que faz pelo prazo e custo que eles imaginam ser adequado. O que normalmente acontece é um dos cenários abaixo:

• O projeto é implementado em alguma linguagem simples e aprender e barata em hospedagem, como PHP ou JavaScript. A parte gráfica inteira é implementada, já que existe um wireframe correspondente, mas o sistema não tem sequer metade das funcionalidades imaginadas. O sistema não escala, sofre com desempenho e não ganha tração, além de ter problemas triviais de segurança, como vulnerabilidades CSRF e XSS. O cliente desiste completamente do projeto;
• O projeto é implementado em duas camadas, sendo uma camada gráfica usando um framework JavaScript, podendo ser transpilado usando Node.js ou não, e uma API RESTful, sendo essa numa linguagem e frameworks apropriados para ganho em escala. Os conceitos iniciais são implementados corretamente em ambas as camadas, mas o cliente começa a pressionar o desenvolvedor para entregar num determinado prazo. Várias boas práticas são abandonadas, a finalização acaba com várias gambiarras e o projeto funciona pela metade. Insatisfeito, o cliente pede todos os fontes de volta e procura empresas como a minha para finalizar, desta vez disposto a bancar um orçamento maior. Com alguma configuração e uma hospedagem correta, o sistema até escala, mas o novo fornecedor de Software gasta um bom tempo corrigindo as gambiarras. Uma boa parte dos clientes não entende que o orçamento é gasto justamente para reescrever partes que não funcionam direito. Uma das estratégias que usamos é trazer novas funcionalidades, usando um tempo delas para corrigir o que não está bom e implementar alguma coisa que o cliente perceba valor. Uma boa parte desses clientes continua conosco, e outra parte decide ou abandonar o projeto, ou seguir com outro fornecedor mais barato, e o problema continua até que o cliente deixe o projeto do jeito que está, ou o abandone;
• O projeto é implementado por aquele que chamo de desenvolvedor-herói: um desenvolvedor que faz da sua missão de vida o projeto, gastando dias e noites nele até o projeto sair, não importando o custo pessoal que isso implica. Aos trancos e barrancos, o projeto sai, finaliza, até funciona em produção, mas depende 100% do desenvolvedor-herói. Em raríssimos casos o projeto continua só com ele. Em alguns casos, o cliente nos procura e pede para que ajudemos no projeto e a lidar com o desenvolvedor-herói, que nos vê como invasores e usurpadores. A relação é complicada e normalmente não amigável. Duas coisas podem acontecer: ficamos um tempo no projeto e finalizamos, corrigindo os maiores problemas que o desenvolvedor-herói não consegue resolver sozinho, ou o desenvolvedor-herói é dispensado e o projeto fica conosco.

Um caso mais raro de cliente, mas que muito interessa para este que vos escreve, é o cliente que vem com um sistema péssimo e pede para reimplementá-lo em uma tecnologia mais moderna. Passado o orçamento e o prazo, o cliente simplesmente aprova tudo. Havendo atrasos, comunicamos o quanto antes, explicando as dificuldades e o que precisa ser feito. Entregamos o projeto, o cliente pede mais coisas, e assim continuamos. Estes são os atuais (e melhores) clientes da Design Líquido.

No entanto, clientes assim são bem difíceis de achar. A maioria dos potenciais clientes são esses que querem sistemas baratíssimos e impossíveis de serem implementados num determinado prazo. Numa conversa com uma colega, cheguei a este dilema que dá título a este texto. Como posso reter um cliente que quer pagar pouco e criar um sistema num prazo quase impossível de ser feito?

Inicialmente, pensei no seguinte:

1. Ter uma fundação comum a todos os projetos. Isso eu comecei em 2018 e finalizei este ano, depois de abandonar a Stack da Microsoft. Hoje a Design Líquido tem uma nova Stack, mais adequada aos tempos atuais, e compreende APIs RESTful, sistemas Web PWA e aplicativos nativos para celular;
2. Investir em mão de obra júnior. Isso eu comecei em 2021, com um programa de aprendizes. O que faço é selecionar alguns talentos e os subsidio para que estudem focados, sem colocar na frente outros problemas, como não ter um emprego e ter contas a pagar. Em resumo, ajudo a evitar o Scarcity Mindset. Os melhores aprendizes são convidados para projetos na Design Líquido;
3. Foco em automatização. Isso também comecei em 2018, escolhendo uma estrutura de nuvem que nos ajude de verdade, e não que crie problemas (especialmente no meu cartão de crédito). Teoricamente falando, hoje estamos prontos para receber qualquer cliente com qualquer sistema já existente, por mais problemático que seja. Em padrões de projeto, fazemos intenso uso da técnica de Scaffolding quando possível;
4. Vitrine própria de produtos. Isso partiu de um dilema antigo meu. Por uma década escrevi o sistema dos outros, mas nunca escrevi os meus. Isso começou a mudar no final de 2020, quando comecei a investir em projetos internos. Isso atrai novos clientes por ter casos de sucesso de fácil demonstração. Evita também o problema de ter um projeto abandonado por um cliente, o que diminui a vitrine.

Isso não resolve todos os problemas, mas resolve alguns. Os problemas que ainda não resolvi:

1. Mudar o discurso. Pragmatismo me faz perder muitos clientes. Quando falo da realidade do custo e dos prazos, potenciais clientes agradecem o tempo, vão ao mercado, acham alguém mais barato, que começa o sistema não entrega e o sistema naufraga. Todos perdem. No entanto, isso é um meio de negócio pra um tipo de empresa que chamo de Agência Digital: são especializados em entregar um site ou sistema visualmente atrativo, com baixo custo de desenvolvimento e baixa qualidade sistêmica. Os projetos são curtos e baratos, e normalmente eles dispõem de um pipeline interno, que começa no comercial, passa para a equipe de Design, depois para o desenvolvimento e finalmente a entrega. Não tem problema o sistema não funcionar bem, porque a missão está cumprida. Essas agências normalmente absorvem clientes em volume e o tempo dispensado a cada cliente é bem curto;
2. Voltar a desenvolver sistemas pequenos. São as origens da Design Líquido, os sistemas anões. Para isso, o que preciso fazer é montar uma esteira de processos melhor do que a das Agências Digitais;
3. Como prospectar clientes. Por muito tempo, a Design Líquido trabalhou com indicações, ou alcance orgânico de redes sociais. Numa eventual expansão, não está claro para nós quais clientes queremos prospectar, mas é algo que precisa ser definido.

Voltando ao Dilema da Estimativa

Mas, então, como resolver o Dilema da Estimativa, finalmente?

Não quero ter que mentir para clientes, que o projeto deles pode ser feito num tempo curtíssimo e num preço pequeno. Invariavelmente vou perder oportunidades. Quando projetos começam assim, já são fracassos automáticos.

Basicamente são duas estratégias:

• Continuar com o taxímetro: funciona bem para nós, e os clientes que aceitam o modelo se habituam bem a ele;
• Simplificar a entrega, melhorar os processos internos e reter o cliente: esta é a estratégia que estou trabalhando. Trazer as receitas de sucesso de outros projetos, descomplicar a arquitetura e ter uma equipe pronta para esses projetos pequenos, de prazo curto e custo baixo. É um desafio enorme, que deve ser alvo de futuros textos.

Eu não tenho uma certeza de que isso irá funcionar, mas é um bom começo. Futuramente voltarei a este assunto.

Há 4 anos atrás comecei, por iniciativa de um cliente meu, a disciplina de programação Coding Craft. Chamo de disciplina de programação porque não envolve apenas cursos direcionados a uma tecnologia ou outra, mas também insights sobre postura, consistência e até alguma promoção pessoal. As pessoas que me procuravam (e ainda me procuram) o fazem por causa da massiva quantidade de respostas que escrevi no Stack Overflow em Português, ofício este que abandonei em 2017. Conforme a tecnologia ASP.NET MVC vai deixando de ser usada, tenho um número cada vez menor de alunos. Não é algo que me incomoda. Acho até natural.

Os cursos cumprem na prática aquilo que coloquei na teoria: módulos com densidade elevada fazem os alunos se obrigarem a melhorar, estudar por si próprios, se dedicar a chegar ao final de uma implementação, e o mais importante, entregar algo. Curiosamente, isso não é algo que se mantém. Os alunos preferem estudar um tempo e depois seguem fazendo outra coisa. Nada mais natural. Flexibilidade de estudo implica também em fazer os alunos pararem de estudar no meio do caminho conforme suas habilidades já satisfazem bem o ritmo de trabalho corrente. Fico bem feliz se uma ou duas aulas já são suficientes pra isso.

No entanto, não acho que uma ou duas aulas, de um módulo de 11 aulas, estão preparando os alunos para se tornarem desenvolvedores de alto perfil - objetivo final dessa disciplina profissional. É por isso que não chamo o Coding Craft de um conjunto de cursos, e sim de uma disciplina. É algo que se matura com o tempo e não é apenas relacionada com o conhecimento corrente, mas também com a capacidade de entender uma futura perspectiva tecnológica e se adaptar a ela. Em suma, de produzir muito mais do que a média de um time de desenvolvimento, com poucos recursos e muitas dificuldades, principalmente.

Primeiro Formato: Turmas de 5 Alunos

Historicamente, houveram duas turmas de cinco alunos da disciplina Coding Craft. Apenas a primeira turma foi com os cinco alunos até o final. A segunda turma teve duas pessoas puxadas que assistiram à primeira aula e nunca mais voltaram para as demais.

Nesse formato, eu dava duas aulas de 90 minutos, com uma pausa de 15 minutos entre elas. A maior parte dos alunos, especialmente da primeira turma, sabia que o curso tinha uma densidade bem alta, então foi uma turma com uma boa produtividade. Já na segunda turma não houveram alunos que entregaram qualquer um dos 11 exercícios do primeiro módulo, o que me motivou a extiguir o formato de aulas com cinco alunos e partir para as aulas individuais.

Mesmo a turma mais empenhada tinha muitos contratempos para manter os cinco alunos comparecendo a seis sábados consecutivos, por três horas. Nunca vi como melhor alternativa fazer um módulo por semana, já que o curso teria 11 semanas de duração, e provavelmente ainda menos comprometimento que o primeiro formato de seis semanas. Os melhores alunos tinham várias dificuldades de entregar os exercícios a tempo das próximas aulas. Para completar o problema, montar turmas era bastante difícil. Como eu não queria investir em publicidade - contando apenas com o interesse espontâneo e a visibilidade no Stack Overflow -, nem gastar muita energia divulgando os cursos, acabei privilegiando as aulas individuais, o que me aproximou mais do formato que eu queria fazer idealmente (tutor-pupilo).

Segundo Formato: Tutor-Pupilo

No final de 2016, comecei a ter os primeiros alunos em aulas individuais. Os módulos foram mantidos, o livro do primeiro módulo foi revisado - inclusive gramaticalmente - e agora os alunos tinham o tempo que precisassem para fazer os exercícios e entregar. Achei que era o suficiente para ter mais alunos prosperando.

De fato, tive mais formandos pelo método Tutor-Pupilo. A retenção de conteúdo e a evolução de cada aluno é fantástica. Apenas um aluno completou pelo menos um módulo pelo método de turmas, contra três alunos pelo método Tutor-Pupilo. Fiquei contente com isso? Não muito.

Até a data desse texto, contabilizei 32 alunos, entre alunos que compraram um módulo inteiro e que compraram aulas avulsas, e isso sem contar alunos de empresas que me contrataram para dar aulas. Dos 32, são 4 formados em pelo menos um módulo, 5 são alunos de aulas avulsas (portanto, não graduam) e 23 ainda em meio a seus cursos ou desistentes. É 12,5% de taxa de sucesso, considerando que nenhum dos 5 alunos de aulas avulsas entregou todos os exercícios correspondentes às aulas (a grande maioria entregou um ou dois apenas).

Entre as estatísticas que compilei, alguns dados interessantes:

• A média de aulas feitas por alunos que compraram um módulo com 11 aulas é 3;
• O período médio entre uma aula e outra, ou seja, contamos aí a resolução do exercício, é por volta de 3 a 4 semanas. Depois da terceira aula do módulo 1 do curso de ASP.NET MVC (em que eu falo de Modularização), esse tempo sobe para períodos em vários meses ou até mesmo anos, e aqui falo da grande maioria;
• O aluno que mais comprou aulas jamais entregou um exercício sequer (foram 21 aulas avulsas);
• Entre 25 de junho de 2016 até hoje, dei mais de 170 aulas, entre aulas para times de empresas, grupos de alunos ou aulas individuais.

Em contato com alunos, formados ou desistentes, curiosamente, todos eles tiveram uma promoção salarial, ou de posição, e um deles até virou professor. Os que terminaram o curso foram os que conseguiram os melhores resultados. Mesmo os que não terminaram conseguiram resultados bem impressionantes.

Me faço, portanto, alguns questionamentos. Ainda vale a pena manter o formato de 11 capítulos por módulo? Antigamente, minha visão era de melhorar a qualidade dos programadores não apenas na questão técnica, mas também na disciplina, na capacidade de fazer muito trabalhando pouco. Será que é isso que meus alunos queriam? Ou será que eles preferem fazer aulas que apenas resolvam problemas mais pontuais?

Seja qual for a resposta para os meus questionamentos, novamente eu preciso repensar a base da disciplina profissional e seus objetivos.

Quem eu quero ajudar agora?

Eu queria muito continuar ajudando programadores brasileiros. Antigamente eu fazia isso respondendo no Stack Overflow. 2000 respostas depois, resolvi ficar só no curso porque as pessoas que vão ao Stack Overflow, principalmente quem lida com a Stack da Microsoft, já vêm com um viés muito errado. É triste de dizer isso, mas são como os partisans do Java nos anos 2000: gostam de trabalhar mais para entregar muito menos. Em vários casos fui bem sucedido em tornar programadores promissores em grandes talentos, mas com toda a mudança tecnológica em direção ao .NET Core (que, por sinal, ainda não decolou como esperado na data da publicação desse texto) e o interesse maior por cursos que mandem um diploma por correio pro aluno colocar na parede - independente do que foi aprendido - sinto que não devo mais gastar energia com os cursos atuais. Eles ficarão disponíveis pra quem ainda quiser fazê-los, mas não devo escrever mais material novo.

Em 21 anos de carreira, entre o hobbyista e o profissional, passei por praticamente todas as áreas do ciclo de desenvolvimento de software. Vi quatro gerações de paradigmas de software e seu respectivo apogeu e queda, para algumas delas, hoje já de pijama. Onde estou, fui encarregado de escrever uma dúzia de cursos, para trazer uma empresa encalhada na era do Oracle EBS para o atual modelo em Cloud distribuído em containers, Front-end, Back-end e muitos microserviços. Seja qual for o tipo de aluno que eu vá ter, uma coisa é certa sobre todos eles:

Quase nenhum deles quer aprender para construir algo grandioso. Quase todos eles querem aprender pra ter um aumento de salário no futuro próximo.

Sinceramente, não quero mudar essa dinâmica. Paixão por arquitetura de software é para uns poucos loucos. O que quero fazer é impactar positivamente muitas vidas. Assim, começo a formular a terceira fase da disciplina Coding Craft. Ela será focada em fazer pessoas conseguirem aumentar seus salários muito rapidamente, mas por razões de excelência técnica.

Voltando à pergunta do título, quem eu mais tive satisfação de ensinar foi quem saiu de uma vida muito humilde para um ambiente fértil e próspero. É elas que eu quero alcançar, mas elas jamais farão um curso que custa quase um salário mínimo brasileiro. O que preciso fazer, então, é oferecer uma forma que essas pessoas possam estudar sozinhas e que eu possa avaliá-las de uma forma mais automatizada. Passada essa fase, posso tutorar aqueles que eu vejo que não desistirão. O filtro ficaria no autômato.

Coding Craft terá cursos de graça. Basta ler os materiais e fazer os exercícios

Para não ser injusto com quem já pagou por cursos, o formato gratuito não terá .NET.

Os novos cursos serão nas tecnologias que estou mais envolvido agora, e que podem variar no futuro. São elas:

• Python 3;
• Kotlin;
• Vue.js.

O site será reformulado para não ser apenas um blog, mas uma plataforma inteira. Os alunos farão suas entregas por um mecanismo automatizado, que executará testes e verificará as soluções. Ainda estou pensando como farei para evitar que alunos copiem os fontes uns dos outros e submetam na plataforma sem qualquer esforço.

Os melhores alunos serão convidados por mim para projetos freelance. O escore na plataforma será fundamental.

Com isso, quero poder saber de muitas histórias, de pessoas que saíram do zero e construíram carreiras inacreditáveis, e poder contá-las aqui. Nada é mais satisfatório que isso.

Logo virei com mais detalhes.

Pedro foi um dos alunos que me procurou pelas várias respostas que escrevi no Stack Overflow em Português. Um dos alunos que não começou a carreira profissional como programador, Pedro se destacou pela solidez nas entregas dos exercícios, bem como mantendo um ritmo constante de aulas e entregas.

Como sempre digo, parte fundamental de se tornar um bom profissional é justamente tendo uma boa disciplina. Minha ajuda nesse assunto foi pequena: apenas complementei o conhecimento que o Pedro já tinha. O restante da bagagem para alçar voos mais altos já estava quase completa.

Pedro começou sua carreira como analista de suporte e infraestrutura, estudando programação por conta. Sua formação não é a de um programador: é formado em Redes de Computadores. No entanto, a experiência profissional começou três anos antes. De grão em grão, foi acumulando conhecimentos novos e as oportunidades foram aparecendo, até que uma oportunidade, em 2012, não apenas juntou um ganho maior como também a chance de mudar da área de suporte e infraestrutura para desenvolvimento, em definitivo. Atualmente, possui um nível de código que nada deixa a desejar para muitos programadores auto-denominados seniores com quem já trabalhei.

O Pedro cursou a Linha Plena do Módulo 1 do Coding Craft em ASP.NET MVC, em meados de Agosto de 2017, resolvendo todos os exercícios no tempo esperado do curso, o que é bastante raro entre meus alunos. No meio disso tudo, não parou: mudou de cidade (de Brasília para Campinas), trocou de emprego e praticamente se tornou líder de time logo após. Em nossa última conversa, tive a excelente notícia de que finalmente comprou sua casa própria.

Que muitas conquistas como essas venham num futuro próximo!

É do seu domínio:

• ASP.NET MVC;
• Entity Framework;
• Dapper;
• Redis;
• Scaffolding e MvcScaffolding;
• Web API 2.2;
• ASP.NET Identity;
• NuGet (montagem e manutenção de servidor);
• i18n (por Resource e pelo pacote i18n);
• Ajax, JavaScript, jQuery;

Outros conhecimentos que julgo importante mencionar:

• C# em cima de .NET 4.6.1;
• Escopo assíncrono, transações, manipulação de enumerações, montagem otimizada de predicados;
• Razor;
• Bootstrap 3;
• Templates T4;
• Versionamento de documentos em sistema próprio;
• Serializações em XML, JSON, binário;
• Streaming.

Contatos

• LinkedIn
• GitHub (veja os exercícios aqui)

Escrevo este texto completando sete meses morando em outro país. A ideia da mudança foi, em boa parte, pro desejo de novos desafios profissionais. O que eu esperava era um nível técnico maior e equipes de programadores mais conscientes. Mais uma vez, a expectativa se mostra uma grande vilã.

Não preciso repetir a frase título. Posso falar de talento. O talento, sim, é um ente raro. É a expressão mais excelente possível da capacidade técnica, mas ineficaz sem a sabedoria. Não basta apenas ter uma capacidade técnica altíssima: é preciso também aplicar essa capacidade técnica da forma mais eficaz. Ou, melhor dizendo, da forma que o time melhor absorva e que traga um padrão superior de produtividade. A prova maior disso são as mentes incríveis que conheci durante a vida - boa parte, aliás, com uma capacidade muito superior à minha - e que não souberam aproveitar as oportunidades quando elas apareceram. São férteis como óasis, mas desperdícios monumentais. Não que eu seja um exemplo crasso de excelência. Sou mais teimoso que competente mesmo, e me sinto uma fraude com relativa frequência.

Aproveitando a analogia, o restante do mundo profissional, em todo e qualquer lugar do mundo, é isso. Árido. Sem lampejos de criatividade em quantidade satisfatória. Infecundo. É vislumbrar o deserto em sua mais perfeita desolação. Montanha após montanha, vale após vale, o cenário é insosso, pobre, infernal. Um areial. Apenas o vento dá algum sinal de animação, sempre da mesma forma. O marasmo é justificado pelo pragmatismo: aquele que se contenta sempre terá sua chance de sobrevivência garantida, ainda que constrita a uma rotina fastidiosa, repetitiva, repleta de defeitos obsoletos. Mas está tudo bem.

Eu sei que não é justo forçar as pessoas a terem talento. Nem tem como, mas existe a possibilidade de uma postura mais aberta a novidades, a autocríticas, a desafios, uma visão mais criteriosa sobre o que pode ser melhorado, e não aceitar que tudo da forma como está é o ponto final da excelência. Quase sempre dá pra melhorar, e nunca é exatamente muito difícil ou impossível.

Um parêntese: tudo é ridiculamente fácil na sua vida e na minha - e se você falar que sua vida é difícil, você é apenas desonesto ou ignorante (peço desculpas). Você não precisa levantar pela manhã se preocupando se vai conseguir comer, dormir, não ser devorado(a) por predadores ou morto(a) por tribos selvagens, se vai ter um furúnculo que vai infeccionar e te matar por sepse. Você tem muito mais do que imagina, tanto que tem tempo para ler esse texto sem que ele prejudique sua sobrevivência, seja comida, remédios, um teto, um banheiro, um chuveiro, roupas, eletrônicos, e assim por diante. Eu conheço gente que até hoje não tem banheiro com água encanada e esgoto em casa, e que não reclama da vida tanto como muitos que muito têm. Aqui já cheguei até a repreender alguns americanos que vieram com esse papo de que o mundo vai de mal a pior, e sempre piorando cada vez mais.

E é por isso mesmo que, tendo uma vida mais fácil que muita gente que viveu antes que você (incluo aqui seus pais, avós e parentes distantes), e que pode se esforçar sempre um pouquinho mais, e fazer tudo um pouquinho melhor a cada dia. Ainda que você seja uma pessoa que pegue no pesado todos os dias, trabalhe até a exaustão e tenha pouco tempo e dinheiro para mudar algo substancialmente, há uma pletora de exemplos de gente que saiu do nada e hoje tem muito, em condições até piores que as suas. Esses caras são exemplos de pessoas brilhantes, perseverantes, exemplares e sensacionais, e devo dizer, não exatamente talentosas, mas com competências e capacidades valiosas, capazes de fazê-las sobressair quando o talento não é suficiente. São óasis no meio de desertos, igual o da foto título que escolhi, o Rio Orange, na África do Sul. Repare que o que temos predominante na paisagem é o deserto, enquanto que, margeando o rio, temos círculos férteis de fazendas de vinhos, frutas, verduras, legumes. Há vida e cores ao redor do potencial criativo, da inovação, das boas ideias, da força de trabalho efetiva e inteligente, assim como há vida e cores ao redor do rio. Pessoas férteis atraem pessoas, sejam também férteis ou não.

Não há mundo profissional que seja chato e repetitivo se o profissionalismo impera. O que existe são empresas amadoras, funcionários amadores, fornecedores amadores. Mediocridade, incompetência e falta de visão de gestão. A responsabilidade pelas origens desses problemas é, fundamentalmente, do gestor, mas cada célula da organização tem sua parcela na conta, e quando essa conta é alta demais, a bancarrota sempre vem. A punição para o amadorismo normalmente é a falência ou a demissão.

No próximo texto, falarei de alguns exemplos clássicos de posturas amadoras dentro de empresas de TI, bem como algumas pequenas atitudes que podem ajudar o profissional a evitar situações desagradáveis, esquistas e prejudiciais à sua carreira.

Este texto é continuação natural deste outro texto. Depois de alguns meses realizando entrevistas de emprego com pessoas espalhadas pelo mundo, consegui definir um bom processo de testes para medir o conhecimentos dos seus candidatos.

Bons métodos começam com as perguntas certas. A seguir proporei três.

O que queremos medir ao escolher um candidato?

Essa eu diria que é a pergunta mais importante. Também acho importante dizer ao candidato como a dinâmica com ele funciona, qual o objetivo dela, o que se quer medir. Acho muito bom que o candidato entenda a intenção da empresa, o que deixa as coisas muito mais transparentes. Transparência é a primeira grande virtude de uma empresa, porque mantém todos no maior nível de honestidade possível.

Então, o que eu meço num candidato? Basicamente:

• Sua capacidade de resolver um problema dentro da linguagem e frameworks escolhidos. Testar genericamente "capacidade de resolver problemas" é idiota e desrespeitoso com o candidato, que não vem para a entrevista preparado para isso. Se a ideia é testar o candidato em pseudocódigo, use um problema relacionado com o dia a dia do trabalho ou algo que possa ser resolvido pela maioria dos programadores em uma hora. Lógica de xadrez ou qualquer outro jogo de tabuleiro não é algo que se resolva em uma hora, pelo menos não pela média dos programadores que conheço;
• Sua capacidade de se adaptar a uma situação em que ele não conhece muito bem, como usar uma nova biblioteca, por exemplo. De novo, dentro da linguagem e frameworks escolhidos;
• Sua postura profissional ao comunicar um problema que encontrou ou uma solução que pretende aplicar para resolver, ou ainda como se comporta ao pedir ajuda. Não há qualquer problema em não conhecer como uma coisa funciona ou não saber um conceito. A grande questão é medir como é o retorno do candidato quando ele passa a conhecer o conceito. Capacidade de assimilação é um ótimo critério a ser medido;
• Ritmo (ou rapidez), estilo de código, qualidade (aqui entra eficiência, se o código é pequeno e legível, e eficácia, ou seja, se o código resolve tudo o que foi pedido) e comportamental.

A seguir, coloco 4 propostas que só examinadores otários pedem em entrevistas. Se você já entrevistou alguém usando qualquer uma delas, melhore, ou se aposente. É um grande favor que faz ao mundo:

• Algoritmos de ordenação, ou problemas acadêmicos em geral. Há quilos de algoritmos de ordenação na Internet, refinados até o último caracter de código. Se você está com saudade da faculdade, por favor, volte para ela. Você usa menos de 40% do que aprendeu na faculdade no seu dia-a-dia;
• Quiz. De novo, a Internet é o melhor lugar para perguntas e respostas como essas. Se o candidato sabe o que é uma coleção imutável, uma classe abstrata ou a definição canônica de polimorfismo, isso não faz ele o candidato mais indicado para a posição: apenas que ele é capaz de memorizar muitos conceitos do Google. Aplicá-los é outra coisa. A única ressalva que faço aqui é se a pergunta é relativa a alguma coisa do dia-a-dia. Vinculado a isso, é razoável e justo pedir um exemplo em código;
• Um problema de quatro horas para resolver em uma. Na boa, se você faz isso, você é um babaca. Irremediavelmente. Pior ainda é se você espera que "o candidato de fato não consiga terminar", porque tem aquela esperança de achar um grande talento numa massa de candidatos. Você é apenas sádico e imbecil. Pessoas em ambiente profissional não esperam trabalhar com metas impossíveis. Ou se você é do tipo que defende metas impossíveis, a barraca de coco verde na praia te espera;
• Um problema que você não sabe resolver. Antes de mais nada, teste a si mesmo contra o problema. Meça quanto tempo você demora. Seja honesto e use condições que você quer aplicar ao candidato, depois use mais tempo e melhore a solução. Não há qualquer problema se o candidato for melhor que você. Isso, a meu ver, é um bom sinal.

Como queremos medir e por que escolhemos os métodos que escolhemos?

Sou naturalmente contra resolver no papel ou no quadro branco. O candidato não tem a chance de testar o código. Há uma boa chance de, a rigor, o código não funcionar porque alguma coisinha mínima faltou, como um fechamento de chaves ou colchetes ou um ponto-e-vírgula. Conferência de símbolos é trabalho para uma IDE, não para o candidato.

Assim sendo, a forma mais justa e razoável de aplicar o teste é usando um Fiddle. Ao final deste texto, colocarei os que julgo melhores para isso. Um Fiddle é uma ferramenta online que é composta por um editor de texto e um compilador/interpretador em tempo real. Ou seja, o candidato escreve o código, o testa e a evolução da sua solução pode ser acompanhada ao vivo. Seus recursos são limitados, ou seja, qualquer ajuda por uma IDE não existe. A única coisa que não é possível é depurar o código. Ainda.

Se a avaliação envolve produzir uma solução com a ajuda de uma IDE, uma solução com controle remoto pode ser uma ótima alternativa, se o candidato não está presencialmente. Neste caso, recomendo as seguintes ferramentas:

• TightVNC;
• TeamViewer.

"Porque eu gosto" ou "porque acho melhor" não é resposta para sua escolha de método de avaliação. Você não tem que colocar suas preferências pessoais acima do interesse da empresa, mesmo que você seja o dono dela. Se essa é sua melhor resposta, por favor, amadureça. O candidato não iria gostar nem um pouco que a avaliação é baseada num achismo seu.

Respostas boas para esta segunda pergunta são "porque fazemos uso frequente de determinadas estruturas", ou ainda "porque nossos futuros projetos serão usados com isso". Encontrando métodos de avaliação que respondam bem a uma dessas duas perguntas, você estará num ótimo caminho.

Qual a visão que queremos que o candidato tenha da empresa?

Possivelmente quase ninguém pensa nesta pergunta quando elabora uma avaliação, mas ela é importantíssima. Eu muito provavelmente indicaria amigos e colegas meus para empresas que possuem um bom método de avaliação. Jamais indicaria amigos e colegas meus para empresas com avaliações idiotas e absurdas.

Ainda que o candidato não passe, ele potencialmente pode colocar em contato com a empresa pessoas que sejam mais aptas para a vaga do que ele. Já aconteceu na empresa que fundei e em mais algumas empresas que conheci com um processo seletivo bacana.

Proposta Coding Craft

Se você gostaria de estabelecer um processo seletivo intrigante, divertido e altamente rico em informações, a Disciplina Coding Craft tem um produto para isso. Mais do que ninguém, queremos que sua empresa seja capaz de escolher o melhor candidato para suas equipes. Sobretudo, que o candidato se sinta avaliado e goste do processo. Sendo assim, dará seu melhor do início ao fim.

Treinamos e capacitamos sua equipe para a elaboração dos mecanismos de entrevistas mais apropriados para o que se deseja de um profissional. Este serviço de consultoria tem um preço fixo e é feita em três etapas: instrução, implementação e teste de dinâmica. Pode envolver até três profissionais da sua empresa.

Investimento: R$600. Há um pequeno livro que acompanha a consultoria, no qual explico o processo mais a fundo.

Interessou? Se manifeste por mensagem aqui, me procure no Twitter, no Facebook ou LinkedIn.

Fiddles Recomendados

• C#: DotNetFiddle;
• JavaScript: JSFiddle;
• Java: Repl.it;
• Python: Repl.it, tendo versão para o Python 2;
• Ruby: Repl.it;
• SQL: SQLFiddle;
• PHP: Repl.it.

Renan foi um dos primeiros alunos individuais do Coding Craft e meu primeiro grande exemplo de curva de aprendizado como Linha Júnior.

Quando entramos em contato pela primeira vez, não trabalhava exatamente numa empresa de software, mas para um instituto em Alta Floresta - MT, em que basicamente o encarregava de tudo relacionado a informática, desde o suporte até desenvolver novas coisas. Recentemente, fiquei sabendo que, durante o curso, o Renan pôde trocar de emprego para alguma coisa mais relacionada com desenvolvimento.

No Coding Craft, fez a linha júnior do módulo 1, além de algumas aulas de reforço em pontos específicos do C#. Em oito meses de progressão, montou 15 sistemas diferentes, além de outros que não eram relacionados com o curso, mas que puderam receber coisas do curso. É do seu domínio:

• ASP.NET MVC;
• Entity Framework;
• Dapper;
• Redis;
• Scaffolding e MvcScaffolding;
• Web API 2.2;
• ASP.NET Identity;
• NuGet (montagem e manuteção de servidor);
• i18n (por Resource e pelo pacote i18n);
• Ajax, JavaScript, jQuery, FullCalendar;

Outros conhecimentos que julgo importante mencionar:

• C# em cima de .NET 4.5.2 e 4.6.1;
• Escopo assíncrono, transações, manipulação de enumerações, montagem otimizada de predicados;
• Razor;
• Bootstrap 3;
• Templates T4;
• Migração do ASP.NET MVC4 para o ASP.NET MVC5.

Renan também possui um perfil ativo no Stack Overflow em Português com perguntas merecedoras de atenção.

Contatos

• LinkedIn;
• GitHub (veja todos os 15 sistemas aqui).

After some weeks trying to update and test this package, I got a weekend to modify and test the MvcScaffolding version for Visual Studio 2017. The packages are available in NuGet and can be installed using the following command:

PM> Install-Package MvcScaffolding.VS2017

Issues? Feel free to reach the repository.

Depois de algumas semanas tentando atualizar e testar este pacote, finalmente consegui um final de semana para modificar e testar o MvcScaffolding para uma versão no Visual Studio 2017. Os pacotes estão disponíveis no NuGet e podem ser instalados usando o seguinte comando:

PM> Install-Package MvcScaffolding.VS2017

Problemas? Abra uma issue no repositório do GitHub (em inglês, claro).

Eu gosto de SQL. Sempre gostei. Acho que sempre vou gostar.

Tive o primeiro contato com a linguagem em 2002. O banco de dados era o MySQL. Eu era estagiário de uma minúscula empresa mais ou menos perto de casa e não tinha salário. Passava o dia inteiro lá mexendo no computador, estudando coisas que eu gostava, montando pequenos sistemas e websites, e de vez em quando fazendo alguma coisa que eles precisavam. O dono da empresa era amigo da minha mãe e não exatamente havia uma função ou um projeto para mim. Havia trabalho, eu fazia. Caso contrário, podia usar o tempo da forma como melhor me convinha. Era um favor que ele fazia me deixando lá em contato com tecnologia. Para mim, estava ótimo.

A coisa que eu achava mais legal no SQL era a proximidade dele com o inglês. Era como conversar com o computador com um pouquinho de matemática. As instruções eram claras e divertidas, e era agradável criar, editar e excluir registros, ainda que como experimentos. Lembro de ter tido tardes muito proveitosas praticando interações com o banco de dados.

14 anos depois, venho a este artigo com a mesma impressão positiva sobre SQL, mas não dentro de sistemas compilados. Fora deles. É até um pouco melancólico defender isso, mas preciso ser razoável.

SQL dentro de um sistema compilado causa mais problemas do que benefícios, essencialmente quando é um sistema não trivial, ou seja, que não é formado em grande parte por CRUDs. Quanto mais complexa a regra de negócios envolvendo SQL, mais incontrolável o sistema se torma. Mas, por que passei a defender isso?

Hoje, quase todas as linguagens compiladas possuem uma implementação de um mapeador objeto-relacional. Há muita gente que é contra, alegando que mapeadores objeto-relacionais são lentos, causam problemas de performance, são limitados em operações, e assim por diante. Isso é verdade para alguns casos, não mais para a grande maioria. No nível em que as ferramentas estão, a perda de performance pode ser considerada desprezível para uma maioria de casos, merecendo otimização pontos em que os frameworks ainda não são capazes de resolver.

Ainda, modificação de sistemas compilados demoram mais em quase tudo. No teste local, no teste unitário, no teste de integração (até porque essas três etapas exigem a compilação antes) e a própria compilação não verifica SQL. Ela supõe que está tudo certo, que nós, programadores, fizemos nossa parte e produzimos o melhor SQL possível. É um otimismo que tem um preço caro lá na frente.

Em resumo, o ganho de produtividade evitando o uso de strings SQL dentro da aplicação é melhor do que a perseguição de desempenho a todo custo, simplesmente descartando o ORM. Outros problemas de desempenho podem ser atacados em compensação.

Posso ilustrar isso numa experiência recente. Meu segundo cliente nos Estados Unidos foi um grande grupo empresarial, com escritórios em três cidades diferentes. O sistema era um serviço REST cheio de ferramentas bacanas e modernas, alguns processos ricos em detalhes, e que tinha três etapas de testes. Um dos testes levava 70 minutos para iniciar. A outra coisa é que um desses testes tinha que ser repetido em dois ambientes, resultando, portanto, em quatro testes diferentes. A melhor parte era fazer merge dos meus colegas e descobrir que um código deles provocou uma falha na minha última etapa de testes. Em média, eu levava 4 dias para terminar uma história de complexidade média, contra 3 horas em sistemas sem teste algum, na minha plataforma de maior domínio, o ASP.NET MVC, com Entity Framework, um ORM em que não há escrita de SQL, onde erros de SQL praticamente inexistem.

A melhor parte: os testes nesse sistema (bom dizer, em Java) não contemplavam tudo. Alguns erros eram descobertos apenas em tempo de execução. Adivinhe de onde eles vinham?

O sistema usava pesadamente sentenças SQL bastante complexas, que eram segmentadas em blocos monolíticos. Como as sentenças eram reusadas por todo o sistema, qualquer erro fazia uma boa parte do sistema parar de funcionar.

A tendência não é algo exclusivo de uma linguagem ou de um framework. Há um padrão que pode ser notado em várias frentes. Citarei algumas.

.NET

Este é bastante óbvio, e começarei pelo clássico. Começou no LINQ to SQL, que depois deu origem ao LINQ to Entities e, finalmente, Entity Framework. Por padrão, as sentenças são escritas ou como LINQ, que é parecido com o SQL, mas que está dentro das linguagens que compilam em .NET, ou como métodos de extensão. Portanto, há toda uma conferência do compilador para que o SQL gerado pelo código seja válido.

Há também o NHibernate, o famigerado framework portado do Java, mais limitado que o Entity Framework e quase morto na data desse texto, mas que cumpriu bem sua função ainda quando era novidade, de transformar métodos do .NET em sentenças SQL. Pularei a parte de HQL porque ela é um desserviço duplo: uma sintaxe própria que nem SQL é.

Não falarei de PetaPoco, Massive e Dapper aqui porque eles usam pedaços de strings para gerar SQL, então não entram no conceito que quero explorar nessa minha tese, que é a do ganho de produtividade com ORMs agnósticos. Aqui estou analisando apenas frameworks que geram 100% do SQL a partir de estruturas que o compilador pode conferir.

Java

Obviamente eu vou falar do Hibernate, mas só de uma parte do Hibernate que não recebeu a devida atenção: o Entity Manager. Acredito que foi aqui que nasceu alguma ideia para a Microsoft fazer o Entity Framework alguns anos depois.

Este era, pra mim, o componente de framework que finalmente poderia tirar o Java da miséria criativa em que se encontra há tantos anos, assim como fez o Spring IoC no seu devido tempo. Ao invés de propor uma sintaxe sucinta, agradável e fluente, a equipe do Hibernate foi no sentido contrário: fez duas formas de interface, sendo uma idêntica ao SQL (o famigerado HQL) e outra usando critérios, objetos especiais que o Java interpreta e constrói sentenças SQL. Ainda que sejam objetos Java, são pura verborragia. É inacreditável como, ao finalmente acertarem a mão em alguma coisa, escolhem o pior caminho para implementar.

Felizmente sou um otimista, e carrego comigo a convicção de que tudo no mundo melhora, ainda que seja Java, e nesse sentido não errei. Os seguintes frameworks merecem total atenção:

• JOOQ;
• JINQ;
• jaque;
• JaQu;
• linq4j;
• Quaere;
• QueryDSL;
• OrmLite.

Poucos deles ainda têm suporte a migrações incrementais, e o horror a folhas de estilo e sites responsivos para escrever documentações continua, além da onipresente preguiça de desenvolver os exemplos, mas me mantenho otimista.

C++

O C++ jamais irá me decepcionar. Foi minha primeira linguagem OO e ela me inspira um passado em que eu era empolgadíssimo com programação. É sempre um prazer colocar a mão em sistema C++, ainda que os empregos estejam meio raros.

C++ possui hoje os seguintes ORMs:

• ODB;
• Hiberlite;
• Bun;
• LiteSQL.

Concluindo

Não falei de linguagens interpretadas porque a curva de produtividade delas é alta o suficiente para que o uso de SQL puro ou ORM não seja um problema como é nas linguagens compiladas.

Considero que o exposto aqui deva ser seriamente levado em consideração por arquitetos e gestores de times grandes (ou seja, mais do que 8 pessoas). Supondo 10 pessoas, 2 erros de SQL para cada e 30 minutos entre arrumar o código, compilar, testar, enviar para o serviço de integração e aguardar o deploy - sendo MUITO otimista, claro - são 10 homens/hora jogados fora por dia. Coloque isso na sua planilha mensal de custos e vamos ver se não vale mesmo a pena sair do SQL tradicional para algo que seu compilador possa detectar.

Antes de mais nada, é importante dizer que este não é um fenômeno novo. Tenho observado isso desde 2011, e o comportamento é basicamente o mesmo em qualquer parte do mundo. Duas histórias são importantes para começar.

A primeira é de 2012. Eu era Analista de Sistemas Sênior em... Java. Para quem me conhece, sabe que não entro em oportunidades assim porque gosto, mas porque preciso. Na época, meu conhecimento chamou a atenção de um amigo que me colocou em contato com um editor de uma revista que escreve sobre programação Java. Confesso que não fiquei animado com o convite, mas estava disposto a escrever um artigo sobre alguma coisa da linguagem para ter alguma visibilidade. O assunto era livre, desde que sobre qualquer coisa que estivesse no mundo Java. Resolvi falar sobre as linguagens que funcionam em cima da JVM, como Scala, Clojure e Groovy. Gosto de todas elas. Também estabeleci um panorama histórico entre o surgimento das linguagens e a evolução do Java, explicando que a linguagem não tinha o poder de expressão a ponto de viabilizar o surgimento de novas linguagens. Tentei ao máximo não ser enviezado em minha opinião, citando várias fontes da internet, como sempre faço em quaisquer um dos meus textos. Afinal, essa opinião não é só minha.

O editor leu o texto e me respondeu que "eu estava sendo muito pessimista em relação ao Java", que todos os pontos de falha que apontei eram "facilmente corrigidos por uso dos frameworks tal e tal", e que "seria bom eu retirar esses pontos do texto, visto que uma revista que fala de Java não deve criticar o Java".

Por que não deve? Java está acima de qualquer crítica?

Eu respondi que não iria retirar coisa alguma do texto, que ele deveria ser publicado assim, se ele quisesse publicar. Ele disse, no melhor que sua educação permitiu, que aguardaria meus ajustes. O texto nunca foi publicado, obviamente.

"Mas você não pegou pesado demais?", não. Uma coisa é criticar por criticar. A outra coisa é desenvolver uma argumentação baseada em boas fontes e analisar em cima de critérios técnicos, que foi o que fiz na época.

A situação ocorreu idêntica novamente, após uma entrevista com um cliente alguns dias atrás. Minha opinião adquiriu mais propriedade após esses 5 anos, e o que acho inacreditável é que... as coisas continuam iguais! O mesmo estilinho de entrevista, os mesmos frameworks, as mesmas práticas ruins, tudo.

Não houve qualquer grande inovação em Java. Nem um framework, nem uma metodologia, nem um paradigma novo. O que teve foi copiado de outras linguagens e frameworks. Voltar ao mercado Java em 2016 foi exatamente igual à minha última tentativa, em 2013, para nova saída em 2014. O que se mudou é que a comunidade deixou de lado as Web Applications para se dedicar à escrita de microserviços REST, o que, convenhamos, não demanda grandes saltos tecnológicos, e aplicações mais sofisticadas para Android (televisão, tablets, carros, celulares, gadgets para casa), que usam Java mas não são parte do Java. As tecnologias já existem há muito tempo: apenas passaram a ser mais usada agora, seja qualquer uma das aplicações que mereçam discussão.

Os defensores do Java normalmente me mandam links como este para justificar que Java vai firme e forte, o que não é exatamente verdade. A metodolodia dessa relação, por exemplo, é o número de hits sobre um tutorial que uma determinada linguagem tem. Ora, considerando que para escrever em Java eu normalmente preciso pesquisar mais, este número não impressiona, exceto pelo fato de que Python é o segundo lugar com um crescimento impressionante. É a maior comunidade? Sim. Tem aplicações para tudo? Sim, exceto compilar código embarcado. É aberto, open source? Mais ou menos.

É aqui que o problema começa.

O maior deles está aqui. A Google teve um gesto corajoso, reescrevendo várias coisas capengas do Java para viabilizar o Android e, em retribuição, recebe esse repolhudo processo pedindo em troca US$9 bi, em valores atualizados até então. Se eu estivesse na Google, certamente me sentiria desanimado com isso. A última decisão favorece a Google, mas a Oracle prometeu apelar.

O panorama que se desenha é desastroso. Esgotada de ideias, nada indica que a Oracle desenvolverá algo novo pelos próximos anos, e pior: ainda que a Google tenha feito a opção de troca pela OpenJDK, a Oracle quer reivindicar também o controle sobre a implementação livre. Isso apenas acelera uma já iniciada corrida de programadores para outras linguagens (como este artigo que mede a popularidade de linguagens pelo número de desafios completados por programadores). Python é a linguagem dominante por cinco anos seguidos. As duas grandes mudanças da última versão estável do Java, a 8, para a antecessora, a 7, foram a implementação do paradigma funcional e a remoção da PermGen, uma estrutura de memória que não deixará saudade, mais grandes falhas que existiram por vários anos foram removidas. Ou seja, se a Google sinalizar suporte a outra linguagem no futuro, será a sentença de morte do Java.

Olhando pelo lado da produtividade, mais problemas. Lutz Prechelt, da Universidade de Karlsruhe, conduziu estudos a respeito da produtividade pelas linguagens de programação. Ainda que inconclusivos, eles mostram o que programadores que já passaram pelo Java já sabem. Demanda ferramentas grandes e caras para funcionar, exige hardware, é extremamente prolixo no padrão de projeto, demanda mais horas para ser desenvolvido, com uma complexidade assustadora em alguns casos e não é eficiente no uso de memória e processamento.

É aqui que evoco o humor. O humor é a melhor forma de explicar o estado de espírito dos programadores. O legal é que colocam Java e Python lado a lado.

Explicado tudo isso, posso explicar a cabeça do programador militante.

O programador militante não é apenas aquele que gosta de uma linguagem: é aquele que vai advogar em causa dela. Não aceita boa parte dos fatos, selecionando os fatos favoritos. Que não admite a crítica. Vai selecionar programadores que pensem como ele e que nunca levantem uma bandeira contrária. Irá proteger seus projetos sempre que possível e migrar outros projetos que não estejam na sua linguagem do coração, ainda que isso signifique trabalhar mais e imponha severas penalidades ao desenvolvimento e tempo de entrega de uma funcionalidade.

Te lembra alguma coisa?

Quase todos os programadores Java que conheço são, de certa forma, militantes, como o entrevistador da oportunidade de dias atrás, que disse que "eu me sentia melhor programando em outra coisa" (e é verdade, eu não gosto mesmo de Java, mas sei programar há uns bons anos, e isso não deveria contar como justificativa para uma negativa de trabalho). Ou seja, fui analisado pelo que gosto. Como não acho Java a melhor coisa do mundo, não sirvo para a posição.

O desprestígio da linguagem não existe para eles: o que existe é a implicância de programadores que não empatizam com a linguagem e suas, ham, maravilhosas funcionalidades. E frameworks, sobretudo. É claro que existem programadores assim em todas as linguagens, mas não se vê uma defesa tão histriônica em outras linguagens como esta, por exemplo, com filminho e auto-elogios piegas:

A melhor forma que existe de retroceder na carreira é se privar de espírito crítico. Entre ser certo e ser eficiente, enfrento um dilema em toda entrevista de Java. Afinal, pode-se esperar em quase todas um entrevistador que seja um programador militante. Para ser eficiente, é preciso exercer a empatia em detrimento da capacidade técnica.

E, quando é a empatia que prevalece, já sabemos o que podemos esperar do trabalho.

PS: Não faço questão de passar em qualquer entrevista que minha opinião sobre uma linguagem ou framework seja importante. Quem condiciona um bom e produtivo ambiente de trabalho somos nós, programadores, independente das ferramentas usadas. Claro que linguagens e frameworks ajudam, mas é quase sempre possível chegar ao mesmo objetivo independente da linguagem ou framework usados.

PS2: O leitor deve notar que gosto de Python, mas não faço uma defesa apaixonada da linguagem, achando que é a melhor coisa do mundo, muito menos dos frameworks dela. Ainda tem seus problemas e muito a melhorar. Críticas são sempre bem vindas!

Tenho um enorme prazer e satisfação de ter contato com os melhores desenvolvedores em língua portuguesa do mundo, através do site Stack Overflow em Português, a quem devo muito pelo reconhecimento e prestígio que me concederam voluntariamente nos últimos 3 anos. Acredito que as grandes mudanças positivas da minha vida nos últimos tempos foi por causa dessa relação de confiança que tenho com a comunidade, e os retornos são muitos: financeiro, social, profissional, pessoal.

Sendo um canal de comunicação para o mundo, mantenho em meu perfil todas as informações importantes que digam quem eu sou, onde estou, no que trabalho, quais são meus grandes projetos e os meios de contato. Isso para mim é o básico. Eu poderia colocar mais informações, mas prefiro ser sucinto e não me delongar no que não interessa. É assim que consigo alunos, contatos profissionais, contratos novos para minha empresa, oportunidades diversas.

No entanto, dividindo espaço com gente tão talentosa e disposta, é engraçado que a timidez e a falta de jeito (somada com um pouco de preguiça, diga-se de passagem) prevalece na hora dessas pessoas fazerem seu próprio cartão de visitas. Não há custos nem sacrifício de destinar algumas poucas linhas para se identificar e dividir com o mundo pelo menos um pouco de si, o mínimo para que outras pessoas possam entrar em contato, por exemplo. Não é raro ver alguns deles reclamando da vida, que ganham mal, que trabalham muito, e assim por diante.

O predominante nas descrições é o seguinte texto:

Aparentemente, este usuário prefere manter um ar de mistério sobre si mesmo.

O que se ganha com o mistério?

Isso na verdade me lembra José Costa, o escritor tímido e miserável de espírito de Budapeste, de Chico Buarque, cujo maior deleite era escrever obras se passando por outras pessoas:

Faltava-me dar prova cabal a Kaspar Krabbe, dizia o Álvaro, de que não iria pôr a perder uma vida honrada, além de um bom negócio, em troca de luzes que jamais almejei. Faltava-me dar mostras de ser ainda o velho José Costa, tão zeloso do próprio nome, que por nada neste mundo abriria mão do anonimato.

Soberbo e orgulhoso do próprio talento, José nunca quis projetar sua estrela porque a fama não lhe interessava. Preferia a prerrogativa de manter o nome incólume de qualquer escrutínio. Dono de uma personalidade estranha e uma excepcional capacidade de síntese, escreveu por encomenda o livro fictício "O Ginógrafo", se passando por Kaspar Krabbe, empresário alemão radicado no Rio de Janeiro. Uma série de caprichos o fez abdicar da própria família e quase o arruinou completamente, muito disso pelo capricho de se manter incógnito.

Recomendo a leitura deste livro sobretudo a todos aqueles que desejam saber o que não fazer em suas carreiras. Esse personagem me foi emblemático porque sua personalidade e seus melindres me irritam em pessoas de carne e osso.

Esse fetiche da identidade protegida até eu tenho, tanto que não uso meu nome de verdade pra tudo. Com mecanismos de indexação tão poderosos como o Google hoje em dia, nem sempre queremos ser associados a tudo aquilo que fazemos na Internet (meu caso), então somente as pessoas que me interessam chegam até mim. De qualquer forma, ainda consigo colocar um tanto de informação que as pessoas que realmente querem falar comigo conseguem sem muita dificuldade, diferentemente do objeto deste meu texto. E, mais importante ainda, conseguem ver minha produção devidamente creditada.

É a mesma coisa que faz o Buckethead, por exemplo. Uma pesquisa no Google sobre ele faz as pessoas acharem o nome dele de verdade, mas no caso dele produz o efeito contrário: as pessoas se interessam mais ainda sobre ele por ele ter uma identidade peculiar. Há várias outras bandas que fazem isso, e a ideia é, sim, vender o peixe, mas protegendo a privacidade e as vidas pessoais de cada um.

Aí vem o detalhe mais importante: esses músicos obtêm um benefício financeiro direto porque são muito bons com o marketing de suas identidades inventadas.

Já os programadores nada ganham com essa discrição toda. Por exemplo, se eu quiser contratar um deles, vou ter um baita trabalho para descobrir os meios de contato, vou ter que ter uma conta específica num site para falar com eles, adentrar um chat bem específico e torcer para que eles estejam lá.

Alguns ainda divulgam LinkedIn e GitHub, que considero que seja o mínimo, mas como empregador interessado em contratá-los, não quero ter que ficar descobrindo as coisas em longas pesquisas. Os programadores precisam supor que meu tempo é finito e não tenho horas para gastar em sondagens, ou lendo código e descobrindo que tipo de sistemas eles já trabalharam.

Vejo muitos programadores reclamando da vida, mas eles mesmos não se ajudam, e é isso que não faz o menor sentido para mim. A autopromoção não toma mais do que 10 minutos do seu tempo por dia e meia dúzia de frases, apenas como uma bússola, uma trilha de pão, um sinal de fumaça, qualquer coisa. Nunca foi tão fácil abrir um canal para novas oportunidades, com tantas ferramentas trabalhando por nós.

O exercício que proponho é você, programador, vestir a pele do seu empregador, entrar no site do Stack Overflow em Português e fingir que vai contratar alguém. Pode escolher linguagem, banco, framework, o que você quiser. Dê uma olhada em uns 15 perfis, e aí se faça a pergunta: é fácil contratar pelo Stack Overflow em Português?

Tendo esta impressão, vá ao seu perfil e coloque toda informação que achar importante que você, no seu perfil de empregador, considera pertinente. Se precisar de ajuda, só deixe um comentário aqui pra mim que posso fazer um feedback a respeito.

No capítulo anterior, falei sobre como o ASP.NET Web Forms resolveu o problema de quem estava no Delphi e não podia abraçar um paradigma completamente novo de desenvolvimento, e sobre os problemas de manter uma abordagem semelhante ao Delphi no desenvolvimento HTTP. Como adenso muito em várias questões, decidi deixar o detalhamento das migrações do Web Forms para este derradeiro capítulo, que também é útil para quem quer sair do Web Forms e ir para o ASP.NET MVC.

O ano é 2017. Já não moro mais no Brasil. Entre alunos, exercícios, livros, clientes e uma porção de coisas que inclui minha nova vida (afinal, morar em outro país é morrer um pouco e renascer mais um pouco), eis que surge um aluno que já havia concluído o Módulo 1 do Coding Craft para ASP.NET MVC, com muita dificuldade de terminar os exercícios dos onze capítulos. Vindo do Delphi, disse que seria ótimo se houvesse uma forma de casar os aspectos do Delphi, dos quais ele é muito mais familiar, com os aspectos do ASP.NET MVC, estabelecendo os paralelos em comum.

Fui programador Delphi também. A passagem de um para outro não é simples, conforme visto nas duas partes anteriores. Disse a ele que uma série de artigos teriam que ser produzidos, primeiro para embasar toda a questão migratória, e possivelmente um curso só sobre isso. De fato, o assunto é muito mais abrangente do que minha primeira impressão. Aqui está o texto introdutório. Em seguida, escreverei o curso.

Antes de finalmente falar de MVC, preciso falar de Windows Forms, que é um padrão que basicamente copiou o Delphi, mas que o apelo foi menor e não decolou tão bem, apesar de ainda ter um ótimo suporte até hoje.

Windows Forms

Paralelamente ao Web Forms, a Microsoft desenvolveu o Windows Forms, que é apenas a continuação natural do Delphi no C#. O mesmo esquema de janelas, o mesmo esquema de componentes, apenas aumentando o número de fontes comuns de 2 para 3 (foi adicionado um arquivo de Resource por form). Tamanha é a semelhança que as empresas que faziam componentes para Delphi passaram a fazer também componentes muito semelhantes para o Visual Studio, como a DevExpress e a DevArt.

Houve uma migração de programadores também do Delphi para o Windows Forms, mas não foi a plataforma predominante de mercado no início dos anos 2000. Até cheguei a fazer alguns sistemas em Windows Forms de 2009 a 2012, mas eram sempre sistemas auxiliares, sem grande força comercial. O apelo ao mundo Web já era muito mais forte.

No entanto, a Microsoft jamais descontinuou o suporte ao Windows Forms, que, de certa forma, ajudou a Microsoft nos próximos passos: o WPF, e com o advento do Windows Phone, a UWP. Os componentes e bibliotecas usados no Windows Forms são, em grande parte, também suportados em WPF e UWP.

Já está previsto em algum módulo do Coding Craft um capítulo sobre as semelhanças de Delphi e Windows Forms, em que vou detalhar isso mais a fundo.

ASP.NET MVC

E finalmente chegamos ao estado estável das coisas até então: o ASP.NET MVC. Na data deste texto, a versão 5 é a mais estável.

Parei no texto anterior na parte que eu falava de endpoints e manutenção de estados, e que eu diria que são dois pontos que mudam radicalmente do Delphi/Windows Forms/ASP.NET Web Forms para o ASP.NET MVC.

Endpoints

Para falarmos de endpoints, primeiramente precisamos falar de REST, a tal Transferência de Estado Representacional. O que ela é?

Em resumo, uma arquitetura em que cada interação com os provedores de informações são requisições e respostas em que não há a manutenção do estado das informações. Melhor dizendo, cada requisição pode ser replicada com o mesmo conjunto de informações a qualquer momento, podendo ter uma resposta diferente.

Por exemplo, suponha que você está no seu site de compras favorito e você está buscando por um determinado produto. Ao pesquisar por este produto, você preencherá alguns parâmetros em tela e enviará um comando para pesquisar no site com base naquelas informações. Se você salvar a página de resultado da pesquisa como Bookmark (favorito) e voltar nela outra hora, as informações dos filtros de pesquisa que você preencheu serão as mesmas. Os resultados podem mudar (como um produto sair de estoque, outro produto aparecer ou os preços e modelos do produto mudarem, mas a pesquisa é a mesma).

Note que numa tela de Delphi é impossível fazer isso, a não ser que seja implementado um mecanismo de salvar pesquisas dentro da aplicação (o que, aliás, era bastante comum). Você precisa entrar no sistema, fazer login, abrir uma tela principal, achar a tela de pesquisa, preencher os parâmetros para só depois disso de comandar a pesquisa obter os resultados. Para isso, o usuário teve que passar por vários estados da aplicação: tela de pesquisa fechada, tela de pesquisa aberta sem parâmetros, tela trabalhando em pesquisa, tela exibindo pesquisa.

É por isso que o uso de Sessions em ASP.NET MVC pode ser considerado como uma má prática: como o estado não é mais necessariamente mantido, ou seja, como qualquer tela pode ser acessada a qualquer momento, a manutenção de informações em memória de servidor é contraproducente.

A tradução de endpoint é "ponto de extremidade", mas é um nome estranho para o Português. Prefiro ponto de informações, e vou usar este termo.

Pensando no REST, um ponto de informações é acessado por um cliente. Seu navegador de Internet, como o Mozilla Firefox ou o Google Chrome são clientes. Seu aplicativo de celular também é, mas consumindo endpoints RESTful, que é assunto para outro texto. Ao acessar este blog na primeira página, seu navegador de Internet pede informações ao ponto de informações padrão (ou raiz). Como este blog é implementado em cima da arquitetura MVC, a requisição será usando o padrão REST e o protocolo HTTP. A programação do blog é feita para trazer os cinco artigos mais recentes que escrevi, no ponto de informações raiz. O retorno disso é um documento HTML com texto, fotos, folhas de estilo e, de vez em quando, até recursos multimídia, como música e vídeo.

Agora, suponha que você quer ler um artigo específico, como a parte 2 dessa série de artigos. Ao clicar para ler o texto, você verá o seguinte no endereço:

https://codingcraft.com.br/2017/04/17/como-sair-do-delphi-para-o-net-parte-2/

Repare que, entre barras após o endereço, temos algumas informações, como o ano, o mês, o dia e o título do texto. Essas informações são recebidas pelo ponto de informação raiz, que pesquisa pelo texto em banco de dados e o retorna, além de mais alguns recursos.

Se eu clicar uma centena de vezes no link ou acessar o endereço através de outros navegadores, o resultado deve ser mais ou menos o mesmo, dependendo do tamanho da tela do dispositivo que está acessando o site, até porque não pretendo mais editar esse texto. Independente do tamanho de tela, a massa de informações do texto é a mesma para qualquer dispositivo.

Há, ainda, outros pontos de informações, como por exemplo uma pesquisa por tags: http://www.codingcraft.com.br/tag/cursos-em-csharp/, ou ainda por autor: http://www.codingcraft.com.br/author/leonel/. Cada um desses endereços são pontos de informações diferentes, com identificadores de informações e valores também diferentes.

No MVC, cada ponto de informações está contido em um Controlador (ou Controller). O Controller contém toda a lógica necessária para orquestrar os diversos componentes da aplicação para estruturar uma informação que um ponto de informações irá devolver.

Cada elemento de dados é representado por um Modelo, ou Model. O Model contém as informações de cada registro, as informações de relacionamento com outras entidades e o comportamento de intercâmbio de informações, bem como alguns aspectos de validação.

Por mim, o que o Controller retorna ao usuário é uma massa estruturada de informações por meio de um componente de apresentação, chamado de Visão ou View. A View cadencia toda a informação numa distribuição espacial bem como coordena todo e qualquer comportamento visual que a tela terá quando receber a massa de informações do ponto de informações.

Cada requisição é feita por um método, ou verbo. O verbo para clicar em um link ou pressionar Enter na sua barra de endereços do navegador é chamado de GET. Gosto do nome verbo, então vai ser ele que vou usar.

Verbos

Cada ponto de informações pode interpretar vários verbos de formas diferentes.

O verbo GET, por exemplo, é o que chamamos de "verbo nulipotente", ou seja, a capacidade de manipulação de informações dentro de um sistema é muito pequena, sem poder, sem efeitos colaterais. Sua principal função é a de retorno simples ou filtrado de informações, como telas de apresentação, pesquisa, detalhamento, e assim por diante.

Há também os verbos POST, PUT e DELETE e mais alguns, mas deixarei a explicação desses para outro texto. Navegadores de Internet implementam apenas GET e POST, mas isso está mudando porque, por muito tempo, foram os únicos verbos necessários dentro do protocolo HTTP. POST é um verbo que recebe informações de um formulário e há manipulação de dados em sistema. Diferentemente de GET, é um verbo que exige uma cadência de eventos para ser aceito, como ter um formulário estruturado preenchido e enviado através de um comando específico, possibilitando ao navegador de Internet (ou cliente) algum saneamento de informações antes do envio. POST é usado para incluir, atualizar e, dependendo, excluir informações de um sistema. Por isso, pode ser considerada uma má prática usar GET para manipulação de dados em sistema.

Atualmente, POST está perdendo, pouco a pouco, as funções de atualização e exclusão, em favor de PUT para atualização e DELETE para exclusão.

Ou seja

Aqui acho que fica claro porque manter Sessions é uma má ideia. Pode surgir a pergunta sobre como um usuário é autenticado em um sistema ASP.NET MVC, mas isso também é assunto para outro texto, ou para o curso.

O que muda do Delphi

Bom, a função visual que o Delphi tinha é feita hoje em dia por JavaScript, a linguagem que manipula o comportamento dos clientes, como aplicativos de celular e navegadores de Internet. Por sorte, muitos frameworks hoje em dia implementam suporte a eventos de tela de forma semelhante, mas, basicamente, toda construção de tela envolve a linguagem de marcação HTML e JavaScript.

Voltando ao que eu falei na primeira parte, o que o ASP.NET Web Forms faz é basicamente gerar esse HTML e JavaScript para o programador, mas isso deixou de compensar à medida que novos componentes são desenvolvidos e os desenvolvedores precisam ter controle total sobre o comportamento da tela do dispositivo. "Componentizar" foi prático num primeiro momento, mas com o advento de frameworks mais poderosos em JavaScript, bem como uma maturação forçosa da linguagem, a prática perdeu força.

Além disso, não há mais a dependência a um ambiente. As telas dos dispositivos suportam vários tamanhos, lançando à comunidade o conceito de responsividade, ou seja, um sistema que se adequa à tela do dispositivo sem perder qualidade visual. Há diversos tipos de interface. Teclados, mouses, canetas stylus, ou as boas e velhas pontas dos dedos sobre a tela. A transferência de estado entre telas cai em desuso aos poucos, em favor dos eventos assíncronos que atualizam porções parciais da tela em uso.

Em resumo, o que deve ser entendido pelos programadores Delphi na hora de lidar com o ASP.NET MVC?

1. Acessos ao sistema podem ser feitos a qualquer momento, de qualquer lugar para qualquer ponto de informação;
2. O retorno de informações ao cliente pode ser HTML, JSON, XML, YAML, imagens, vídeos, entre outros;
3. Caixas de texto, Drop Downs, grupos Radio, grupos de Checklist, áreas de texto e outros componentes de entrada são feitos por formulários. Grids são feitas usando tabelas e JavaScript;
4. Ao contrário de sistemas Delphi, em que cada sistema está o tempo todo conectado a um servidor, uma aplicação Web raramente está conectada o tempo todo ao servidor. A exceção são para requisições de protocolos Web Socket;
5. A autenticação e controle de usuários pode ser feita a qualquer momento, em qualquer ponto de informações.

O restante mencionarei nos futuros cursos que estou escrevendo para orientar programadores interessados em aprender mais em .NET vindos do Delphi. Entre em contato para mais informações.

No artigo anterior, fiz uma contextualização histórica a respeito do Delphi e do surgimento do .NET, o que houve com os desenvolvedores na época (também falando sobre a minha realidade) e o que a Microsoft propôs para que os desenvolvedores abandonassem o desenvolvimento em Windows Desktop para começar algo para a Web. Mencionei também que a conversão teve um sucesso moderado. Aqui recomeço deste gancho: os acertos de erros do ASP.NET Web Forms e o que a Microsoft fez depois de 9 anos.

Da mesma forma que comecei o texto anterior, vou contextualizar minha realidade para chegar ao assunto que quero falar. Preferencialmente começando de forma muito semelhante.

O ano era 2009. Como falei no texto anterior, eu era um Analista de Sistemas, mas aqui, Júnior. Tinha acabado de ser promovido, de fato. Eu era um programador prolífico, cheio de ideias. Algumas meu chefe apoiava. Outras, se mantinha cético. Cheguei a ouvir que eu era um cara muito idealista. Tinha pouca vivência com clientes e estava aprendendo a ser mais diplomático no telefone, nos e-mails, nos contatos em geral. Na época, a empresa estava começando no ASP.NET e vendia seus primeiros sistemas nessa tecnologia. Os programadores que trabalhavam nesses projetos tinham mais visibilidade que os programadores que mantinham os sistemas legados. Quem trazia dinheiro era mais valorizado. Eu era dos sistemas legados. Tinha conseguido trazer dinheiro destravando ideias de implementação que há muito estavam engavetadas, mas meu trabalho aparecia pouco. Arrisco dizer que meu trabalho só apareceu de verdade depois que saí da empresa.

Eu tinha um colega que estudava Ruby on Rails por conta. Trabalhávamos lado a lado. Ele sempre falava como a tecnologia era maravilhosa, mas apenas isso, sem muitos detalhes. Eu estudava PHP nas minhas noites livres (sim, horrível, mas estudava, então está valendo) e fazia uns sistemas de vez em quando. Meu colega sugeriu, ao invés de começar diretamente no Ruby on Rails, passar por um framework MVC antes, sendo o CakePHP uma boa opção para começar. Baixei o CakePHP e comecei a estudar. Por mais que PHP seja uma linguagem ruim, o framework implementava bem boa parte dos conceitos MVC que foram muito importantes mais adiante.

Coisas como scaffolding, estratificação de Models, apresentação independente de formato e, sobretudo, produtividade vieram na época que estudei CakePHP. Várias soluções do framework não eram boas, mas a base foi fantástica para o próximo passo: o Ruby on Rails.

Fiz o famoso Ruby on Rails Tutorial escrito pelo Michael Hartl. Era longo, intrincado, cheio de detalhes (ainda é). O conceito de ter um gerenciador de pacotes surgiu para mim aqui. Era incrível poder confiar na ferramenta para resolver todos os emperros de atualização de componentes. Também fui apresentado ao conceito de pré-processadores (CSS e JS), carga preguiçosa e antecipada através do Active Record, variação incremental do banco de dados através do mecanismo de migrações, em que a aplicação controla o banco de dados por via de código, serialização em diferentes formatos, vários tipos diferentes de testes unitários, e então finalmente entendi a empolgação do meu colega, e ela procede. Rails foi por muito tempo o santuário das grandes ideias para a Web. Um achado.

Mas, quem usava Ruby on Rails no Brasil?

Bom, pouca gente. Era preciso ter devoção e paciência para programar em Ruby on Rails no Brasil e ser remunerado por isso (hoje já está bem melhor, felizmente). Eu tinha três opções, portanto:

1. Investir no CakePHP e/ou outros frameworks MVC no PHP: descartei essa logo de cara. PHP nunca pagou muito bem no Brasil. Provavelmente iria arrumar um emprego pra ganhar menos;
2. Estudar Ruby on Rails e procurar vagas em Ruby: a escassez do mercado nunca me empolgou. Trabalhar com o que se gosta é bom, mas ganhar dinheiro também é, e provavelmente eu iniciaria como Programador Júnior, que não é algo que me empolgava;
3. Procurar um framework MVC em uma linguagem de mercado: aqui eu tinha Delphi, Java e .NET. Delphi não tinha o paradigma Web até então. Java tinha o Spring MVC e o .NET tinha o ASP.NET MVC.

ASP.NET MVC? Curioso.

Todas as minhas horas livres na frente do computador iam para estudar aquele framework, que era jovem e cheio de coisas semelhantes ao Rails. Ainda não tinha todos os recursos, mas já estava bem maturado. Havia a implementação de um framework em separado para os dados, muito semelhante ao Active Record do Rails, com o dispositivo de migrações e tudo, mas dentro da realidade do Microsoft SQL Server. Havia um mecanismo de execução de código .NET na apresentação, chamado de Razor, e, sobretudo, havia o scaffolding, que na época era experimental, mas funcionava divinamente bem, e que alguns anos mais tarde foi incorporado nativamente ao Visual Studio 2013, já na versão do ASP.NET MVC5. Comecei no MVC3.

Finalmente eu havia achado meu norte. Finalmente eu estava na toada da tecnologia de ponta. Isso foi essencial para minha vida mudar completamente, eu trocar de emprego, abrir empresa, multiplicar minha renda por 4.

Historinha contada, espero que tenha instigado o leitor à altura para esta parte 2.

Web Forms e Seus Problemas

Como eu disse na parte anterior, o ASP.NET Web Forms trazia todo um conjunto de funcionalidades que eram comuns a programadores Delphi, mas que iam contra o bom padrão de design e fluxo do HTTP, com algumas ideias como, por exemplo, a manutenção de estados da aplicação, mas era um começo. Os problemas disso não tardaram a vir.

O Inferno dos Postbacks

Cada operação de fornecimento de dados a aplicações ASP.NET Web Forms eram feitas por padrão usando POST, mesmo as que não eram formulários. Isso fez a equipe analisar a requisição e incluir um parâmetro chamado Page.IsPostBack com o intuito de verificar se a página estava vindo de um método POST para ela mesma. A ideia parecia boa no começo, mas era usada à exaustão em todo tipo de lógica bizarra que se possa imaginar. Experimente fazer uma pesquisa no Google e veja a quantidade de problemas relacionados ao Postback que são encontrados.

Sendo o padrão de método POST mais utilizado que GET, isso aumentava o caos na hora de usar Postback, gerando um sem-número de casos bizarros e fluxos imprevisíveis nas aplicações. Isso forçou os times a se adaptarem e a estudarem os conceitos e os bons padrões de design HTTP, ainda que timidamente.

Sessions

Havia também a necessidade da manutenção de vários estados, como no Delphi, responsabilidade está que foi transferida para a implementação das Sessions. Sessions até não foram tão problemáticas como o Postback, pelo menos de início. Com o início de transações distribuídas e conceitos de balanceamento de carga, isso mudou.

Sessions simplesmente não funcionam bem em ambientes distribuídos, pelo menos usando a configuração padrão. As soluções que a Microsoft encontrou foram:

1. Montar um servidor isolado de Sessions. Aparentemente é a abordagem que melhor resolve o problema de uma forma geral, mas acarreta no uso de mais recursos de infraestrutura;
2. Usar o SQL Server para armazenamento de Sessions. É mais complicado de usar porque todo dado precisa ser serializado (e, consequentemente, desserializado) na comunicação com o banco de dados.

Code Behind

O Code Behind é o arquivo .PAS do ASP.NET Web Forms. É um arquivo em uma linguagem do .NET que implementa os eventos disparados pela apresentação. Esse disparo é feito através de requisições para endpoints - ou seja, endereços que recebem requisições -, e que recebem informações adicionais para a execução do evento. Esse envio de informações é feito através de formulários, requisições GET ou ainda, JavaScript. Por padrão, um arquivo de Code Behind implementa apenas um endpoint.

Aqui é importante dizer que cada componente do Web Forms, no fim das contas, será a geração de HTML e JavaScript com o necessário para a chamada aos eventos escritos no Code Behind. Mas, e se queremos um comportamento que não mude o estado da tela, como um evento Ajax, por exemplo?

Resposta: não é possível fazer, a não ser instalado uma biblioteca de componentes chamada AjaxControlToolkit, que nem é mais desenvolvida pela Microsoft. Ou, ainda, o uso de Web Methods, que é só o nome bonito para expor o método do Code Behind como um endpoint verdadeiro. Aqui vem um pensamento:

Se estamos agora trabalhando diretamente com endpoints verdadeiros, não é melhor passar tudo para endpoints verdadeiros e não trabalhar mais com componentes engessados, que só geral HTML e JavaScript como resultado final?

É aqui que o ASP.NET MVC obtém seu grande triunfo sobre o ASP.NET Web Forms. Só há a opção de trabalhar com endpoints verdadeiros, preferindo não usar estados e mercadores de requisições POST. É o primeiro framework que implementa todo o ciclo existente no HTTP sem fricção.

Na terceira e última parte, vou descrever o que muda do Web Forms para o MVC, ainda traçando paralelos com o Delphi.