Não somos uma empresa de software. Uma reescrita completa ainda é uma má ideia? [duplicado]

14

Eu entendo o raciocínio por trás do artigo de Joel Spolsky " Coisas que você nunca deve fazer, parte I ", mas eu sempre vê-lo referenciado em situações em que o objetivo final é a produção de software. E se eu sou um desenvolvedor que mantém um site de comércio eletrônico? Meu trabalho não está escrevendo uma plataforma de varejo, mas sim colocando-a em uso. Na verdade, isso não seria nem mesmo uma reescrita, mas uma grande transição de banco de dados e de web design.

O software no qual o nosso site está baseado está escrito em ASP clássico e, fundamentalmente, está faltando muitos recursos que os clientes esperam de um site de compras atual. Em vez de continuar a adicionar esses recursos em partes, meu pressentimento é que eu deveria começar a transição para uma plataforma mais moderna. Perderíamos as personalizações que fizemos ao longo dos anos, mas, francamente, muitos desses recursos já existem (e quase certamente já foram implementados melhor!) No pacote para o qual gostaria de mudar.

Estou sendo vítima do espírito da Netscape, ou estou certo em pensar que meu tempo é melhor gasto em lugares além de fazer com que nossas ferramentas façam o que precisamos?

Para esclarecer, isso é o equivalente a trocar de plataforma de blog para nós. Qualquer "desenvolvimento" que eu faça é essencialmente reescrever o front-end do nosso site, enquanto o back-end está fora do meu controle.

Suponha que o desenvolvimento do WordPress tenha parado há anos e estivesse faltando recursos "modernos" como comentários, páginas estáticas, links permanentes limpos, etc. Claro, eu poderia escrever um plug-in para adicionar essas coisas, mas depois de um tempo, não Seria melhor mudar as plataformas para algo que tivesse todos esses recursos necessários desde o início?

    
por Nicholas Sideras 31.05.2011 / 22:17
fonte

9 respostas

33

Antes de atualizar ...

Poderia ser uma boa ideia se, e somente se:

  • adiciona recursos que seus clientes solicitaram
  • não perde recursos existentes na solução atual

    (alguns usuários perguntarão a eles, e se você for uma pequena empresa, deixar os clientes é muito caro - e pode iniciar uma onda)

  • não adiciona requisitos invisíveis / ocultos e efeitos colaterais,

  • o não vem com restrições ambientais (ou as considera em cálculos),
  • seu novo middleware de destino é ativamente desenvolvido e suportado , e será assim por um longo período,
  • você cuidadosamente considera os custos (e vê um benefício relativamente de curto prazo depois disso) de:
    • desenvolvimento,
    • implantação,
    • treinamento,
    • maintenance & suporte,
    • maintenance & suporte,
    • maintenance & suporte.

Certifique-se de que não será mais difícil de manter do que é agora.

Além disso, você menciona sua tecnologia atual, mas para a qual você gostaria de se mudar. É ainda mais perigoso se você mudar de tecnologia.

Se você decidir atualizar ...

Certifique-se de:

  • backup dos seus dados,
  • ensaie um plano de recuperação de negócios ...:
    • para reverter para seu status atual de trabalho o mais rápido possível se as coisas derem errado,
    • para se comunicar com os clientes sobre a transição e os problemas (com falha) e o status de seus dados.

Se você atualizar (e se possível) iterativamente!

  1. Atualize seu banco de dados ou crie um novo,
  2. copie seus dados
    • atualize seus backups regularmente para trabalhar em cópias recentes,
    • e backup das cópias antigas bem (criptografadas com segurança, etc ...)
  3. Desenvolva em um ambiente separado ,
  4. teste internamente muito ,
  5. teste com um grupo de foco de alguns clientes confiáveis.

Se for necessária uma alternância completa de middleware, veja se há casos de sucesso de migrações entre essas duas soluções de software e leia com atenção o que outras pessoas fizeram e quais armadilhas e roadbumps eles encontraram.

Refatorar e monitorar a qualidade

Se for apenas (ou quase inteiramente) sobre o código confuso, não faça isso . Em vez disso:

  • Leia minha resposta em como organizar o código sujo e sem comentário (aplica-se a trechos de código específicos, mas também a bases de código maiores, e o material recomendado pode ajudar!)
  • Apenas refator ao longo do tempo,
  • Use os sistemas integração contínua e inspeção contínua para monitorar a qualidade e os impactos da refatoração,
  • E tente entrar em contato com os clientes para perguntar claramente quais recursos estão faltando e criar um caso de negócios muito sólido em torno de cada um deles para saber se eles valem a pena para projetos de melhoria pequena.

O desenvolvimento é caro, a manutenção ainda mais e a criação de coisas sem nenhum motivo específico pode ser bom para agradar os usuários, mas lembre-se de que você precisará manter e dar suporte a isso.

