SlideShare uma empresa Scribd logo
Jackson Mafra
A eterna luta:
compatibilidade
retroativa vs. dívida
técnica
Desenvolvedor e Consultor WordPress
Desenvolvedor há mais de 20 anos com background em
projetos de e-commerce e mercado imobiliário, desde 2009
com interesses focados para o desenvolvimento de
interfaces móveis e aplicações corporativas.
Me chama lá...
http://about.me/jacksonfdam
http://linkedin.com/in/jacksonfdam
@jacksonfdam
Jackson Mafra
AGENDA
02
05
03
06
Como eles se relacionam?
Principais conclusões
O que é dívida técnica?
01
O que isso significa para o
WordPress?
04
O que é Compatibilidade
Retroativa?
Como podemos melhorar isso ?
Prelúdio
Uma breve introdução
00
O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
O Mítico Homem-Mês: Ensaios Sobre Engenharia de
Software (The Mythical Man-Month: Essays on Software
Engineering)
O argumento central de O Mítico Homem-Mês é o de que
grandes projetos de programação sofrem de problemas de
gestão cuja natureza difere dos projetos pequenos em
função da divisão das tarefas; a integridade conceitual de
um produto é um fator crítico em seu desenvolvimento; e
que é difícil, mas possível, atingir tal integridade.
O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
Seu ensaio seminal de 1986, "Não existe bala de prata"
também está aqui, complementado por um novo texto da
edição de 1995, onde Brooks afirma que "Não haverá
nenhuma bala de prata no intervalo de dez anos".
Estes dez anos já se passaram e Brooks continua atual.
O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
Apesar de ser uma obra que teve alguma relevância no
passado a edição, mesmo atualizada, não representa nem
de perto o modelo atual de gestão.
Os exemplos utilizados tem mais de 40 anos, algumas
práticas já foram substituídas por métodos ágeis.
Talvez num contexto estritamente acadêmico e conceitual
faça sentido, mas no dia-a-dia a obra é incapaz de
endereçar os problemas de gestão em um ambiente de
transformação digital.
O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
Em mapas mind/mentais.
Torre de Pisa
Como você pode ver, esse é um monumento super
conhecido que fica na Itália, mais especificamente em
Pisa por isso o nome: Torre de Pisa.
Essa torre tem uma história super interessante, ela foi
construída no século 12 e, por motivos de o solo não ter
sustentação suficiente para aguentar seu peso, ela
começou a tombar.
A estrutura foi então estabilizada só em 2001 após 8
anos de "retrabalho".
Torre de Pisa
Na verdade, uma das correções feita durante o
retrabalho tornou inclinação ainda pior! Assim né, quem
aqui nunca fez uma refatoração que na real tornou o
problema pior, né? Não podemos culpar eles…
Tudo provavelmente começou com alguns erros e
problemas, mas a construtora decidiu ignorá-los e
continuou aumentando a obra em cima desses
problemas.
Torre de Pisa
A torre foi erguida tão rapidamente que esses pequenos
“bugs” na construção acabaram comprometendo toda a
estrutura.
E o mesmo acontecer com softwares.
A diferença é que esses bugs são mais visíveis durante
o processo de desenvolvimento, porque, depois de
algum tempo, tudo começa a ser mais difícil de entregar
até que os bugs sejam resolvidos.
Produto
Quem é responsável?
Se pensar, somos levados a pensar que isso é um problema do time de pessoas
técnicas, ou seja, de pessoas desenvolvedoras, que foram responsáveis por escrever o
código que causou tudo isso.
Um software é o resultado da estrutura e dos
processos da empresa inteira.
Quem é responsável?
Algumas vezes os gargalos e problemas vêm de diferentes partes da sua empresa.
- Time de Gerência vs Velocidade do Time de Desenvolvimento
- Time de Produto pode não ter um plano a longo prazo
- Time de UI/UX pode estar muito distante das pessoas desenvolvedoras
E também não podemos esquecer que às vezes nós precisamos nos culpar pelas má
decisões.
- Nossas má-decisões contam
- Síntomas de Frameworks
- Baixa cobertura de testes
O que é dívida
técnica?01
Descreve a dívida que a equipe de
desenvolvimento assume quando escolhe
um design ou abordagem fácil de
implementar no curto prazo mas com
grande impacto negativo no longo prazo.
O que é dívida técnica?
O que você tem no seu software é DÍVIDA TÉCNICA!
Não existe débito técnico!
O que é dívida técnica?
Dívida Técnica (DT) / Technical Debt (TD)
Ward Cunningan e a alegoria do empréstimo bancário
Ward Cunningham desenvolvedor da primeira wiki, criou esta metáfora chamada Debt
Metaphor.
Introduzida em um relato de experiência no OOPSLA 1992 onde o débito técnico de um
projeto é como se endividar, decisão que pode acelerar o desenvolvimento e entregas
em determinados momentos, mas que deve ser seguido de resgates e quitação.
O que é dívida técnica?
Sem executar os devidos refatoramentos para reduzir o endividamento, podemos
perder o controle e esta dívida não mitigada pode acumular, dívida sobre dívida,
colocando em risco todo o projeto.
Debt Metaphor
O que é dívida técnica?
Steve McConnell classificou a dívida técnica em dois tipos,
Sem querer – Desenvolvedores junior escrevem código de baixa qualidade por conta de
sua inexperiência técnica.
Intencional - A equipe faz uma decisão consciente para otimizar para o momento atual
e não para o futuro, fazendo algumas escolhas de design que podem ser uma maneira
rápida e de baixa qualidade para resolver a situação.
O que é dívida técnica?
Alejandro Olchik e a alegoria do Restaurante
Débito técnico equivale a um restaurante optar por ser mais “ágil” abrindo mão de
perder tempo em lavar a louça que suja na cozinha e durante o atendimento, vai chegar
uma hora em que não terá mais louça para fazer os pratos ou atender os clientes.
Se não tomar o cuidado de manter a cozinha, louça e instalações limpas, esta decisão
oportunista começará a gerar problemas de forma cumulativa e chegará uma hora em
que sua operação será paralisada porque de tanto acumular chega-se à inflexão.
O que é dívida técnica?
Uncle Bob, adiciona que muitas vezes um código bagunçado é considerada dívida
técnica. Mas isso está errado. Segundo ele,bagunça não é dívida técnica.
Bagunça é só bagunça.
Decisões que geram dívidas técnicas se baseiam em restrições do projeto. Elas são
arriscadas, mas podem trazer benefícios.
A decisão de fazer uma bagunça no código nunca é racional; é sempre baseada na
preguiça e na falta de profissionalismo e não têm chances de ser pagas no futuro. A
bagunça é sempre uma perda.
O que é dívida técnica?
Martin Fowler e seu canvas da dívida técnica
Uma canvas de mapeamento e planejamento de riscos, quando sob controle é o mesmo
canvas – Probabilidade x Impacto.
Mas Martin Fowler propõe uma nova perspectiva visual – Domínio (conhecimento
prévio) x Risco (prudência).
Fowler propôs uma canvas para diagnosticar dívida técnica que busca explicitar os
fundamentos ou explicações racionais acordadas que o originam, explicitando ser
aconteceu(rá) por pressa ou conveniência, um risco calculado ou desconhecido.
4 tipos de Dívida Técnica
Irresponsável Prudente
Sem querer
Proposital
O time não tem tempo para o design e
utiliza uma solução rápida e com
pouca preocupação com a qualidade.
O time precisa entregar o produto
agora com todas as limitações
conhecidas e assume de maneira pró-
ativa as consequências.
O time não tem consciência dos
princípios básico de design e então
nem sequer imagina a bagunça que
estão adicionando.
Isso é verdade para times com
excelentes arquitetos. Eles fornecem
uma solução que agrega valor ao
negócio, mas depois de completar a
solução, eles entendem que a
abordagem de design poderia ter sido
melhor.
Confira em martinfowler.com/bliki/TechnicalDebtQuadrant.html
Design LinhaPayoff
Confira em martinfowler.com/bliki/DesignStaminaHypothesis.html
O que é
Compatibilidade
Retroativa?
Um produto que este possui compatibilidade
reversa, compatibilidade descendente ou
retrocompatibilidade quando é capaz de assumir o
lugar de um produto mais antigo, interagindo com
outros produtos que foram desenhados para
funcionar com a versão anterior
02
CompatibilidadeRetroativa (CR)
Interoperabilidade baseada no tempo
- Manter-se interoperável com um sistema legado mais antigo, geralmente uma versão
mais antiga de si mesmo
Quebrando mudanças
- Mudanças que quebram a cadeia de compatibilidade
CompatibilidadeRetroativa (CR)- É sobrea interface
Mudanças de interface são mudanças significativas (Breaking Changes)
- Você pára de cumprir o contrato que tinha com seus usuários
O código por trás das interfaces é uma caixa preta
- As mudanças de implementação estão corretas se as interfaces permanecerem
intactas
Por que issoé importante?
Mais fácil de desenvolver contra
- Evita a sensação de estar codificando contra um alvo em movimento
Aumenta a confiança
- As pessoas confiam no projeto por um tempo sem quebrar aleatoriamente
Ideal para usuários finais
- Migrar em uma mudança significativa requer proficiência técnica
Por que nem tudo é completamente CR?
Compatibilidade com versões anteriores impede a inovação
- Não há lugar para "mudança perturbadora" se as coisas precisarem permanecer as
mesmas
Compatibilidade com versões anteriores é difícil
- Cada mudança requer consideração cuidadosa e testes extensivos
Compatibilidade com versões anteriores bloqueia você do novo brilho
- Adotar mudanças importantes, não importa o quão benéfico seja, não é uma opção
Como eles se
relacionam?03
É inevitável que tenhamos que
decidir como chegar nos tais prazos
e essas decisões geralmente giram
em torno de sacrifícios...
O que queremos?
Para nossos usuários
Queremos maximizar a compatibilidade com versões anteriores
Para nossos desenvolvedores
Queremos minimizar a dívida técnica
CR causaDT
Mudanças se transformam em adições
Se você introduzir um novo método, você precisa manter o antigo por perto, que se
transforma em pura dívida
Exclusões se transformam em mudanças
Em vez de remover um método não utilizado, você precisa descontinuá-lo (depreciá-lo)
Bugs se transformam em recursos
Em vez de corrigir um bug, pode ser necessário documentar e mantê-lo, pois o código
de terceiros pode depender dele
CompatibilidadeFutura
Mudança é inevitável
Ao planejar um projeto, os requisitos devem sempre incluir a dimensão "tempo"
Antecipar necessidades futuras
Planejar com antecedência e incluir pontos de extensão necessários no futuro evita DT
VersãoSemântica
3.1.7
<major> . <minor> . <patch>
VersãoSemântica
– 3 (Major) – controle de compatibilidade. Informa que existem funcionalidades/códigos
incompatíveis com as versões anteriores.
– 1 (Minor) – controle de funcionalidade. Informa que novas funcionalidades foram
adicionadas ao código.
– 7 (Patch) – controle de correção de bugs. Informa que um ou mais erros foram
identificados e corrigidos.
– Pré-release – versão candidata. É uma versão com algumas instabilidades pois pode
ter incompatibilidades no pacote.
Efeito do versionamentosemântico
O que isso
significa para o
WordPress? 04
WP acumulaalgumas DT
WP acumulaalgumas DT
Asinterfaces WP não sãoexplícitas
O WordPress geralmente não define uma API estrita
Uma grande quantidade de código está disponível, e os desenvolvedores fazem uso
desse código
Interface implícita
Quando nenhuma Interface explícita é definida, todo o código se torna a interface
implícita
Conclusão:
Qualquer mudança no código é uma mudança radical
Os requisitos do WP estão crescendo
As necessidades de compatibilidade com versões anteriores são requisitos
Eles precisam ser levados em consideração ao discutir mudanças ou recursos de
planejamento
Escala enorme
- Base de código de 15 anos com suporte para 12 anos de versões PHP e múltiplas
iterações da linguagem JavaScript
- Todos os patches de segurança com backport em 13 versões principais
Conflitosde requisitos
O relógio está
correndo!
Cada mudança está se tornando cada vez mais cara.
Dívida técnica descontrolada eventualmente leva a
→ Falência Técnica!
Como podemos
melhorar isso ?05
Soluçõessustentáveis
I.M.P.A.C.T
O IMPACT é um processo de:
Identificar
Marcar
Planejar
Agir
Testar
Soluçõessustentáveis
I.M.P.A.C.T
Como podemos ver, o primeiro passo é sobre encontrar os pontos de débito dívida
técnica e, no segundo passo, precisamos ter certeza que esses pontos estão visíveis
para todo o time.
Podemos fazer isso através da criação tarefas marcadas como Débito Técnico Dívida
Técnica, por exemplo.
Soluçõessustentáveis
I.M.P.A.C.T
E nós também podemos escolher prioridades nessas tarefas baseados na relevância.
Ferramentas como o Jira têm mecanismos para aumentar essa prioridade de acordo
com o tempo, o que é incrível pois, como vimos anteriormente, o custo do débito técnico
da dívida técnica também aumenta ao longo o tempo.
Soluçõessustentáveis
Você pode encontrar informações mais detalhadas
no livro "Refactoring for Software Design Smells
Managing Technical Debt".
Soluçõessustentáveis
Princípio de Pareto
Para caso você não saiba quantas tarefas deve
ter a cada iteração do time.
Nós podemos usar o princípio de Pareto, no qual
20% da produtividade do time é destinada para
as tarefas de débito e o resto dos 80% pode ser
usado para tarefas normais como novos
recursos, correção de bugs e tudo mais.
É lucrativo?
Para este ponto, vou usar uma palestra de
J.B. Rainsberger.
Nela, Rainsberger explica o custo do
próximo novo recurso do seu software e
como você pode diminuir a incerteza de
calcular esse custo.
É lucrativo?
Nesse gráfico ele faz uma comparação dos dois custos ao longo do tempo do projeto.
Apesar de que a proposta de se começar pensando em design de arquitetura e tudo
mais tenha um custo bem mais alto no início, podemos ver que esse custo é mitigado ao
longo do tempo se comparado com a outra abordagem.
Ao longo do tempo o custo do próximo recurso sem se pensar em design se torna tão
grande que se a gente parasse tudo e fosse refazer tudo do zero valeria mais a pena.
É lucrativo?
Se você atualmente está escrevendo seu software dessa forma, você está apostando
que o projeto vai acabar antes da linha pontilhada chegar.
E a parte mais difícil disso tudo é que nós não temos idéia de quando esse momento vai
chegar, ele pode ser em 3 meses, um ano, 10 anos… Nós não sabemos.
Softwares de baixa qualidade tornou-se um
dos tópicos mais caros da história da
humanidade.
2.84 Trilhões de Dólares
- Custo de baixa qualidade de software
CISQ divulgou um relatório sobre os custos de software nos EUA
Além do Lucro
Além do gasto excessivo de dinheiro e das entregas mais lentas existem várias outros
problemas que podemos identificar que são causados apenas por trabalhar com um
nível alto de débito.
O débito técnico traz muito peso às nossas vidas. Se você está constantemente lidando
com códigos problemáticos, uma tarefa que parece fácil de se concluir pode se
transformar em um verdadeiro monstro.
Ansiedade e Depressão
É comum ter receios em fazer mudanças, ainda mais se você é novo no projeto. As
reuniões de planejamento podem se tornar intermináveis uma vez que a equipe de
desenvolvimento precisa discutir com a equipe de gerência do projeto para explicar o
quão difícil é entregar as novas coisas agora.
Começamos a ficar ansiosos porque não sabemos se algo vai surgir com o tempo, algum
grande problema ou um bug difícil de se encontrar no meio de uma sprint.
Quem aqui nunca teve ou ainda tem algum código com algo desatualizado ou não
mantido mais?
Atrofiadashabilidadestécnicas
É um cenário comum para pessoas desenvolvedoras. E é bem complicado de se lidar,
porque nós precisamos aceitar todas as consequências e os problemas que vêm com
isso.
Geralmente o que acontece é que você começa a copiar e colar código de uma
biblioteca ou framework desatualizado e a corrigir os problemas você mesmo. Ou até, às
vezes, você só faz uma cópia do projeto e começa a usar o seu clone.
Atrofiadashabilidadestécnicas
Imagine só como deve ser difícil pra alguma pessoa desenvolvedora ser realocada no
mercado de trabalho depois de passar cinco anos em um framework javascript que não
é mais mantido e então precisa mudar para trabalhar com React ou Vue.js por exemplo.
Muitos conceitos que nós já estamos acostumados a trabalhar podem nem existir numa
ferramenta velha.
Crescimentoproblemático
Não faz sentido a empresa que você trabalha crescer 300% ou 400% ao ano se o seu
time não tiver saúde mental e tempo para trabalhar da melhor forma num tamanho
maior. É bem comum esse cenário em startups que glamourizam horas excessivas
trabalhadas por alguma meta irreal. Aquele pico de vendas do produto no meio da noite
em que você precisou acordar pra levantar algum serviço da aplicação que caiu pela
quantidade de acessos.
Em um mundo realista e respeitável, as máquinas deveriam tomar conta dessas
situações ao invés de colocar toda a pressão nas pessoas envolvidas.
Principais
conclusões 06
Concluindo o que
concluímos.
Dívida Técnica
deve ser evitada
Dívida Técnica
precisa ser "paga"
Compatibilidade Retroativa
deve ser mantida
Compatibilidade Retroativa
cría dívida técnica
Apenas Breaking Changes
podem reduzir substancialmente
Dívida Técnica
→ reduz Dívida Técnica
→ reduz mudanças significativas
Compatibilidade Futura
Pense antes de codificar!
porque cada erro torna seu futuro trabalho mais difícil
Depois de conversar sobre tudo isso.
A Torre de Pisa está sustentável.
Na real essa é uma das raras situações
onde um bug vira feature :)
Palestra inspiradaem uma palestra de AlainSchlesser
Alain Schlesser.
@schlessera
www.alainschlesser.com
Software Engineer
- @WPCLI Maintainer
- @WordPress Core Contributor
- @GoogleDevExpert in Web
Technologies
Obrigado!
Qualquer dúvida, crítica ou sugestão só me
procurar:
@jacksonfdam
jacksonfdam@gmail.com
CRÉDITOS
É aqui que você dá crédito a quem faz parte deste projeto.
Gostou dos recursos deste modelo? Obtenha-os gratuitamente em nossos outros sites.
◂ Presentation template by Slidesgo
◂ Icons by Flaticon
◂ Infographics by Freepik
◂ Images created by Freepik - Freepik
◂ Author introduction slide photo created by Freepik
◂ Text & Image slide photo created by Freepik.com

