Segredos do Windows: A batalha dos recursos

Quando você está remodelando um recurso do zero, cada recurso antigo torna-se uma nova solicitação de recurso.

Raymond Chen

De vez em quando, um componente de interface do usuário vai ter uma reformulação profunda. Quando isso acontece, todos os outros recursos começa em-100 pontos — até mesmo características que já existiam na versão antiga.

Este conceito de-100 pontos originalmente foi explicado por Eric Gunnerson, ao discutir por que a linguagem c# tem algumas características, mas outros não. O princípio aplica-se geralmente a qualquer processo de design de produto. Cada idéia para um recurso começa com um défice imaginário-100 pontos. Isso significa que tem que demonstrar um efeito significativo do net-positivo sobre o produto como um todo a fim de emergir como sendo verdadeiramente digno de consideração.

Um recurso que fornece um atalho para algo que já é bastante fácil de fazer não ganha muitos pontos e vai deixar de atingir o território positivo. Um recurso que beneficia apenas uma pequena porcentagem de usuários também não ganhar pontos suficientes para superar seu déficit inicial. Uma característica que parece bastante simples, por si só, mas cria complexidade adicional em outro lugar pode acabar sendo um líquido negativo. Esta é uma situação bastante ruim mesmo sem a pena adicional de começar com um resultado"negativo".

Arranque de mim

Menu iniciar em Windows 95 substituiu o antigo gerente de programa do Windows 3.1. O gerente de programa tinha uma opção chamada salvar configurações ao sair. Se você não verificado-, quaisquer alterações feitas a grupos de programa iria ser Descartado quando você fez logoff. Não havia nenhum recurso correspondente em Windows 95.

Quando o recurso de remoção acontece, muitas vezes há um clamor enorme de pessoas que foram anexadas a esse recurso antigo do design antigo. Eles dizem: "Como ousa você remover o recurso X do redesenhado Frimble Framble?" Esta pergunta é para trás, no entanto. O recurso não foi retirado o redesenhado Frimble Framble. O recurso nunca existiu no redesenhado Frimble Framble. Portanto, não é que o recurso foi removido — é que o recurso não foi adicionado.

A decisão de chutar o código antigo para o meio-fio e começar do zero presumivelmente não é feita apenas para risos. O velho modelo pode não ser adequado para cargas de trabalho modernas. Um design que funciona quando há alguns milhares de registros pode não funcionar tão bem quando há milhões de registros. O design antigo simplesmente pode ser ultrapassado. Em vez de tentar construir uma nova versão em cima do velho, os designers decidiram ir com um novo começo.

Todas as características de projeto anterior entram em uma batalha de recurso contra todas as características do novo design. A maioria vai sobreviver porque eles são recursos básicos que todo o projeto teria de ter em conta. Eles facilmente superar o défice de 100 pontos que todos os recursos têm no início do processo.

Por outro lado, características mais esotéricas ou menos utilizadas não podem torná-lo na versão final. Outros não podem sobreviver não por falta de pontos, mas por falta de recursos. Suponha que um projeto velho tinha 100 recursos. Suponha que você tem recursos suficientes para dar a nova versão 100 recursos. Se todos os recursos do design antigo foram transportados para o novo design, o resultado seria um novo design totalmente idêntico do modelo antigo. Se for esse o caso, por que redesenhá-lo em primeiro lugar?

O conflito entre antigos e novos pode ser direto. Recurso antigo X pode ser em conflito direto com o novo recurso de Y. Se você optar por manter o X, então você não pode fazer de forma eficiente Y e vice-versa. Por exemplo, recurso X pode se tornar inviável uma vez que a contagem de registro superior a algumas centenas de milhares. Alternativamente, um recurso pode deixar de fazê-lo em uma nova versão, não porque ele perdeu a batalha de recurso contra uma outra característica, mas porque as pessoas, criando a nova versão não estavam mesmo cientes do velho recurso em primeiro lugar.

Em muitos casos, características antigas perdem-se com muita relutância. "Sim, nós realmente desejamos nós poderia adicionar recurso X, e foi uma decisão muito dolorosa para deixá-lo fora," diz a equipe. "Nós estávamos esperando para ser capaz de esgueirar-se, mas o custo estimado para adicionar o recurso saiu a cerca de 10 dias, e nós simplesmente não temos que muito tempo em nossa programação. Desculpe."

Como com qualquer projeto, realidade impede você de fazer tudo o que deseja fazer. Parte do trabalho de Engenharia está fazendo trade-offs entre as coisas que você deve fazer para decidir quais recursos serão implementados e que características têm de ser deixado para trás.

Raymond Chen

Raymond Chendo Web site, The Old New Thing e identicamente intitulado livro (Addison-Wesley, 2007) tratam Windows histórico e programação do Win32. As informações fornecidas aqui é apenas para fins informativos e não pretende ser um substituto para aconselhamento profissional.

Conteúdo relacionado