Como implementar o código de uma maneira que diminui a possibilidade de re-trabalhos completos [fechado]

Question

Eu tinha um pedaço de trabalho jogado fora devido a uma única pequena alteração de especificações que acabou por não ter sido spec'ed corretamente. Se tivesse sido feito logo no início do projeto, em seguida, a maior parte desse trabalho nunca teria sido necessário, em primeiro lugar .

Quais são algumas boas dicas / princípios de design que mantêm estas coisas aconteçam?

Ou para diminuir a quantidade de re-trabalhando para código que é necessário para implementar pedidos de recurso ou projeto muda implementação mid?

Answer 1

modularize. Faça pequenos blocos de código que fazem bem o seu trabalho. No entanto, isso é apenas o começo. Geralmente é uma grande combinação de fatores que contribuem para o código tão ruim que precisa de um retrabalho completa. Tudo a partir de requisitos altamente instáveis, design pobre, a falta de propriedade do código, a lista vai sobre e sobre.

Adicionando-se ao que outros têm trazido acima:. COMUNICAÇÃO
A comunicação entre você eo cliente, você e gestão, você e os outros desenvolvedores, você e seu departamento de QA, a comunicação entre todos é fundamental. Certifique-se a administração entende prazos razoáveis ??e certifique-se você e para o cliente entender exatamente o que é que o seu edifício.

Answer 2

Aproveite o tempo para manter uma comunicação aberta com o cliente que a sua construção o produto para. Faça marcos e configurar um tempo para apresentar o projeto para o cliente em cada etapa. Mesmo se o cliente está completamente desapontado com um marco quando você mostrá-lo, você pode riscar o que você tem e começar de novo a partir da última etapa. Isso também exige que o seu trabalho ser construída em blocos que independente do trabalho um do outro como Csunwold afirmou.

Pontos ...

1. Mantenha uma comunicação aberta
2. Seja aberto e honesto com o progresso do produto
3. Esteja disposto a mudar diariamente quanto às necessidades do negócio dos clientes e especificações para a mudança de produto.

Answer 3

Software requisitos de mudança, e não há muito que se possa fazer sobre isso exceto para interação mais frequente com os clientes.

Pode-se, no entanto, o código de construção que é mais robusto em face da mudança. Não vai te salvar de jogar fora o código que responde a uma exigência de que ninguém precisa mais, mas pode reduzir o impacto de tais alterações.

Por exemplo, sempre que isso se aplica, usar interfaces em vez de classes (ou o equivalente em seu idioma), e evitar a adição de operações para a interface a menos que você tenha certeza absoluta de que você precisa deles. Ao construir seus programas de que maneira você são menos propensos a confiar no conhecimento de uma implementação específica, e você é menos provável para implementar coisas que você não precisa.

Outra vantagem dessa abordagem é que você pode facilmente trocar uma aplicação para outra. Por exemplo, às vezes compensa para escrever a mais estúpida (em termos de eficiência), mas o mais rápido para escrever e testar a implementação para o seu protótipo, e apenas substituí-lo por algo mais inteligente no final, quando o protótipo é a base do produto eo desempenho realmente importa. Acho que esta é uma maneira muito eficaz para evitar otimizações prematuras, e, assim, jogando fora coisas.

Answer 4

modularidade é a resposta, como já foi dito. mas pode ser uma resposta difícil de usar na prática. sugiro focando em:

• pequenas bibliotecas que não predefinidos bem as coisas
• dependências mínimas entre módulos

escrever interfaces de primeira é uma boa maneira de conseguir esses dois (com interfaces utilizadas para as dependências). escrever testes seguinte, contra as interfaces, antes do código é escrito, muitas vezes destaca escolhas de design que são un-modular.

Eu não sei se o seu aplicativo é UI-intensiva; que pode torná-lo mais difícil de ser modular. ainda é geralmente vale a pena o esforço, mas se não, então supor que ele vai ser jogado fora antes de tempo e siga o princípio do iceberg, que 90% do trabalho não está vinculado a interface do usuário e assim mais fácil de manter modular.

Finalmente, eu recomendo "o programador pragmática" pela caça Andrew e Dave Thomas tão cheio de dicas. o meu favorito é DRY - "Não se repita." - qualquer código que diz a mesma coisa duas vezes cheira

Answer 5

• iterate pequena

• iterate muitas vezes

• teste entre iterações

• obter um produto de trabalho simples para fora o mais cedo possível para que o cliente pode dar entrada.

Basicamente assumir material vai ficar jogado fora, então código apropriadamente , e não recebem o suficiente em algo que tê-lo ser jogado fora custa muito tempo.

Answer 6

G'day,

Olhando através das outras respostas aqui eu perceber que todos estão mencionando o que fazer para o seu próximo projeto.

Uma coisa que parece estar faltando no entanto está a ter um washup para descobrir por que a especificação. estava fora de sincronia. com as necessidades reais necessários pelo cliente.

Eu só estou preocupado que se você não fizer isso, não importa o que se aproximar de você está tomando para implementar seu projeto seguinte, se você ainda tem que incompatibilidade entre as necessidades reais e as especificações. para seu próximo projeto, então você vai, mais uma vez estar na mesma situação.

Pode ser algo tão simples como má comunicação ou talvez fluência exigência do cliente.

Mas pelo menos se você sabe a causa e você pode tentar ajudar minimizar as chances de isso acontecer novamente.

Não bater o que as outras respostas estão dizendo e há algumas grandes coisas lá, mas por favor, aprender com o que aconteceu para que você não está condenado a repeti-la.

HTH

aplausos,

Answer 7

Às vezes, uma reescrita é a melhor solução!
Se você estiver escrevendo software para uma câmera, você poderia supor que a próxima versão também irá fazer vídeo ou vídeo estéreo ou 3D de varredura a laser e incluem todos os ganchos para toda esta funcionalidade, ou você pode escrever como um versátil arquitetura astronauta extensível que ele poderia lidar com a próxima câmera incluindo motores a jato -. mas vai custar muito em dinheiro, recursos e desempenho que você poderia ter sido melhor não fazê-lo

Uma reescrita completa para nova funcionalidade em um novo papel nem sempre é uma má idéia.

Answer 8

Como csunwold disse, modularizing seu código é muito importante. Escrevê-lo de modo que se uma peça cai propenso a erros, não estragar o resto do sistema. Dessa forma, você pode depurar uma única seção de buggy ao ser capaz de contar com segurança sobre o resto.

Além disso, a documentação é fundamental. Se o seu código está bem e claramente anotados, retrabalhando-lo no futuro será infinitamente mais fácil para você ou quem quer que passa a ser de depuração.

Usando o controle de origem pode ser útil também. Se você encontrar um pedaço de código não funciona corretamente, há sempre a oportunidade de voltar a um iteração robusta passado.

Answer 9

Apesar de não aplicar diretamente ao seu exemplo, ao escrever código que tentar manter um olho para fora para maneiras em que eu posso ver o software evolui no futuro.

Basicamente eu tentar antecipar onde o software vai, e criticamente, eu resistir à tentação de implementar qualquer uma das coisas que eu posso imaginar acontecendo. Tudo o que eu estou depois é tentar fazer as APIs e interfaces apoiar futuros possíveis sem implementar essas características ainda, na esperança de que me ajuda destes cenários possíveis 'vir para cima com uma interface melhor e mais à prova de futuro.

nem sempre funciona é claro.