Hoje vamos de dicas para o caos e a destruição. É a atitude pessimista que dá emprego para mais gente no mercado, produz mais trabalho, assim produzimos um ciclo vicioso de projetos ruins, recuperações de projetos, refatorações e posteriormente reconstruções dos mesmos projetos!

Essas dicas vão ajudar você empurrar qualquer projeto ladeira à baixo!

1) Comece pela arquitetura

Comece escolhendo uma arquitetura que lhe dê mais prazer. Não olhe para nenhum requisito. Não se preocupe se o projeto é mobile, desktop, embarcado, vestível… nada disso é relevante se o seu intuito é fazer esse projeto fracassar.

Quantidade de usuários?

Quem é o público?

Volumetria?

Nada disso tem importância no objetivo que propomos aqui.

2) Diversifique as tecnologias

Uma boa dica é ignorar completamente o skill da sua equipe e o skill do time técnico. Escolha as tecnologias de acordo com um benchmark boladão qualquer.

Aliás benchmarks são excelentes para comprovar que C++, RUST e GO deveriam ser as linguagens da web, mesmo que você tenha um time todo de desenvolvedores NodeJS ou C#.

3) Fuja dos STANDARDS e PATTERNS

Essa dica é incrível.

Quanto maior a comunidade, pior.

Quanto maior o suporte e a quantidade de conteúdo disponível, pior.

Qualquer similaridade que facilite a cooptação de profissionais que são nativos de outros stacks, não é algo bem vindo.

Que tal Blazor, Cheerp, CheepJ?

Evite a todo custo React e Angular no front.

4) Use seu projeto como playground

Tá faltando emoção? Estudou alguns minutinhos, ou assistiu uma live no canal do youtube ou em um curso da Udemy?

Está na hora de testar seus conhecimentos e colocar algo em produção!

• RabbitMQ
• Kafka
• Identity Server
• Keycloak
• Redis
• MongoDB
• SQL Server
• Neo4J.

O primeiro passo é ir adicionando o máximo de tecnologias possível.

Depois distribua os problemas e casos de uso para cada uma delas, para que pareça fazer sentido.

5) Ignore a documentação

Se você pode passar 6 horas debugando, para que perder meia hora na documentação?

A documentação acabaria com o argumento: “Eu li em um tutorial e fiz isso aqui.” ou “Eu vi como subir e fiz, não sei se está certo”.

Documentação é para especialista!

Programador raiz vai na tentativa-e-erro, stack overflow e nos grupos técnicos!

Afinal, não podemos dar certeza sobre o que fizemos. Devemos sempre terceirizar, e se houver um tutorial, esse cara é o cara certo para culparmos.

Surgiu uma dúvida, ou quer aprender a fazer alguma coisa? Esqueça o google e a documentação. Vá direto ao Stack Overflow.

Separe um profile do browser para colocar o stack overflow como mecanismo de busca.

6) Boas práticas são para amadores motivados

No dia-a-dia de um projeto profissional, boas práticas não existem.

Boas práticas só existem no mundo de alice dos criadores de conteúdo e MVP’s. Igore SOLID, GoF Patterns.

Quando menor o número de classes, melhor.

Devemos desenvolver como pensamos, de forma linear, construindo passo-a-passo, com a menor quantidade de abstrações e isolamento possível.

Isso é coisa de hypster.

7) Ignore logs

A garantia de que algo está funcionando é a ausência de gerentes e diretores bufando no teu cangote.

Se não há ninguém reclamando, então está tudo no ar.

8) Nunca lance exceptions

Confie plenamente na infraestrutura de ingestão de dados e cadastros básicos.

Pré-condições de métodos e cenários que são problemas conhecidos não precisam ser revalidados e os fluxos não precisam ser interrompidos abuptamente.

Não refaça nenhuma validação de consistência, assuma que outras partes já fizeram seu trabalho.

Revalidar premissas é esforço duplicado!

9) Não compartilhe decisões

