O projeto está quase pronto, mas código de espaguete procedural. Eu reescrevo ou continuo tentando enviá-lo? [fechadas]

Você se deparou com o calcanhar de Aquiles da maioria das formações de CS: eles ensinam as ferramentas e técnicas, mas não o comércio. Construir software é uma arte que você adquire apenas através de anos de prática e da experiência de ter seu software usado (os usuários são críticos mais duros do que os professores). Construir software também é quase sempre um negócio, em que os objetivos de negócios podem substituir as ambições técnicas.

Antes de mais nada, envie. Se você mostrar ao proprietário da empresa o software e ele achar que está pronto para envio, envie-o. Se não é nesse ponto, mas perto, termine. O único software que importa é aquele que é realmente usado. A única empresa de software que ganha dinheiro é aquela que tem um produto.

Em segundo lugar, você aprendeu muitas coisas valiosas, por isso deve apreciar a experiência para o que ela ensinou a você :

1. Slinging code sem um plano ou arquitetura é uma receita para o desastre
2. Há muito mais para programar do que escrever código
3. Os proprietários de empresas não técnicas geralmente não entendem o impacto das decisões técnicas (como quem contratar), e cabe aos desenvolvedores explicar as coisas para eles.
4. A maioria dos problemas já foi resolvida muito melhor do que você resolveria, em estruturas existentes. Vale a pena conhecer as estruturas que existem e quando usá-las.
5. Pessoas recém-saídas da escola designadas para um grande projeto com pouca orientação tendem a produzir uma tigela de código de espaguete. Isso é normal.

Aqui estão mais alguns conselhos para você sobre como proceder:

1. Comunique-se, comunique-se, comunique-se. Você deve ser muito aberto e franco sobre o estado do projeto e suas idéias sobre como proceder, mesmo que não tenha certeza e veja vários caminhos. Isso deixa o proprietário da empresa a escolha sobre o que fazer. Se você manter o conhecimento para si mesmo, você os privará de escolhas.
2. Resista à tentação da reescrita completa. Enquanto você está reescrevendo, o negócio não tem produto. Além disso, uma reescrita raramente é tão boa quanto você imaginou. Em vez disso, escolha uma arquitetura e migre a base de código para ela gradualmente. Até mesmo uma base de código horrível pode ser recuperada dessa maneira. Leia livros sobre refatoração para ajudá-lo.
3. Aprenda sobre o teste automatizado / teste de unidade . Você precisa criar confiança no código, e a maneira de fazer isso é cobri-lo com testes automatizados. Isso anda de mãos dadas com a refatoração. Contanto que você não tenha os testes, teste manualmente e de forma abrangente (tente quebrar seu código, porque seus usuários farão isso). Registre todos os bugs que encontrar para poder priorizá-los e corrigi-los (você não terá tempo para consertar todos os bugs, nenhum software estará livre de bugs no mundo real).
4. Saiba como implantar um aplicativo da Web e mantê-lo em execução. O livro Operações na Web: Manter os dados no tempo é um bom começo.

Isso soa como qualquer outro sistema que foi jogado em mim para corrigir.

Relaxe, isso acontece com muitas pessoas. Um júnior jogado no fundo do poço sem experiência, sem ajuda, sem apoio e sem orientação, não é exatamente uma receita para o sucesso. Contratar e esperar que um programador júnior construa um novo sistema a partir do zero que funcione bem, tenha bom desempenho e seja sustentável não seja realista. Você tem sorte se tudo isso acontecer com um programador sênior.

Na minha opinião você tem que vir limpo. Isso não será divertido. Diga-lhes que você fez o seu melhor, ele funciona (principalmente), mas você está preocupado que ele não tenha um bom desempenho e que haja muitos bugs (há sempre bugs). Ele precisa ser revisado por um programador sênior, e eles devem ser capazes de corrigir qualquer problema de desempenho / segurança gritante rapidamente. Ou eles podem implantá-lo e cruzar os dedos. Vai ficar tudo bem, ou vai fumar. Talvez você consiga resolver problemas quando eles surgirem. Se você tem uma grande base de usuários, talvez não.

Ou você pode fazer o que a maioria das pessoas faz nessa situação: pegar o dinheiro, desaparecer e deixar que ele resolva o problema. Deixarei isso para você descobrir qual é a escolha ética.

Edit (como essa pergunta tem muitos votos, eu também posso adicionar mais conteúdo)

Parte das alegrias de ser um programador é que pessoas não técnicas (provavelmente seu gerente, definitivamente o resto do negócio) não têm idéia do que você faz. Isso é bom e ruim. Parte do mal é que você tem que explicar constantemente como os projetos de desenvolvimento de software funcionam. Planejamento, requisitos, revisões de código, testes, implantação e correção de bugs. É seu trabalho explicar a importância do teste e reservar tempo para testar. Você tem para manter sua posição aqui. As pessoas não entenderão a importância ( "não podemos simplesmente começar a usá-lo?" ), mas assim que começarem a testar (não no ambiente ao vivo!) Elas entenderão rapidamente os benefícios. Uma das razões pelas quais eles contrataram você é porque eles não sabem nada sobre desenvolvimento de software, então cabe a você educá-los. Você precisa enfatizar a importância do teste e correção de bugs aqui - lembre-se, eles não são programadores, eles não sabem a diferença entre uma divisão por zero e uma tag html quebrada.

Muitas vezes, muitos dos problemas que surgem não são realmente erros. Eles serão problemas de usabilidade, requisitos perdidos, requisitos que mudaram, expectativas do usuário (por que não posso usar isso no meu celular?) E, em seguida, os bugs reais reais reais. Você precisa resolvê-los antes de ir ao vivo - muitas vezes, muitos bugs podem ser resolvidos ou corrigidos alguns dias depois. Se as pessoas esperam um sistema perfeito, vão sentir muita dor. Se eles estão esperando insetos, sua vida será mais fácil nas próximas semanas.

Ah, e não confunda o teste do usuário com o teste de unidade nem com o teste do sistema.

• Teste de unidade - minha função de código retorna o valor correto
• Teste do sistema - apresenta um erro quando clico no X
• Teste de aceitação do usuário (UAT) - o programa está em conformidade com os requisitos? Faz o que eles pediram para você fazer? Pode ir ao vivo?

Se você não tiver escrito os requisitos do que eles pediram, o UAT será muito, muito mais difícil. É aqui que muitas pessoas caem. Ter o que eles queriam que o sistema fizesse, escrito em papel, tornaria sua vida muito mais fácil. Eles vão dizer "Por que não faz X?" e você pode dizer "Você me disse para fazer Y". Se o programa estiver errado, corrija-o. Se os requisitos estiverem errados, corrija o documento, peça um dia ou dois a mais (não, insista), faça a alteração, atualize a documentação e faça um novo teste.

Uma vez que você tenha passado por esse processo algumas vezes, você pode começar a procurar no Agile ... mas isso é outro mundo:)

TL; DR O teste é bom

Sempre que você começar do zero, você com certeza cometerá a mesma quantidade de erros ou mais devido à Segunda Síndrome do Sistema . Seus novos erros serão diferentes, mas a quantidade de tempo necessária para a depuração será semelhante e, por isso, se desesperará com o fato de não ser um bom ajuste. Ele também atrasará a implantação na produção ou a implantação de novos recursos se a primeira versão for implantada, o que será um sério problema para a empresa. Joel Spolsky o chama de "único erro estratégico pior" que qualquer empresa ou desenvolvedor pode fazer.

A abordagem recomendada é, em vez disso, limpar a bagunça inicial, bit por bit, durante a manutenção. E nem tente refatorar apenas por causa disso. Além disso, os gerentes geralmente vêem isso como desperdício de dinheiro (o que geralmente é) e traz um risco desnecessário de introduzir novos bugs. Uma vez dolorosamente depurado o código, pode não ser bonito, mas funcionará. Então, deixe-o até que você precise tocá-lo por outras razões (seja uma correção de bug, novo recurso ou apenas uma mudança solicitada pelo marketing). Em seguida, limpe as partes que são mais difíceis de ajustar. Isso geralmente é chamado de Regra de escoteiros .

E nesse ponto você não precisa discutir isso com o gerente. Apenas inclua a refatoração mínima desejada na estimativa da solicitação. Você aprenderá através da experiência quando você pode se render um pouco porque a empresa está realmente em uma solução e quando você não quer criar problemas no futuro e simplesmente não admite a possibilidade de hackeá-la rapidamente.

Por fim, mais um pouco de leitura recomendada: a Big Ball of Mud .

Eu esqueci onde li pela primeira vez, mas eu só queria repetir, com um pouco mais de força, o que outras pessoas disseram:

Shipping is a feature.

Não há nada pior do que aquele cara que continua "limpando" código existente (possivelmente hacky, feio, sujo) que funciona perfeitamente bem , introduzindo novos bugs, etc. O que importa no real mundo está fazendo o seu trabalho. Você já fez isso. Navio. Não se perca em redesenhos de um projeto que funciona perfeitamente bem, mesmo que seja feio sob o capô. Quando você corrigir, faça isso de forma incremental e torne-se uma boa suíte de testes para que você tenha o menor número possível de regressões.

Todo projeto deixa você mais inteligente do que era antes. Após cada projeto, você terá acumulado mais experiência, o que teria sido muito útil quando você o teve desde o início. Eu sei que é difícil não revisitar tudo e aplicar o que você aprendeu. Mas lembre-se:

Perfeito é o inimigo do bem.

Para o cliente, é sempre melhor ter um bom software agora do que um software perfeito que nunca será lançado.

Este foi apenas o seu primeiro projeto. Haverá muitos outros projetos no futuro, nos quais você poderá aplicar tudo que aprendeu desde o início.

I [...] read Uncle's Bob clean code.

I'm having this persistent thought that I have to rewrite the whole project.

Este livro tem uma seção chamada, muito apropriadamente, "O Grande Reprojeto no Céu".

Não tente reescrever tudo porque, no caso improvável de você ter tempo de fazê-lo, você enfrentará os mesmos problemas de qualquer maneira. Quando você tiver terminado o redesenho, você terá aprendido coisas novas e perceberá que as primeiras partes são muito pouco profissionais, então você vai querer reescrevê-lo novamente.

Redesenhar e reescrever são boas, mas somente se forem feitas incrementalmente em um sistema em funcionamento. Como outro usuário apontou, siga a regra do Boy Scout, refatorando seu código pouco a pouco enquanto você trabalha nele.

Você está indo bem.

Você diz que seu código funciona e está quase pronto para envio, certo? E você percebe que seu código pode ser amplamente melhorado. Bom.

O seu dilema me lembra muito da minha primeira experiência com freelancing (ser contratado no meu segundo ano na uni para criar um sistema de PDV multilíngüe). Eu passei por questionamentos intermináveis como nunca fiquei satisfeito com o código, queria escalabilidade, queria reinventar rodas melhores ... Mas acabei atrasando o projeto (como, por 12 meses aproximadamente) e ... o que? Depois de implantar a coisa, ela ainda precisa de muitos testes, testes, correções, etc ...

Você tem experiência em trabalhar com bases de código profissionais? Muitas bases de código estão cheias de códigos difíceis de manter. Uma alternativa para descobrir a complexidade do software ao tentar construir um programa grande seria manter / estender um código igualmente confuso escrito por outras pessoas.

Os únicos casos em que vi reescritas completas fazem muito bem quando a equipe adotou simultaneamente um novo conjunto de ferramentas / estrutura.

Se a lógica subjacente (o que o programa faz, não como ele é apresentado como funções, classes e assim por diante ...) é som, funcionará tão bem, então, você está pensando que é código de espaguete não funciona t significa que não deve ser implantado.

Você precisa permitir que seu cliente tenha algo que possa usar. Então, quando eles pedem para você melhorar / adicionar funcionalidade, você decide se um refatorador é necessário, e não há problema em informar ao seu cliente que "é necessário algum trabalho técnico para integrar o novo recurso". Por que eles vão entender que vai custar-lhes mais dinheiro, e eles terão que esperar mais tempo. E eles vão entender (ou você pode sair).

Um momento melhor para reescrever tudo seria quando outro cliente pedisse para você criar algo semelhante.

A maior parte do que eu diria em resposta à sua pergunta foi dita por outras pessoas. Leia "Coisas que você nunca deve fazer, parte I", de Joel Spolsky (juntamente com alguns de seus outros posts sobre "astronautas de arquitetura"). Lembre-se que "o perfeito é o inimigo do bem". Aprenda a refatorar de forma incremental. O envio é importante, etc.

Se você está realmente interessado no dilema que você tem, você também deve ler "Lean Startup". Muitos dos conselhos que você está recebendo aqui vão entrar em ressonância com você mais se você ler esse livro. Basicamente, taxa de queima de recursos é seu pior inimigo e nada é mais valioso para você e seu organização do que o usuário final / feedback do cliente. Portanto, coloque seu produto em um estado viável (o Produto Mínimo Viável - ou MVP) e envie-o para fora da porta (independentemente de como o código realmente se pareça). Deixe seus clientes ditarem seus futuros changesets e versões, e não o contrário. Se você se concentrar nessa abordagem, tanto você quanto seu chefe serão mais felizes a longo prazo.

Por razões que outros explicaram completamente, é hora de terminar o projeto e enviá-lo, por mais doloroso que isso possa ser.

Gostaria apenas de enfatizar que testar o aplicativo também faz parte do "acabamento" dele. Se partes significativas da funcionalidade não tiverem sido completamente exercidas e corretas resultados confirmados, então você está justificado em sua preocupação de que as pessoas terão problemas com este aplicativo quando ele é implantado.

Testes de unidade e testes automatizados de nível superior são ótimos e são coisas que você deve ter o máximo que puder antes de tentar refatorar (ou reescrever) este aplicativo. Mas agora você precisa testar , mesmo que tenha que executar todos os testes "manualmente" e confirmar o funcionamento correto "a olho". Se você descobrir como automatizar esses testes mais tarde, isso ajudará na hora de começar a trabalhar na próxima versão do produto.