Refatorar ou concentrar-se na conclusão do aplicativo


23

Você refataria seu aplicativo à medida que avançaria ou se concentraria em concluir o aplicativo primeiro? A refatoração significará que o progresso do aplicativo diminuirá.

A conclusão do aplicativo significa que você terá um aplicativo possivelmente muito difícil de manter mais tarde?

O aplicativo é um projeto pessoal. Realmente não sei como responder "O que impulsiona a funcionalidade e o design", mas acho que é para resolver ineficiências no software atual por aí. Também gosto de software fácil de usar mínimo. Estou removendo alguns recursos e adicionando alguns que acho que ajudarão.


1
Você poderia fornecer alguns dados adicionais sobre o seu cenário? Por exemplo, é um projeto individual ou você faz parte de uma equipe? É um produto comercial, interno ou de código aberto? O que impulsiona a funcionalidade e o design?
mlschechter

@mlschechter, atualmente estou trabalhando em um projeto pessoal. Ainda não decidi se vou vendê-lo (por exemplo, em codecanyon) ou liberá-lo Open Source. Eu realmente não sei responder "O que impulsiona a funcionalidade e o design", mas acho que é para resolver ineficiências no software atual por aí. Também gosto de software fácil de usar mínimo. Então, eu estou removendo algumas características e adicione um pouco que eu sinto vontade ajuda
Jiew Meng

Respostas:


23

Faça funcionar. Então faça isso rápido. Finalmente, faça bonito.

Se você tiver uma boa separação entre seu código (apresentação, negócios e camadas de dados) usando interfaces e não for um design monolítico, a refatoração não deve ser tão difícil.

Se você está com tanta dificuldade em refatorar, provavelmente é um cheiro de código - sugiro que você veja Solid Principles


+1 em Faça funcionar . Então faça isso rápido . Finalmente, faça bonito .
Karthik Sreenivasan

O meu ponto também. Não refatorar antes de fazê-lo funcionar, a menos que você perceba que seu design o impede de concluir a tarefa.
Gus

Se você fizer isso usando o teste de unidade para garantir que realmente funcione , em vez de apenas parecer fazer a coisa certa, a estrutura induzida por esses testes será 90% da refatoração que você gostaria de fazer.
Michael Anderson

Prefiro dizer: faça funcionar, faça certo, faça rápido - nessa ordem.
Niklas H

Preferiria ser: faça funcionar , faça rápido , faça funcionar novamente , faça bonito , faça funcionar novamente . Se nesse momento você precisar torná-lo rápido novamente, você fez errado.
Florian F

8

Eu acho que o ponto essencial é manter as interfaces limpas . Você sempre pode refatorar ou até reescrever as implementações de módulos / classes / quaisquer que sejam posteriormente, desde que as camadas de comunicação entre elas sejam saudáveis. Passe algum tempo descobrindo o que é fácil mudar mais tarde e o que não é. Faça o último direito.

Isso é consistente com o espírito do TDD. Para escrever bons testes, você precisa de uma boa interface para testar. O quão confuso está nos bastidores no momento não é tão importante, porque você pode melhorá-lo mais tarde.


5

Eu refatoro sempre que vou, especialmente usando TDD.

  1. Escreva os testes

  2. Faça os testes passarem

  3. Refatorar

Isso ajudará você a ter menos erros e um código melhor para o produto final. Também permitirá que você tenha menos código para manter quando terminar.


5

Refatorar cedo e frequentemente! O tempo que você "economiza" em não fazê-lo é gasto muitas vezes tentando invadir o próximo recurso e pesquisando bugs em códigos excessivamente complexos ou caóticos.


2

Refatorar é como pegar seu quarto.

Se você mantiver as coisas arrumadas, terá uma sobrecarga linear, proporcional à quantidade de trabalho produtivo que você está realizando no código, O (n) em termos de algoritmologista. Supondo que você gaste 10% do seu tempo refatorando (ou mantendo seu quarto arrumado), esses 10% são um dado e permanecerão constantes ao longo do tempo.

