YCC-GDE (Generic Development Environment): Introdução

O GDE, Generic Development Environment é a base do projeto Zero, que têm por objetivo fornecer um ambiente de desenvolvimento para diferentes arquiteturas, contando com bibliotecas e funcionalidades em C++ de uso comum para diferentes projetos baseados em sistemas Posix.

O primeiro passo nesta frente é confeccionar a base de um ambiente de desenvolvimento, neste contexto surgiu o projeto GDE. São características desejáveis para este ambiente de desenvolvimento o generalismo, reprodutibilidade, escalabilidade e manutenibilidade.

Generalismo

Dado que esta base será utilizada para confecção de bibliotecas, estáticas ou dinâmicas, aplicações de exemplo, PoC's, testes e aplicações, é desejável que este ambiente de desenvolvimento seja generalista para facilitar a etapa inicial de diferentes projetos.

Esta caracaterística pode ser atingida se atentando para arquitetura do ambiente de desenvolvimento, de tal forma que a configuração de cada um dos ambientes fique isolada em um único arquivo, o qual se responsabiliza pela definição das características relevantes para cada uma das proposições.

Isolar as responsabilidades, além de contribuir para o generalismo, também contribui para a escalabilidade e manutenibilidade, visto que proporciona uma facilidade maior para a adição de novas arquiteturas e utilização em novos projetos, bem como facilita a manutenção e adaptabilidade do sistema.

As questões que devem ser levantadas com relação a esta característica são:

• Qual a dificuldade associada na adição de uma nova arquitetura?
• Qual a dificuldade em iniciar um novo projeto a partir da base do GDE?
• A estrutura proposta atende diferentes projetos?

Reprodutibilidade

No dia a dia da programação você provavelmente já ouviu: - "Mas na minha máquina funciona!".

Para evitar este tipo de situação, o ideal é que possamos garantir que o mesmo cenário será executado independente da máquina host, do sistema operacional e do desenvolvedor. A solução desta problemática tem nome e sobrenome, Docker Container.

Podemos gerar uma imagem Docker, fixando o sistema operacional, as dependências e suas versões para cada um das arquiteturas e projetos a serem propostos. 

Além da reprodutibilidade, utilizar uma Imagem Docker facilita o ramp-up do projeto, visto que a instalação da imagem fornece todas as dependências do ambiente de desenvolvimento. A princípio, esta parece uma vantagem irrelevante, mas já atuei em um projeto no qual o ambiente de desenvolvimento era instalado diretamente na máquina host, sempre que um novo colaborador entrava para o time ou que uma máquina era formatada, o trabalho para instalar cada uma das dependências e validar as funcionalidades do ambiente de desenvolvimento era considerável. Na continuidade do projeto o ambiente de desenvolvimento foi portado para uma Imagem Docker e virou consenso entre o time: "Docker é uma Mãe"!

Escalabilidade

Neste contexto, a escalabilidade se enquadra na facilidade para adição de novas arquiteturas e recursos. Bem como a adição de novas bibliotecas, aplicações de suporte, recursos de terceiros e dependências. 

Visando maior controle e independência entre as dependências do ambiente de desenvolvimento, o ideal é que possamos separar a descrição e instalação de cada uma delas em um arquivo diferente, de tal forma que cada um destes arquivos contenha todo o processo de instalação, inclusive das dependências de cada uma das funcionalidades utilizadas por este determinado recurso. Desta forma, cada um destes arquivos se torna um documento sobre a instalação do recurso e de suas dependências.

Neste sentido, os arquivos responsáveis pela geração da Imagem Docker e instalação de dependências é o Dockerfile. Nos próximos capítulos será abordada a possibilidade de utilização de camadas de Dockerfiles para geração de uma única Imagem Docker, com este recurso, será possível isolar cada etapa do processo em um arquivo Dockerfile específico e independente.

Manutenibilidade

A complexidade só se justifica pela necessidade!

Não encontrei o dono desta frase, mas a levo como um mantra no dia a dia da programação. Soluções complexas, em sua grande parte, não se justificam e geram problemas consideráveis para o time de desenvolvimento, atrasam e dificultam o processo de manutenção e o ramp-up de novos colaboradores na equipe.

Manter a simplicidade é essencial para a longevidade e o baixo custo do projeto, ao tornar o código mais complexo com a utilização de recusos pouco triviais, sempre se questione acerca da real necessidade de utilização de tal recurso. Atente-se a indagações internas como:

• Esta complexidade implica em vantagens relevantes?
• As vantagens compensam as desvantagens?
• Se eu fosse um desenvolvedor junior e entrasse na equipe após a implementação deste recurso, a minha curva de aprendizado seria afetada negativamente de forma considerável?
• Qual o tempo necessário para que eu explique e ensine este recurso para um colaborador?
• Qual o tempo necessário para que um colaborador entenda o recurso e se torne produtivo sem meu auxílio?

Desenvolvedores, via de regra, são curiosos e possuem apreço pelo aprendizado de novos recursos, eu por exemplo, me sinto mais produtivo quando estou aprendendo sobre a utilização de novas técnicas e funcionalidades, porém, tal "ansiedade" pelo aprendizado pode, por vezes, nos levar a implementação de soluções complexas para problemas relativamente simples e triviais. Por isso lembre-se: a complexidade só se justifica pela necessidade!