Além disso, se você não é uma empresa de software, você tem pessoal treinado o suficiente para dar suporte a essa tarefa durante o desenvolvimento e após a implantação? E se alguns de seus funcionários saírem no meio da tarefa?

    
por 31.05.2011 / 22:27
fonte
11

Os projetos fracassados sobre os quais Joel Spolsky escreveu eram grandes empresas. Para os poucos exemplos que ele forneceu, há alguns exemplos de sucessos de reescrita:

  • Mac OS X
  • Windows NT

Agora, o Windows foi reescrito mais de uma vez e, a cada vez, foi atingido ou ignorado se as alterações seriam bem recebidas ou não. Por exemplo, o NT foi um sucesso, pois tornou o Windows utilizável na Enterprise (onde o Unix já existia). Por outro lado, o Vista não foi tão bem recebido. No entanto, em ambos os casos, a Microsoft fez hedge de suas apostas.

O ponto que Spoelski faz é que uma reescrita de software é uma proposta incrivelmente arriscada . À medida que a complexidade do projeto aumenta, o risco aumenta exponencialmente.

O contraponto com Brooks e o comentário fazer um para jogar fora é que sua primeira versão de qualquer coisa é um processo de aprendizado. Ao tentar tratá-lo como mais do que um processo de aprendizado, você ficará preso a códigos ruins por um longo tempo. Em Programador Pragmático e em muitas outras fontes, pequenas refatorações para limpar más decisões são muito menos arriscadas do que reescrever escalas inteiras.

Agora, na sua situação, você tem que olhar para as escolhas à sua frente. Você tem os seguintes desafios:

  • Seu software atual é baseado em uma plataforma obsoleta
  • As novas plataformas resolvem melhor os problemas que você teve com sua plataforma atual e, mais completamente,
  • Alterar plataformas é arriscado
  • As regravações precisam ser planejadas ou falharão

Antes de pensar em reescrever, você precisa responder algumas perguntas:

  • Este software já está próximo do final de sua vida útil? (ou seja, se ele tiver um prazo de validade limitado, o custo e o risco associados à alteração da plataforma podem não valer a pena)
  • O software é simples / pequeno? Quanto maior o software ou mais complexo, mais coisas podem e correrem mal.
  • Sua plataforma de destino é capaz de fazer tudo o que você precisa? Para avaliar isso, pode valer a pena simplesmente fazer a (s) coisa (s) questionável (s) para ver se é viável. Pode ser possível, mas tão feio quanto o que você tem agora. É melhor descobrir com um teste controlado do que depois de tomar a decisão.
  • Por quanto tempo o seu cliente pode esperar entre lançamentos? Se uma reescrita completa pode ser feita no mesmo ciclo de lançamento (ou mais rapidamente), então é provavelmente um acéfalo. No entanto, a maioria dos clientes não se preocupa com seus problemas e eles não vêem seus problemas como problemas. Eles não vão querer esperar enquanto você faz uma reescrita completa.
Eu passei por este exercício mais de uma vez, e às vezes saía em favor de uma reescrita e às vezes saía em favor de manter o status quo. Várias vezes, descobrimos que, se reescrevêssemos apenas uma parte do aplicativo, poderíamos reduzir significativamente nossa dor e, ao mesmo tempo, fornecer valor ao cliente.

    
por 31.05.2011 / 22:42
fonte
5

Migre de forma incremental

O ponto sobre não reescrever do zero é que você arrisca bagunçar todo o seu produto através de especificações instáveis, listas de bug fugitivas, etc, e o tempo / custo que você gastaria com nada disponível para mostrar pelo seu trabalho. é difícil de justificar.

Como você já usa o ASP, recomendo implementar novas partes do site no ASP.NET e, gradualmente, mover as páginas mais antigas para a nova estrutura à medida que você as atualiza. Fizemos isso com um produto legado e, ao longo de 18 meses, migramos completamente, mas poderíamos enviar uma atualização a cada duas semanas para acompanhar a demanda do cliente.

    
por 31.05.2011 / 22:30
fonte
4

Toda a ideia de uma reescrita completa é que não há nada, nem uma única coisa, de valor em qualquer lugar no código existente. De fato, toda a idéia era falha e deveria ser expurgada da terra.

Na minha experiência, isso raramente é o caso. Geralmente é apenas obsoleto e precisa receber uma nova camada de tinta por meio de uma transição para uma plataforma menos obsoleta. Quase todos os aplicativos anteriores representam um estrato fossilizado de comportamento e otimização de aprendizado. Eles são camada sobre camada de melhorias incrementais em uma tentativa de alcançar um pico funcional. Ignore este processo por sua conta e risco.

