Pular para o conteúdo principal

Uma pergunta para melhorar seu legado

Já falei aqui no blog, em outras ocasiões, acerca do meu trabalho em sistemas legados. Pois agora, após de acumular mais algumas experiências, discussões e refinamentos creio que cheguei em uma forma mais sucinta [mas não definitiva] de explicar a lógica que sigo. Tal raciocínio me levou a levantar esta questão no Agile Trends e Agile Brazil deste ano.


Na apresentação cobri diversos exemplos e consequências que derivam do raciocínio. Mas em todos eles existe uma idéia central guiando o processo. Uma pergunta, que ajuda a sumarizar como penso. É sobre ela que quero falar hoje.

Qual o menor passo sustentável que eu consigo executar agora.

Esta pergunta poder ser decomposta em quatro partes.

O menor passso

Sempre somos tentados a pensar na melhor solução. Nossa educação nos treinou a sempre buscar a resposta certa para as perguntas que nos são apresentadas. Porém nem toda pergunta nasce igual. Sendo assim, um mesmo problema [em software] pode ter soluções distintas, de acordo com seu contexto. Dar um passo menor consiste em não apenas quebrar o problema (e solução) em partes mais digestíveis. Mas entender que cada uma delas fornece pequenas dicas de que estamos indo na direção correta. Quanto menor, mais rápido conseguimos verificar e ajustar o curso.

Sustentável

Idealmente uma decisão sustentável seria aquela que não te causa problemas no futuro. Essa é uma tarefa difícil de se alcançar. Isso porque, toda linha de código que se constrói, enquanto resolve um problema, abre portas para uma infinidade de outros. Por isso, prefiro reconstruir a definição de sustentável como as decisões que você se sente confortável com as conseqüências no futuro. Isso implica em se pensar nos desdobramentos e estar ciente da dívida técnica (e negocial) que nossas decisões de software geram.

Eu consigo executar

Ter consciência de nossas limitações é importante. Por muitas vezes não temos o conhecimento ou domínio para executar nosso melhor plano. Entender essa limitação e decidir como ela influencia o caminho a ser seguido. Qual o custo de se adiquirir essa capacidade em relação as necessidades do projeto?

Agora

Por fim, é importante ter em mente durante a tomada de decisão, não somente o que queremos pro sistema no futuro. É rpeciso balancear suas necessidades baseando-se também no agora. Nada adianta decidirmos a melhor solução [sustentável] se a mesma só estará disponível depois de uma capacitação de seis meses, quando a necessidade do negócio é para o mês seguinte. Temos que balancear nossas decisões e planos com o que nos é apresentado no presente e construir o caminho a partir daí.




Como exemplos de extratégias de como melhorar seu legado indico os artigos do Marting Fowler sobre Sacrificial ArchitectureStrangler Application .

Postagens mais visitadas deste blog

A experiência de software

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" ( me recuso a chamar de Fábricas de Software ) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado. Uma fábrica de software artesanal Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são empurrados goela abaixo entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou se

TDD como ferramenta de aprendizado

Na penúltima sessão do DojoBrasilia surgiu a seguinte questão: Será que o TDD não atrapalha no aprendizado de novas tecnologias?  A grande questão girava em torno de que o respeito estrito as regras ao TDD tornariam o aprendizado lento e enviesado. Isso por que você estaria focado em passar o teste o que estaria limitando sua velocidade no aprendizado na tecnologia, bem como a visão do objetivo final. Caso do dojoBrasília No caso da sessão que levantou a questão acho que o principal sentimento de "lentidão" se deve a grande carga de tecnologias novas que estavam envolvidas. Escolhemos iniciar um problema conhecido em não uma, mas várias tecnologias ( Backbone.js , Undescore , CoffeeScript , Jasmine , etc). Ao final da sessão a sensação de pouco avanço era justificada pelo tempo gasto compreendendo as tecnologias em questão. A sessão seguinte não obteve o avanço que muitos esperavam. Mas nela podemos ver como o uso de TDD compensou. Tínhamos apenas 4 cas

Formando pessoas desenvolvedoras na bxblue

Eu sempre fui apaixonado por ensinar. Trabalho com a formação e ensino desde 2003, indo desde o ensino das bases de computação até lecionar em cursos de pós-graduação. Estar no dia-a-dia com pessoas que estão no começo da carreira é um mix de satisfação e desafio. Satisfação por você ter a oportunidade de contribuir com um pedacinho tão especial da história daquela que será uma pessoa desenvolvedora no futuro. Desafiadora pelo fato de precisarmos nos despir de aprendizados já superados em nossas mentes e nos esforçamos por enxergar novamente pelos olhos de quem ainda não tem a mesma vivência que você. Por onde passei, eu sempre acreditei que um bom equilíbrio entre profissionais experientes e em formação é a melhor combinação para um time de tecnologia. Isso é benéfico não apenas para a retenção, como também é estímulo para uma cultura de aprendizado e humildade. Cultura essa que favorece o compartilhamento e interação não apenas entre quem faz o software, mas também as demais áreas da