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

15

Acabei de começar um novo projeto pessoal (Python) e estou escrevendo o que significa um "rascunho" do programa, o mínimo necessário para fazer o que eu quero fazer. Eu ainda não estou colocando extensivo erro / exceção manipulação ou elementos de interface do usuário estética (mesmo nos casos em que eu sei que essas coisas serão necessárias), e a documentação é apenas o suficiente para ajudar o futuro a ver o que estava fazendo.

É contra qualquer princípio definido de design / gerenciamento de projetos começar tão difícil? Eu sou um cientista, não um programador, então não estou a par dessas coisas. Então, a questão principal é, 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 toda a exceção manipulação e tal que você sabe que vai precisar em última análise.

  2. Escreva um rascunho minimamente funcional desde o início e entre para preencher todos os minúcias mais tarde.

Pergunta relacionada: Quando é aceitável sacrificar a" limpeza "do design para realizar um projeto?

    
por neuronet 08.02.2015 / 19:41
fonte

3 respostas

10

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

Resultado final

Você está escrevendo um software de controle da 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 em um assunto sensato.

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

Como você espera chegar lá?

Você está fazendo um pesado desenvolvimento de cachoeira, onde você gasta muito tempo tentando descobrir o que é necessário, e então você vai sair por meses, desenvolvendo? Se sim, então você quer atingir a qualidade de alvo mencionada acima bem cedo. Obtenha toda a sua infraestrutura de verificação de erros planejada no início.

Você está fazendo um desenvolvimento ágil e pesado, em que você está organizando algo por uma semana ou duas, que será mostrado aos interessados, que podem solicitar revisões radicais e onde você espera poder interagir entre muitos outros. 2 sprints pequeninos até atingir o alvo? Então você pode estar melhor em conseguir algo que funcione, mas frágil rapidamente, e apenas adicionando correias e suspensórios conforme os requisitos do produto se solidificam.

Se você estiver no controle da decisão de cascata ou ágil (que na verdade é um continuum e não uma escolha binária), então tome essa decisão com base na mudança esperada. Se tiver certeza de que sabe exatamente como será o resultado final, a cascata é sua melhor escolha. Se você tem apenas uma noção vaga do que precisa acabar, a sua melhor escolha é ágil. (Agile é mais popular nos dias de hoje, 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 ambas as perguntas sobre o seu projeto, e isso deve levá-lo em uma direção básica.

Eu posso dizer isso por mim mesmo, se eu freqüentemente escrevo scripts únicos que são projetados de maneira péssima e não tenho nenhuma verificação de erros. Também cuido do código de produção, onde a arquitetura e o tratamento de erros recebem muita atenção. Tudo depende do que você está fazendo.

Uma advertência final: se você decidir que está fazendo scripts únicos que podem ser feitos rapidamente, certifique-se. Infelizmente, muitas vezes acontece que os scripts rápidos e sujos que fazem algo interessante são utilizados em larga escala quando outros os notam. Certifique-se de que, quando isso acontecer, seja dado tempo para o endurecimento.

    
por 08.02.2015 / 20:02
fonte
11

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 passar do tempo, alguns padrões tornam-se "conhecidos" como soluções preferíveis porque resolvem o problema de uma maneira que preenche certos requisitos de consistência, familiaridade, desempenho, manutenibilidade e assim por diante.

Segue-se que, se o problema que o padrão de software pretende resolver não existir no seu software em particular, então você não precisa do padrão. Além disso, quaisquer discussões sobre quais padrões Seu software pode precisa também incluir discussões detalhadas sobre o seu software proposto: o que é suposto 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 no meio de armazenamento. Exceções dão ao código uma maneira de dizer ao chamador "Algo aconteceu que me impede de continuar, e não há nada que eu possa fazer sobre isso, então eu estou desistindo." Se você não tem nenhum lugar em seu código onde existem condições como essa, então você não precisa de exceções. Ou você pode simplesmente retornar um código de erro e evitar completamente a exceção.

Conforme você ganha experiência, aprende sobre padrões de software e quando o uso deles é apropriado. Você também saberá quanto design 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.

    
por 08.02.2015 / 19:59
fonte
4

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

Primeiro, calcule o que você deseja 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 anotados em um pedaço de papel à sua frente. Mas é importante que você saiba o que você quer fazer.

Com base nisso, elabore a estrutura geral do sistema. Mais uma vez, isso é muitas vezes apenas um desenho rápido das diferentes classes / módulos e como eles se relacionam entre si, mas pode ser tão complexo quanto um documento inteiro. O importante é que você tenha algum tipo de idéia de como você irá implementar o sistema. Mas, isso provavelmente será refinado à medida que você trabalha nele, então 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, a principal coisa aqui é que, para ter certeza de que uma vez implementada uma função, isso é feito e totalmente funcional - idealmente, isso é acompanhado por um teste de unidade que garante que ele continue funcionando. Eu costumo partir da suposição de que estarei tão ocupado que nunca terei tempo para voltar ao recurso e corrigi-lo.

Depois que os recursos principais são implementados, geralmente tento colocar o sistema em uso o mais próximo possível do ambiente de produção. Isto dá-lhe a) quaisquer erros que possa ter perdido anteriormente e b) tenha uma boa ideia da prioridade das próximas funcionalidades.

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

Qualidade de código vs. recursos

Com o acima em mente, eu tento sacrificar recursos sobre a qualidade do código, se eu tiver que fazer um prazo. Simplesmente porque, pelo menos na minha linha de trabalho, quando termino alguma coisa, minha gerência presume que está feito. E isso eles podem me dar a próxima tarefa. Eu não tenho muito tempo fazendo código mais agradável depois do fato.

Agora, e quanto ao tratamento de exceções?

Se você não quiser implementar isso de cara, pode listar isso apenas como outro recurso da lista. E quando você chegar a isso, você pode implementar isso. Mas provavelmente no seu caso provavelmente há muitas outras coisas que são mais importantes primeiro.

No entanto, existe um requisito mínimo para exceções: Certifique-se de que o usuário seja notificado se algo der errado - não importa o quanto a saída possa ser feia. Não engula exceções em algum lugar.

    
por 09.02.2015 / 02:07
fonte