Como você começa a projetar um grande sistema?[fechado]

StackOverflow https://stackoverflow.com/questions/15690

  •  08-06-2019
  •  | 
  •  

Pergunta

Foi-me mencionado que serei o único desenvolvedor por trás de um grande sistema novo.Entre outras coisas, projetarei uma UI e um esquema de banco de dados.

Tenho certeza de que receberei alguma orientação, mas gostaria de poder impressioná-los.Enquanto isso, o que posso fazer para me preparar e o que preciso ter em mente quando me sentar em frente ao computador com as especificações?

Algumas coisas para manter em mente:Sou um estudante universitário em meu primeiro trabalho real de programação.Estarei usando Java.Já temos o SCM configurado com testes automatizados, etc...então as ferramentas não são um problema.

Foi útil?

Solução

Você sabe muito sobre OOP?Se sim, dê uma olhada no Spring e no Hibernate para manter sua implementação limpa e ortogonal.Se você conseguir isso, verá que o TDD é uma boa maneira de manter seu design compacto e enxuto, especialmente porque você tem "testes automatizados" em funcionamento.

ATUALIZAR:Olhando para a primeira série de respostas, não poderia discordar mais.Particularmente no espaço Java, você deve encontrar muitos mentores/recursos para trabalhar seu aplicativo com objetos, não é uma abordagem centrada em banco de dados.O design do banco de dados normalmente é o primeiro passo para o pessoal da Microsoft (o que faço diariamente, mas estou em um programa de recuperação, er, Alt.Net).Se você mantiver o foco no que precisa entregar a um cliente e deixar seu ORM descobrir como persistir seus objetos, seu design deverá ser melhor.

Outras dicas

Isso parece muito com meu primeiro emprego.Logo após a universidade, fui solicitado a projetar o banco de dados e a camada de lógica de negócios, enquanto outras pessoas cuidariam da interface do usuário.Enquanto isso, o chefe olhava por cima do meu ombro, sem vontade de abrir mão do que antes era seu bebê e agora era meu, e enfiava o dedo nele.Três anos depois, os desenvolvedores estavam fugindo da empresa e ainda faltavam X meses para realmente vendermos qualquer coisa.

O grande erro foi ser demasiado ambicioso.Se este for seu primeiro emprego, você vai comete erros e você vai precisa mudar a forma como as coisas funcionam muito depois de escrevê-las.Tínhamos todos os tipos de recursos que tornavam o sistema mais complicado do que o necessário, tanto no nível do banco de dados quanto na API que ele apresentava a outros desenvolvedores.No final, a coisa toda era complicada demais para suportar de uma só vez e simplesmente morreu.

Então meu conselho:

  1. Se você não tem certeza de assumir um trabalho tão grande sozinho, não faça isso.Informe seus empregadores e peça-lhes que encontrem ou contratem alguém para trabalhar com você e que possa ajudá-lo.Se for necessário adicionar pessoas ao projeto, isso deve ser feito próximo ao início, e não depois que as coisas começarem a dar errado.

  2. Pense com muito cuidado sobre a finalidade do produto e reduza-o ao mais simples conjunto de requisitos que você pode imaginar.Se as pessoas que forneceram as especificações não forem técnicas, tente ver além do que escreveram e ver o que realmente funcionará e ganhará dinheiro.Converse com clientes e vendedores e entenda o mercado.

  3. Não há vergonha em admitir que você está errado.Se acontecer que todo o sistema precisa ser reescrito, porque você cometeu algum erro na sua primeira versão, então é melhor admitir isso o mais rápido possível para que você possa começar.Da mesma forma, não tente criar uma arquitetura que possa antecipar todas as contingências possíveis em sua primeira versão, porque você não sabe o que é cada contingência e simplesmente errará.Escreva uma vez pensando em jogar fora e começar de novo - talvez não seja necessário, a primeira versão pode servir, mas admita se o fizer.

Também discordo de começar com o banco de dados.O banco de dados é simplesmente um artefato de como seus objetos de negócios são persistidos.Não conheço nenhum equivalente em Java, mas .Net possui ferramentas excelentes, como SubSônico que permitem que o design do seu banco de dados permaneça fluido enquanto você itera no design dos objetos de negócios.Eu diria que antes de mais nada (mesmo antes de decidir quais tecnologias introduzir) concentre-se no processo e identifique seus substantivos e verbos...em seguida, construa a partir dessas abstrações.Ei, realmente funciona no "mundo real", assim como o OOP 101 lhe ensinou!

Antes de começar a codificar, planeje o esquema do seu banco de dados - todo o resto fluirá a partir disso.Obter o banco de dados razoavelmente correto desde o início economizará tempo e dores de cabeça mais tarde.

