imagem Hum…projetar pra que? Ora bolas!

20170708_213015

Imagine uma pessoa que joga videogame e que é apaixonado por músicas 8 bit.

Imagine agora que essa pessoa é você.

Imagine também que existe um monte de gente chata pra caramba que fala que videogame é coisa de criança, que isso não dá futuro, mesmo com você lá sonhando em fazer jogos, criar mundos, novos poderes, apertar a mão do Miyamoto e virar uma celebridade.

Mas ainda assim você quer ir atrás de seus sonhos e alguém te diz que para fazer isso é preciso estudar computação, daí você vai lá, cheio de vontade, estudar esse negócio misterioso e quando chega, começam a te ensinar sobre variáveis, atribuições, compiladores, Pascal, te forçam a documentar passo a passo como você toma café da manhã assim: você puxa a cadeira da mesa, senta nela, abre o pote de margarina, pega a faca, pega um pão da sacola, passa a faca na margarina, esfrega no pão e depois come.

What?

Você está acostumado a fazer as coisas de forma simples, não conhece este universo de desenvolvimento de software que é cheio de formalidades e pensa que talvez fosse mais fácil fazer um simples desenho num papel. Mas não é preciso argumentar sobre o choque de realidade entre querer fazer algo lúdico porque parece ser natural e o de ter de projetá-lo porque é necessário.

Todo mundo tem seu tempo para assimilar conceitos. Ao chegar em um curso especializado é necessário vestir a camisa para projetar algo passo a passo, pensando nas partes, dividindo conceitos que podem ser quebrados para conquistar cada funcionalidade, pois a compreensão de existência de cada sistema depende do quão sua visão se aproxima ou se distancia dele.

Entrevistar, diagramar, documentar, modularizar, escrever código, executar o resultado de seu trabalho, receber feedback, tudo isso faz parte do projetar.

Sentimentos e sensações muito diferentes surgem quando você começa o seu curso de computação e vê o Hello World na tela pela primeira vez e depois quando você já discute sobre abstração. Para mim é a mesma sensação ao se impressionar com o código fonte de alguém que você sempre admirou pela sua capacidade de aprender sozinho e depois de um tempo, quando você vê novamente que esta pessoa continua fazendo as coisas do mesmo jeito, após 10, 20 anos, utilizando-se do argumento que está dando certo, que tá funcionando, que ninguém reclama, que aquele programa que só possui um Main do tamanho de uma linguiça de 30 metros de código atochada de ifs, breaks, variáveis com nomes de b1, b2, b6 que não são vitaminas, talvez você já consiga perceber que o nível da barbárie e do trauma de um projeto assim pode travar a sua evolução como projetista e pessoa. Trocando palavras, pode ser que você já tenha despertado o seu Mangekyo Sharigan e já tenha lhe caído a ficha da necessidade de se projetar corretamente.

Pensar na arquitetura desde o comecinho do que o usuário vê na tela, do que ele toca, do que ele busca, não precisa achar chato construir formulários, relatórios em gráficos a todo momento e que fazer o seu super herói num jogo seria bem mais divertido. Não precisa se preocupar, projetar sistemas é sim uma atividade lúdica. Assim como compor uma música, colocando bateria, guitarra, teclado, voz e baixo em um programa que separa cada instrumento para você aumentar o volume de cada camada de forma independente é assim também a arquitetura de um software. Imagine que a melodia que dá característica à sua música, que te faz cantarolar seja a camada view de seu software, que precisa ser trabalhada para o usuário trabalhar, brincar e usar. Que a camada DAO seja o contrabaixo que fica por trás das câmeras servindo de base para a música. Que os solos de guitarra e teclado sejam a regra de negócio que ditam como é que deve ser transmitido o seu som e por aí vai.

Esse projetar além de poder ser encarado de forma lúdica deve ser fruto de um aprendizado constante. O nosso modo de trabalhar um projeto deve ser um tanto multidisciplinar porque a nossa função de analistas/desenvolvedores é sempre de se conectar com as necessidades de problemáticas que nos são impostas, seja num meio rural ou em alguma área da economia. Sempre que desenvolvemos, arquitetamos, projetamos uma solução ela deve ser antes de tudo profissional do ponto de vista de se utilizar as ferramentas e padrões necessários que aprendemos em nossas aulas tanto para agregar valor ao nosso trabalho quanto para ganhos de produtividade, de performance, equilíbrio de recursos utilizados e sempre manter a sintonia com as tecnologias atuais.

Grandes soluções são frutos de grandes projetos, quanto mais você documenta, testa, diagrama, codifica, projeta tem a oportunidade de aumentar a qualidade de seu software. Lembre-se sempre que seu case de sucesso favorito não se tornou a personificação de sua admiração em um ímã de geladeira a toa.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s