Mais conteúdo relacionado

Mais procurados

Luís Rasquilha Buzzmedia: Modelo de Satisfacao de Cliente
Luís Rasquilha Buzzmedia: Modelo de Satisfacao de ClienteLuís Rasquilha Buzzmedia: Modelo de Satisfacao de Cliente
Luís Rasquilha Buzzmedia: Modelo de Satisfacao de Cliente
Luis Rasquilha
 
Arquitetura Evolutiva - A retomada do ágil 18 anos depois
Arquitetura Evolutiva - A retomada do ágil 18 anos depoisArquitetura Evolutiva - A retomada do ágil 18 anos depois
Arquitetura Evolutiva - A retomada do ágil 18 anos depois
André Paulovich
 
[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...
[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...
[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...
André Paulovich
 
O futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java EnterpriseO futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java Enterprise
Globalcode
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
Luciano Almeida
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
Hélio Medeiros
 
Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
Leandro Silva
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
Adriano Bertucci
 
APS - RAD x Ágeis
APS - RAD x ÁgeisAPS - RAD x Ágeis
APS - RAD x Ágeis
Silvio Carréra
 
O Papel do Product Owner
O Papel do Product OwnerO Papel do Product Owner
O Papel do Product Owner
Marcia Maia
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
Mauricio Cesar Santos da Purificação
 
Treinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATELTreinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATEL
Daniel Calmazini
 
Scrum - Primeiros Passos - Curso de Férias Fatec Praia Grande
Scrum - Primeiros Passos - Curso de Férias Fatec Praia GrandeScrum - Primeiros Passos - Curso de Férias Fatec Praia Grande
Scrum - Primeiros Passos - Curso de Férias Fatec Praia Grande
Gabriel Rubens
 
Automação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégiasAutomação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégias
Kleitor Franklint Correa Araujo
 
Introdução a Engenharia de Software.pdf
Introdução a Engenharia de Software.pdfIntrodução a Engenharia de Software.pdf
Introdução a Engenharia de Software.pdf
IvanFontainha
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
Daniel Cukier
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Ricardo Bánffy
 
Implementing lean software development
Implementing lean software developmentImplementing lean software development
Implementing lean software development
Luiz Faias Junior
 
Introdução ao Scrum
Introdução ao ScrumIntrodução ao Scrum
Introdução ao Scrum
Giovanni Bassi
 
Qualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual StudioQualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual Studio
Adriano Bertucci
 

Mais procurados (20)

Luís Rasquilha Buzzmedia: Modelo de Satisfacao de Cliente
Luís Rasquilha Buzzmedia: Modelo de Satisfacao de ClienteLuís Rasquilha Buzzmedia: Modelo de Satisfacao de Cliente
Luís Rasquilha Buzzmedia: Modelo de Satisfacao de Cliente
 
Arquitetura Evolutiva - A retomada do ágil 18 anos depois
Arquitetura Evolutiva - A retomada do ágil 18 anos depoisArquitetura Evolutiva - A retomada do ágil 18 anos depois
Arquitetura Evolutiva - A retomada do ágil 18 anos depois
 
[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...
[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...
[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...
 
O futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java EnterpriseO futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java Enterprise
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
 
Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
APS - RAD x Ágeis
APS - RAD x ÁgeisAPS - RAD x Ágeis
APS - RAD x Ágeis
 
O Papel do Product Owner
O Papel do Product OwnerO Papel do Product Owner
O Papel do Product Owner
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Treinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATELTreinamento - Product Owner - CLARO-NET-EMBRATEL
Treinamento - Product Owner - CLARO-NET-EMBRATEL
 
Scrum - Primeiros Passos - Curso de Férias Fatec Praia Grande
Scrum - Primeiros Passos - Curso de Férias Fatec Praia GrandeScrum - Primeiros Passos - Curso de Férias Fatec Praia Grande
Scrum - Primeiros Passos - Curso de Férias Fatec Praia Grande
 
Automação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégiasAutomação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégias
 
Introdução a Engenharia de Software.pdf
Introdução a Engenharia de Software.pdfIntrodução a Engenharia de Software.pdf
Introdução a Engenharia de Software.pdf
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Implementing lean software development
Implementing lean software developmentImplementing lean software development
Implementing lean software development
 
Introdução ao Scrum
Introdução ao ScrumIntrodução ao Scrum
Introdução ao Scrum
 
Qualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual StudioQualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual Studio
 

Semelhante a PHP Conference 2020 - A eterna luta: compatibilidade retroativa vs. dívida técnica

Dívida técnica por gustavo cocina
Dívida técnica por gustavo cocinaDívida técnica por gustavo cocina
Dívida técnica por gustavo cocina
Gustavo Cocina
 
2023-05 Warren Talks: Technical Debts 101
2023-05 Warren Talks: Technical Debts 1012023-05 Warren Talks: Technical Debts 101
2023-05 Warren Talks: Technical Debts 101
Felipe Coelho Machado
 
Introdução às metodologias ágeis de desenvolvimento de software
Introdução às metodologias ágeis de desenvolvimento de softwareIntrodução às metodologias ágeis de desenvolvimento de software
Introdução às metodologias ágeis de desenvolvimento de software
Jaime Schettini
 
Introdução às metodologias ágeis
Introdução às metodologias ágeisIntrodução às metodologias ágeis
Introdução às metodologias ágeis
Comunidade Tá safo!
 
[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?
[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?
[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?
Rafael Burity
 
Scrum - Uma rapida visão
Scrum - Uma rapida visãoScrum - Uma rapida visão
Scrum - Uma rapida visão
Rafael Vinicius Kuhn Toebe
 
Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)
Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)
Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)
André Paulovich
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
Rodrigo Branas
 
Refactoring
RefactoringRefactoring
Refactoring
Rodrigo Branas
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e devel
Jose Augusto Carvalho
 
Responsive wordpress
Responsive wordpressResponsive wordpress
Responsive wordpress
Jackson F. de A. Mafra
 
Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...
Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...
Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...
REVIE Inteligencia Empresarial
 
Mitos do Desenvolvimento de Software
Mitos do Desenvolvimento de SoftwareMitos do Desenvolvimento de Software
Mitos do Desenvolvimento de Software
guest2f8cba
 
Projeto Digital para Empreendedores
Projeto Digital para EmpreendedoresProjeto Digital para Empreendedores
Projeto Digital para Empreendedores
Thiago Nunes
 
UOL HOST: Diplomacy for a good experience
UOL HOST:  Diplomacy for a good experience UOL HOST:  Diplomacy for a good experience
UOL HOST: Diplomacy for a good experience
Lu Terceiro
 
Scrum e a Crise Mundial
Scrum e a Crise MundialScrum e a Crise Mundial
Scrum e a Crise Mundial
scrumability
 
Mobile UX - MobileConf 2014 - RJ
Mobile UX - MobileConf 2014 - RJMobile UX - MobileConf 2014 - RJ
Mobile UX - MobileConf 2014 - RJ
Horácio Soares
 
UOL HOST: diplomacia por uma boa experiência
UOL HOST: diplomacia por uma boa experiênciaUOL HOST: diplomacia por uma boa experiência
UOL HOST: diplomacia por uma boa experiência
Íris Jacomino
 
Engenharia de Software I - Aula 8
Engenharia de Software I - Aula 8Engenharia de Software I - Aula 8
Engenharia de Software I - Aula 8
Alessandro Almeida
 
TDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágil
TDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágilTDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágil
TDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágil
André Paulovich
 

Semelhante a PHP Conference 2020 - A eterna luta: compatibilidade retroativa vs. dívida técnica (20)

Dívida técnica por gustavo cocina
Dívida técnica por gustavo cocinaDívida técnica por gustavo cocina
Dívida técnica por gustavo cocina
 
2023-05 Warren Talks: Technical Debts 101
2023-05 Warren Talks: Technical Debts 1012023-05 Warren Talks: Technical Debts 101
2023-05 Warren Talks: Technical Debts 101
 
Introdução às metodologias ágeis de desenvolvimento de software
Introdução às metodologias ágeis de desenvolvimento de softwareIntrodução às metodologias ágeis de desenvolvimento de software
Introdução às metodologias ágeis de desenvolvimento de software
 
Introdução às metodologias ágeis
Introdução às metodologias ágeisIntrodução às metodologias ágeis
Introdução às metodologias ágeis
 
[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?
[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?
[GDGSP] android meetup #67 | Realmente preciso de ux no projeto mobile?
 
Scrum - Uma rapida visão
Scrum - Uma rapida visãoScrum - Uma rapida visão
Scrum - Uma rapida visão
 
Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)
Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)
Arquitetura evolutiva - Arquitetura ágil (TDC FLORIPA 2023)
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
 
Refactoring
RefactoringRefactoring
Refactoring
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e devel
 
Responsive wordpress
Responsive wordpressResponsive wordpress
Responsive wordpress
 
Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...
Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...
Artigo: Erros no Gerenciamento de Projetos de Inteligência Competitiva - Dani...
 
Mitos do Desenvolvimento de Software
Mitos do Desenvolvimento de SoftwareMitos do Desenvolvimento de Software
Mitos do Desenvolvimento de Software
 
Projeto Digital para Empreendedores
Projeto Digital para EmpreendedoresProjeto Digital para Empreendedores
Projeto Digital para Empreendedores
 
UOL HOST: Diplomacy for a good experience
UOL HOST:  Diplomacy for a good experience UOL HOST:  Diplomacy for a good experience
UOL HOST: Diplomacy for a good experience
 
Scrum e a Crise Mundial
Scrum e a Crise MundialScrum e a Crise Mundial
Scrum e a Crise Mundial
 
Mobile UX - MobileConf 2014 - RJ
Mobile UX - MobileConf 2014 - RJMobile UX - MobileConf 2014 - RJ
Mobile UX - MobileConf 2014 - RJ
 
UOL HOST: diplomacia por uma boa experiência
UOL HOST: diplomacia por uma boa experiênciaUOL HOST: diplomacia por uma boa experiência
UOL HOST: diplomacia por uma boa experiência
 
Engenharia de Software I - Aula 8
Engenharia de Software I - Aula 8Engenharia de Software I - Aula 8
Engenharia de Software I - Aula 8
 
TDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágil
TDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágilTDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágil
TDC BH 2019 - Arquitetura Evolutiva - Segredo da arquitetura ágil
 

Mais de Jackson F. de A. Mafra

PHP SSO no Zentyal
PHP SSO no ZentyalPHP SSO no Zentyal
PHP SSO no Zentyal
Jackson F. de A. Mafra
 
Phprs meetup - deploys automatizados com gitlab
Phprs   meetup - deploys automatizados com gitlabPhprs   meetup - deploys automatizados com gitlab
Phprs meetup - deploys automatizados com gitlab
Jackson F. de A. Mafra
 
O que você precisa saber sobre chatbots
O que você precisa saber sobre chatbotsO que você precisa saber sobre chatbots
O que você precisa saber sobre chatbots
Jackson F. de A. Mafra
 
WCPOA2019 - WordPress como um backend de seus aplicativos
WCPOA2019  - WordPress como um backend de seus aplicativosWCPOA2019  - WordPress como um backend de seus aplicativos
WCPOA2019 - WordPress como um backend de seus aplicativos
Jackson F. de A. Mafra
 
WordPress como um backend de seus aplicativos
WordPress como um backend de seus aplicativosWordPress como um backend de seus aplicativos
WordPress como um backend de seus aplicativos
Jackson F. de A. Mafra
 
The Ultimate Guide to Development in WordPress
The Ultimate Guide to Development in WordPressThe Ultimate Guide to Development in WordPress
The Ultimate Guide to Development in WordPress
Jackson F. de A. Mafra
 
Precisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicaçõesPrecisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicações
Jackson F. de A. Mafra
 
Hangout Tempo Real Eventos - ChatOps (ChatBots e DevOps) - Como bots podem ...
Hangout  Tempo Real Eventos - ChatOps (ChatBots e DevOps)  - Como bots podem ...Hangout  Tempo Real Eventos - ChatOps (ChatBots e DevOps)  - Como bots podem ...
Hangout Tempo Real Eventos - ChatOps (ChatBots e DevOps) - Como bots podem ...
Jackson F. de A. Mafra
 
Hangout Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...
Hangout  Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...Hangout  Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...
Hangout Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...
Jackson F. de A. Mafra
 
Hangout Tempo Real Eventos - Javascript - Os Primeiros Passos
Hangout  Tempo Real Eventos - Javascript - Os Primeiros PassosHangout  Tempo Real Eventos - Javascript - Os Primeiros Passos
Hangout Tempo Real Eventos - Javascript - Os Primeiros Passos
Jackson F. de A. Mafra
 
Hangout Tempo Real Eventos - Nodejs - Os Primeiros Passos
Hangout  Tempo Real Eventos - Nodejs - Os Primeiros PassosHangout  Tempo Real Eventos - Nodejs - Os Primeiros Passos
Hangout Tempo Real Eventos - Nodejs - Os Primeiros Passos
Jackson F. de A. Mafra
 
Desmistificando o DialogFlow
Desmistificando o DialogFlowDesmistificando o DialogFlow
Desmistificando o DialogFlow
Jackson F. de A. Mafra
 
ChatOps (ChatBots + DevOps)
ChatOps (ChatBots + DevOps) ChatOps (ChatBots + DevOps)
ChatOps (ChatBots + DevOps)
Jackson F. de A. Mafra
 
Conexao kinghost - Vendas inteligentes com intelibots
Conexao kinghost - Vendas inteligentes com intelibotsConexao kinghost - Vendas inteligentes com intelibots
Conexao kinghost - Vendas inteligentes com intelibots
Jackson F. de A. Mafra
 
WoMakersCode 2016 - Shit Happens
WoMakersCode 2016 -  Shit HappensWoMakersCode 2016 -  Shit Happens
WoMakersCode 2016 - Shit Happens
Jackson F. de A. Mafra
 
Phalcon 2 High Performance APIs - DevWeekPOA 2015
Phalcon 2 High Performance APIs - DevWeekPOA 2015Phalcon 2 High Performance APIs - DevWeekPOA 2015
Phalcon 2 High Performance APIs - DevWeekPOA 2015
Jackson F. de A. Mafra
 
Dev Heroes
Dev HeroesDev Heroes
Trilha Android - Android Evolved
Trilha Android - Android EvolvedTrilha Android - Android Evolved
Trilha Android - Android Evolved
Jackson F. de A. Mafra
 
TDC 2015 - POA - Trilha PHP - Shit Happens
TDC 2015 - POA - Trilha PHP - Shit HappensTDC 2015 - POA - Trilha PHP - Shit Happens
TDC 2015 - POA - Trilha PHP - Shit Happens
Jackson F. de A. Mafra
 
Material design
Material designMaterial design
Material design
Jackson F. de A. Mafra
 

Mais de Jackson F. de A. Mafra (20)

PHP SSO no Zentyal
PHP SSO no ZentyalPHP SSO no Zentyal
PHP SSO no Zentyal
 
Phprs meetup - deploys automatizados com gitlab
Phprs   meetup - deploys automatizados com gitlabPhprs   meetup - deploys automatizados com gitlab
Phprs meetup - deploys automatizados com gitlab
 
O que você precisa saber sobre chatbots
O que você precisa saber sobre chatbotsO que você precisa saber sobre chatbots
O que você precisa saber sobre chatbots
 
WCPOA2019 - WordPress como um backend de seus aplicativos
WCPOA2019  - WordPress como um backend de seus aplicativosWCPOA2019  - WordPress como um backend de seus aplicativos
WCPOA2019 - WordPress como um backend de seus aplicativos
 
WordPress como um backend de seus aplicativos
WordPress como um backend de seus aplicativosWordPress como um backend de seus aplicativos
WordPress como um backend de seus aplicativos
 
The Ultimate Guide to Development in WordPress
The Ultimate Guide to Development in WordPressThe Ultimate Guide to Development in WordPress
The Ultimate Guide to Development in WordPress
 
Precisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicaçõesPrecisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicações
 
Hangout Tempo Real Eventos - ChatOps (ChatBots e DevOps) - Como bots podem ...
Hangout  Tempo Real Eventos - ChatOps (ChatBots e DevOps)  - Como bots podem ...Hangout  Tempo Real Eventos - ChatOps (ChatBots e DevOps)  - Como bots podem ...
Hangout Tempo Real Eventos - ChatOps (ChatBots e DevOps) - Como bots podem ...
 
Hangout Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...
Hangout  Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...Hangout  Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...
Hangout Tempo Real Eventos - Android - Os primeiros passos do desenvolviment...
 
Hangout Tempo Real Eventos - Javascript - Os Primeiros Passos
Hangout  Tempo Real Eventos - Javascript - Os Primeiros PassosHangout  Tempo Real Eventos - Javascript - Os Primeiros Passos
Hangout Tempo Real Eventos - Javascript - Os Primeiros Passos
 
Hangout Tempo Real Eventos - Nodejs - Os Primeiros Passos
Hangout  Tempo Real Eventos - Nodejs - Os Primeiros PassosHangout  Tempo Real Eventos - Nodejs - Os Primeiros Passos
Hangout Tempo Real Eventos - Nodejs - Os Primeiros Passos
 
Desmistificando o DialogFlow
Desmistificando o DialogFlowDesmistificando o DialogFlow
Desmistificando o DialogFlow
 
ChatOps (ChatBots + DevOps)
ChatOps (ChatBots + DevOps) ChatOps (ChatBots + DevOps)
ChatOps (ChatBots + DevOps)
 
Conexao kinghost - Vendas inteligentes com intelibots
Conexao kinghost - Vendas inteligentes com intelibotsConexao kinghost - Vendas inteligentes com intelibots
Conexao kinghost - Vendas inteligentes com intelibots
 
WoMakersCode 2016 - Shit Happens
WoMakersCode 2016 -  Shit HappensWoMakersCode 2016 -  Shit Happens
WoMakersCode 2016 - Shit Happens
 
Phalcon 2 High Performance APIs - DevWeekPOA 2015
Phalcon 2 High Performance APIs - DevWeekPOA 2015Phalcon 2 High Performance APIs - DevWeekPOA 2015
Phalcon 2 High Performance APIs - DevWeekPOA 2015
 
Dev Heroes
Dev HeroesDev Heroes
Dev Heroes
 
Trilha Android - Android Evolved
Trilha Android - Android EvolvedTrilha Android - Android Evolved
Trilha Android - Android Evolved
 
TDC 2015 - POA - Trilha PHP - Shit Happens
TDC 2015 - POA - Trilha PHP - Shit HappensTDC 2015 - POA - Trilha PHP - Shit Happens
TDC 2015 - POA - Trilha PHP - Shit Happens
 
Material design
Material designMaterial design
Material design
 

PHP Conference 2020 - A eterna luta: compatibilidade retroativa vs. dívida técnica

  • 1. Jackson Mafra A eterna luta: compatibilidade retroativa vs. dívida técnica
  • 2. Desenvolvedor e Consultor WordPress Desenvolvedor há mais de 20 anos com background em projetos de e-commerce e mercado imobiliário, desde 2009 com interesses focados para o desenvolvimento de interfaces móveis e aplicações corporativas. Me chama lá... http://about.me/jacksonfdam http://linkedin.com/in/jacksonfdam @jacksonfdam Jackson Mafra
  • 3. AGENDA 02 05 03 06 Como eles se relacionam? Principais conclusões O que é dívida técnica? 01 O que isso significa para o WordPress? 04 O que é Compatibilidade Retroativa? Como podemos melhorar isso ?
  • 5. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software O Mítico Homem-Mês: Ensaios Sobre Engenharia de Software (The Mythical Man-Month: Essays on Software Engineering) O argumento central de O Mítico Homem-Mês é o de que grandes projetos de programação sofrem de problemas de gestão cuja natureza difere dos projetos pequenos em função da divisão das tarefas; a integridade conceitual de um produto é um fator crítico em seu desenvolvimento; e que é difícil, mas possível, atingir tal integridade.
  • 6. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software Seu ensaio seminal de 1986, "Não existe bala de prata" também está aqui, complementado por um novo texto da edição de 1995, onde Brooks afirma que "Não haverá nenhuma bala de prata no intervalo de dez anos". Estes dez anos já se passaram e Brooks continua atual.
  • 7. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software Apesar de ser uma obra que teve alguma relevância no passado a edição, mesmo atualizada, não representa nem de perto o modelo atual de gestão. Os exemplos utilizados tem mais de 40 anos, algumas práticas já foram substituídas por métodos ágeis. Talvez num contexto estritamente acadêmico e conceitual faça sentido, mas no dia-a-dia a obra é incapaz de endereçar os problemas de gestão em um ambiente de transformação digital.
  • 8. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software Em mapas mind/mentais.
  • 9. Torre de Pisa Como você pode ver, esse é um monumento super conhecido que fica na Itália, mais especificamente em Pisa por isso o nome: Torre de Pisa. Essa torre tem uma história super interessante, ela foi construída no século 12 e, por motivos de o solo não ter sustentação suficiente para aguentar seu peso, ela começou a tombar. A estrutura foi então estabilizada só em 2001 após 8 anos de "retrabalho".
  • 10. Torre de Pisa Na verdade, uma das correções feita durante o retrabalho tornou inclinação ainda pior! Assim né, quem aqui nunca fez uma refatoração que na real tornou o problema pior, né? Não podemos culpar eles… Tudo provavelmente começou com alguns erros e problemas, mas a construtora decidiu ignorá-los e continuou aumentando a obra em cima desses problemas.
  • 11. Torre de Pisa A torre foi erguida tão rapidamente que esses pequenos “bugs” na construção acabaram comprometendo toda a estrutura. E o mesmo acontecer com softwares. A diferença é que esses bugs são mais visíveis durante o processo de desenvolvimento, porque, depois de algum tempo, tudo começa a ser mais difícil de entregar até que os bugs sejam resolvidos.
  • 13. Quem é responsável? Se pensar, somos levados a pensar que isso é um problema do time de pessoas técnicas, ou seja, de pessoas desenvolvedoras, que foram responsáveis por escrever o código que causou tudo isso.
  • 14. Um software é o resultado da estrutura e dos processos da empresa inteira.
  • 15. Quem é responsável? Algumas vezes os gargalos e problemas vêm de diferentes partes da sua empresa. - Time de Gerência vs Velocidade do Time de Desenvolvimento - Time de Produto pode não ter um plano a longo prazo - Time de UI/UX pode estar muito distante das pessoas desenvolvedoras E também não podemos esquecer que às vezes nós precisamos nos culpar pelas má decisões. - Nossas má-decisões contam - Síntomas de Frameworks - Baixa cobertura de testes
  • 16. O que é dívida técnica?01 Descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo.
  • 17. O que é dívida técnica? O que você tem no seu software é DÍVIDA TÉCNICA! Não existe débito técnico!
  • 18. O que é dívida técnica? Dívida Técnica (DT) / Technical Debt (TD) Ward Cunningan e a alegoria do empréstimo bancário Ward Cunningham desenvolvedor da primeira wiki, criou esta metáfora chamada Debt Metaphor. Introduzida em um relato de experiência no OOPSLA 1992 onde o débito técnico de um projeto é como se endividar, decisão que pode acelerar o desenvolvimento e entregas em determinados momentos, mas que deve ser seguido de resgates e quitação.
  • 19. O que é dívida técnica? Sem executar os devidos refatoramentos para reduzir o endividamento, podemos perder o controle e esta dívida não mitigada pode acumular, dívida sobre dívida, colocando em risco todo o projeto.
  • 21. O que é dívida técnica? Steve McConnell classificou a dívida técnica em dois tipos, Sem querer – Desenvolvedores junior escrevem código de baixa qualidade por conta de sua inexperiência técnica. Intencional - A equipe faz uma decisão consciente para otimizar para o momento atual e não para o futuro, fazendo algumas escolhas de design que podem ser uma maneira rápida e de baixa qualidade para resolver a situação.
  • 22. O que é dívida técnica? Alejandro Olchik e a alegoria do Restaurante Débito técnico equivale a um restaurante optar por ser mais “ágil” abrindo mão de perder tempo em lavar a louça que suja na cozinha e durante o atendimento, vai chegar uma hora em que não terá mais louça para fazer os pratos ou atender os clientes. Se não tomar o cuidado de manter a cozinha, louça e instalações limpas, esta decisão oportunista começará a gerar problemas de forma cumulativa e chegará uma hora em que sua operação será paralisada porque de tanto acumular chega-se à inflexão.
  • 23. O que é dívida técnica? Uncle Bob, adiciona que muitas vezes um código bagunçado é considerada dívida técnica. Mas isso está errado. Segundo ele,bagunça não é dívida técnica. Bagunça é só bagunça. Decisões que geram dívidas técnicas se baseiam em restrições do projeto. Elas são arriscadas, mas podem trazer benefícios. A decisão de fazer uma bagunça no código nunca é racional; é sempre baseada na preguiça e na falta de profissionalismo e não têm chances de ser pagas no futuro. A bagunça é sempre uma perda.
  • 24. O que é dívida técnica? Martin Fowler e seu canvas da dívida técnica Uma canvas de mapeamento e planejamento de riscos, quando sob controle é o mesmo canvas – Probabilidade x Impacto. Mas Martin Fowler propõe uma nova perspectiva visual – Domínio (conhecimento prévio) x Risco (prudência). Fowler propôs uma canvas para diagnosticar dívida técnica que busca explicitar os fundamentos ou explicações racionais acordadas que o originam, explicitando ser aconteceu(rá) por pressa ou conveniência, um risco calculado ou desconhecido.
  • 25. 4 tipos de Dívida Técnica Irresponsável Prudente Sem querer Proposital O time não tem tempo para o design e utiliza uma solução rápida e com pouca preocupação com a qualidade. O time precisa entregar o produto agora com todas as limitações conhecidas e assume de maneira pró- ativa as consequências. O time não tem consciência dos princípios básico de design e então nem sequer imagina a bagunça que estão adicionando. Isso é verdade para times com excelentes arquitetos. Eles fornecem uma solução que agrega valor ao negócio, mas depois de completar a solução, eles entendem que a abordagem de design poderia ter sido melhor. Confira em martinfowler.com/bliki/TechnicalDebtQuadrant.html
  • 26. Design LinhaPayoff Confira em martinfowler.com/bliki/DesignStaminaHypothesis.html
  • 27. O que é Compatibilidade Retroativa? Um produto que este possui compatibilidade reversa, compatibilidade descendente ou retrocompatibilidade quando é capaz de assumir o lugar de um produto mais antigo, interagindo com outros produtos que foram desenhados para funcionar com a versão anterior 02
  • 28. CompatibilidadeRetroativa (CR) Interoperabilidade baseada no tempo - Manter-se interoperável com um sistema legado mais antigo, geralmente uma versão mais antiga de si mesmo Quebrando mudanças - Mudanças que quebram a cadeia de compatibilidade
  • 29. CompatibilidadeRetroativa (CR)- É sobrea interface Mudanças de interface são mudanças significativas (Breaking Changes) - Você pára de cumprir o contrato que tinha com seus usuários O código por trás das interfaces é uma caixa preta - As mudanças de implementação estão corretas se as interfaces permanecerem intactas
  • 30. Por que issoé importante? Mais fácil de desenvolver contra - Evita a sensação de estar codificando contra um alvo em movimento Aumenta a confiança - As pessoas confiam no projeto por um tempo sem quebrar aleatoriamente Ideal para usuários finais - Migrar em uma mudança significativa requer proficiência técnica
  • 31. Por que nem tudo é completamente CR? Compatibilidade com versões anteriores impede a inovação - Não há lugar para "mudança perturbadora" se as coisas precisarem permanecer as mesmas Compatibilidade com versões anteriores é difícil - Cada mudança requer consideração cuidadosa e testes extensivos Compatibilidade com versões anteriores bloqueia você do novo brilho - Adotar mudanças importantes, não importa o quão benéfico seja, não é uma opção
  • 32. Como eles se relacionam?03 É inevitável que tenhamos que decidir como chegar nos tais prazos e essas decisões geralmente giram em torno de sacrifícios...
  • 33. O que queremos? Para nossos usuários Queremos maximizar a compatibilidade com versões anteriores Para nossos desenvolvedores Queremos minimizar a dívida técnica
  • 34. CR causaDT Mudanças se transformam em adições Se você introduzir um novo método, você precisa manter o antigo por perto, que se transforma em pura dívida Exclusões se transformam em mudanças Em vez de remover um método não utilizado, você precisa descontinuá-lo (depreciá-lo) Bugs se transformam em recursos Em vez de corrigir um bug, pode ser necessário documentar e mantê-lo, pois o código de terceiros pode depender dele
  • 35. CompatibilidadeFutura Mudança é inevitável Ao planejar um projeto, os requisitos devem sempre incluir a dimensão "tempo" Antecipar necessidades futuras Planejar com antecedência e incluir pontos de extensão necessários no futuro evita DT
  • 37. VersãoSemântica – 3 (Major) – controle de compatibilidade. Informa que existem funcionalidades/códigos incompatíveis com as versões anteriores. – 1 (Minor) – controle de funcionalidade. Informa que novas funcionalidades foram adicionadas ao código. – 7 (Patch) – controle de correção de bugs. Informa que um ou mais erros foram identificados e corrigidos. – Pré-release – versão candidata. É uma versão com algumas instabilidades pois pode ter incompatibilidades no pacote.
  • 39. O que isso significa para o WordPress? 04
  • 42. Asinterfaces WP não sãoexplícitas O WordPress geralmente não define uma API estrita Uma grande quantidade de código está disponível, e os desenvolvedores fazem uso desse código Interface implícita Quando nenhuma Interface explícita é definida, todo o código se torna a interface implícita Conclusão: Qualquer mudança no código é uma mudança radical
  • 43. Os requisitos do WP estão crescendo As necessidades de compatibilidade com versões anteriores são requisitos Eles precisam ser levados em consideração ao discutir mudanças ou recursos de planejamento Escala enorme - Base de código de 15 anos com suporte para 12 anos de versões PHP e múltiplas iterações da linguagem JavaScript - Todos os patches de segurança com backport em 13 versões principais
  • 45. O relógio está correndo! Cada mudança está se tornando cada vez mais cara. Dívida técnica descontrolada eventualmente leva a → Falência Técnica!
  • 47. Soluçõessustentáveis I.M.P.A.C.T O IMPACT é um processo de: Identificar Marcar Planejar Agir Testar
  • 48. Soluçõessustentáveis I.M.P.A.C.T Como podemos ver, o primeiro passo é sobre encontrar os pontos de débito dívida técnica e, no segundo passo, precisamos ter certeza que esses pontos estão visíveis para todo o time. Podemos fazer isso através da criação tarefas marcadas como Débito Técnico Dívida Técnica, por exemplo.
  • 49. Soluçõessustentáveis I.M.P.A.C.T E nós também podemos escolher prioridades nessas tarefas baseados na relevância. Ferramentas como o Jira têm mecanismos para aumentar essa prioridade de acordo com o tempo, o que é incrível pois, como vimos anteriormente, o custo do débito técnico da dívida técnica também aumenta ao longo o tempo.
  • 50. Soluçõessustentáveis Você pode encontrar informações mais detalhadas no livro "Refactoring for Software Design Smells Managing Technical Debt".
  • 51. Soluçõessustentáveis Princípio de Pareto Para caso você não saiba quantas tarefas deve ter a cada iteração do time. Nós podemos usar o princípio de Pareto, no qual 20% da produtividade do time é destinada para as tarefas de débito e o resto dos 80% pode ser usado para tarefas normais como novos recursos, correção de bugs e tudo mais.
  • 52. É lucrativo? Para este ponto, vou usar uma palestra de J.B. Rainsberger. Nela, Rainsberger explica o custo do próximo novo recurso do seu software e como você pode diminuir a incerteza de calcular esse custo.
  • 53. É lucrativo? Nesse gráfico ele faz uma comparação dos dois custos ao longo do tempo do projeto. Apesar de que a proposta de se começar pensando em design de arquitetura e tudo mais tenha um custo bem mais alto no início, podemos ver que esse custo é mitigado ao longo do tempo se comparado com a outra abordagem. Ao longo do tempo o custo do próximo recurso sem se pensar em design se torna tão grande que se a gente parasse tudo e fosse refazer tudo do zero valeria mais a pena.
  • 54. É lucrativo? Se você atualmente está escrevendo seu software dessa forma, você está apostando que o projeto vai acabar antes da linha pontilhada chegar. E a parte mais difícil disso tudo é que nós não temos idéia de quando esse momento vai chegar, ele pode ser em 3 meses, um ano, 10 anos… Nós não sabemos.
  • 55. Softwares de baixa qualidade tornou-se um dos tópicos mais caros da história da humanidade.
  • 56. 2.84 Trilhões de Dólares - Custo de baixa qualidade de software CISQ divulgou um relatório sobre os custos de software nos EUA
  • 57. Além do Lucro Além do gasto excessivo de dinheiro e das entregas mais lentas existem várias outros problemas que podemos identificar que são causados apenas por trabalhar com um nível alto de débito. O débito técnico traz muito peso às nossas vidas. Se você está constantemente lidando com códigos problemáticos, uma tarefa que parece fácil de se concluir pode se transformar em um verdadeiro monstro.
  • 58. Ansiedade e Depressão É comum ter receios em fazer mudanças, ainda mais se você é novo no projeto. As reuniões de planejamento podem se tornar intermináveis uma vez que a equipe de desenvolvimento precisa discutir com a equipe de gerência do projeto para explicar o quão difícil é entregar as novas coisas agora. Começamos a ficar ansiosos porque não sabemos se algo vai surgir com o tempo, algum grande problema ou um bug difícil de se encontrar no meio de uma sprint. Quem aqui nunca teve ou ainda tem algum código com algo desatualizado ou não mantido mais?
  • 59. Atrofiadashabilidadestécnicas É um cenário comum para pessoas desenvolvedoras. E é bem complicado de se lidar, porque nós precisamos aceitar todas as consequências e os problemas que vêm com isso. Geralmente o que acontece é que você começa a copiar e colar código de uma biblioteca ou framework desatualizado e a corrigir os problemas você mesmo. Ou até, às vezes, você só faz uma cópia do projeto e começa a usar o seu clone.
  • 60. Atrofiadashabilidadestécnicas Imagine só como deve ser difícil pra alguma pessoa desenvolvedora ser realocada no mercado de trabalho depois de passar cinco anos em um framework javascript que não é mais mantido e então precisa mudar para trabalhar com React ou Vue.js por exemplo. Muitos conceitos que nós já estamos acostumados a trabalhar podem nem existir numa ferramenta velha.
  • 61. Crescimentoproblemático Não faz sentido a empresa que você trabalha crescer 300% ou 400% ao ano se o seu time não tiver saúde mental e tempo para trabalhar da melhor forma num tamanho maior. É bem comum esse cenário em startups que glamourizam horas excessivas trabalhadas por alguma meta irreal. Aquele pico de vendas do produto no meio da noite em que você precisou acordar pra levantar algum serviço da aplicação que caiu pela quantidade de acessos. Em um mundo realista e respeitável, as máquinas deveriam tomar conta dessas situações ao invés de colocar toda a pressão nas pessoas envolvidas.
  • 67. Apenas Breaking Changes podem reduzir substancialmente Dívida Técnica
  • 68. → reduz Dívida Técnica → reduz mudanças significativas Compatibilidade Futura
  • 69. Pense antes de codificar! porque cada erro torna seu futuro trabalho mais difícil
  • 70. Depois de conversar sobre tudo isso. A Torre de Pisa está sustentável.
  • 71. Na real essa é uma das raras situações onde um bug vira feature :)
  • 72. Palestra inspiradaem uma palestra de AlainSchlesser Alain Schlesser. @schlessera www.alainschlesser.com Software Engineer - @WPCLI Maintainer - @WordPress Core Contributor - @GoogleDevExpert in Web Technologies
  • 73. Obrigado! Qualquer dúvida, crítica ou sugestão só me procurar: @jacksonfdam jacksonfdam@gmail.com
  • 74. CRÉDITOS É aqui que você dá crédito a quem faz parte deste projeto. Gostou dos recursos deste modelo? Obtenha-os gratuitamente em nossos outros sites. ◂ Presentation template by Slidesgo ◂ Icons by Flaticon ◂ Infographics by Freepik ◂ Images created by Freepik - Freepik ◂ Author introduction slide photo created by Freepik ◂ Text & Image slide photo created by Freepik.com