Concepção e design antes da codificação: quanto isso é verdade? [fechadas]

Aprendi na escola e li em todos os outros lugares que uma boa metodologia de desenvolvimento precisa de concepção e design antes de codificar corretamente.

Essa não é uma informação nova, mesmo para um programador iniciante. No entanto, gostaria de saber se este é um bom conselho, porque desde que comecei a desenvolver em várias linguagens de programação nunca consegui projetar e conceber tudo desde o início.

Eu sempre derreti design, concepção e programação. Eu sou o pior desenvolvedor do mundo ou a idéia que aprendemos na escola é apenas um velho dogma religioso sem sentido ?

Como podemos sequer conceber e projetar algo que nunca experimentamos e programamos antes? Isso não é ridículo? A programação não conduz a concepção e o design?

Acho que a resposta deve ser: planeje o máximo que puder, mas não mais do que isso.

Poucas pessoas se manifestariam contra as virtudes do planejamento, mas o debate negligencia principalmente um aspecto importante. O planejamento funciona apenas na medida em que você tem a habilidade de fazer um bom plano; essa habilidade costuma vir com experiência. Se você não tem muita experiência, qualquer plano que você elaborar provavelmente terá uma quantidade razoável de problemas, isso significa que, para criar um produto que não seja um desastre total, o plano precisará ser revisado fortemente durante o desenvolvimento, se o plano for detalhado, isso provavelmente invalidará muitos detalhes, ou pior, você tentará manter os ajustes no mínimo para poder seguir o plano.

Definitivamente, algumas coisas exigem planejamento, e se você não tem a habilidade de fazer o nível de plano necessário, o único caminho a seguir que posso imaginar é a criação de protótipos, escrevendo código simplesmente para ganhar experiência com a tarefa necessária para fazer um plano adequado. .

Esteja você pronto ou não para escrever o código de produção, depois de atingir seu nível máximo de planejamento, não há mais nada a fazer além de codificação. Talvez seja um desastre, mas essas são boas experiências de aprendizado e você estará muito melhor equipado para fazer um plano revisado.

Isso é absolutamente verdade. Quanto maior e mais complexo o requisito, mais verdadeiro é.

Para um aplicativo de console pequeno calcular a sequência de Fibonacci, talvez você não precise mais do que alguns minutos pensando em como estruturar o algoritmo e a interface do usuário (que, sim, podem ser simplesmente stdin e stdout).

Mas e quanto a uma plataforma de negociação em tempo real que se espera realizar milhões de transações por segundo, distribuídas globalmente e que exijam 99.9999 de tempo de atividade e 100% de correção? Você poderia simplesmente codificar isso?

Existem muitas outras opções entre esses dois extremos.

Dê uma olhada no projeto Euler . Resolva alguns problemas, na sequência apresentada. Você descobrirá que, para resolver alguns dos problemas em tempo razoável, é necessário pensar antes de entrar no código.

Se você não precisa de tempo para pensar e criar seu programa antes de começar a codificar, está trabalhando em coisas triviais ou perdendo algo maior.

Eu nunca consegui projetar e conceber tudo desde o início

Ninguém faz nada além do mais trivial dos problemas. Novamente, quanto maior e mais complexo o projeto, mais verdadeiro é - os projetos terão erros, coisas que serão esquecidas etc.

A arte consiste em projetar em alto nível primeiro, verificando se as peças grandes se encaixam. Em seguida, obtenha uma lista de prioridades - começando a trabalhar primeiro na infraestrutura / infraestrutura mais crucial. Em seguida, dividimos as peças maiores por outras menores, garantindo que cada peça maior seja composta por peças que façam sentido.

Isso exige tempo e esforço - e pode não estar completo ou totalmente correto no início.

Mas é por isso que ele é chamado suave -ware e não dura -ware. É maleável e pode ser alterado.

Aprendi na escola e li em todos os outros lugares que uma boa metodologia de desenvolvimento precisa de concepção e design antes de codificar corretamente.

Isso é verdade.

No entanto, gostaria de saber se este é um bom conselho, porque desde que comecei a desenvolver em várias linguagens de programação nunca consegui projetar e conceber tudo desde o início.

