terça-feira, 2 de junho de 2015

Hardcore Devel #18 - Minimalist Arena #1

Tá, eu sei que eu já falei muito sobre o meu projeto antes, mas como antes não ficava documentado no tíutlo, eu to começando a documentar agora. O resto vocês podem considerar como números negativos! Afinal, nada impede isso!

Bem vindos ao Hardcore Devel! Nosso diário de desenvolvimento de aplicativos e curiosidades sobre o mundo da programação de computadores!

Cara eu devia transformar isso em uma espécie de vinheta. Ou talvez colocar o Gicmaal pra apresentar isso, mas da última vez ele não esteve muito afim de fazê-lo. Então vamos as novidades com o projeto MinArena!

Bom, o projeto estava uma bagunça. Como todo bom projeto começa. Então o nosso trabalho recente foi todo sobre refatoração de código. Só que isso não se faz assim de qualquer jeito. Vamos começar a falar um pouco sobre organização de código fonte aqui.

A primeira coisa que eu vou falar é. Não espere que o primeiro código vai ficar limpo. Isso não acontece, a não ser que você seja um cara muito burocrático com todo o pedaço de código que você escreve. Na verdade, existe o que eles chamam de processo de desenvolvimento de software, e isso é justamente a base da engenharia de software.

Acontece que eu não sou um engenheiro de software. Eu sou um programador.

Então não se preocupe. O seu primeiro código tem uma grande probabilidade de sair bagunçado. É normal, e não é algo com o qual você tem de se intimidar. Um professor meu da faculdade, cujo site você pode acessar aqui, costumava a dizer "Early optimization is the root of all evil." e eu tomei essa frase pra mim quando a vontade de programar se perde pelo fato do código parecer uma grande bagunça.

Aos poucos a gente vai consertando, e novamente, não se resolve isso de qualquer jeito. É necessário um pouco de planejamento antes de sair refatorando código, mas isso remete ao problema inicial de geralmente programarmos sem planejamento nenhum.

Sem planejamento nenhum é o cacete, cara-pálida.

Na verdade nós já raciocinamos com abstrações. Somos capazes de rapidamente abstrairmos as camadas que compõem o nosso software e raciocinar com elas. Tudo bem que o produto implementado não fique logo identicamente a abstração inicial formulada. E muitas vezes não vai estar, pois essa abstração pode ser modificada ao longo da implementação, mas o fato é que ela existe.

E a partir daí coloque essa abstração no papel e compare com o seu código. Se houver muitas discrepâncias, pode ser que seja a hora de refatorar o seu código para torná-lo mais condizente com a abstração!

Então é isso aí, façam códigos e lapidem eles conforme vocês fazem!

Abraço!

Nenhum comentário:

Postar um comentário