Por que os projetos são reescritos e porque eles falham

O tema antigo - você pode ou não reescrever um produto grande e funcional com uma base de usuários ativa? A resposta, em geral, será - sim, você pode. A única pergunta é como? Tendo visto várias dessas tentativas no passado (com ou sem sucesso), este artigo é a visão do autor sobre esse problema.

Código ruim, processo de construção excessivamente complicado, tecnologias desatualizadas, linguagem de programação terrível - todos esses problemas, e muitos outros, acompanham todo projeto grande suficientemente bem-sucedido, qualquer processo de desenvolvimento de software em qualquer organização. Como mostra a prática, na maioria dos casos, a situação só piora com o tempo - pequenos inconvenientes se transformam em desagradáveis ​​“características do nosso trabalho”, as pontuações aumentam constantemente durante o planejamento de tarefas e a qualidade do produto acabado começa a sofrer. O toque final neste quadro é o não cumprimento de prazos e planos devido à impossibilidade de depurar a funcionalidade, ou mesmo de entregá-la ao ambiente de trabalho. Muitas vezes, nessas situações, dizemos que a dívida técnica se acumulou.

Essa dívida surge de forma totalmente natural e persegue todos os sistemas, por mais bem-sucedidos que sejam, quando há o próprio produto, seus usuários, canais de comunicação com eles. Não importa se o produto é vendido diretamente, ou se é uma parte auxiliar da atividade da empresa, é importante que esteja em operação há muito tempo. Os usuários desejam obter uma nova funcionalidade (talvez até paguem por ela), a administração quer disponibilizá-la aos usuários o mais rápido possível, pois o departamento de desenvolvimento, sob pressão dos prazos, implementa as mudanças necessárias. O processo se repete muitas vezes e, mais cedo ou mais tarde, alguém dirá em voz alta - “parece que temos uma dívida, talvez técnica!”

Todos começaram a notar que cada nova tarefa é mais difícil que a anterior, e isso não é mais um acidente, a complexidade está crescendo exponencialmente. Existem locais “frágeis” no código que é melhor não tocar, na maioria das vezes defeitos de usuários e alarmes do sistema de monitoramento do ambiente de trabalho “chegam”. Em primeiro lugar, as iniciativas para introduzir novas tecnologias e práticas destinadas a melhorar a qualidade do produto como um todo são adiadas e, em seguida, completamente esquecidas. Forma-se a ideia geral de que algo está errado, começa a busca dos motivos do que está acontecendo e de quem é a culpa. Claro, não há nada de bom neste estado de coisas, ainda mais - o negativo começa a envenenar o clima da equipe.

, , — , , , , , , , , , , .

, , , , , , . , — , ? , .

, . , . , , , - — , ? , ? ? , ? . , , , , — , . — .

— , , , , . , , . — . , IDE , , . .

— , :

• , ? - , .
• - , - , .
• , , .
• , .
• , , , , .
• - , , .
• , - , .

, — , , . . , — , , . , — , , .

. , , . — , . — . — ? .

“ ?”. ! , 100% — , - , , . , , , — 50/50, 60/40, . — , , .

, , — , , . ! ! ! — . .

, , — , .

, — , , , — . , — ? , , . , Flash — , , . , , — . , , , .

. — , , — , . , , . , … , .

, . , , , , , . , , - . , , , — , , , , “ ”, . ? , , . , , , — .

? — . , — . , , , . , .

— , : , , , .. , , . , , , . . , , , , , — , . , — , . — , . — , , , , .

— , , , . . , , , . , , , , — .

, , . — , , , . , . - Terra incognita, . - - , , , - ( ) . - , - , . , , .

, , . . , . , API. http- . — , - , offline-, - Selenium-, UI, . , API.

, , . — . , . API , , -, ? , ? , , — , — .

. , , , , — . , , — . , :

1. ,

- ? - — . — , . “, ”: “ , , , , ”. , , “ ” , , , — , “” , . , ?

, — , API, .. — , - . . , , , , , , . , , .

, . — , , , . , , , , , , , , . , — , . , , - , , , , . , , , , , , — , . .

— , , . , , , , : , , . — , .

, , , , — , . , — , .

, , - . . — “”, “”. , , .

, , , . , , web-, , — , . , , , — “”? ? , ? , . , , ?

, , , — . Twitter, , , , , . , , . , Ruby on Rails, JVM, . .

, — , . , , , . , , , , . , (-, ) . , . , .

. , , . — , , , , . , . — , , — .

P.S.

Tudo o que foi escrito acima se aplica, é claro, a produtos de software grandes e funcionais com uma base de usuários ativa. E apenas para os casos em que não é possível simplesmente lançar uma nova versão do produto junto com a antiga, como foi, por exemplo, com o Basecamp e como é com todos os chamados. Software "in a box".