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

21

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?

Tyanna
fonte
O seguinte link foi útil para mim: elegantcode.com/2012/01/16/marines-vs-boy-scouts
QuanhD

Respostas:

18

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!

FrustratedWithFormsDesigner
fonte
1
+1 para a sugestão de documentar a solução mais robusta. O recurso pode ou não ser implementado exatamente como você planejou, mas é definitivamente uma boa idéia informar o futuro implementador sobre seus pensamentos sobre as mudanças.
Mike Partridge
2
Na verdade, comecei a escrever os stubs de método para a antecipação da v2 hoje de manhã, depois de ler o documento. Acho que vou deixar por aqui e alguns comentários para dizer como serão os resultados no futuro. Obrigado :)
Tyanna
1
Fique de olho na bola .... minha experiência é uma coisa ruim se preocupar com qualquer coisa a ver com a V2 quando você tiver o prazo V1 prestes a acertar você entre os olhos. Se for flexível, não será um prazo. Se um desenvolvimento perde um prazo, a culpa é do desenvolvedor.
mattnz
13

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.

Kevin McCormick
fonte
Gosto da ideia de conversar com o designer e a gerência para ver se eles são casados ​​com esse recurso. Eu vejo isso mais como um sino inútil que causará mais trabalho do que vale a pena ... mas então eu sou um desenvolvedor atento. :)
Tyanna 17/01/12
2
+1: Evite tentar prever o futuro. Quando chegar, será surpreendente.
precisa saber é o seguinte
7

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.

Kevin Cline
fonte
É verdade, mas só é verdade se você tiver tempo para planejá-lo com muita antecedência e possuir o conhecimento comercial necessário para antecipar a natureza de várias mudanças. Considerando a maioria das situações de negócios (agora, mais baratas, menores), concordo totalmente com suas declarações. Eu tenho alguns exemplos, no entanto, se você é um verdadeiro crente não :)
Joel Etherton
@ JoelEtherton: Mesmo que você tenha conhecimento de negócios, antecipar mudanças é muito difícil, a ponto de muitas vezes não valer a pena tentar ... apenas a minha experiência.
sleske
@lesleske: Às vezes, possivelmente, mas minha experiência tem sido em ambas as direções. No meu trabalho atual, um bom planejamento e previsão me salvaram uma tonelada de dores de cabeça extras.
Joel Etherton
6

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.

Angelo
fonte
+1 para "nenhuma funcionalidade semi-implementada". Gostaria de poder votar mais.
sleske
1

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".

Mike Dunlavey
fonte
Boa ideia sobre como manter as alterações separadas. Em vez de um diff, um ramo é provavelmente uma ideia melhor (visível, mais fácil de mesclar etc.). Você sempre pode excluí-lo mais tarde.
sleske
1

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.

Cola
fonte