Falar sobre abstrações nos dias atuais, é refletir sobre a própria natureza da ciência da computação e da engenharia de software. Soluções escaláveis, problemas rotineiros, todos passam em algum momento pela escolha de como serão visto pelos usuários finais, e é comumente aí em que soterramos sob camadas e mais camadas de abstração as nossas soluções.
Pensamos na facilidade de entender, de manter, e até de expandir; mas como lidamos com os problemas que existem nas partes que encobrimos com a abstração? Até que ponto camadas de abstração influenciam positivamente nosso entendimento e manejo sobre alguma tecnologia.
Segundo o Neal Ford, abstrações se acumulam em níveis, e estes níveis precisam ser minuciosamente analisados, enquanto ao impacto nas futuras decisões. Não que ele insinue a mediunidade para engenheiros de software; o que ele sugere é uma jornada reflexiva, por meio de 10 lições, que evitariam a nossa distração por todas as abstrações elaboradas.
“Não confundir a abstração com o objeto em sí”. Utilizar abstrações de altos níveis, foi muito importante para nossa evolução, pensar em pastas e arquivos ao invés de zeros e uns. Pensar em linguagens e plataformas e como podemos ganhar produtividade com elas pode ser mais fácil com camadas de abstração porque em dado momento, assim como foi, e ainda é, para o emacs, a fácil extensibilidade nas definições de funções, pode se voltar contra a própria perpetuação do código, que quando não mantida a definição de comandos pode ser perder para sempre, ou ser muito custoso para recuperar. Fitas e mais fitas de código perdidas, sem interpretação? O Martin Fowler trata o assunto em: http://martinfowler.com/bliki/InternalReprogrammability.html.
Vale a pena ver o talk: