Estou planejando trabalhar / iniciar alguns projetos pessoais que podem acabar como meu trabalho diário. Isso me fez pensar, por onde devo começar?

• Apenas protótipo - escreva apenas um código básico funcional que poderia me custar muito tempo otimizando e refatorando para facilitar a expansão.

• Escreva um código limpo, otimizado e documentado desde o início, tendo em mente que, se depois de algum tempo não for econômico, será descartado.

Atualização: A combinação do YAGNI com as respostas sunpech e M.Sameer faz todo o sentido para mim :) obrigado a todos pela ajuda.

Existe uma terceira opção ... escrever código limpo via desenvolvimento orientado a testes para implementar os requisitos que são necessários hoje porque o YAGNI.

A tentação de escrever um código que não é necessário no momento, mas que pode estar no futuro, sofre de várias desvantagens ... Você não precisará disso :

• O tempo gasto é gasto na adição, teste ou aprimoramento da funcionalidade necessária.
• Os novos recursos devem ser depurados, documentados e suportados.
• Qualquer novo recurso impõe restrições sobre o que pode ser feito no futuro; portanto, um recurso desnecessário agora pode impedir a implementação de um recurso necessário posteriormente.
• Até que o recurso seja realmente necessário, é difícil definir completamente o que ele deve fazer e testá-lo. Se o novo recurso não for definido e testado corretamente, ele pode não funcionar corretamente, mesmo que eventualmente seja necessário.
• Isso leva ao inchaço do código; o software se torna maior e mais complicado. A menos que haja especificações e algum tipo de controle de revisão, o recurso pode não ser conhecido pelos programadores que poderiam fazer uso dele.
• Adicionar o novo recurso pode sugerir outros novos recursos. Se esses novos recursos também forem implementados, isso poderá resultar em um efeito de bola de neve no sentido de uma característica arrepiante.

Como resultado, você não deve apenas prototipar ... nem escrever código limpo, otimizado e documentado desde o início, tendo em mente que, se em algum tempo não for econômico, será descartado.

Escreva o código que você precisa agora, sabendo que poderá atender melhor às necessidades de hoje e de amanhã.

como sempre...

Depende

Se você está fazendo um protótipo para mitigar um risco ou expor um desconhecido, basta codificá-lo e esperar jogá-lo fora quando terminar

Se você estiver fazendo prototipagem para refinamento iterativo, basta codificá-lo e esperar modificá-lo e refatorá-lo com frequência

Se você está começando a escrever o produto real, mas chamando-o de prototipagem, para ter preguiça , não seja preguiçoso e escreva-o bem da primeira vez

Se você está fazendo prototipagem, por que pensa em código limpo? A própria idéia da criação de protótipos é que ela serve para provar um conceito ou idéia e ser jogada fora depois.

Discordo da maioria das pessoas aqui dizendo que, se você já está pensando na escolha entre escrever código limpo ou fazer algo rapidamente para a criação de protótipos, escolha o último. Especialmente quando você está falando sobre o desenvolvimento do estágio inicial. Não estou dizendo que nunca escreva um código limpo, estou dizendo que tire a ideia, veja que é a direção a seguir e depois limpe-a - refatorar.

Como desenvolvedores de software, ficamos tão envolvidos em fazer as coisas certas e limpas na primeira vez, que não percebemos que não é um código que estamos entregando, é uma solução para um problema .

Penso em codificar como escreveria um artigo:

Ao escrever um artigo, começamos em algum lugar, esboçamos idéias, contornos etc. Ele não conterá todos os detalhes ou terá uma aparência finalizada - é essencialmente um primeiro rascunho, seguido por um segundo e assim por diante. Muito será reescrito, substituído e / ou até removido ao longo do caminho para um papel mais refinado e acabado. (Obviamente, essa analogia não chega ao ponto de dizer que o código está realmente realmente terminado ou final como um artigo.)

Existem dois tipos de prototipagem:

• Protótipo evolutivo que continua evoluindo através de aprimoramentos e correções para se tornar o produto final.
• Protótipo descartável que existe apenas para tornar a coleta de requisitos e o feedback do cliente mais eficazes nos estágios iniciais do projeto e, em seguida, ser totalmente descartada e o desenvolvimento do produto final começa do zero.

De acordo com Capers Jones, os protótipos evolutivos produzem produtos finais de baixa qualidade que exigirão muito mais esforço e mais tempo para alcançar a estabilidade.

