Design e Codificação - de cima para baixo ou de baixo para cima? [fechadas]

Question

Quando a codificação, o que, em sua experiência é uma abordagem melhor?

1. Quebre o problema em pedaços pequenos o suficiente e, em seguida, implementar cada peça.
2. Quebrar o baixo problema, mas, em seguida, implementar usando uma abordagem de cima para baixo.
3. Qualquer outro?

Answer 1

Aqui está o que eu faço:

Compreender o domínio em primeiro lugar. Entender o problema a ser resolvido. Certifique-se de que você eo cliente (mesmo se o cliente é você!) Estão na mesma página, como o que problema deve ser resolvido.

Em seguida, uma solução de alto nível é proposta para o problema a partir daí, o projeto vai se transformar em bolhas ou balas em uma página ou qualquer outra coisa, mas o ponto é que ele vai sacudir em componentes que podem ser projetados.

Nesse ponto, eu escrever testes para as classes ainda a ser escrito e, em seguida, carne para fora as classes para passar esses testes.

Eu uso uma abordagem de teste-primeiro e construção de trabalho, componentes testados. Isso é o que funciona para mim. Quando as interfaces de componentes são conhecidos e são conhecidos as 'regras' de como eles falam uns com os outros e prestar serviços a outro, então torna-se geralmente um 'tudo o gancho juntos' simples exercício.

Isso é como eu fazê-lo, e tem funcionado bem para mim.

Answer 2

I tendem a projetar top-down e implementar bottom-up.

Para a implementação, construindo as menores peças funcionais e montá-los em estruturas de nível superior parece ser o que funciona melhor para mim. Mas, para o projeto, eu preciso para começar a partir do quadro geral e decompô-lo para determinar o que essas peças vão ser.

Answer 3

Você pode querer olhar sobre o Agile Manifesto . De cima para baixo e para cima fundo são baseadas em Built It All At Once concepção e construção.

O "software de Trabalho sobre documentação abrangente", a primeira coisa que você construção é a coisa útil menor você pode começar a funcionar. Topo? Inferior? Nem.

---

Quando eu era jovem, trabalhei em projetos que estavam - por contrato - estritamente de cima para baixo. Isso não funciona. Na verdade, ele não pode trabalhar. Você começa montanhas do design redundante e código como resultado. Não foi uma boa abordagem, quando aplicada sem pensar.

O que eu notei é que a abordagem Agile - pequenos pedaços que funcionam - tende a dividir o problema em partes que podem ser captadas de uma vez. A top-down / bottom-up já não importa tanto. Na verdade, ele pode não importa a todos.

O que leva fazer: "Como você se decompor para o desenvolvimento Agile" O truque é evitar a criação de A Big Thing que você deve então se decompor. Se você analisar um problema, você encontrar atores tentando realizar os casos de uso e falhando porque não tem todas as informações, ou eles não tem isso no tempo, ou eles não podem executar suas decisões, ou algo parecido.

Muitas vezes, estes não são grandes coisas que precisam de decomposição. Quando eles estão, você precisa trabalhar com o problema nos Metas Backward de direção. De Metas para coisas que permitem que você faça esse objetivo para as coisas que permitem que os facilitadores, etc. Uma vez que os objetivos são muitas vezes grandes coisas, isso tende a ser Top Down -. Da meta geral de negócios para processos de negócios detalhado e passo

Em algum momento, nós visão geral essas várias etapas que levam à objetivos. Nós fizemos a parte de análise (quebrar as coisas). Agora vem a parte síntese: nós remontar o que temos em coisas que podemos realmente construir. A síntese é de baixo para cima. No entanto, não vamos deixar levar. Temos vários pontos de vista, cada um dos quais é diferente.

Temos um modelo. Isso é muitas vezes construída a partir de detalhes em um modelo conceitual maior. Então, às vezes decomposto novamente em um modelo normalizado para OLTP. Ou decomposto em um esquema em estrela normalizado para OLAP. Então nós trabalhamos backup para criar um mapeamento ORM do modelo normalizado. Up - Down -. Up

Temos de processamento. Isso é muitas vezes construída a partir de resumos dos processos de negócio para baixo em detalhes de etapas de processamento. Em seguida, o software é projetado em torno dos passos. Então, o software é dividido em classes e métodos. Down - Up -. Baixo

[ Digressão . Com os usuários esclarecidos, esta decomposição define novos títulos de trabalho e formas de trabalho. Com os usuários não esclarecidos, os velhos empregos ficar e nós escrevemos montanhas de documentação para mapear trabalhos antigos para o novo software.]

Temos componentes. Nós muitas vezes olha para as peças, olhe para o que sabemos sobre os componentes disponíveis, e fazer um tipo de correspondência. Este é o processo randomest; É semelhante à maneira como cristais formar - existem centros de nucleação e o tipo de design de solidifica em torno desses centros. Serviços web. Base de dados. Gestão transação. Atuação. Volume. Diferentes características que de alguma forma nos ajudar a escolher os componentes que implementam alguns ou todos da nossa solução. Muitas vezes se sente bottom-up (de recurso ao produto), mas, por vezes, de cima para baixo ( "Eu estou segurando um martelo, chamada tudo um prego" == usar o RDBMS para tudo.)

