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!
Uma deliciosa sopa de símbolos.
Nenhum comentário:
Postar um comentário