E aí está o seu problema.

Para a maioria dos problemas não triviais, você precisará pensar um pouco para descobrir como as coisas vão funcionar - como as coisas vão se encaixar. Paradoxalmente, para a maioria dos problemas não triviais, não há como você planejar tudo . Há muita coisa desconhecida para você explicar, muitas mudanças que ocorrerão durante o desenvolvimento. O Agile ganhou força porque aceita esta segunda metade do acordo: as pessoas não são oniscientes e as mudanças são constantes.

Portanto, é certamente verdade que você precisa criar o projeto com antecedência, mas também é verdade que é impossível projetar apenas com antecedência.

Você absolutamente deve ter algum design antes de codificar.

O motivo é bem direto - se você não tem nenhum design, não sabe o que está fazendo .

Você absolutamente deve ter algum código antes que o design seja final.

O motivo é bem direto - o design mudará e o desenvolvimento de partes do design revelará perguntas, oportunidades e desafios difíceis de antecipar sem começar a trabalhar na solução.

O desenvolvimento é iterativo.

Seja por planejamento ou não, se a equipe percebe ou não, todo projeto de software é executado de forma iterativa - parte do trabalho é concluída e, em seguida, avaliada, e a avaliação leva a mudanças na maneira como o restante do trabalho é realizado.

Tente mais de uma abordagem.

É preciso prática e experiência para saber a melhor maneira de equilibrar o design inicial com a criação de código. É uma habilidade que quase ninguém dominou e cada projeto terá ideais diferentes (considere projetar uma pequena ferramenta para seu próprio uso, em comparação com uma equipe que cria um produto grande e de lançamento único, como um grande videogame).

Projetei e observei que outros projetavam vários sistemas no passado e vi o processo se desenrolar de muitas maneiras diferentes, mas o que acho comum é que a arquitetura inicial deve ao menos planejar a existência da maioria dos recursos principais.

Por exemplo, eu vi um sistema de controle de HVAC que não tinha o conceito de prédios, pisos, salas etc. sendo adaptados a eles e o resultado foi tão feio quanto possível. Ou um dispositivo de música móvel construído a partir de componentes mais adequados para o seu relógio de bolso (não inteligente). Escusado será dizer que os produtos finais em ambos os casos não eram os favoritos dos clientes.

Quando você diz "concepção", isso é apenas um passo acima da "idéia" e um conceito pode ser muito confuso. Os negócios geralmente se preocupam com conceitos. Os clientes geralmente se preocupam com o UX - um conceito trazido à realidade de uma maneira fácil e agradável de usar e que agrega algum valor ao seu uso.

Você precisa fazer o "conceito" antes de qualquer programação. Não consigo me imaginar abrindo o visual studio (ou seu IDE de sua escolha) e escrevendo código aleatoriamente, para ver aonde ele vai.

Você não pode fazer um design completo (nem deveria) antes da codificação, mas deve ter um esboço aproximado do fluxo de trabalho do usuário.

O design e a codificação de UX geralmente se alimentam mutuamente, você provavelmente será forçado a usar alguma abordagem ágil para qualquer coisa, exceto o menor dos projetos, como uma maneira de incorporar esse fato à maneira como aborda o trabalho. Portanto, não pense que você é o pior dos programadores se não puder ver tudo de uma vez - ninguém pode e as pessoas que pensam que podem são as que ignoram o suficiente do problema para poderem afirmar que têm um programa completo. cenário.

Um exemplo para colocar um tamanho em algo grande. Conceito: "Crie uma ferramenta visual baseada em nuvem que permita às empresas integrar suas plataformas de software". Parece ótimo e é possível começar a escrever material de marketing e vendê-lo antes mesmo de ele estar lá. Você precisa ter isso antes de codificar.

Pré-design: "Possui formas e setas como no Visio para descrever a lógica; possui recursos de plug-in para permitir conexões com várias plataformas (SAP, SF, bancos de dados ...); possui um console de monitoramento onde é possível pesquisar dados que passam pelo sistema; ter uma maneira de descrever os dados visualmente e transformar um formato para outro ". Outra grande bolha de marketing. Também fornece algumas idéias sobre o que é importante; deve ter um esboço tão bruto antes da codificação também.

