Quantos detalhes colocar na primeira iteração do projeto?

Acabei de iniciar um novo projeto pessoal (Python) e estou escrevendo o que equivale a um "rascunho" do programa, o mínimo necessário para fazer o que eu quero fazer. Ainda não estou inserindo um extenso tratamento de erros / exceções ou elementos estéticos de interface do usuário (mesmo nos casos em que sei que essas coisas serão necessárias), e a documentação é suficiente para ajudar no futuro a ver o que estava fazendo.

É contra qualquer princípio definido de design / gerenciamento de projeto começar tão difícil? Eu sou um cientista, não um programador, por isso não estou a par dessas coisas. Portanto, a principal questão é: existe um consenso sobre onde se deve procurar cair entre os dois extremos de:

1. Escreva um código completo e de alta qualidade desde o início, com todo o tratamento de exceções e de forma que você saiba que será necessário.

2. Escreva um rascunho minimamente funcional desde o início e preencha todas as minúcias mais tarde.

Pergunta relacionada: Quando é correto sacrificar a "limpeza" do design para concluir um projeto?

Não existe uma resposta única, pois isso depende inteiramente do projeto. Precisamos pensar em duas coisas aqui. Qual é o seu objetivo final? Como você espera chegar lá?

Resultado final

Você está escrevendo o software de controle Mars Orbiter? Então é melhor você se certificar de que está escrevendo o código mais robusto possível. É melhor verificar se todas as exceções são tratadas de maneira sã.

Você está escrevendo um programa que somente você executará e só executará manualmente de vez em quando? Então não se preocupe com exceções. Não se preocupe com a arquitetura pesada. Faça com que funcione até o ponto em que funciona para você.

Como você espera chegar lá?

Você está desenvolvendo pesado desenvolvimento em cascata, onde gasta muito tempo descobrindo o que é necessário e depois passa meses desenvolvendo? Nesse caso, você deseja atingir a qualidade alvo mencionada acima com bastante antecedência. Obtenha toda a infraestrutura de verificação de erros planejada no início.

Você está desenvolvendo um forte desenvolvimento ágil, no qual está montando algo por uma semana ou duas, que será mostrado às partes interessadas, que podem solicitar revisões radicais e onde você espera poder repetir vários sprints de uma a duas vezes até você acertar o alvo? Pode ser melhor conseguir algo funcionando, mas é frágil rapidamente e adiciona cintos e suspensórios à medida que os requisitos do produto se solidificam.

Se você estiver no controle sobre a decisão em cascata ou ágil (que na verdade é um continuum, não uma escolha binária), tome essa decisão com base nas alterações esperadas. Se você tem certeza de que sabe exatamente como será o resultado final, a cascata é sua melhor escolha. Se você tiver apenas uma vaga noção do que precisa terminar, o ágil é sua melhor escolha. (Atualmente, o Agile é mais popular não porque é inerentemente melhor, mas porque a segunda situação é muito mais comum.)

Agora encontre sua própria resposta

Para a maioria, a resposta estará em algum lugar no meio. Responda a ambas as perguntas sobre o seu projeto, e ele deve levar você a uma direção básica.

Posso dizer isso por mim mesmo, se eu escrevo frequentemente scripts únicos que são abismalmente projetados e não têm erro ao verificar o que quer que seja. Eu também manuseio o código de produção, onde a manipulação e a arquitetura de erros recebem grande atenção. Tudo depende do que você está fazendo.

Uma ressalva final: se você decidir que está executando scripts únicos que podem ser feitos com rapidez e sujeira, verifique se. Infelizmente, muitas vezes acontece que scripts rápidos e sujos, que fazem algo interessante, são aproveitados para uso amplo quando outros os percebem. Certifique-se de que, quando isso acontecer, seja dado tempo para o endurecimento.

Todos os conceitos e padrões de design e codificação de software surgem em resposta a algum problema. O padrão ou conceito é uma solução para esse problema. Com o tempo, alguns padrões se tornam "bem conhecidos" como soluções preferíveis porque resolvem o problema de uma maneira que atende a certos requisitos de consistência, familiaridade, desempenho, manutenção e assim por diante.