Se, no entanto, você jogar suas roupas sujas em um canto e continuar fazendo isso, a quantidade de tempo que você vai gastar em seu quarto aumenta à medida que a bagunça se torna mais complexa. Supondo que cada peça de roupa suja contribua exponencialmente para o tempo de limpeza necessário, agora você está em uma situação de O (e n ).

Qualquer um que já tenha se aprofundado no conceito de complexidade algorítmica observará que há um ponto de equilíbrio em algum lugar, ou seja, há uma quantidade ideal de roupa suja a acumular; quanto isso depende dos fatores constantes que são descartados na notação big-O. Outro fator é o valor do seu trabalho ao longo do tempo: se o seu trabalho vale muito agora, mas é barato na próxima semana (ou seja, há um prazo nesta sexta-feira para este projeto e mais três, mas depois disso, você ficará praticamente ocioso ), a equação pode resultar em não refatoração.

E depois há a massa crítica da complexidade. Em algum momento, a bagunça ('bagunça crítica', se você quiser) fica tão ruim que parece mais fácil queimar a sala inteira e comprar roupas novas. Na realidade, geralmente não é, mas parece que sim, e os efeitos psicológicos tornarão dez vezes mais difícil lidar com isso.

E, obviamente, se você entrar em um projeto que já é uma grande bagunça redundante, você terá poucas opções.

TL; DR: em caso de dúvida, refatorar. Você deve ter realmente boas evidências antes de decidir não.


1

Se você tiver a chance de adicionar recursos ou eliminar erros para obter a satisfação de suas vendas / clientes onde você acha que deveria estar, faça-o. Quando houver menos novas demandas, você poderá equilibrar com a refatoração. Em algum momento, você precisa se certificar de que está escrevendo o código que as pessoas desejam. Com todas as coisas iguais, prefiro jogar fora 100 horas de código do que 1000. É isso que você fará se ninguém quiser.


0

Realmente depende de onde você está!

Outras coisas em que pensar:

Você tem certeza de que realmente tem o design funcional certo? Você pode refazer o design novamente depois de receber algum feedback do usuário?

Eu preferiria liberar do que reescrever. Otimize depois de ter certeza de que acertou em cheio o design funcional.


0

Contanto que você tenha certeza de que pode cumprir o prazo, pode refatorar tudo o que quiser. No entanto, mesmo que haja um pouco de incerteza melhor para se manter no desenvolvimento e possa ser refatorado apenas em uma etapa incremental modesta.


0

Se o design ruim que você deseja refatorar realmente o machuca, é melhor corrigi-lo agora do que criar mais código que depende dele. Refatorar mais tarde seria mais difícil e mais caro; é provável que você não consiga mais fazer isso.

Por outro lado, se o seu único problema for a feia, convém concluir o software primeiro, porque quase nada supera a realização das tarefas .


0

A refatoração será muito importante à medida que você trabalha para concluir sua inscrição.

+ VES

  1. Fluxo claro: a refatoração dará clareza ao código porque, às vezes, se o código for pouco estruturado, entenda que o fluxo do código após um período de tempo se tornaria difícil e o código da refatoração poderá se tornar uma tarefa difícil e os erros poderão ser introduzidos.

  2. Melhorar o desempenho: a refatoração adequada do aplicativo ajudará definitivamente a melhorar o desempenho do aplicativo.

  3. Manutenção: Por último, mas não menos importante, seria mais fácil manter a longo prazo.

-VE

  1. Demorado: Seria muito mais demorado em cada estágio de seu progresso. Portanto, pode haver um atraso na conclusão.

Bottom Line

Dependendo do tipo de projeto, você pode priorizar a qualidade ou conclusão do código, o que for exigente para a situação atual.


O que são VES e VE?
FreeAsInBeer

positivos e negativos.
Florian F

0

Com base na minha experiência pessoal, normalmente concluo os aplicativos primeiro com a condição de que haja um prazo a ser atingido. Depois de concluído, você pode refatorá-lo.

Terminar e refatorar. Mas se não houver prazo a ser agitado ou prazo, sugiro que refatorar seria bom.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.