Mantenha as coisas simples agora ou programe com o futuro em mente?

Atualmente, estou codificando um novo aplicativo para minha empresa que está bastante envolvido. Para cumprir o prazo, a funcionalidade foi atenuada um pouco, para que possamos ter algo pronto para o lançamento.

Foi-me dada a tarefa de colocar a versão 1 em funcionamento até o final do mês. Estou no meio do desenvolvimento e cheguei ao ponto agora que há um fim à vista.

Ontem, dediquei algum tempo a encontrar uma solução fácil e agradável para um dos requisitos e estou bastante orgulhosa de como tudo acabou. Hoje de manhã, o documento da versão 2 foi enviado e existe um requisito que exigirá que o código que escrevi ontem seja destruído ou severamente alterado. Exigiria muito trabalho no futuro se eu deixasse do jeito que está. Agora, posso levar um dia extra para tornar minha solução atual mais robusta, de modo que o recurso v2 possa ser adicionado com muito menos esforço, mas isso me atrasará um pouco na codificação extra necessária.

Não sei se vou fazer a v2. Pode ser eu ou um colega de trabalho ou mesmo um estagiário.

Se você estivesse no meu lugar, gastaria seu tempo agora para facilitar as coisas no futuro ou deixaria sua solução e lidaria com isso quando chegar a hora?

Se o prazo for Carved In Stone, basta terminar o que você precisa para cumpri-lo. Certifique-se de aumentar as estimativas para a v2 para acomodar as alterações de código para o novo requisito. Além disso, certifique-se de documentar brevemente o que você acha que precisará alterar para os novos recursos da v2, para que um colega de trabalho possa buscá-lo se você for transferido para outra coisa.

Se houver flexibilidade suficiente no prazo (1 dia, pelo que parece, então procure uma extensão de 2,5 dias), com certeza, vá em frente e codifique para o futuro conhecido!

Evite cair presa (cedo) do Segundo Efeito do Sistema . Aqui estão algumas boas técnicas para aplicar:

1. Definitivamente, evite a remoção da versão 1 apenas por causa do que você vê na versão 2. Planejar com antecedência é bom, mas o criador das especificações da v2 deve ser responsável pela falha da v2, não da v1.
2. (Se possível), veja se você pode solicitar ao criador que refaça os requisitos da versão 2 que não exigirão alterações maiores agora - e planeje-os posteriormente, talvez para a v3.
3. Lembre-se do YAGNI , mas tente codificar a extensibilidade - evite números mágicos, valores codificados, escreva bons testes de unidade ou contratos de código etc. A aplicação de boas técnicas logo no início tornará a refatoração e as alterações de código menos dolorosas ao longo do caminho.

A maioria dos projetos de software que crescem como cidades são bem-sucedidos a longo prazo. O planejamento evolutivo apenas em um futuro limitado permite que seu software seja lançado dentro do prazo e com as funcionalidades necessárias no lançamento - e não mais. Veja este trecho de Carl Sagan:

O arranjo [de uma cidade] poderia ser mais eficiente se todos os sistemas cívicos fossem construídos em paralelo e substituídos periodicamente (é por isso que incêndios desastrosos - as grandes conflagrações de Londres e Chicago, por exemplo - às vezes são uma ajuda no planejamento da cidade). Mas o lento acréscimo de novas funções permite que a cidade trabalhe mais ou menos continuamente ao longo dos séculos.

• Carl Sagan, Cosmos : http://www.eridanus.info/genesis.html

Não adicione código hoje para os requisitos do próximo mês. Hoje você deve escrever o código mais limpo possível para os requisitos que possui. Estou cético que o trabalho de um dia agora salve vários dias depois. Ouvi afirmações como essa e não consigo me lembrar de um único caso em que isso fosse verdade. Você pode me convencer mostrando algum código, mas minha experiência me diz que isso é improvável.

Deixe como está.

Os desenvolvedores realmente apreciam um projeto legado que faz o que deveria fazer e não mais.

Hoje, o que pode parecer uma boa idéia para "organizar" a base de código para atender a um requisito "futuro" provavelmente funcionará como um obstáculo para a compreensão do código no futuro. Ninguém gosta de lidar com funcionalidades parcialmente implementadas e com vestígios de requisitos fantasmas esquecidos. Não estou dizendo que será esse o caso, mas as coisas geralmente acabam assim, apesar das melhores intenções.

Boas respostas. Gostaria apenas de acrescentar - o que faço em um caso como esse é uma boa diferença para que eu possa capturar o que fiz e esquecê-lo em um local seguro. Então, se a oportunidade surgir novamente na próxima versão, será fácil.

Em geral, um bom desenvolvedor antecipa requisitos futuros, mas quando o prazo está chegando, é hora de responder a bugs no que você já tem e não "agitar o barco".

Depende. Há uma boa regra antiquada: trate outras pessoas como você quer ser tratado. O que você faria se fosse seu próprio projeto e conhecesse todas as prioridades?

Se a v2 for definitivamente necessária e o prazo final for apenas um desejo, e não uma necessidade difícil, não crie dívidas técnicas e conserte suas velas enquanto o tempo estiver bom. Mesmo se alguém fizer a v2, eles apreciarão a previsão.

Se houver alguma dúvida sobre a necessidade da v2, fique com o YAGNI. Além disso, se você está do outro lado do espectro e tem um desses clientes que constantemente envia mensagens de spam com suas idéias antes de se formarem, verifique seus e-mails apenas 2 ou 3 vezes ao dia e não se apresse com a ação, você ficará surpreso quantos "problemas" e solicitações se tornam irrelevantes antes mesmo de você os ler.