2009/11/13 Marcos Douglas <m...@delfire.net>: > 2009/11/13 Joao Morais <jcmorai...@gmail.com> >> > 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. > > Ah sim, decisões de projeto, por onde começar. Pensei que vc queria > definir toda uma arquitetura e só depois que todas as respostas > estivessem respondidas, aí só faltaria codificar.
Pensou certo. Definir toda a arquitetura antes e depois codificar. Mesmo que fiquem faltando alguns detalhes, algumas implementações. É como escrever contra uma interface que foi completamente definida, mas que ainda não possui uma única classe que a implemente. > Este seria o modelo > Cascata, certo? No entanto eu acredito mais nas filosofias Ágeis, > utilizando o interativo e incremental. Mas eu concordo com vc. Acho que não se aplica. O que cascata separa é concepção de elaboração e desenvolvimento durante o desenvolvimento de um projeto. Nós somos nossos próprios clientes e estas decisões seriam, digamos, um documento de arquitetura que pode ser concebido no modelo iterativo. Ágil, sim; irresponsável, não. >> > 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. > > Não, não, não! Vc entendeu errado, mas acho que foi culpa minha. Nada. Agora que entendi claramente o que você disse. Mal entendido resolvido. Bom, sinceramente eu até preferiria alguma crítica a fim de me ajudar a melhorar o modelo. >> > 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. > > Bem, eu estava falando de código mesmo. Não conheço a arquitetura do > FPC pra dar alguma opinião. No entanto eu acho que o código tem muito > a ver com a arquitetura. Código é uma forma de uma pessoa se expressar. Pegue um cara ímpar, mosca branca, inteligentíssimo, mas que é gago e tem uma letra horrível. A letra conta sim, mas não é tão importante quanto a harmonia daquilo que está escrito. Definir a arquitetura e orquestrar o lugar das coisas antes te criar as tais coisas fará com que você crie tudo uma única vez (hã... ok, esse seria o caminho feliz) e evite retrabalho. Como falei noutra ocasião, quanto maior a equipe e/ou mais complexa a solução, maior a necessidade de ter estes cuidados. Mas cada um vai escrever da forma que está acostumado, a menos que a equipe tenha ditado até o espaço em branco antes e depois do ":=". Curiosidade, estou no meio de um projeto assim, absurdo de grande, em que o cliente receberá todos os artefatos produzidos, fontes inclusive, e cita até regras de checkstyle incluindo o máximo da complexidade ciclomática dos métodos. > Vc fala de algoritmo para alocação, tokens, etc, ou seja, a > Arquitetura, correto? Mas se que adiantaria isso se tivesse mal > escrito (não sei se está ou não, pois eu só vi códigos das classes que > seria utilizadas no meu projeto)? Ninguém entenderia a arquitetura. > Então, acho que tudo está relacionado... Entendo. Isso pode ficar meio complicado com mais de uma pessoa mexendo ou dando manutenção no mesmo código. Mas eu falo um pouco além disso, ao menos nessa etapa. Por exemplo, você está se lixando se o kernel do Linux (com perdão da redundância) é um lixo ou é organizado. Ele é fechado pra você, e você tem apenas uma interface de uso. Essa interface tem que ser algo decente, e o código interno, seja um lixo ou não, tem que fazer aquilo que ele se compromete. A interface de uso do kernel do Linux é a arquitetura, seu código é construído de acordo com o que essa interface dita pra você. >> > 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. > > Ok João, tá certo... rs... Então comenta. Cata a mensagem aonde eu proponho uma arquitetura pra gente seguir e dá seu parecer, abrindo em detalhes aonde você tiver idéias ou sugerindo outra abordagem aonde você não concordar. Só estou esperando esses comentários para dar sequência aos meus. > Mas acho que devemos deixar as mensagens aqui na lista mesmo. Assim > podemos receber sugestões/críticas. Se alguém achar que isto é > off-topic, aí então paramos de escrever. O que acha? A gente vai falar de programação, arquitetura de software, programação web, mvc, alguns padrões de projeto, parsers e pascal. Mas nada de Delphi. Bom, talvez valha como um off-topic. Ou não [1]. =) Joao Morais [1] http://desciclo.pedia.ws/wiki/Ou_n%C3%A3o
