Projete mudanças futuras ou resolva o problema em questão [fechado]

35

Ao escrever o código ou durante o design, você tenta generalizar o problema na primeira instância ou tentar resolver esse problema muito específico.

Estou perguntando isso porque tentar generalizar o problema tende a complicar as coisas (o que pode não ser necessário) e, por outro lado, será muito difícil estender a solução específica se houver uma mudança na exigência.

Eu acho que a solução é encontrar o caminho do meio que é mais fácil dizer do que fazer. Como você lida com esse tipo de problema? Se você começar a generalizá-lo em que ponto do tempo você sabe que essa generalização é suficiente?

    
por Naveen 24.03.2009 / 18:50
fonte

9 respostas

57

Muitas vezes, quando você tenta projetar para o futuro, suas previsões sobre necessidades futuras acabam erradas. Geralmente, é melhor refatorar quando você realmente sabe como as necessidades mudaram do que sobrecarregar seu sistema no primeiro dia. Ao mesmo tempo, não se atire no pé também. Há certamente um meio-termo, e saber onde isso é é mais arte do que ciência.

Para reduzi-lo a uma regra básica: menos é mais.

    
por 24.03.2009 / 18:53
fonte
18

Você está familiarizado com o Agile? Um dos grandes princípios do Agile é YAGNI . Acho que é a melhor maneira de abordar as coisas.

"You aren't gonna need it" ...is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."

...YAGNI is a principle behind the XP practice of "do the simplest thing that could possibly work" (DTSTTCPW). It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration. Used without continuous refactoring, it could lead to messy code and massive rework. Continuous refactoring in turn relies on automated unit tests as a safety net (to detect unforeseen bugs) and continuous integration to prevent wider integration problems...

YAGNI is not universally accepted as a valid principle, even in combination with the supporting practices. The need for combining it with the supporting practices, rather than using it standalone, is part of the original definition of XP...

    
por 24.03.2009 / 18:55
fonte
10

Esta é provavelmente uma das partes mais difíceis do desenvolvimento de software, porque você precisa andar na linha entre "YAGNI" e "PYIAC" (pinte-se em um canto).

É bem fácil dizer "não escreva um recurso a menos que você precise dele". A parte difícil é projetar seu código para que você possa adicionar recursos mais tarde quando precisar.

A chave é ser capaz de projetar uma arquitetura extensível onde você não escreve mais código do que o que você precisa atualmente. A capacidade de fazer isso bem vem de muita experiência (e dor).

    
por 24.03.2009 / 19:19
fonte
6

Eu passo algum tempo pensando antecipadamente sobre a direção geral do design - não muito, mas o suficiente para esboçar uma visão geral de alto nível. Em seguida, sigo uma metodologia ágil baseada em história usando o TDD para desenvolver soluções para histórias individuais. Como estou implementando via TDD, mantenho minha visão geral de alto nível em mente e (a) direciono minhas implementações específicas para seguir a visão geral de alto nível ou (b) refatorio (e aprimoro) meu entendimento / direção de alto nível com base em o que eu aprendo durante o teste / implementação.

Eu acho que é um erro não fazer planejamento antecipado, mas é provavelmente um grande a fazer muito. Tanto quanto possível, gosto de deixar-me experimentar guiar-me no quadro geral e, em seguida, deixar o design crescer organicamente ao longo das linhas que expus em minha mente sobre como o aplicativo vai se desenvolver. Usando o TDD eu acho que o design em si é forçado em melhores princípios de design (desacoplado, responsabilidade única, etc) e é mais maleável com relação a mudanças do que se eu tentar pré-conceber o todo e encaixar o desenvolvimento nele.

    
por 24.03.2009 / 19:02
fonte
2

O que você está tentando lidar tem a ver com a reutilização (ou seja, a generalização de um problema com o qual você está lidando agora para que você possa reutilizar o trabalho (código) no futuro). Eu já disse isso antes e link para ele novamente.

Acho que ouvi outras pessoas dizerem algo sobre o seguinte:

I solve the problem the first time. When I repeat my solution the first time, I note it. When I repeat it again, I refactor.

    
por 24.03.2009 / 18:54
fonte
2

Um bom design acomoda futuras mudanças e definitivamente vale a pena ir. Considere o sistema operacional UNIX e seu "tudo é uma filosofia de arquivo". Essa decisão de projeto foi tomada para não atender a alguma necessidade imediata, mas com vistas a requisitos futuros. Um estremecimento é pensar em como seria um sistema operacional baseado em um design "ágil".

    
por 24.03.2009 / 19:08
fonte
2

Design para "agora + 1". Isso significa resolver o problema imediato e criar funcionalidades suficientes para que, da próxima vez que eles pedirem uma alteração, você já tenha feito a metade (ou mais) feito e tenha a opção de a) resolvê-la imediatamente e refatorando mais tarde, ou b) resolvendo "now + 1" de novo (com o "agora" meio pronto)

Isso depende do projeto e, em resumo, a experiência ensinará o que é "+1".

    
por 24.03.2009 / 19:13
fonte
1

A filosofia de YAGNI , você não precisa, pode ser resumido com (do artigo):

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

  • The time spent is taken from adding, testing or improving necessary functionality.
  • The new features must be debugged, documented, and supported.
  • Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
  • Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
  • It leads to code bloat; the software becomes larger and more complicated.
  • Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
  • Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.
    
por 24.03.2009 / 19:00
fonte
0

Acredito piamente em projetar o problema em questão e não explodir seu design tentando adivinhar todos os casos que você precisa atender, porque "algum dia poderemos precisar dele".

Basicamente, dada uma lista de requisitos específicos, design contra isso, no entanto, isso não significa que você não deva:

  • torna os aspectos de seu design configuráveis, em vez de codificar esses aspectos em sua solução. Seja através de parâmetros passados no tempo de execução ou através de uma configuração de configuração externa na inicialização (ou após o HUP).
  • renda seu código com números mágicos,
  • evite dar uma olhada para ver se há algo já escrito que você possa reutilizar, talvez depois de adaptar a solução existente para fornecer uma abordagem adequada para a situação existente, bem como para o novo (s) requisito (s).

O principal problema com o design de "futuros possíveis" é que você está sempre apenas adivinhando. Possivelmente fazendo suposições educadas, mas "quando chega o empurrão" ainda é apenas uma série de palpites.

Ao fazer isso, você também tem a possibilidade muito real de apertar sua solução para se adequar ao (s) caso (s) geral (is), em vez de resolver o problema específico em questão, conforme definido por seus requisitos conhecidos.

O que isso está dizendo? "Quando tudo o que você tem é um martelo, tudo começa a parecer um prego".

Eu gostaria de ter um quilo para cada vez que ouvi alguém dizer: "Mas é uma solução mais adaptável para os casos gerais que podemos ver no futuro".

    
por 26.06.2009 / 16:02
fonte

Tags