Design / Código: "Tenha um navegador hospedado um designer de HTML com esses e outros recursos; codifique o back-end em Java para que ele possa ser executado em qualquer servidor existente; defina estruturas de dados e UX para consultá-los ou modificá-los conforme necessário; planeje recuperação de desastre, erro relatórios, registro de auditoria; controle de versão do plano; controle de acesso do plano; .... "- quanto mais fina a lista, mais irrealista é prever tudo isso.

... no entanto, deve-se estar ciente de como as coisas podem acabar parecer grosseiras ou o seu produto final pode acabar com algumas implementações realmente inúteis que acabam matando o conceito de ótima aparência - digamos que seu designer visual exija 40 " tela para mostrar qualquer fluxo de trabalho do mundo real ou não há como pesquisar os logs além de uma correspondência exata de string limitada a um dos 20 campos do log etc. etc. Não há uma boa maneira de impedir que isso aconteça além de executar sua implementação - alguns terão sucesso, outros irão falhar.

Eu sempre atribuo tempo da seguinte maneira:

1. 1/3 Desenho
2. 1/3 Desenvolvimento
3. 1/3 Teste

Design: não apenas visual, mas também conceitual. Divida-o em partes, visualmente e pela lógica. Procure pontos em comum que são reutilizados e são um padrão de design em si.

Desenvolvimento: Depois de conhecer suas peças, codifique-as. Então você os integra.

Teste: não apenas testando se o código foi integrado e escrito adequadamente, invariavelmente haverá insights descobertos e lições aprendidas, além de criar novas maneiras de interagir, novos recursos serão concebidos e desejados. Cuidado com a oscilação do escopo.

Além desses aspectos, lembre-se de que um projeto também possui três fases além dessas.

1. A primeira tentativa de engenharia
2. A segunda tentativa de engenharia excessiva, a partir das lições aprendidas na 1ª tentativa.
3. A terceira tentativa corretamente projetada.

Descobri que quanto melhor você faz a fase de design, ela minimiza as tentativas adicionais. Em vez de refazer a coisa toda, você pode ter apenas um subsistema que é reformulado.

Sou desenvolvedor de software e gerente de desenvolvimento de software para projetos internos, terceirizados e de desenvolvimento offshore.

Há uma suposição incorreta fundamental aqui. Você nunca será capaz de criar um bom design sem escrever primeiro o código (a escola nunca ensinará isso). No entanto, a escola está certa de que você não obterá um bom código sem o design.

A solução é:

1. Escreva algum código que você acha que pode resolver o problema.
2. Crie um design com base no que aprendeu com o código.
3. Jogue fora todo o código e reescreva-o do zero, de acordo com o design.
4. Repita conforme necessário.

Jogar fora todo o código não é uma etapa opcional nesse processo, mas para pequenos projetos, formalmente, escrever o design pode ser. Para projetos grandes, é mais provável que você repita a etapa " jogar fora todo o código " - embora se você tiver modularidade suficiente, isso poderá se aplicar apenas a parte da base de código.

Muitos projetos se apegam ao código legado porque não estão dispostos a alterá-lo - ou porque é muito complicado, porque nunca foi projetado para ser jogado fora. Reconhecer o fato de que sua primeira tentativa será um fracasso tornará sua vida muito melhor.

concepção é o design chave sempre pode ser alterado a programação terá que atender aos requisitos do aplicativo totalmente concebido.

1º qual é o ponto; 2º como ele precisa ser acessado; 3º quem é o usuário; 4º? e como cada função que você adicionar funcionará.

antes de fazer qualquer escolha quanto à arquitetura do seu aplicativo Web, planeje e pense completamente.

então escolha a melhor pilha

Sou desenvolvedor LAMP

então eu tendem a restringir a questão para qual framework php eu vou usar. e os scripts de front-end necessários para que ele faça todas as coisas necessárias da maneira ideal

para adicionar isso, aprenda a usar estruturas MVC, ZEND e CAKEPHP são as melhores estruturas de desenvolvimento rápido (PHP)