0
Metodologias de desenvolvimento de software - Parte I
Já passei várias horas conversando com pessoas das mais variadas idades e com diversos tipos de experiências na área de desenvolvimento de sistemas e um assunto muito comum é:
"Como você desenvolve seus sistemas?"
Na realidade não adoto uma única metodologia para todos os tipos de sistemas que desenvolvo, já que cada metodologia possui um ponto forte.
Para cada sistema, depois de avaliado o nível de complexidade, confiabilidade e tamanho, é adotada a metodologia que melhor se adequa a suas características.
Irei começar pelo modelo em cascata, que é uma abordagem mais antiga, porém a mais útilizada até hoje no desenvolvimento de software.
Neste modelo, o projeto vai progredindo com o passar do tempo.
Análise -> Projeto -> Codificação -> Teste
Modelagem:
Como o software faz parte de um sistema maior (HARDWARE, BD, PESSOAS, todos interagindo), o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois são alocados alguns subconjuntos desses requisitos para o software.
Supondo que fossemos desenvolver um sistema para gerenciamento de uma biblioteca, começaríamos com a definição de quais são os problemas atuais para o controle da biblioteca.
Análise de requisitos para o software:
O foco da análise volta-se para o software a ser desenvolvido. São levantadas as questões: Domínio da informação (para que o software serve e em que contexto ele está inserido), funções necessárias, comportamentos (sempre que acontecer X, fazer Y), desempenho e interface. Todos esses requisitos são documentados e revistos com o cliente.
Projeto:
O processo de desenvolvimento envolve múltiplos passos que foca: estrutura de dados, arquitetura do software (como ele será construído), protótipo, e detalhes procedimentais (algorítimos). Este processo traduz (agora já pensando em nível técnico) as especificações de requisitos citadas no item anterior.
Geração de código:
Se o projeto é realizado detalhadamente, a geração de código vira algo mecânico.
Teste:
O processo de teste focaliza os aspecto lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos (descobrir erros na interface com o usuário e garantir que entradas definidas produzirão resultados reais, que estão de acordo com os resultados exigidos. É criada uma tabela de testes, contendo a entrada, o tipo dela - numérica, alfanumérica -, seu tamanho e informações sobre o que é esperado que se obtenha como saída).
Manutenção:
A manutenção do software reaplica cada uma das fases anteriores a um programa existente ao invés de a um novo programa.
Esse modelo é o mais antigo e o mais utilizado atualmente. Porém, a crítica levou até mesmo seus atuais adeptos a questionar a sua eficácia. Alguns problemas:
1) Projetos reais raramente seguem o fluxo proposto. Como resultado, modificações podem causar confusão à medida que a equipe prossegue.
2) É difícil para o cliente estabelecer todos os requisitos explicitamente. (Principalmente na internet isso ocorre muito). Este modelo exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de vários projetos.
3) O cliente precisa ter paciência. Uma versão "executável" do sistema não estará disponível enquanto o projeto não terminar. Um erro grosseiro pode ser desastroso, se não for identificado até que o sistema seja revisto.
"Como você desenvolve seus sistemas?"
Na realidade não adoto uma única metodologia para todos os tipos de sistemas que desenvolvo, já que cada metodologia possui um ponto forte.
Para cada sistema, depois de avaliado o nível de complexidade, confiabilidade e tamanho, é adotada a metodologia que melhor se adequa a suas características.
Irei começar pelo modelo em cascata, que é uma abordagem mais antiga, porém a mais útilizada até hoje no desenvolvimento de software.
Neste modelo, o projeto vai progredindo com o passar do tempo.
Análise -> Projeto -> Codificação -> Teste
Modelagem:
Como o software faz parte de um sistema maior (HARDWARE, BD, PESSOAS, todos interagindo), o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois são alocados alguns subconjuntos desses requisitos para o software.
Supondo que fossemos desenvolver um sistema para gerenciamento de uma biblioteca, começaríamos com a definição de quais são os problemas atuais para o controle da biblioteca.
Análise de requisitos para o software:
O foco da análise volta-se para o software a ser desenvolvido. São levantadas as questões: Domínio da informação (para que o software serve e em que contexto ele está inserido), funções necessárias, comportamentos (sempre que acontecer X, fazer Y), desempenho e interface. Todos esses requisitos são documentados e revistos com o cliente.
Projeto:
O processo de desenvolvimento envolve múltiplos passos que foca: estrutura de dados, arquitetura do software (como ele será construído), protótipo, e detalhes procedimentais (algorítimos). Este processo traduz (agora já pensando em nível técnico) as especificações de requisitos citadas no item anterior.
Geração de código:
Se o projeto é realizado detalhadamente, a geração de código vira algo mecânico.
Teste:
O processo de teste focaliza os aspecto lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos (descobrir erros na interface com o usuário e garantir que entradas definidas produzirão resultados reais, que estão de acordo com os resultados exigidos. É criada uma tabela de testes, contendo a entrada, o tipo dela - numérica, alfanumérica -, seu tamanho e informações sobre o que é esperado que se obtenha como saída).
Manutenção:
A manutenção do software reaplica cada uma das fases anteriores a um programa existente ao invés de a um novo programa.
Esse modelo é o mais antigo e o mais utilizado atualmente. Porém, a crítica levou até mesmo seus atuais adeptos a questionar a sua eficácia. Alguns problemas:
1) Projetos reais raramente seguem o fluxo proposto. Como resultado, modificações podem causar confusão à medida que a equipe prossegue.
2) É difícil para o cliente estabelecer todos os requisitos explicitamente. (Principalmente na internet isso ocorre muito). Este modelo exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de vários projetos.
3) O cliente precisa ter paciência. Uma versão "executável" do sistema não estará disponível enquanto o projeto não terminar. Um erro grosseiro pode ser desastroso, se não for identificado até que o sistema seja revisto.
Bom artigo.
20/11/2008 4:26am
(~16 anos atrás)
Gustavo,
Quanto ao javadoc, tens toda a razão. Gostaria que comentasse minha afirmação que uma equipe que se foca no software tem mais capacidade para a pós-documentação do mesmo. Aguardo.
Quanto aos modelos das multinacionais, sinceramente, aproveitar o que dá certo lá, não é garantia nenhuma de dar certo aqui.
Ficar copiando modelos, é tentar seguir a mediocridade do mercado, e é o que quase todo o mercado faz. Criar idêntidade própria (cultura) é muito importante para uma empresa.
Não só acredito na programação extrema, mas na empresa extrema. Mesmo que grande, mesmo que com grandes projetos.
A necessidade de processos pesados por parte das empresas citadas parte da questão de que elas não estão conseguindo lidar da melhor forma com a Globalização, e precisam criar vagas em países mais pobres, para diminuir o custo das operações. Logo, elas não aproveitam o capital humano, precisando recorrem ao chicote.
Ou vai dizer que os softwares feitos pela Índia são para os indianos usarem?
A capacidade de mudar (mudar é aprender, já ensinava o budismo) é o maior valor para uma empresa hoje.
Lembre-se que o caminho da cópia de modelos, certamente é o pior caminho.
Quanto ao javadoc, tens toda a razão. Gostaria que comentasse minha afirmação que uma equipe que se foca no software tem mais capacidade para a pós-documentação do mesmo. Aguardo.
Quanto aos modelos das multinacionais, sinceramente, aproveitar o que dá certo lá, não é garantia nenhuma de dar certo aqui.
Ficar copiando modelos, é tentar seguir a mediocridade do mercado, e é o que quase todo o mercado faz. Criar idêntidade própria (cultura) é muito importante para uma empresa.
Não só acredito na programação extrema, mas na empresa extrema. Mesmo que grande, mesmo que com grandes projetos.
A necessidade de processos pesados por parte das empresas citadas parte da questão de que elas não estão conseguindo lidar da melhor forma com a Globalização, e precisam criar vagas em países mais pobres, para diminuir o custo das operações. Logo, elas não aproveitam o capital humano, precisando recorrem ao chicote.
Ou vai dizer que os softwares feitos pela Índia são para os indianos usarem?
A capacidade de mudar (mudar é aprender, já ensinava o budismo) é o maior valor para uma empresa hoje.
Lembre-se que o caminho da cópia de modelos, certamente é o pior caminho.
14/02/2005 2:15pm
(~20 anos atrás)
Juan, como você deve ter percebido, 10 anos foi apenas uma suposição. Poderia ser 1 ano, mas se mudassem os funcionários da empresa daria na mesma.
Javadoc é uma ferramenta útil para se documentar códigos e não processos. Um método não diz nada a respeito do funcionamento da empresa, diz apenas a respeito do funcionamento daquele fragmento de código.
De tiver interesse pesquise sobre CMMI. Tenho certeza que empresas como IBM, Microsoft, Oracle e HP por exemplo não investem em algo com um nível de documentação tão grandioso se fosse realmente inútil.
Claro que você não deve fazer sites institucionais com a rigidez de uma metodoligia dessas. Neste ponto aconselho o XP, sem dúvidas!
Mas se decidir algum dia desenvolver sistemas com inteligência de negócio e apoio à decisão gerencial, começar a aprender metodologias mais sérias de desenvolvimento será de grande valia para você, não tenho dúvidas.
Lembre-se que o caminho mais rápido nem sempre é o melhor caminho.
Javadoc é uma ferramenta útil para se documentar códigos e não processos. Um método não diz nada a respeito do funcionamento da empresa, diz apenas a respeito do funcionamento daquele fragmento de código.
De tiver interesse pesquise sobre CMMI. Tenho certeza que empresas como IBM, Microsoft, Oracle e HP por exemplo não investem em algo com um nível de documentação tão grandioso se fosse realmente inútil.
Claro que você não deve fazer sites institucionais com a rigidez de uma metodoligia dessas. Neste ponto aconselho o XP, sem dúvidas!
Mas se decidir algum dia desenvolver sistemas com inteligência de negócio e apoio à decisão gerencial, começar a aprender metodologias mais sérias de desenvolvimento será de grande valia para você, não tenho dúvidas.
Lembre-se que o caminho mais rápido nem sempre é o melhor caminho.
13/02/2005 9:26pm
(~20 anos atrás)
Bom resolví seguir o assunto no meu blog, se quiser ler ta lá em
<a href="http://riabrasil.blogspot.com/">http://riabrasil.blogspot.com/</a>
Argumento que uma equipe XP está mais qualificada a escrever uma documentação.
Fui.
<a href="http://riabrasil.blogspot.com/">http://riabrasil.blogspot.com/</a>
Argumento que uma equipe XP está mais qualificada a escrever uma documentação.
Fui.
11/02/2005 12:35pm
(~20 anos atrás)
Caro Gustavo,
Seu pressuposto de um sistema ficar 10 anos sem desenvolvimento é irreal.
Não existe sistema sem um desenvolvedor, e cabe a este administrar as regras deste.
Quanto a documentação, um processo leve pode ser utilizado nestes sistemas, como por exemplo o Javadoc, onde ao programar as classes, os desenvolvedores já criam a documentação do sistema. Outra informação valiosa é o fluxo de comments do CVS.
Feito?
Seu pressuposto de um sistema ficar 10 anos sem desenvolvimento é irreal.
Não existe sistema sem um desenvolvedor, e cabe a este administrar as regras deste.
Quanto a documentação, um processo leve pode ser utilizado nestes sistemas, como por exemplo o Javadoc, onde ao programar as classes, os desenvolvedores já criam a documentação do sistema. Outra informação valiosa é o fluxo de comments do CVS.
Feito?
10/02/2005 12:41pm
(~20 anos atrás)
Juan,
Imagino que você esteja acostumado a desenvolver sistemas legados e por isso não irei sair deste escopo pois se partir para o lado dos sistemas de apoio a decisão, o XP realmente deixaria muito a desejar.
O que acontece é que se você desenvolve sistemas sem a devida documentação do Processo de negócio e todos os impactos que essas regras tem no sistema (seja orientado a objetos ou não) a manutenibilidade se torna muito crítica.
Imagine que você desenvolve um sistema contábil (e não simplesmente sites). Bom, se usarmos o XP como metodologia de desenvolvimento faríamos uma análise superficial do que é necessário desenvolver e em seguida partiríamos para o desenvolvimento.
Agora... quais são as leis que envolvem a contabilidade? O que foi levado em consideração para montar a lógica de negócios que irá, no final do processo, dizer ao administrador da empresa (usuário) que estamos tendo lucro e não prejuízo?
Dez anos se passaram após o sistema ter sido desenvolvido usando o XP. O sistema continua informando o saldo contábil da empresa.
Porém a lei mudou e agora o sistema que foi desenvolvido precisará ser alterado. E agora?
Conclusão: Neste caso é mais fácil refazer o sistema contábil pois existem diversas partes do código interligadas e não faz-se idéia do motivo de um método "getBalanceteMeioAno()" ter ligação com o método "setNaturezaOperacao()".
Você poderia me dizer: "Ué? Mas a natureza da operação faz parte do cálculo do balancete". Ai eu lhe pergunto: Isso na nova ou na antiga lei?
E isso pode ir muito mais longe pois usei um exemplo bem bobo, mas poderíamos ter um sistema que deverá corrigir o voo de um airbus para que o piloto não precise colocar as mãos no console para conduzir o avião de São Paulo para a Hong Kong. Já imaginou a infinidade de regras que existem para que isso seja feito?
Diagrama de classe nenhum irá conseguir explicar o motivo de algo ter sido feito de uma maneira X ou Y...
Mas tudo bem... a equipe XP poderá se reunir e dizer: "É... no caso do último avião que caiu as alterações não funcionaram... que tal se tentarmos retirar esse método?"
O buraco é mais embaixo.
Por isso digo: XP é bom? Muito... se você tiver bom senso na hora de usar. Se usa-lo para qualquer coisa achando que é a solução dos problemas dos engenheiros de software com certeza irá se surpreender em muito pouco tempo.
Um abraço e qualquer outra dúvida, envie que ficarei feliz em poder ajudar.
Imagino que você esteja acostumado a desenvolver sistemas legados e por isso não irei sair deste escopo pois se partir para o lado dos sistemas de apoio a decisão, o XP realmente deixaria muito a desejar.
O que acontece é que se você desenvolve sistemas sem a devida documentação do Processo de negócio e todos os impactos que essas regras tem no sistema (seja orientado a objetos ou não) a manutenibilidade se torna muito crítica.
Imagine que você desenvolve um sistema contábil (e não simplesmente sites). Bom, se usarmos o XP como metodologia de desenvolvimento faríamos uma análise superficial do que é necessário desenvolver e em seguida partiríamos para o desenvolvimento.
Agora... quais são as leis que envolvem a contabilidade? O que foi levado em consideração para montar a lógica de negócios que irá, no final do processo, dizer ao administrador da empresa (usuário) que estamos tendo lucro e não prejuízo?
Dez anos se passaram após o sistema ter sido desenvolvido usando o XP. O sistema continua informando o saldo contábil da empresa.
Porém a lei mudou e agora o sistema que foi desenvolvido precisará ser alterado. E agora?
Conclusão: Neste caso é mais fácil refazer o sistema contábil pois existem diversas partes do código interligadas e não faz-se idéia do motivo de um método "getBalanceteMeioAno()" ter ligação com o método "setNaturezaOperacao()".
Você poderia me dizer: "Ué? Mas a natureza da operação faz parte do cálculo do balancete". Ai eu lhe pergunto: Isso na nova ou na antiga lei?
E isso pode ir muito mais longe pois usei um exemplo bem bobo, mas poderíamos ter um sistema que deverá corrigir o voo de um airbus para que o piloto não precise colocar as mãos no console para conduzir o avião de São Paulo para a Hong Kong. Já imaginou a infinidade de regras que existem para que isso seja feito?
Diagrama de classe nenhum irá conseguir explicar o motivo de algo ter sido feito de uma maneira X ou Y...
Mas tudo bem... a equipe XP poderá se reunir e dizer: "É... no caso do último avião que caiu as alterações não funcionaram... que tal se tentarmos retirar esse método?"
O buraco é mais embaixo.
Por isso digo: XP é bom? Muito... se você tiver bom senso na hora de usar. Se usa-lo para qualquer coisa achando que é a solução dos problemas dos engenheiros de software com certeza irá se surpreender em muito pouco tempo.
Um abraço e qualquer outra dúvida, envie que ficarei feliz em poder ajudar.
04/01/2005 10:36pm
(~20 anos atrás)
"Se por um lado isso é interessante, já que o projeto parte muito rapidamente para o desenvolvimento, por outro lado isso é muito ruim com relação a questão da manutenção do sistema.
Se temos um sistema desenvolvido utilizando o XP onde as regras de negócio são complexas, isso não estará devidamente documentado e consequentemente será como se estivéssemos tentando decifrar o alfabeto egípcio sem nem mesmo saber que é egípicio. "
Cara,
Esse comentário não faz o menos sentido.Me parece que não fizeram o tema de casa (ler e pesquisar) antes de comentar o assunto.
Se o XP não possui documentação, não é por bagunça, mas sim por que sua estrutura torna desnecessária esta burocracia.
Uma vez que todos os programadores conhecem o projeto, e o código, você tem o diagrama de classes e você está continuamente aprimorando o código, a documentação passa a ser apenas um monte de papel sem propósito.
Bom, é meu primeiro comentário neste site, abraços a todos!
Se temos um sistema desenvolvido utilizando o XP onde as regras de negócio são complexas, isso não estará devidamente documentado e consequentemente será como se estivéssemos tentando decifrar o alfabeto egípcio sem nem mesmo saber que é egípicio. "
Cara,
Esse comentário não faz o menos sentido.Me parece que não fizeram o tema de casa (ler e pesquisar) antes de comentar o assunto.
Se o XP não possui documentação, não é por bagunça, mas sim por que sua estrutura torna desnecessária esta burocracia.
Uma vez que todos os programadores conhecem o projeto, e o código, você tem o diagrama de classes e você está continuamente aprimorando o código, a documentação passa a ser apenas um monte de papel sem propósito.
Bom, é meu primeiro comentário neste site, abraços a todos!
22/12/2004 6:51am
(~20 anos atrás)
Caro amigo.
Estou começando a escrever uma série de artigos que abordam um problema, acredito eu, mais grave do que definição de metodologias desenvolvimento: O dspreparo para se pensar de forma lógica.
Vou te contar uma historinha curta e que servirá para você.
Tenho 40 anos e trabalhei profissionalmente com tecnologia por 15 anos (meu primeiro software vendido foi para uma farmácia e eu tinha 13 anos), de lá para cá fiz duas culdades (economia e direito) e em 1993 (com 30 anos portanto), percebi que apesar de estar fazendo o que eu mais gostava na vida, eu não ia ganhar dinheiro de verdade com software. Não sei porque mas algo subtamente me aconteceu e eu larguei um excelente emprego como analista de sistemas de uma grande companhia para me lançar em uma área que, apesar de ter feito alguns estágios, era desconhecida para mim: o Comércio Exterior.
Hoje sou proprietário de uma Trade Company com sede em Portugal onde moro, possuo filiais em mais de 20 países, escritórios em outros 18. Meu patrimônio acumulado nestes onze anos ultrapassa os US$ 50 milhôes e estou fazendo o que mais gosto de fazer. Programar e compartilhar meu conhecimento.
Como disse no início, estou programando em PHP a pouco mais de 25 dias, porém se perceber sou semdúvida nenhuma o campeão do site em respostas neste período.
Hoje passo meu dia com meu computador ligado neste forum e "dou meu espediente" pontualmente das 8:00 às 18:00.
Programar é minha vida mas devemos ser pragmáticos e saber que Bills Gates são ráros.
Para concluir meu pensameto percebo que muitas das vezes o que falta não é conhecimento da linguagem mas falta de raciocínio lógico para implementar.
Muitas questões poderiam ser respondidas rapidamente com uma rápida passada pla página da própria php (br.php.net/manual/pt_BR/ref.função que eu quero.php), mas eles não procuram ou não sabem nem mesmo o que estão procurando. Será preguiça mental, despreparo de raciocínio ou o que?
Li seu artigo e estou tentado a não mais escrever sobre este tema e deixar para que você, se achar interessante, abordar.
No mais permanecerei por aqui enquanto achar necessário.
Um grande abraço e parabéns.
Estou começando a escrever uma série de artigos que abordam um problema, acredito eu, mais grave do que definição de metodologias desenvolvimento: O dspreparo para se pensar de forma lógica.
Vou te contar uma historinha curta e que servirá para você.
Tenho 40 anos e trabalhei profissionalmente com tecnologia por 15 anos (meu primeiro software vendido foi para uma farmácia e eu tinha 13 anos), de lá para cá fiz duas culdades (economia e direito) e em 1993 (com 30 anos portanto), percebi que apesar de estar fazendo o que eu mais gostava na vida, eu não ia ganhar dinheiro de verdade com software. Não sei porque mas algo subtamente me aconteceu e eu larguei um excelente emprego como analista de sistemas de uma grande companhia para me lançar em uma área que, apesar de ter feito alguns estágios, era desconhecida para mim: o Comércio Exterior.
Hoje sou proprietário de uma Trade Company com sede em Portugal onde moro, possuo filiais em mais de 20 países, escritórios em outros 18. Meu patrimônio acumulado nestes onze anos ultrapassa os US$ 50 milhôes e estou fazendo o que mais gosto de fazer. Programar e compartilhar meu conhecimento.
Como disse no início, estou programando em PHP a pouco mais de 25 dias, porém se perceber sou semdúvida nenhuma o campeão do site em respostas neste período.
Hoje passo meu dia com meu computador ligado neste forum e "dou meu espediente" pontualmente das 8:00 às 18:00.
Programar é minha vida mas devemos ser pragmáticos e saber que Bills Gates são ráros.
Para concluir meu pensameto percebo que muitas das vezes o que falta não é conhecimento da linguagem mas falta de raciocínio lógico para implementar.
Muitas questões poderiam ser respondidas rapidamente com uma rápida passada pla página da própria php (br.php.net/manual/pt_BR/ref.função que eu quero.php), mas eles não procuram ou não sabem nem mesmo o que estão procurando. Será preguiça mental, despreparo de raciocínio ou o que?
Li seu artigo e estou tentado a não mais escrever sobre este tema e deixar para que você, se achar interessante, abordar.
No mais permanecerei por aqui enquanto achar necessário.
Um grande abraço e parabéns.
15/10/2004 4:48pm
(~20 anos atrás)
Muitas vezes não podemo seguir este tipo de "metodologia", não por nós desenvolvedores, mas sim por N fatores (dependendo da empresa).
Prazo do projeto - Nem sempre temos tempo para executar determinados passos
Custos - As vezes, para não atingir logo o numero de horas contradadas, os desenvolvedores, por pura "pressão da empresa", deixam de executar sequer uma metodoligia basica.
Eu conheço muita gente que quando pega um projeto para desenvolver, faz coisas do tipo, "modelar" o banco de dados de acordo com o desenvolvimento do sistema, ou seja, integridades, procedures, isto são coisas que pouco são utilizadas para este tipo de pessoas.
Bom, poderia escrever um monte de coisas aqui, mas não é necessário, achando eu que muita gente tambem conhece ou mesmo tenha passado por este tipo de situação.
Mas parabenizo o autor do artigo, pelo fato de abordar um assunto que dá muito pano para manga.
Abraço.
Prazo do projeto - Nem sempre temos tempo para executar determinados passos
Custos - As vezes, para não atingir logo o numero de horas contradadas, os desenvolvedores, por pura "pressão da empresa", deixam de executar sequer uma metodoligia basica.
Eu conheço muita gente que quando pega um projeto para desenvolver, faz coisas do tipo, "modelar" o banco de dados de acordo com o desenvolvimento do sistema, ou seja, integridades, procedures, isto são coisas que pouco são utilizadas para este tipo de pessoas.
Bom, poderia escrever um monte de coisas aqui, mas não é necessário, achando eu que muita gente tambem conhece ou mesmo tenha passado por este tipo de situação.
Mas parabenizo o autor do artigo, pelo fato de abordar um assunto que dá muito pano para manga.
Abraço.
12/09/2004 7:25pm
(~20 anos atrás)
Esse é um tema muito importante e abrangente. Parabéns pelo artigo, que dá a oportunidade de trocarmos idéias.
Acho apenas que a sua abordagem sobre a fase de programação poderia ser mais explorada. Muitas empresas adotam metodologias baseadas em diversas técnicas ou notações, e poucas criam padrões para o desenvolvimento, a construção. Não adianta nada ter um projeto excelente, bem documentado se o código é um lixo.
Programar bem não é fazer funionar. Também não é só usar o melhor algoritmo para executar uma função. Alguns pontos importantes a serem considerados:
- Declaração explícita das vairáveis, com comentários sobre suas utilidades, e com nomes significativos.
- SQLs bem construídos, levando-se em conta o uso dos indices.
- Documentação dos blocos de programa.
- Modularização e funções genéricas que possam ser reaproveitadas.
- Lógicas simples e necessárias.
- Encapsulamento do código.
- Identação.
- Padrão de interface (no projeto e entre projetos)
Abraços.
Alexandre
alexandrecampos.att_ps@petrobras.com.br
Acho apenas que a sua abordagem sobre a fase de programação poderia ser mais explorada. Muitas empresas adotam metodologias baseadas em diversas técnicas ou notações, e poucas criam padrões para o desenvolvimento, a construção. Não adianta nada ter um projeto excelente, bem documentado se o código é um lixo.
Programar bem não é fazer funionar. Também não é só usar o melhor algoritmo para executar uma função. Alguns pontos importantes a serem considerados:
- Declaração explícita das vairáveis, com comentários sobre suas utilidades, e com nomes significativos.
- SQLs bem construídos, levando-se em conta o uso dos indices.
- Documentação dos blocos de programa.
- Modularização e funções genéricas que possam ser reaproveitadas.
- Lógicas simples e necessárias.
- Encapsulamento do código.
- Identação.
- Padrão de interface (no projeto e entre projetos)
Abraços.
Alexandre
alexandrecampos.att_ps@petrobras.com.br
01/09/2004 2:40pm
(~20 anos atrás)