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

239

Sou um desenvolvedor web iniciante (um ano de experiência).

Algumas semanas depois de me formar, eu me ofereci um emprego para criar uma aplicação web para uma empresa cujo dono não é muito técnico. Ele me recrutou para evitar o roubo de sua ideia, o alto custo de desenvolvimento cobrado por uma empresa de serviços e ter alguém jovem em quem ele pudesse confiar para manter o projeto a longo prazo (cheguei a essas conclusões sozinho muito depois de ser contratado. ).

Cocky como eu era naquela época, com um diploma em ciência da computação, aceitei a oferta pensando que poderia construir qualquer coisa.

Eu estava chamando os tiros. Depois de algumas pesquisas eu decidi sobre PHP, e comecei com PHP simples, sem objetos, apenas código processual feio. Dois meses depois, tudo estava ficando confuso e era difícil fazer algum progresso. O aplicativo da web é enorme. Então, decidi verificar um framework MVC que facilitaria minha vida. Foi aí que eu tropecei no garoto legal da comunidade PHP: o Laravel. Adorei, foi fácil aprender e comecei a codificar imediatamente. Meu código parecia mais limpo, mais organizado. Parecia muito bom.

Mas, novamente, o aplicativo da web era enorme. A empresa estava me pressionando para entregar a primeira versão, que eles queriam implantar, obviamente, e começar a procurar clientes.

Como o Laravel foi divertido de se trabalhar, isso me fez lembrar por que escolhi esse setor em primeiro lugar - algo que esqueci enquanto estava preso no sistema educacional de merda.

Então comecei a trabalhar em pequenos projetos à noite, lendo sobre metodologias e melhores práticas. Revisei a POO, mudei para o design e a análise orientada a objetos e leia o livro do tio Bob Código Limpo .

Isso me ajudou a perceber que eu realmente não sabia de nada. Eu não sabia como construir o software THE RIGHT WAY. Mas neste momento já era tarde demais e agora estou quase terminando. Meu código não está limpo, apenas código spaghetti, um problema real para consertar um bug, toda a lógica está nos controladores, e há pouco design orientado a objeto.

Estou tendo esse pensamento persistente de que preciso reescrever todo o projeto. No entanto, eu não posso fazer isso ... Eles continuam perguntando quando tudo será feito.

Eu não consigo imaginar esse código implantado em um servidor. Além disso, ainda não sei nada sobre a eficiência do código e o desempenho do aplicativo da Web.

Por um lado, a empresa está aguardando o produto e não pode mais esperar. Por outro lado, não consigo me ver indo mais longe com o código real. Eu poderia terminar, embrulhar e implantar, mas só Deus sabe o que pode acontecer quando as pessoas começarem a usá-lo.

Eu reescrevo, ou apenas continuo tentando enviar, ou há outra opção que eu tenha perdido?

    
por solidsnake 15.07.2014 / 05:48
fonte

16 respostas

251

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.
por 15.07.2014 / 09:39
fonte
113

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

    
por 15.07.2014 / 07:21
fonte
61

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 .

    
por 15.07.2014 / 09:36
fonte
28

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.

    
por 16.07.2014 / 07:38
fonte
24

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.

    
por 15.07.2014 / 14:09
fonte
15

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.

    
por 15.07.2014 / 17:03
fonte
9

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.

Em suma, a menos que você possa demonstrar que a coisa toda vai explodir na cara de todos se for implantada, adiar a implantação seria pouco profissional e não beneficiará nem você nem seu cliente. Aprender a fazer pequenos refatores enquanto corrige bugs ou adiciona novos recursos, que será uma experiência valiosa para você.

    
por 16.07.2014 / 10:09
fonte
7

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.

O que eu gostaria de acrescentar é o seguinte: você foi encarregado de algo que era considerado factível por um único recém-formado que trabalhava com um pequeno orçamento / período de inicialização. Você não deve nada muito mais sofisticado do que uma boa programação estruturada e procedural. (E, FYI, "programação procedural" não é uma palavra ruim. É uma necessidade em algum nível na maioria dos casos, e é totalmente adequada para muitos projetos inteiros.)

Apenas certifique-se de fazer programação processual estruturada. Repetição no seu código não é necessariamente um sinal de que você precisa de grandes estruturas polimórficas. Pode ser simplesmente um sinal de que você precisa pegar o código repetido e colocá-lo em uma sub-rotina. O fluxo de controle "espaguete" pode ser simplesmente uma oportunidade para se livrar de um problema global.

Se houver aspectos do projeto que legitimamente exigem polimorfismo, herança de implementação, etc., sugiro que talvez o tamanho do projeto tenha sido subestimado.

    
por 16.07.2014 / 16:36
fonte
4

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 15.07.2014 / 16:48
fonte
4

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.

Algumas pessoas têm o dom de se sentar diante de um novo projeto de software como um usuário de teste alfa e fazer as coisas darem errado. Isto é, eles são bons em quebrar coisas. Se você tiver a sorte de ter uma pessoa tão talentosa trabalhando com você, experimente primeiro o aplicativo para que você tenha a chance de corrigir qualquer problema óbvio no início. Se você tiver que fazer essa tarefa sozinho, então:

  • Seja metódico.
  • Experimente todos os recursos.
  • Imagine que você é um usuário inexperiente em seu aplicativo. Cometer erros estúpidos e ver como o software lida com eles.
  • Anote o que você está fazendo para tentar novamente depois que achar que resolveu os problemas.
por 16.07.2014 / 19:29
fonte
1

