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ê :
- Slinging code sem um plano ou arquitetura é uma receita para o desastre
- Há muito mais para programar do que escrever código
- 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.
- 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.
- 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:
- 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.
- 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.
- 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).
- 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.