Daqui resulta que, se o problema que o padrão de software pretende resolver não existir no seu software específico, você não precisará do padrão. Além disso, qualquer discussão sobre quais padrões seu software pode precisar também deve incluir discussões detalhadas sobre o software proposto: o que ele deve fazer? Qual problema isso resolve? Quantos usuários haverá? Os usuários compartilharão dados de alguma forma? E assim por diante.

O problema que as exceções devem resolver é quando algo acontece que o código não pode fazer nada. Um exemplo seria uma operação Arquivo / Abrir, na qual é especificado um nome de arquivo que não existe na mídia de armazenamento. As exceções fornecem ao código uma maneira de dizer ao chamador "Aconteceu algo que me impede de continuar e não há nada que eu possa fazer sobre isso, então estou desistindo". Se você não tiver nenhum local no seu código onde existam condições como essa, não precisará de exceções. Ou, você pode simplesmente retornar um código de erro e evitar a exceção completamente.

À medida que você ganha experiência, aprenderá sobre padrões de software e quando o uso deles é apropriado. Você também saberá quanto projeto inicial você precisa; novamente, isso depende totalmente do aplicativo que você está escrevendo. Pequenos utilitários são escritos de uma maneira fundamentalmente diferente de grandes aplicativos corporativos, em outras palavras.

Existe uma abordagem muito simples e prática para isso, que funciona para uma ampla gama de projetos de pequeno a médio porte. Mesmo que provavelmente não funcione bem para a Mars Explorers.

Primeiro, decida o que você quer que o sistema faça e anote cada um dos recursos individuais. Isso pode ser tão sofisticado quanto um storyboard de usuário inteiro ou tão simples quanto alguns pontos marcados em um pedaço de papel à sua frente. Mas é importante que você saiba o que deseja fazer.

Com base nisso, elaborar a estrutura geral do sistema. Novamente, esse é apenas um desenho rápido das diferentes classes / módulos e de como elas se relacionam, mas pode ser tão complexo quanto um documento inteiro. O importante é que você tenha algum tipo de idéia de como implementará o sistema. Mas isso provavelmente será aprimorado à medida que você trabalha, portanto, não tente ir para o complexo e detalhado.

De todos esses recursos, descubra quais são as principais coisas que o programa precisa fazer - os principais recursos.

Em seguida, implemente-os um por um. Agora, o principal aqui é que, para garantir que uma vez implementado um recurso, isso esteja pronto e funcionando totalmente - idealmente, isso é acompanhado por um teste de unidade que garante que ele continue funcionando. Normalmente, suponho que estarei tão ocupado que nunca terei tempo para voltar ao recurso e corrigi-lo.

Depois que os principais recursos são implementados, geralmente tento colocar o sistema em uso o mais próximo possível do ambiente de produção. Isso fornece a) quaisquer bugs que você possa ter perdido anteriormente eb) você terá uma boa idéia da prioridade dos próximos recursos.

Em seguida, você pode continuar implementando os recursos restantes, conforme necessário.

Qualidade do código vs. recursos

Com o exposto acima, costumo sacrificar os recursos pela qualidade do código, se for preciso cumprir um prazo. Simplesmente porque, pelo menos na minha linha de trabalho, quando eu termino algo, minha gerência assume que está feito. E que eles podem me dar a próxima tarefa. Não tenho muito tempo aprimorando o código após o fato.

Agora, e o tratamento de exceções?

Se você não quiser implementar isso de imediato, basta listá-lo como outro recurso da lista. E quando você chegar lá, você pode implementar isso. Mas provavelmente no seu caso, provavelmente existem muitas outras coisas que são mais importantes primeiro.

No entanto, há um requisito mínimo para exceções: verifique se o usuário é notificado se algo der errado - não importa quão feia a saída possa ser. Não engula exceções em algum lugar.