Sua pergunta diz: "Começou errado, devo começar de novo", enquanto o texto adicional realmente diz "Concluído projeto, mas fez errado, eu deveria começar de novo". Apenas para a manchete da pergunta: Se a quantidade de trabalho de programação que você fez é pequena em comparação com o trabalho total necessário, então começar tudo de novo fará sentido. Isso acontece muito quando o problema é complexo e mal entendido, e é gasto algum tempo para descobrir qual é o problema. Não adianta continuar com um mau começo, se jogá-lo fora e começar tudo de novo, desta vez com uma boa compreensão do problema, significa que você realmente terminará mais rápido.

    
por 21.07.2014 / 02:16
fonte
0

Isso é o que eu faria pessoalmente:

  1. Saia, dê uma desculpa e desista (você pode até mesmo devolver parte do seu salário para não parecer ruim)
  2. Limpe seu código o máximo possível
  3. Crie documentação sobre todas as partes boas do seu trabalho, como seu bom design, boas ideias, etc.

Por que sugiro tudo isso para você?

Porque pense no futuro. Haverá tempo no futuro quando certas pessoas receberem esse código. Eles farão todo tipo de suposições e julgamentos sobre você e sua habilidade. Eles não se importam quando você escreveu, eles não se importam com a circunstância. Eles só querem ver o que querem ver para confirmar o que querem confirmar.

Você será marcado como qualquer nome ruim, termo que eles podem criar para causar um impacto negativo em você. E mesmo que você no futuro possa ser totalmente diferente em termos de habilidade técnica, habilidades, conhecimento, estilo e a situação será tão diferente, este código será usado contra você de todas as formas possíveis. É como um tribunal onde eles podem dizer todas as coisas ruins sobre você e seu código e design e você nem está ciente disso para que possa se explicar e se defender. (e você pode aprender muitas vezes que eles estão profundamente errados, repetidamente) Então não faça isso. Desista.

Confie em mim, existem pessoas que fizeram muitas suposições sobre você porque você fez algo para qualquer propósito em qualquer momento. Para eles, se você fez isso na situação A, você fará isso na situação B. Eles acham muito simples.

    
por 17.07.2014 / 09:25
fonte
0

Mais duas sugestões, aposto que pelo menos uma delas não foi feita.

1) Coloque um bug tracker no lugar e ensine seu chefe a usá-lo. Isso pode ser parte da conversa sobre como você errou, aprendeu melhor e vai consertar isso de uma maneira planejada

2) Comece a usar o controle de versão, embora espere que você já esteja fazendo isso.

Existem montes de sistemas hospedados que fornecem tanto os acima como gratuitos em pequenas contas. Eu particularmente gosto do FogBugz que também tem um ótimo sistema de estimativa e conclusão de tarefas que dará ao seu chefe ainda mais certeza de que você está lidando com as coisas de uma maneira bem gerenciada.

editar

Nossa, alguém realmente não gostou disso - um voto negativo e um sinalizador de exclusão? Por quê?

Tenho desenvolvido software por mais de trinta anos, incluindo muito trabalho de consultoria e herdando o código de outras pessoas. Um grande número de sistemas de problemas que vi foram onde as pessoas cavaram um buraco e não tiveram notas detalhadas sobre como chegaram lá nem tinham controle de versão.

    
por 21.07.2014 / 14:28
fonte
-2

Para responder à sua pergunta: como muitos outros disseram, não. Envie-o e limpe-o pouco a pouco no processo de correção de bugs.

Além disso, enquanto os livros / StackExchange / webforums são bons recursos de aprendizado, é provável que você descubra que nada pode corresponder ao aprendizado que você receberá trabalhando (ou mesmo discutindo trabalho) com outros programadores. Encontrar e participar de um grupo local de uma tecnologia que você está usando ou gostaria de aprender é um investimento maravilhoso do seu tempo. Além do conhecimento técnico a ser adquirido, é uma maneira fácil de fazer contatos, o que é inestimável, já que você está ansioso por futuros shows.

    
por 16.07.2014 / 18:55
fonte
-2

Seu chefe estava ciente do seu nível de experiência quando ele contratou você. Apenas expresse suas preocupações e deixe-o saber que você está nervoso com isso. Também deixe-o saber o quanto você aprendeu e quanto melhor você pode fazer o próximo projeto.

    
por 15.07.2014 / 18:34
fonte
-2

Você é um desenvolvedor web iniciante, sem um bom desenvolvedor presente para aconselhá-lo, seu chefe o contratou sabendo disso muito bem. Eu acho que você está indo tão bem quanto qualquer um poderia esperar que você fizesse. Na verdade, o fato de você ter a percepção de que o trabalho poderia ter sido melhor, e de que você realmente aprendeu coisas que lhe permitiriam fazer melhor, significa que você está se saindo melhor do que a maioria. Lembre-se, para sua própria sanidade, de que a versão de você que começou o trabalho não poderia ter feito melhor. Alguém mais experiente (e, portanto, melhor remunerado), ou você com um projeto de experiência, poderia ter feito melhor.

O que fazer agora : seja feliz que você seja um desenvolvedor melhor que há um ano. O próximo projeto você fará melhor (e no final você terá mais experiência novamente e não ficará feliz com o que fez; isso é normal). Alterar ou reescrever o último projeto dará ao negócio muito pouco benefício pelo custo. O que você pode fazer é substituir o código incorreto por um código bom quando precisar fazer alterações de qualquer maneira; isso faz sentido porque modificar código mal mantido pode ser mais difícil do que substituí-lo por um bom código. E se você conseguir que um novo desenvolvedor inexperiente ajude, diga a eles que este código não é um exemplo que eles devem copiar.

    
por 20.07.2014 / 14:05
fonte