Portanto, se você estiver pensando em prototipar para que o cliente possa ver algo o mais rápido possível para ajudá-lo a ter uma melhor idéia e mais detalhes sobre os requisitos, é melhor ser um protótipo descartável e ter o desenvolvimento feito em código limpo posteriormente. Se você não puder pagar por isso, escreva um código limpo desde o início e mantenha-o com cuidado, mas como outros sugeriram, não otimize demais e não adicione coisas até que você precise.

Estou relutante em desculpar a codificação suja por qualquer motivo. Na minha experiência, as pessoas que alegam ser rápida e suja como desculpa para a criação de protótipos têm essa atitude em relação a qualquer código, incluindo a produção. Se alguém cria um protótipo confuso, ele cria confusão em qualquer código. Prototipagem não significa codificação suja, significa suposições simplificadas para testar os casos de uso mais importantes. O código pode não ser formalmente testado ou cuidar de todos os detalhes, mas ainda deve ser bem projetado e implementado. Limpeza é um sinal de competência, programadores competentes sentem repulsa natural por códigos confusos, não importa qual seja seu objetivo.

Escreva código limpo, otimizado e documentado desde o início. Eu sou incapaz de fazer isso sozinho e é um problema real. Não sou codificador, mas já trabalhei para empresas de desenvolvimento de software em funções de gerenciamento voltadas para o cliente em quantidade razoável e, como elas me dão muitas boas idéias, ocasionalmente construo um protótipo para alguma coisa. Quase todas as vezes que o protótipo era entregue a um desenvolvedor que "limpava" e o transformava em um produto de remessa. Quando eu verifico a fonte, ainda será 80-90% o meu código de baixa qualidade.

Um colega meu apoia com entusiasmo a prototipagem repetida, com a ressalva de que é preciso ter disciplina suficiente para jogar cada protótipo fora e escrever novamente do zero - e não apenas isso, garantir que não seja influenciado pelos detalhes da implementação decididos na última vez , pois o que se acaba fazendo é escrever o mesmo protótipo em um estilo trivialmente diferente várias vezes. Ele sugeriu semi-seriamente que, se você realmente estivesse anexado a algum pedaço brilhante de código que não poderia descartar, imprima, exclua o repositório de controle de origem e publique a impressão para si mesmo - ela desaparecerá tempo suficiente para que não possa se infiltrar na próxima iteração.

Você sempre pode começar fazendo o trabalho (de todo), revisá-lo para torná-lo limpo e depois torná-lo rápido / pequeno, se fizer sentido economicamente fazer isso. Eu começaria com alguns experimentos que você joga fora e depois o TDD volta a existir quando você tem uma idéia do que funciona.

Ambos são bons. Ambos eu gosto. Eles não se contradizem.

Eu gosto de prototipar. Prototipagem está desenvolvendo minhas habilidades criativas. Estou testando muitas soluções possíveis. Fazer isso rápido me dá a possibilidade de testar várias maneiras possíveis de resolver problemas.

Eu gosto de escrever código limpo e bom testado. Desenvolve minhas habilidades principais. Normalmente escolho um dos protótipos e o aprimoro ou reescrito do zero.

Mas você nunca deve confundir o protótipo com o código de produção. O protótipo nunca deve entrar em produção. Deve ser sempre marcado como protótipo. Na melhor das hipóteses, faça toda a prototipagem em seu próprio ramo.

Costumo dizer que extremos são quase sempre ruins.

Aconselho a manter o equilíbrio entre limpo, bem documentado e prototipado. Quando você desenvolve uma biblioteca ou plataforma, você não tem experiência, eu vou mais para a direção da criação de protótipos. Isso é especialmente verdade no começo e para plataformas, como Android ou contêineres, que colocam você no espartilho. Isso significa que você implementa as interfaces deles e eles chamam você.

Pela minha própria experiência, a maior parte do código não dura muito tempo. Dito isto, avance rapidamente implementando seu recurso. Quando, mais cedo ou mais tarde (na maioria das vezes, mais cedo), você precisa refazer / refatorar o código existente por causa do próximo recurso que você organiza, especialmente as peças com as quais é complicado trabalhar. Preste atenção para ter testes automatizados adequados para tornar possível a refatoração sem complicações. Pertencendo às plataformas mencionadas acima, como o Android: muitas vezes, eles tornam os testes automatizados não tão fáceis por causa do acoplamento estreito e do projeto de testabilidade. Em seguida, você pode elevar sua base de testes a um nível superior, por exemplo, testes de integração.

Eu escrevi um artigo que pode dar algumas dicas sobre como iniciar: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d