Pular para o conteúdo principal

Arquitetura Evolutiva tem que respirar

Uncle Bob é um grande defensor da filosofia em que o desenvolvedor deve adiar ao máximo as decisões que criam amarras ao seu código. Esta é considerada prática já estabelecida quando estamos tratando de componentes externos como Bancos de Dados (por mais que alguns não consigam seguir essa filosofia), mas o que Robert quer é ir além, onde nosso código tenha o mínimo de dependência tanto de ferramentas, frameworks até mesmo a nossa arquitetura de deploy.

De início pode não pareceruma tarefa fácil. Como desenvolvedores vivemos uma batalha diária a cada tomada decisão. Estas devem encontrar o equilíbrio entre a sustentabilidade de longo prazo do nosso sistema e a velocidade com que conseguimos colocá-lo no ar. Afinal, o valor presente em um software cuja a manutenção seja impraticável é tão nulo quanto um que nunca vai ao ar. Soma-se ainda que para quem vive uma realidade Lean, apesar do desenvolvimento aparentar incremental, a evolução do produto não segue esta mesma linha. Sendo na real formado por diversas "quebras".


Considerando que a cada etapa do processo de aprendizado do produto muita coisa pode (e provavelmente vai) mudar. Nosso software deve estar pronto para fazer o mesmo. Estando apto a embarcar mudanças que podem até mesmo jogar seu repositório inteiro pela janela. Neste caso, eu considero que duas perguntas são chave na tomada de decisões. Primeiro, "Qual a solução mais barata que eu estou disposto a fazer agora?" e segundo "O que eu posso jogar fora do que eu fiz?". A primeira pergunta é bem conhecida entre os praticantes do Lean Startup (de novo, não que seja fácil de se praticar). Já a segunda envolve uma habilidade que poucos desenvolvedores possuem, o desapego


Muitos de nós temos dificuldade de nos livrar de coisas da nossa vida. Séries como Os Acumuladores estão aí para nos mostrar os extremos a que esse tipo de realidade pode chegar. Infelizmente muitos programadores são acumuladores de código, seja mantendo funcionalidades que não são mais usadas, classes não acessíveis por ninguém, testes que não testam nada ou o pior de todos, código comentado. Muitos amontoam essas quinquilharias sob a promessa de que "podem ser úteis no futuro". Porém, o que acabam fazendo é contribuir para aumentar a carga de legado, levando a produtividade do time para baixo. Por isso, se você possui algo que se encaixe em uma dessas situações no seu código, faça um favor, delete-as. Não tenha medo, o controle de versão vai te ajudar se um dia você precisar de algum artefato arqueológico destes (pouco provável).

Dominada esta habilidade, você estará apto a diminuir o tamanho do seu código. Deixando mais espaço (tanto no projeto como na sua mente) para construir novas coisas. É aqui que retornamos a primeira pergunta. Dela as palavras que mais importante a se levar em consideração são "barata" e "disposto". Por barato o que queremos dizer é aquilo que gera valor de forma mais rápida, implicando em menor custo e por consequência um maior retorno (seja monetário ou de aprendizado). Já no disposto entram os valores que você, como desenvolvedor, impõe no seu trabalho. Talvez você esteja disposto a criar algo que seja insustentável no futuro em prol de um aprendizado mais rápido, para que esta dívida seja paga no futuro. As vezes não tem a disposição para abrir mão de uma solução mais redonda, já que não quer carregar isto para frente. É a disposição (pessoa e da equipe) que determina o tamanho do passo que vai ser dado. Determinando não só o ritmo de trabalho como a segurança com que se caminha.

Dominando esta segunda habilidade, podemos escolher como crescer nosso software. Isso em conjunto com a primeira permite que nosso software cresca em "ondas". Sempre tateando qual o caminho mais seguro para que seu software vá evoluindo. E é isso que permite evoluir não apenas tecnicamente, mas também em valor de negócio. Alcançando o equilíbrio tão necessário para as soluções que nós desenvolvemos.


Comentários

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

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

WorkChopp Intacto

Olá pessoal! Sou o @andersonfer_ e tô invadindo o blog do Fabricio pra contar sobre um evento muito legal que organizamos na @IntactoSoftware . Como eu ainda não tenho blog (shame on me), pedi permissão pra falar por aqui! Espero que gostem! Depois do #agileBR , todos nós voltamos naquela vontade de distribuir o conhecimento adquirido lá entre toda galera. Então tivemos a ideia de organizar um workshop baseado em uma dinâmica que eu assisti, apresentada pelo Emilio Gutter e pela Alejandra Alfonso . Eu sempre fui muito favorável às dinâmicas, jogos e afins pq acho que têm um poder muito grande de quebrar as resistências das pessoas e fazê-las enxergar os benefícios das metodologias e técnicas ágeis para além dos contextos e projetos em que estão inseridas e consequentemente tentar aplicar esses conceitos no seu dia-a-dia. Optamos por relizar a dinâmica Construindo A Cidade Ágil. Os 2 grupos tinham à disposição papeis coloridos, tesoura e cola pra construir, em 4 sprints de 3 min