Excelente vídeo como sempre. Quem acompanha o canal já sabe que para entregar rápido e com qualidade precisam existir testes; tanto neste vídeo quanto no do Dave Farley não é citado o TDD explicitamente, mas acredito que esteja implícito. Afinal, não adianta ter uma estrutura que segue à risca a cartilha do SOLID se não existirem testes que dão a segurança para modificar e evoluir o sistema. Sem eles, o medo de colocar algo em produção sempre estará à espreita.
Professor, nós precisamos acabar com a ideia estabelecida do que é um MVP. No mercado a ideia estabelecida do MVP é sinônimo de underengineering. Basicamente: precisamos dessa feature para ontem. Daí sufocam o estágio inicial do projeto, que é o estágio no qual demoramos mais se seguimos boas práticas. Eu sempre lembro dos gráficos do primeiro capítulo do arquitetura limpa. A velocidade aumentando vertiginosamente na adoção de desenvolvimento profissional ao passo com que o número de desenvolvedores se mantém estável. Em contrapartida se seguirmos a ideia estabelecida de “MVP” acontece estritamente o contrário. A velocidade de desenvolvimento cai e o número de desenvolvedores aumenta. Outro ponto importante, ser ágil não é só entregar rápido a qualquer custo, não é só usar colunas quadro. Envolve entregar rápido com qualidade uma solução extensível (no sentido estrito do OCP).
Sim. Queria deixar claro que quando falo em entregar rápido não estou falando em entregar com pressa. É entregar cedo e com frequência. O overengineering vem muitas vezes de ficar adiando a entrega, de ficar preso no processo, sem um objetivo claro. Quando falo para entregar cedo, não é para entregar qualquer coisa. É para entregar algo de qualidade, mas cedo e frequentemente.
concordo 100% com a segunda parte do vídeo, sobre o overengineering, inclusive podemos cair no overengineering escolhendo programação funcional para um projeto hehe, isso eu sei que você vai discordar! 😅 sobre a primeira parte do vídeo, que fala sobre velocidade X qualidade, estamos de acordo que no agil não deveriamos utilizar triangulo de ferro, inclusive publiquei um artigo no medium com o título "Ser ágil e utilizar o triângulo de ferro não faz sentido!" mas além disso tenho alguns pontos: dizer que "é um mito que TDD deixa a equipe mais lenta" não é verdade, utilizando TDD o time fica mais lento sim, podendo chegar a 15% a mais de tempo, em compensação leva o produto para produção com menos defeitos a forma mais rápida de entregar um software é com ZERO qualidade, e o go horse é prova disso: tudo é feito de qualquer jeito, sem se preocupar com o amanhã, sem nenhum pattern ou boa prática, você só faz o que tem que ser feito, essa que é a forma mais rápida de entregar software, e obviamente se você for fazer algo visando a qualidade, você vai demorar mais para entregar, isso é um fato na engenharia de software... não faz sentido dizer que quem produz software com qualidade entrega mais rápido que quem faz go horse A MENOS QUE você esteja se referindo a longo prazo... ai eu concordo com você, o go horse na medida que você vai mexendo no código e entregando, vai ficando cada vez mais dificil e devagar lidar com o débito técnico, e com código de qualidade e testes de verdade, você consegue implantar mais rápido mas no mundo real, infelizmente o pessoal de negócios vai pressionar, o time vai dizer que ainda está no período de testes ainda, o pessoal de negócios vai escalar pros "deuses do olimpio", que vai te mandar deployar em produção até o fim do dia, dane-se os testes inacabados, e você vai deployar porque quer manter seu emprego 🤷🏻♂
Pq PF seria overengineering? Pra quem manja, o código sai até mais rápido e é bem mais enxuto e poderoso. Sobre sua argumentação: de fato, NO COMEÇO, o go horse vai mais rápido. Mas logo começa a ficar difícil mudar o software e, portanto, fica mais devagar. O mesmo com TDD. Talvez no começo será um pouco mais lento mas com um pouco de tempo já fica mais ágil do que fazer tudo nas coxas. Você precisa pensar as coisas mais a médio / longo prazo para entender a ideia. Eu entendo a questão da pressão. É necessário maturidade para conseguir trabalhar de maneira ordenada e convencer as lideranças de que você sabe o que está fazendo.
@@otaviolemos imagina que uma empresa pequena quer um sistema simples pra solicitação de reembolso dos funcionários, um PHP ou Ruby já resolve sua vida, a curva de aprendizado e a complexidade associada a PF podem ser desnecessárias para um sistema de reembolso relativamente simples, uma linguagem de programação imperativa evita a complexidade desnecessária que uma linguagem funcional como Clojure pode trazer, então sim, podemos cair no overengineering escolhendo qualquer coisa para nosso projeto, PF não está de fora!
@@otaviolemos sobre os 15% do TDD, eu recebi essa informação, quando eu estava fazendo minha pós graduação em engenharia de software, do meu professor @Renato Barbieri, que é um especialista na área e possui diversas certificações relevantes sobre o assunto
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
Excelente vídeo como sempre. Quem acompanha o canal já sabe que para entregar rápido e com qualidade precisam existir testes; tanto neste vídeo quanto no do Dave Farley não é citado o TDD explicitamente, mas acredito que esteja implícito. Afinal, não adianta ter uma estrutura que segue à risca a cartilha do SOLID se não existirem testes que dão a segurança para modificar e evoluir o sistema. Sem eles, o medo de colocar algo em produção sempre estará à espreita.
Código sem teste não existe. 😅
Que vídeo incrível. Esse é um daqueles vídeos para ficar reassistindo de tempos em tempos
Valeu, Raffael!
Professor, nós precisamos acabar com a ideia estabelecida do que é um MVP. No mercado a ideia estabelecida do MVP é sinônimo de underengineering. Basicamente: precisamos dessa feature para ontem. Daí sufocam o estágio inicial do projeto, que é o estágio no qual demoramos mais se seguimos boas práticas. Eu sempre lembro dos gráficos do primeiro capítulo do arquitetura limpa. A velocidade aumentando vertiginosamente na adoção de desenvolvimento profissional ao passo com que o número de desenvolvedores se mantém estável. Em contrapartida se seguirmos a ideia estabelecida de “MVP” acontece estritamente o contrário. A velocidade de desenvolvimento cai e o número de desenvolvedores aumenta. Outro ponto importante, ser ágil não é só entregar rápido a qualquer custo, não é só usar colunas quadro. Envolve entregar rápido com qualidade uma solução extensível (no sentido estrito do OCP).
Sim. Queria deixar claro que quando falo em entregar rápido não estou falando em entregar com pressa. É entregar cedo e com frequência. O overengineering vem muitas vezes de ficar adiando a entrega, de ficar preso no processo, sem um objetivo claro. Quando falo para entregar cedo, não é para entregar qualquer coisa. É para entregar algo de qualidade, mas cedo e frequentemente.
Fez um resumo com qualidade, quantidade e em pouco tempo. Metalinguagem !
Hahha boa!
Excelente video mestre Otávio
concordo 100% com a segunda parte do vídeo, sobre o overengineering, inclusive podemos cair no overengineering escolhendo programação funcional para um projeto hehe, isso eu sei que você vai discordar! 😅
sobre a primeira parte do vídeo, que fala sobre velocidade X qualidade, estamos de acordo que no agil não deveriamos utilizar triangulo de ferro, inclusive publiquei um artigo no medium com o título "Ser ágil e utilizar o triângulo de ferro não faz sentido!"
mas além disso tenho alguns pontos: dizer que "é um mito que TDD deixa a equipe mais lenta" não é verdade, utilizando TDD o time fica mais lento sim, podendo chegar a 15% a mais de tempo, em compensação leva o produto para produção com menos defeitos
a forma mais rápida de entregar um software é com ZERO qualidade, e o go horse é prova disso: tudo é feito de qualquer jeito, sem se preocupar com o amanhã, sem nenhum pattern ou boa prática, você só faz o que tem que ser feito, essa que é a forma mais rápida de entregar software, e obviamente se você for fazer algo visando a qualidade, você vai demorar mais para entregar, isso é um fato na engenharia de software...
não faz sentido dizer que quem produz software com qualidade entrega mais rápido que quem faz go horse A MENOS QUE você esteja se referindo a longo prazo... ai eu concordo com você, o go horse na medida que você vai mexendo no código e entregando, vai ficando cada vez mais dificil e devagar lidar com o débito técnico, e com código de qualidade e testes de verdade, você consegue implantar mais rápido
mas no mundo real, infelizmente o pessoal de negócios vai pressionar, o time vai dizer que ainda está no período de testes ainda, o pessoal de negócios vai escalar pros "deuses do olimpio", que vai te mandar deployar em produção até o fim do dia, dane-se os testes inacabados, e você vai deployar porque quer manter seu emprego 🤷🏻♂
Pq PF seria overengineering? Pra quem manja, o código sai até mais rápido e é bem mais enxuto e poderoso.
Sobre sua argumentação: de fato, NO COMEÇO, o go horse vai mais rápido. Mas logo começa a ficar difícil mudar o software e, portanto, fica mais devagar. O mesmo com TDD. Talvez no começo será um pouco mais lento mas com um pouco de tempo já fica mais ágil do que fazer tudo nas coxas. Você precisa pensar as coisas mais a médio / longo prazo para entender a ideia.
Eu entendo a questão da pressão. É necessário maturidade para conseguir trabalhar de maneira ordenada e convencer as lideranças de que você sabe o que está fazendo.
A propósito: esse 15% você tirou de onde?
@@otaviolemos imagina que uma empresa pequena quer um sistema simples pra solicitação de reembolso dos funcionários, um PHP ou Ruby já resolve sua vida, a curva de aprendizado e a complexidade associada a PF podem ser desnecessárias para um sistema de reembolso relativamente simples, uma linguagem de programação imperativa evita a complexidade desnecessária que uma linguagem funcional como Clojure pode trazer, então sim, podemos cair no overengineering escolhendo qualquer coisa para nosso projeto, PF não está de fora!
@@otaviolemos sobre os 15% do TDD, eu recebi essa informação, quando eu estava fazendo minha pós graduação em engenharia de software, do meu professor @Renato Barbieri, que é um especialista na área e possui diversas certificações relevantes sobre o assunto
@@artu_almeida se você tiver um especialista em PF aposto contigo que ele faz mais rápido do que os caras do PHP/Ruby.
Parabéns pelo conteúdo chará!
🤔🤔🤔🤔🤔