A eterna luta: compatibilidade retroativa vs. dívida técnica

Vamos abordar primeiro a logística de manutenção de um projeto com alto débito técnico como o WordPress.
Em seguida, examinará o que isso significa para projetos que dependem do WordPress.
Finalmente, ele irá percorrer algumas maneiras potenciais de mudar para um processo mais equilibrado, com uma análise mais detalhada de como o
WordPress finalmente conseguiu escapar de seu requisito do PHP 5.2.

Transcript

1. Jackson Mafra
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
4. Uma breve introdução
5. 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. 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. 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. Em mapas mind/mentais.
9. 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. 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. 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. 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. 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. 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 você tem no seu software é DÍVIDA TÉCNICA! Não existe débito técnico!
18. 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. 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. 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. 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. 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. 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. 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. Confira em martinfowler.com/bliki/DesignStaminaHypothesis.html
27. 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
28. 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. 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. 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. 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. É inevitável que tenhamos que decidir como chegar nos tais prazos e essas decisões geralmente giram em torno de sacrifícios...
33. Para nossos usuários Queremos maximizar a compatibilidade com versões anteriores Para nossos desenvolvedores Queremos minimizar a dívida técnica
34. 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. 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
36. 3.1.7 <major> . <minor> . <patch>
37. – 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.
42. 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. 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. Cada mudança está se tornando cada vez mais cara. Dívida técnica descontrolada eventualmente leva a → Falência Técnica!
47. I.M.P.A.C.T O IMPACT é um processo de: Identificar Marcar Planejar Agir Testar
48. 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. 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. Você pode encontrar informações mais detalhadas no livro "Refactoring for Software Design Smells Managing Technical Debt".
51. 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. 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. 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. 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 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. É 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. É 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. 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. 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.
62. Concluindo o que concluímos.
63. Dívida Técnica deve ser evitada
64. Dívida Técnica precisa ser "paga"
65. Compatibilidade Retroativa deve ser mantida
66. Compatibilidade Retroativa cría dívida técnica
67. Apenas Breaking Changes podem reduzir substancialmente Dívida Técnica
68. → reduz Dívida Técnica → reduz mudanças significativas
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 :)
73. Qualquer dúvida, crítica ou sugestão só me procurar: @jacksonfdam jacksonfdam@gmail.com
74. É 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