Por fim, temos de código. Isto é até inferior. Mais ou menos. Você tem que definir uma estrutura de pacote. Você tem que definir classes como um todo. Essa parte foi de cima para baixo. Você tem que escrever métodos, dentro das classes. Costumo fazer isso de baixo para cima - rough o método, escrever um teste de unidade, terminar o método. Áspero fora o próximo método, escrever um teste de unidade, terminar o método.

O princípio de condução é Agile - construir algo que funciona. Os detalhes são todos over o mapa - cima, baixo, frente, para trás, dados, processo, ator, área temática, o valor do negócio

.

Answer 4

Sim. Fazer todas essas coisas.

Pode parecer sarcástico (desculpe, eu reverter para a forma), mas este é realmente um caso em que não existe uma resposta certa.

Answer 5

Também na forma ágil, escrever seu teste (s) primeiro!

Em seguida, todo o software é um ciclo contínuo de

• Red - o código de falha no teste
• Green - o código passa o teste
• Refactor -. Melhorias de código que são de preservação da intenção

defeitos, novos recursos, alterações. Tudo segue o mesmo padrão.

Answer 6

A sua opção 2 é uma forma razoável para ir. Se você quebrar o baixo problema em pedaços compreensíveis, de cima para baixo abordagem irá revelar quaisquer grandes falhas de projeto antes de implementar todos os pequenos detalhes. Você pode escrever topos de menor funcionalidade nível para manter tudo pendurado juntos.

Answer 7

Eu acho que há mais a considerar que versos top- projeto bottom-down. Você, obviamente, precisa quebrar o projeto em unidades manejáveis ??de trabalho, mas você também precisa considerar a priorização etc. E em um projeto de desenvolvimento iterativo, muitas vezes você vai redefinir o problema para a próxima iteração, uma vez que você entregou a solução para o anterior .

Answer 8

Ao projetar, eu gosto de fazer meio-out. Eu gosto de modelar o domínio, então projetar as aulas, passar para o banco de dados e interface de lá. Se existem características específicas que são UI baseada ou baseados em banco de dados, eu posso projetar os da frente também.

Quando a codificação, eu geralmente gosto de fazer bottom-up (de banco de dados em primeiro lugar, em seguida, entidades empresariais, então UI), se possível. Acho que é muito mais fácil de manter as coisas em linha reta com este método.

Answer 9

Acredito que com bons designers de software (e na minha opinião todos os desenvolvedores de software também deve ser designers de software em algum nível), a magia está em ser capaz de fazer top-down e bottom-up ao mesmo tempo.

O que eu estava "educado" para fazer por meus mentores é começar por muito breve top-down para entender as entidades envolvidas, em seguida, mover para baixo para cima para descobrir os elementos básicos que querem criar, em seguida, fazer backup e ver como eu posso ir um baixo nível, sabendo o que eu sei sobre os resultados do meu-se inferior, e assim por diante até que "eles se encontram no meio".

Espero que ajude.

Answer 10

O projeto fora para dentro.

Você começa com o que você está tentando alcançar na extremidade superior, e você sabe o que você tem para trabalhar com na extremidade inferior. Continue trabalhando ambas as extremidades até que eles se encontram no meio.

Answer 11

Eu meio que concordar com todas as pessoas dizendo "não", mas todo mundo cai em algum lugar no espectro.

Eu sou mais um top-down tipo de cara. I escolher um recurso de alto nível / ponto / whatever e implementá-lo como um programa completo. Isto deixa-me esboçar um plano e estrutura básica dentro dos limites do domínio do problema.

Então eu começar com outra característica e refatorar para fora tudo a partir do original que pode ser usado pelo segundo em entidades nova e partilhada. Ensaboe, enxague, repita até pedido está completo.

No entanto, eu conheço um monte de pessoas que são caras se bottom, que ouvem um problema e começar a pensar em todos os subsistemas de apoio que poderiam precisar para construir a aplicação em cima dela.

Eu não acredito que qualquer abordagem é certo ou errado. Ambos podem alcançar resultados. Eu até tentar encontrar caras se bottom para trabalhar, como podemos atacar o problema a partir de duas perspectivas diferentes.

Answer 12

Ambos são aproximações válidas. Às vezes, um apenas "sente" mais natural do que o outro. No entanto, há um grande problema: alguns idiomas principais e, especialmente, suas estruturas e bibliotecas realmente muito em suporte IDE, como destaque de sintaxe, tipo de fundo verificação, compilação de fundo, a conclusão de código inteligente, IntelliSense e assim por diante .

No entanto, isso não funciona com top-down codificação! No top-down de codificação, você usa constantemente variáveis, campos, constantes, funções, procedimentos, métodos, classes, módulos, os traços, mixins, aspectos, pacotes e tipos que você ainda não implementaram! Então, o IDE será constantemente gritar com você por causa de erros de compilação, não será vermelho linhas onduladas em todos os lugares, você vai ter nenhuma conclusão de código e assim por diante. Assim, o IDE praticamente proíbe você de fazer a codificação de cima para baixo.

Answer 13

Eu faço uma variante de cima para baixo. I tendem a tentar e fazer a interface primeiro - Eu, então, usar isso como minha lista de características. O que é bom sobre esta versão é, ele ainda funciona com IDE que de outra forma reclamar. Apenas comentar a chamada uma função para o que ainda não foi implementado.