Se você está na posição de tomar decisões, tome! Ignore outros amadores que estão junto com você nessa jornada.

10) Não produza padrões

Cada demanda é única e pode se dê total liberdade para escolher qualquer tecnologia, qualquer solução, escrever variações dos componentes.

11) Nada é mais importante do que entregar rápido

Toda atividade deve ser executada com a busca pelo menor tempo entre pedido e entrega.

Se achou um código no SO que atende: copie e cole.

Achou um post? Copie e traga para o projeto.

Acho um código no github? Adapte e coloque em produção o mais rápido possível.

Afinal, quando queremos afundar um projeto, basta ter velocity atual como único drive.

12) Ignore regras de modelagem de banco, você não é DBA

Padronização, normalização, isso tudo é coisa que outro profissional deve cuidar para você, ele se chama DBA. Enquanto ele não olha teu código, use LOB’s para upload de arquivos de todos os tamanhos, inclusive aqueles arquivos que são carregados em todo request, como imagens do usuário e assets básicos.

Se você é um iniciante, e quer afundar um projeto? Não aprenda SQL, vá direto para os ORM’s, afinal, quem lida com SQL é DBA!

13) Caching

Você não precisa de caching, um simples banco de dados e sua web app são suficientes para qualquer demanda.

Por se tratar de uma aplicação de Linha de Negócio, cache de segundos é irrelevante.

Se não puder deixar um item por anos, meses, no máximo horas no cache, esqueça, queremos afundar o projeto.

14) Mensageria

Mensageria é algo desnecessário e gourmetizado, que complica o dia-a-dia. Se precisar de resiliência, com .NET, use somente Polly, de preferência com retry infinito.

Se serviços dependentes caírem, isso não vai ser um grande problema para os usuários, eles provavelmente estarão acostumados com essas quedas.

Atenda todas as requisições de ponta-a-ponta, realizando todas as atividades da forma mais prática: na controller.

Se por algum motivo achar que vale a pena usar mensageria, comece com abstrações, como Masstransit e EasyNetQ! Afinal, quando queremos fracassar, precisamos fracassar em vários pedaços.

15) Em microsserviços, dê preferência para

Processamento síncrono na thread do request HTTP.

Use apenas HTTP

Compartilhe banco para facilitar os joins.

Aliás, joins são muito bem vindos!

Se possível implemente um protocolo sob o TCP ou UDP que seja extremamente otimizado. Evite standards, novamente.

Se te forçarem a usar gRPC, ou até mesmo o velho WCF, abuse dos client certificates, principalmente se não houver gestão de ciclo de vida de certificados!

Nesse caso, o fracasso dessa implementação gira em torno de 15 dias após a expiração do certificado, portanto, assegure o certificado expirará perto de uma black friday ou natal.

São os melhores períodos para uma boa crise que ninguém entende o que aconteceu, na maioria dos mercados.

16 ) (.NET) Faça deploy manual, de preferência no Windows, de preferência no IIS

Automatizar significa gastar um tempo precioso em que poderíamos gastar produzido algumas funcionalidades críticas sem testes.

Use o IIS e windows para garantir o máximo de velocidade.

Assegure que haja liberdade e autonomia pra que todos os desenvolvedores possam fazer builds em suas máquinas e publicar em qualquer ambiente, inclusive produção.

17 ) Não faça updates e upgrades

Escolha uma versão qualquer de Angular, .NET e afins e não faça upgrades nunca, ou raramente pelo menos. Upgrades custam caro, e são puro retrabalho.

O ciclo de vida mais rápido dos projetos atualmente foi desenhado por uma conspiração para aumentar a demanda por um cargo que é o atualizador de libraries. Fuja disso!

Por hoje é só!

Se você seguir apenas algumas dessas dicas, com certeza seu projeto fracassará.

Não precisa seguir todas!

A diferença entre remédio e veneno, é a dosagem.

Uma morte prematura do projeto pode colocar em risco teu pescoço.

BONUS

Se você é um apaixonado por procedures, use-as ao máximo.