O que você faria se estivesse em uma situação em que o projeto em que você está trabalhando é obviamente construído mal e terá falhas no futuro e será um pesadelo para manter ... mas é considerado um "sucesso" pela gerência porque os clientes estão felizes?
Eu não deveria me importar? Tudo bem que os clientes nem percebam que poderiam ter uma aplicação melhor que essa?
Em que momento paro de me preocupar em construí-lo da maneira certa e continuo com o fluxo?
Respostas:
Se os clientes estão felizes, você está fazendo algo certo. Muitas pessoas gostam de cachorro-quente sem saber como são feitas ...
Se o aplicativo for uma boa solução para o problema, mas você estiver preocupado com a falha da base, descubra como melhorar as coisas de forma incremental e elabore um plano para implementar essas melhorias à medida que você atualiza o produto. Incremental é a chave: se você deseja reescrever partes inteiras, seu gerente dirá corretamente que isso não é razoável. O perfeito pode ser inimigo do bem. Veja a história de jwz de como o Netscape deixou o IE assumir a liderança porque eles "tiveram que" reescrever o Navigator.
Se a interface do usuário do aplicativo é uma bagunça, os clientes ainda podem estar felizes porque estão comparando-o com "o caminho difícil" e até mesmo um programa de buggy pode ser muito melhor que isso. Você o está comparando a um ideal que você pode imaginar por causa de sua formação e habilidades. Mais uma vez, considere como você pode melhorar as coisas de maneira incremental e inclua isso como parte do plano.
Não pare de se importar: você quer que seu trabalho seja o melhor possível. Mas lembre-se também de que é o cliente que paga suas contas e você está escrevendo um software para eles, não você.
Não é um pesadelo para eles. Será um pesadelo para você e eles parecem pensar que você sabe o que está fazendo, por isso será corrigido. Você prefere que as pessoas que não entendem a programação pensem que seu aplicativo é pior do que realmente é? Esta não é a exceção. Aproveite isso enquanto você pode. É melhor que você espere que o cliente supere esse aplicativo. Eles podem ir tão longe em outra direção como empresa que isso é absolutamente inútil. Você pode reescrevê-lo por um conjunto de razões completamente diferente do que você pensa.
Eu acho que você nunca deveria parar de se importar, mesmo que pareça que a alta gerência tenha parado. Eu acho que o importante a tirar dessa experiência é lembrar e documentar todas as coisas que você acha que deram errado. Evitar esses erros no futuro acabará por ser reconhecido, se não este atual grupo de gerentes, talvez o próximo grupo de gerentes em que você trabalha.
Eu começaria a apresentar idéias para as próximas etapas do desenvolvimento, que incluem a re-fatoração para melhorar a qualidade do código. Evite se aprofundar nos detalhes técnicos, mas indique como as correções sugeridas significarão satisfação contínua do cliente. Esteja preparado para misturar a limpeza com os novos recursos, pois o gerenciamento estará sempre procurando algo novo para vender.
Em geral, os clientes não se importam com a manutenção até que algo dê errado. Idealmente, sua empresa se preocuparia com sua reputação e desejaria protegê-la mantendo o código.
No entanto - se este produto for visto como de muito curto prazo, pode não haver realmente um valor agregado para fazê-lo corretamente. Nesse caso - procure as correções baratas - as coisas com pouco esforço que têm um grande valor para a sanidade do desenvolvedor.
Você não Você usa o sucesso para garantir financiamento / permissão / adesão e começar a refatorar para tecnicamente correto e fácil de manter. Ou você usa o sucesso para ser promovido a partir do departamento "Eu mantenho a antiga base de código".
Talvez sua prioridade / ponto de vista esteja errado.
O mais importante de qualquer projeto de software é que ele atenda aos requisitos do usuário.
Isso é um zilhão de vezes mais importante do que estar "correto" de acordo com as tendências de design da C / S deste mês.
Sim, você deve usar padrões de design corretos, usar a tecnologia corretamente etc. mas apenas na medida em que facilita a implementação dos requisitos dos usuários de maneira robusta e sustentável.
Um sistema realmente mal escrito que realmente atenda a uma necessidade comercial é sempre melhor do que um código maravilhosamente escrito e maravilhosamente documentado que ninguém deseja ou tem motivos para usar.
Tente se comunicar com os usuários atuais e pergunte a eles quais aspectos eles acham que precisam ser aprimorados. Então você pode melhorar alguns aspectos que acha que precisam ser aprimorados e também os aspectos que os usuários propuseram. Você pode justificar suas melhorias como "necessárias para implementar as melhorias propostas pelo usuário"
Por exemplo: se os usuários pensam que a função de pesquisa é lenta. Você pode melhorar isso criando uma melhor camada de dados, que obviamente serve mais do que apenas a pesquisa, mas pode justificar o tempo gasto.