Sobre 'Codigo limpo vs código rápido', 'monolito vs microsserviços', 'feito vs perfeito' e respostas prontas

Muito boa postagem.

Curioso falar em "bom sênior", faz sentido, mas sênior deveria ser bom por definição, né? :P :) Não quer dizer que sabe tudo, que não comete erros, mas tem certos entendimentos e sabe corrigir rotas. O sênior é justamente quem não cai em armadilhas.

Infelizmente não sou otimista de ver aqui e ali alguns dizendo que microsserviços não são solução para tudo (na verdade para quase nada), ainda 90% achará que não pode ficar de fora dos outros 90% que estão usando, quando na verdade nem 1% está, provavelmente nem 0,1% deveria estar usando, e como todos querem estar na moda um dia pode ter 10% de gente usando o problema que se diz ser solução. Pelo menos tenho visto cada vez mais pessoas dizendo que usam microsserviços mas não ser verdade, a pessoa não sabe fazer então ela faz algo diferente, até pode ser melhor assim, e dá o nome para dizer que está na moda, e pode por no currículo que fez um projeto assim, mesmo sem nem entender o que é :D

Infelizmente hoje em dia nada tem muito voto, essa deveria ser uma das postagens de mais destaque aqui. Obviamente assino embaixo em tudo.

Faz sentido?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Escopo, prazo e vida útil. Se atender aos 3 requisitos uma abordagem limpa é muito mais que bem vinda quando a ideia é que um desenvolvedor daqui a 5 anos mantenha ou crie novas funcionalidades pro sistema.

Interessante a discussão sobre "relaxo e overengineering", como você colocou. Uma coisa que tenho tentado exercitar com os do olimpo é o conceito de apetite. Se a empresa tem um apetite de 1 semana para criar uma feature X, o resultado será diferente se o apetite fosse de 3 meses, por exemplo. E quem deve setar o apetite é o próprio negócio. É a inversão da estimativa tradicional que é: "quero uma feature X, em quanto tempo o desenvolvimento consegue fazer isso?". Ao inverter a peça, a discussão é "o que consigo fazer em Y dias/semanas/meses?". Aí o escopo será cortado (ou alongado) para aquilo que será construído. Obviamente esse conceito não é meu, mas do Shape Up. O tempo é fixo, e o escopo é variável. Ao contrário da abordagem tradicional onde o tempo é variável, mas o escopo é fixo.

Tem que avaliar o tempo, o dinheiro, o escopo, a urgência, as skills da equipe... Entre outras inúmeras variáveis.

Você matou a charada.

Programação não é um fim em si mesmo. Não devemos escrever código limpo só porque o Uncle Bob mandou. Programação é meio para resolver problema. Acho que o mais importante é ter em mente do porquê devemos fazer essas escolhas. E o porquê SEMPRE é o negócio.

eu li em um livro sobre microsserviços com django que o uso de microsservicos deve ser avaliado com cautela e que o uso inapropriado pode ser a causa da morte de uma empresa. parecer uma boa opcao para um sistema mt complexo e muito grande; que nessecite de baixissimo acoplamento. em sistemas pequenos e ate medios, parece ser mais vantajoso ser monolitico.

O famoso "depende" como resposta irrita alguns. Mas, o programador, o desenvolvedor, o "analista", precisa se armar mais dos "dependes" da vida.

Isso aqui me lembrou um meme, "papagaio aprende a falar depende e vira programador sênior". Brincadeiras a parte, mas um muitas vezes durante reuniões onde os sêniors estao discutindo sobre tecnologia ou arquitetura sinto como se eles fossem seres superiores ou como você nomeeou os do olimpo, mas creio que grande parte disso é devido a minha vergonha de querer participar de alguma coisa e acabar falando besteira já que não tenho muito conhecimento sobre um determinado assunto.

Por este motivo eu acredito que a habilidade de saber questionar ou até mesmo sugerir coisas pertinentes em relação a certos temas vêm com a experiência e também com o conhecimento que a gente vai adquirindo ao longo da carreira trabalhando e estudando.