2009/11/13 Marcos Douglas <m...@delfire.net>: > 2009/11/12 Joao Morais <jcmorai...@gmail.com> >> Então Marcos, eu coloquei uma vantagem de um ambiente padronizado, e >> não necessariamente com uma VM. E também não generalizei, nem >> relacionado a VM nem relacionado a padronização. O foco acima vai de >> encontro ao custo de ter uma VM, que por vezes é nada perante o >> benefício. > > Concordo com os benefícios de uma VM e ainda mais de um ambiente padronizado. > Uma VM não é imprescindível, mas o ambiente padronizado é. O que eu > quis dizer anteriormente, sobre o custo da padronização, é que não > devemos colocar o foco em somente criar o melhor ambiente padronizado, > pq muita burocracia tb não ajuda.
Discordo. Deixe-me contextualizar. Quando falo em padronização, estou citando a forma que um projeto será construido e evoluido. Não estou falando de nomes de variáveis, parâmetros, métodos, etc., mas aonde ficarão os lay outs de página, como eles se integram com o restante do código, se iremos construir com DAO, BC ou apenas um objeto de negócio e um framework de persistência, etc. Isto é importante e deve, sob meu humilde ponto de vista, ser definido antes da primeira linha de código. >> Tem circunstâncias em que uma padronização é essencial para não virar >> o caos. Quanto mais complexa a solução e/ou maior a equipe de >> desenvolvimento, maior a necessidade de padrões. > > Concordo, mas isso é depois que o software já está grande ou muito complexo. > Veja vários projetos OpenSource que tem por aí. Se vc for utilizar um > software opensource ele poderá ser muito bom. No entanto, vendo seu > código, veremos que não tem muitos padrões... Tem algumas coisas que preciso evoluir, algumas violações que preciso refatorar e algumas implementações que precisam ser finalizadas. Mas se você citar o que você enxerga de ruim, vai me ajudar a nortear a implementação ou dar a mim a oportunidade de te apresentar minha visão do que eu fiz. > Um exemplo é o próprio > compilador FPC. Já viu o código? Tem Units que é "certinha", bem > padronizada e tal já outras... Qual a melhor abordagem? A padronizada, > claro, no entanto acho que se houvesse uma escolha entre desenvolver > ou ficar pensando em qual padrão, eles optaram por desenvolver. Você está falando de que, modelagem de classe? Formatação de código? Nome de métodos e variáveis? Nomes de unidades? Eu conheço muito pouco do compilador para citá-lo como exemplo, mas o que eu chamo de padronização é a forma que os caras lêem tokens, como trabalharam a gramática, como implementaram o algoritmo para alocação de registrador de forma otimizada e independente de processador, organização dos packages, enfim, algo relacionado a arquitetura interna do compilador e suas bibliotecas do que olhar meia dúzia de linhas. Os caras têm uma arquitetura muito sólida, mesmo que eu ou você achemos que o código é muito feio. Estou falando de arquitetura, e não de código. >> De volta ao foco. Minha idéia é criar especificações simples para que >> o projeto saia do papel. Vamos colocar um cenário hipotético: >> linguagem Pascal, compilador FPC (tá virando off topic aqui), >> publicação da aplicação via FastCGI, construção sob a classe >> TCustomFCGIApplication, apresentação via ExtJS/ExtPascal com um >> framework MVC (caso o Ext* não tenha um) para orquestrar a >> apresentação. O MVC vai padronizar os arquivos da apresentação e >> algumas boas práticas ou outros frameworks vão padronizar os arquivos >> e classes de negócio e persistência. > > OK, concordo em ter uma linha a seguir. Então, vamos começar? rs... Sim. A gente precisa de um ponto de encontro, nem que sejam trocas de mensagens em private, e informar à lista sobre a nossa escolha. Depois você precisa dizer se o que eu já disse está legal e tentar evoluir. Eu mesmo posso detalhar melhor o que eu citei, caso o caminho esteja legal, ou trilharmos caminhos diferentes. Viu só? A gente já andou um bocado, só faltou ver com outros olhos. Joao Morais