Também muitas vezes vejo pessoas se comprometendo com uma "reescrita completa" e depois reescrevem o aplicativo para o primeiro dia de seu ciclo de melhoria, sem incorporar nenhuma das lições ou aprimoramentos obtidos em anos de operação. Sim, esse material é horrível para uma base de código limpa, mas está lá porque a base de código original era insuficiente. Sim, reescreva, mas incorpore as coisas que estavam faltando na ideia original. O melhor software vem assim: incorporando as lições aprendidas em versões inferiores em um lançamento mais perfeito.

    
por 31.05.2011 / 22:38
fonte
3

é sabedoria convencional que fazer uma reescrita é uma má ideia. E por um bom motivo. As reescritas completas geralmente são uma má ideia e muitas vezes falham de forma espetacular.

Mas a melhor maneira de indicar o conselho é ... "Uma reescrita completa é sempre uma má idéia, exceto quando é uma boa idéia".

Não substitua a sabedoria convencional pelo seu julgamento pessoal (ou da sua equipe) sobre o que é melhor para a sua aplicação . Um pouco de sabedoria convencional não pode e não se aplica a todas as situações. Cabe a você avaliar por si mesmo - tendo em mente as advertências que os outros fornecem - se uma reescrita é necessária ou não. Ninguém mais aqui sabe tanto sobre seus objetivos de projeto e aplicação quanto o você faz.

    
por 31.05.2011 / 22:54
fonte
2

Não parece que você está fazendo uma reescrita completa, mais que você está movendo sua empresa para uma nova plataforma que já implementa a funcionalidade existente, que é muito mais sensata do que reescrever um novo sistema inteiramente a partir do zero. Vá em frente! ... e certifique-se de ter planos de backup, planos de recuperação, ensaiar e testar a transição várias vezes (em um ambiente de teste isolado apropriado), fazer alguns testes de usabilidade na nova plataforma, etc ...

Muitas transições comerciais de uma plataforma para outra. Eu sei que existem empresas financeiras que estão migrando de seus sistemas de mainframe COBOL e é muito maior do que apenas uma transição de banco de dados e design de interface do usuário. Mas também é essencial.

    
por 31.05.2011 / 22:33
fonte
1

A questão é sobre qual estratégia é "melhor", certo? Como você pode ver pelas respostas aqui, há prós e contras para ambos. Então como você decide? Minha resposta é que você tem que fazer uma análise de risco adequada. Você também precisa ponderar as consequências em dois níveis: uma perspectiva de tempo curto e uma longa, e isso tem a ver com a vida útil esperada do sistema ou produto. Tudo se resume a tomar o caminho mais econômico, e para isso você tem que saber quanto (tempo) todos os custos e os riscos (em termos de custos) que estão envolvidos. Esta não é uma tarefa fácil, mas tem que ser feita se você gosta de tomar uma decisão de negócios válida, em vez de um palpite.

Cuidado com as respostas categóricas.

    
por 01.06.2011 / 13:20
fonte
0

Estou diante de um problema semelhante com um aplicativo da Web Java Struts confuso. Eu pretendo reescrever todo o site no tempo, mas não posso parar de melhorar o código existente. Em vez disso, planejo desenvolver novas páginas em uma arquitetura melhor e migrar as páginas antigas quando tiver que tocá-las ou quando não houver tarefas urgentes.

    
por 31.05.2011 / 22:25
fonte
0
Sou proponente de reescrever, contrariando o conselho de Joel. Isto é principalmente porque eu encontrei muitos sistemas que estavam apenas errados e tinham sido feitos "errados" por tanto tempo que seria impossível refatorar tudo que precisava ser consertado. E eu quero dizer "tudo": o banco de dados estava ruim, o código era ruim e não era reutilizável, até o uso de HTML / CSS desatualizado. Quando algo é tão ruim, a refatoração é como um canal que vaza - você precisará substituí-lo em algum momento, e fazê-lo mais cedo ou mais tarde economizará tempo e dinheiro. Eu vi em primeira mão os efeitos de seguir o mantra "reescreve o mal", e o resultado final foi quando o sistema finalmente caiu, ele caiu espetacularmente e arrastou a empresa para a falência, tudo porque ninguém podia ver que as coisas eram terrível e uma reescrita teria sido a única graça salvadora.

Para responder à pergunta do OP, se o site não puder ser sustentável para o futuro, se estiver usando tecnologias muito obsoletas que não são mais suportadas (tornando mais difícil fazer com que as pessoas o mantenham), então é hora de considerar um reescrever. Seja ou não uma empresa de software ou não, não é tão relevante quanto a pergunta se o que você economiza ( LONGTERM , não cai na armadilha de pensar a curto prazo; é essa armadilha que faz com que os sistemas estagnar e infeccionar em primeiro lugar!), ao fazer uma reescrita, superará a bagagem adicional de manter um sistema terminalmente doente.

    
por 02.06.2011 / 14:04
fonte