O principal é ser capaz de abstrair a complexidade do sistema para que você não fique atolado nele assim que começar.

  • Primeiro leia as especificações como uma história (folheando-as).Não pare em cada requisito para analisá-lo ali mesmo.Isso permitirá que você obtenha uma visão geral do sistema sem muitos detalhes.Neste ponto você começaria a identificar os principais componentes funcionais do sistema.Comece a anotá-los (use uma ferramenta de mapa mental, se desejar).

  • Em seguida, pegue cada componente e comece a explodi-lo (e vinculando cada detalhe aos requisitos do documento de especificações).Faça isso para todos os componentes, até atender a todos os requisitos.

  • Agora, você deve começar a observar os relacionamentos entre os componentes e se há repetições de recursos ou funções nos vários componentes (que você pode extrair para criar componentes utilitários ou algo assim).Agora, você terá um bom mapa detalhado de suas necessidades em mente.

  • AGORA, você deve pensar em projetar o banco de dados, diagramas ER, design de classes, DFDs, implantação, etc.

O problema de executar primeiro a última etapa é que você pode ficar atolado na complexidade do seu sistema sem realmente obter uma compreensão geral.

Eu faço o contrário.Acho que fazer isso primeiro com o esquema do banco de dados deixa o sistema preso em um design orientado a dados que é difícil de abstrair da persistência.Tentamos fazer designs de modelos de domínio primeiro e então baseie o esquema do banco de dados neles.

E depois há o design da infraestrutura:a equipe deve, em primeiro lugar, estabelecer convenções sobre como estruturar o programa.E então trabalhamos juntos para chegar a um acordo sobre um design para a funcionalidade comum do sistema (por exemplo, coisas que todos precisam, como persistência, registro, etc.).Esta se torna a estrutura do sistema.

Todos nós trabalhamos nisso juntos primeiro, antes de dividirmos o resto das funcionalidades entre nós.

Pela minha experiência, os aplicativos Java (também .NET) que consideram o banco de dados por último têm grande probabilidade de apresentar desempenho insatisfatório quando colocados em um ambiente corporativo.Você precisa realmente pensar no seu público.Você não disse se era um aplicativo web ou não.De qualquer forma, a infraestrutura que você está implementando é importante ao considerar como você lida com seus dados.

Não importa qual metodologia você considere, como você obtém e salva seus dados e seu impacto no desempenho devem estar entre suas prioridades nº 1.

Sugiro pensar em como esse aplicativo será usado.Como os futuros usuários trabalharão com isso?Tenho certeza que você sabe pelo menos algumas coisas sobre o que esse aplicativo precisa lidar, mas meu primeiro conselho é "pense no usuário e no que ele precisa".

Desenhe em papel comum, pensando em onde dividir o código.Lembre-se de não misturar lógica com código GUI (erro comum).Dessa forma, você estará pronto para estender o alcance de seus aplicativos no futuro para servlets e/ou miniaplicativos ou qualquer plataforma que surgir.Divida em camadas para que você possa responder a grandes mudanças com mais rapidez, sem reconstruir tudo.As camadas não devem ver nenhuma outra camada além das camadas vizinhas mais próximas.

Comece com a verdadeira funcionalidade central.Todo esse tempo demorado (que atrasará seu projeto em 4 semanas) não importará muito para a maioria dos usuários.Ele pode ser adicionado mais tarde, quando você tiver certeza de que pode entregar no prazo.

Por falar nisso.Mesmo que isso não tenha nada a ver com design, gostaria apenas de dizer que você não entregará no prazo.Faça uma estimativa realista do consumo de tempo e depois duplique-o :-) Presumo aqui que você não estará sozinho neste projeto e que as pessoas irão e virão conforme o projeto avança.Pode ser necessário treinar pessoas no meio do projeto, as pessoas vão de férias/precisam de cirurgia, etc.

Divida o grande sistema em pedaços menores.E não pense que é tão complexo, porque geralmente não é.Pensar muito complexo apenas estraga seus pensamentos e, eventualmente, o design.Em algum momento você simplesmente percebe que poderia fazer a mesma coisa com mais facilidade e então redesenha-a.

Pelo menos este foi meu maior erro no design.

Mantenha simples!

Encontrei ideias muito perspicazes sobre como iniciar um novo grande projeto, com base em

  • boas práticas comuns
  • Desenvolvimento orientado a testes
  • e abordagem pragmática

no livro Crescente software orientado a objetos, guiado por testes.

Ainda está em desenvolvimento, mas os primeiros 3 capítulos podem ser o que você está procurando e, IMHO, vale a pena ler.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top