Este artigo foi traduzido por máquina.

Cutting Edge

Desastres de software: Estratégias de prevenção e recuperação

Dino Esposito

Tão emphatic quanto pode parecer, nossas vidas dependem software. Como os usuários dos serviços de vários nós, sabemos muito bem que o software funcionando como esperado pode realmente salvar nosso dia. Mas o software está ficando mais complexo porque ela tem que modelar a complexidade dos processos do mundo real. Os desenvolvedores, arquitetos e gerentes de TI devem lidar com isso.

Neste artigo, examinarei práticas recomendadas que ajudam a corrigir um sistema de deteriorated e mostrar a você os padrões que poderão impedir que um sistema cresce de maneira não-controlada. O termo "big bola de lama" (BBM) foi criado há anos para se referir a um sistema que amplamente estruturadas e macia com ocultas dependências entre as partes, com muita duplicação de dados e código e uma identificação de clara de camadas e preocupações — uma Selva de código espaguete. Para ler mais sobre o BBM, eu recomendo um excelente trabalho na Foote de Brian e Joseph Yoder da Universidade de Illinois em Urbana-Champaign, que você pode baixar em http://bit.ly/nfPe2Y. Neste artigo, os autores não condemn um BBM como o problema pior-nunca; eles apenas sugerem que os arquitetos e desenvolvedores estar pronto para enfrentar o risco BBM e saiba como manter tudo sob controle.

A dinâmica de sistemas de Software

Alguns há 30 anos, no início da era software, aplicativos eram muito mais fácil escrever hoje. Tínhamos sem a necessidade de GUIs. Não foi preciso se preocupar muito sobre estética, necessidades de distribuição, problemas de escalabilidade ou preocupações de implantação. E, por último, mas certamente não menos importante, tínhamos muito menos lógica de negócios para implementar.

No momento, o desenvolvimento de software foi levado a sério e as melhores mentes de envolvidos. Bastante surpreendentemente, no início da década de 1990 já tínhamos a maioria dos princípios de arquitetura e desenvolvimento de software e padrões dispostas. Indiscutivelmente, muito pouco tenha sido inventada "!" desde. Princípios como separação de preocupações e inversão de dependência, paradigmas como OOP (programação) e orientação aspecto orientada a objeto e práticas, como o design para capacidade de teste não foram desenvolvidas em anos recentes. Muitas delas estão sendo redescoberto e aplicadas pelos arquitetos e desenvolvedores de hoje, mas eles existem há décadas.

Mas por que tem esses princípios e práticas foi qualquer em uma classificação de limbo anos? Pode haver muitos motivos para isso, mas é um Evite comuns do desenvolvedor, "Ele funciona, então, por que deve posso aprimorá-la (e o custo do desperdício esse tempo extra de pagamento)?"

O Dynamics diferentes do Microsoft mundos e Java

Em meados de 1990, o advento da orientação a objeto e de idiomas, como Java (mais de C++) solicitado muitas empresas a reestruturar o seu software, movendo blocos maiores de lógica comercial de bancos de dados e mainframes. Desenvolvedores de Java, especificamente no espaço empresarial, tinham que lidar com mais complexidade do que o encontrado no desenvolvimento rápido de aplicativos (RAD) normalmente associado à programação de Visual Basic. Ele não é surpreendente que aspecto orientação, estruturas de injeção de dependência (como Spring) e mappers de objeto/relacional (como o Hibernate) — para não mencionar uma longa lista de ferramentas (como, por exemplo, NUnit, Ant, Javadoc, Maven e assim por diante) de programação — se originou no mundo Java. Eles foram criadas por desenvolvedores para desenvolvedores suavizar o impacto da complexidade de ferramentas.

Ao mesmo tempo, no mundo Visual Basic, RAD foi a última moda. Visual Basic ajudado empresas a criar bons front-ends de procedimentos armazenados quando não usando o código de mainframe. O advento dos serviços da Web criou uma fachada extra e deu ao código de mainframe nome muito mais atraente de "serviços legados".

A OOP versus RAD debate nos últimos 15 anos foi uma disputa razoável. Quando a Microsoft introduziu recursos orientados a objeto no Visual Basic, era realmente difícil de explicar para desenvolvedores por que me diga esses recursos terrível eram tão importantes. E eles realmente não foram, dado o nível relativamente baixo de complexidade dos aplicativos thin.

A.NET revolução

O lançamento do Microsoft.NET Framework aconteceu em um momento crucial. Ele aconteceu quando algumas das grandes empresas que anteriormente tiver optado por uma abordagem RAD tinham visto suficiente da Internet e tivesse sistemas de back-end antigos o suficiente para justificar uma reconstrução luz da novos processos de negócios relacionados à Internet. Ao mesmo tempo, essas empresas encontrados na plataforma Microsoft uma estrutura extensível, potente e confiável. Obviamente, levou apenas alguns anos.NET possam ser superestimados com a mesma quantidade enorme de complexidade que colegas Java sofreu uma década anterior. Maioria.NET developers, porém, cresceram com a abordagem RAD e princípios RAD para desenvolvimento.

Em um mundo RAD, você tende a preferir o código que simplesmente funciona e a criação de aplicativos, adicionando os blocos que geralmente são independentes. (E quando elas não são realmente independentes, você torná-las dessa forma, código de abusing e duplicação de dados).

O problema não está com RAD como um paradigma de programação. O problema real que é mais provável que levar para o famoso BBM está aplicando RAD (ou qualquer outro paradigma) sem correções que podem impedir que o crescimento do aplicativo e multiplicação subseqüente de complexidade, sob controle.

Desmarque os sintomas de um BBM

Parece ser uma lei natural de programação que cada unidade de software de qualquer tamanho (seja ela uma classe, uma camada ou um sistema inteiro) degrada. Seus paper mencionado anteriormente, na Foote e Yoder chamá-lo a "erosão estrutural" do software. Pessoalmente, eu gostaria de chamá-lo a biodegradability do software. Como unidades de software são mantidas ou alteradas, eles se tornam mais difíceis de manter ou alterar posteriormente. Independentemente do nome, hoje em dia é apenas parte do negócio; Você não poderá ignorá-la e tentar fazer isso, basta causará danos.

Biodegradability de software totalmente está conectado ao crescimento fragmentado de projetos. Incorporando a um sistema existente de um novo requisito — que foi projetada sem que esse requisito específico — é sempre problemático. Não significa que ele não é possível usar ou não deve, ser feito — apenas significa que, adicionando um novo requisito, você está alterando o contexto. Uma única alteração normalmente não tem um impacto enorme na arquitetura, mas quando as alterações individuais ocorrem com freqüência, o contexto do sistema muda ao longo do tempo e muda de forma em algo que provavelmente requer uma arquitetura diferente. Esse processo é também conhecido como requisitos de rotatividade.

Da mesma forma, crescimento fragmentado é parte do negócio e não estão sendo pronto para lidar com o que é um dos deadly sins da arquitetura de software moderno. Adicionando novos requisitos de um por vez sem reconsiderando o sistema como um todo em cada etapa, você pode criar as condições ideais para um BBM.

Que sintomas comuns unequivocally dizer que você vai ter muito lama nas engrenagens do seu sistema? Um BBM não obtenha formado durante a noite e não chega no início. Endereçamento esses sintomas, que descreverei, ajudará a impedir que ele fique muito grande.

O primeiro alarme bell toca quando você fizer uma alteração em uma classe e acaba quebrando o código na classe de outro, aparentemente não relacionado. Esse é o efeito desagradável do software rígido, o que é caracterizado por algum nível de resistência à mudança, que determina basicamente regressão.

Um segundo alarme bell toques quando ocorre falha na tentativa de reutilizar um trecho de código a aparentemente reutilizável. Se o mesmo código não funcionar depois que ele é movido para outro projeto, as causas mais prováveis são difíceis de encontrar dependências ou classes rigidamente acoplados. Eles também são a principal causa de rigidez de software.

Acoplamento forte é benéfico porque ele ajuda você a escrever código mais rápido e que o código provavelmente será executado mais rapidamente. No entanto, não, faz o código de fácil manutenção. Em um projeto que cresce de forma gradual (como a grande maioria dos projetos de hoje), a capacidade de manutenção é de longe o atributo de software principal que você deseja levar em conta.

Finalmente, um terceiro alarme toques de campainha quando você precisa aplicar uma correção para uma função, mas não se sentir seguro para aplicar uma correção ideal (ou não conseguir fazer isso), para que você recorrer a outra alternativa.

Felizmente qualquer sistema pode sobreviver a uma ocorrência (ou até mesmo alguns) esses sintomas. Sua mecânica subjacente é bastante perversa, porém. Se você esquecer um desses sintomas, você pagará o risco de deixar o sistema mais complicada.

Por exemplo, vamos considerar o sintoma segundo (às vezes chamado immobility). Você deve adicionar um novo recurso e você se sentir seguro bastante adaptar um pouco e reutilizar uma função existente. Tentar e ele não funciona porque a classe que você esperava seria reutilizável é, na realidade, totalmente conectada a outras pessoas. A alternativa que você possui está importando um conjunto muito maior de funções em vários módulos. Em tais casos, uma solução comum (mas ingênuos) está duplicando algum código sem nunca tentar uma Limpador de reutilização de classes. Duplicação de código corrige o problema temporariamente, mas apenas que cresce o BBM.

Causas possíveis para um BBM

É raro para um desenvolvedor único criar um BBM. Em vez disso, um BBM tem muitas causas e freqüentemente a causa principal tem que ser pesquisado fora do nível atual de desenvolvimento. Gerentes exigentes, bem como os clientes que não sabem realmente o que querem, transmitem para desenvolvedores informações claras e ambíguo. A menos que a equipe tem muita experiência em geral de desenvolvimento de software e no domínio específico, isso automaticamente gera arbitrárias opções sucessivamente fixo por meio de comprometimentos e soluções alternativas. O efeito líquido é que a arquitetura geral é enfraquecida na sua base.

Todas as pessoas envolvidas em um projeto de software podem fazer muito para evitar um BBM e suavizar seu impacto considerável. Vamos examinar as etapas fundamentais para tirar quando perceber que está imersa em um BBM.

Uma estratégia de recuperação de desastres

Quando você enfrenta um BBM, a idealista coisa a fazer é simplesmente reescrever o aplicativo com base nos requisitos revisados e novas opções de arquitetura. Mas uma reescrita completa nunca é uma opção que você pode considerar. Como você faria sobreviver a lama?

Na Foote e Yoder usam uma imagem evocativos apresentar a opção apenas razoável, você tem nesses casos: Sweep rubbish sob o tapete e prosseguir com a sua própria vida. Mas acho que posso resumir uma estratégia de recuperação de desastres software em três etapas. A primeira etapa está parando qualquer desenvolvimento novo. A segunda etapa é isolar pontos fracos em camadas (quando não hierárquico) e a organização de ferramentas para medir qualquer regressão esses pontos. Finalmente, você pegar cada uma dessas camadas problema isolado e, com muito cuidado, tente refatorá-los para uma arquitetura mais limpa e mais rígida.

O segundo após você interromper o desenvolvimento em um projeto turva, você começa a pensar um monte de testes relevantes. Imersa em um BBM, a última coisa que você pense são testes de unidade clássico. Os testes relevantes neste contexto são classificação dos testes de integração que abrangem várias camadas e às vezes níveis. Esses testes são lentos para serem executados em primeiro lugar, mas — e muito mais importante — eles podem ser lentos para gravar. Você precisará isolar partes (provavelmente grandes) do comportamento e ocultá-los por trás de uma fachada que pode ser comandada por meio de testes. Escrever uma fachada pode não ser fácil, mas geralmente é no mínimo possível. É principalmente uma questão de tempo e trabalho. Esses testes são uma grande ajuda para as próximas etapas, pois fornecem a você uma ferramenta automatizada para medir a regressão conforme você prosseguir com a etapa final. A etapa final consiste em meticuloso refatoração trabalho onde o primeiro problema abordado é o acoplamento forte.

Planejando uma estratégia para impedir que um BBM

A prevenção é sempre preferível de tratamento. Existem três virtudes cardinal de uma equipe que podem impedir que um pate BBM, que discutiremos posteriormente. Considerando que a maioria dos projetos ultimamente sofrem com um alto nível de rotatividade de requisitos, fragmentado crescimento é de fato, não meramente uma possibilidade. Para impedir que um BBM, você deve ter uma estratégia eficaz para lidar com crescimento fragmentado de funcionalidade.

O mantra mantido pelo software de declarações que o software moderno perfeito serve as necessidades atuais e é flexível o suficiente para acomodar requisitos futuros. O primeiro porque dos três mencionado anteriormente é a experiência de domínio. Quando você não pode ter um especialista em um domínio real da sua equipe, pelo menos você precisa de alguém com um conhecimento profundo do domínio — que provavelmente faz você especialista novo domínio. Experiência de domínio leva você a opinião sensata sobre recursos que provavelmente será necessário e solicitado. Assim, você pode facilmente planejar com antecedência, mantendo o princípio YAGNI (você Ain't Gonna precisa ele) claramente em mente.

A abordagem de cartões (CRC) classe-responsabilidade-colaboração me ajudou a compreender melhor a mecânica de domínios que me deparei pela primeira vez. Vejo mais como uma maneira de ensinar a você mesmo domínio, que uma forma para inventar um design adequado de fichas CRC. O design, por outro lado, é adequado somente se validado pelo cliente real. Casos de uso — ou, melhor ainda, um protótipo — são as opções mais inteligentes.

O protótipo pode ser um problema porque os clientes podem goste tanto dele que eles forçam a estendê-lo em vez de começar do zero com um novo design. Protótipos normalmente são feitos com código descartável deliberadamente escrito seja rápida e, como tal, destituída de princípios e padrões. Você não que apenas começar com o código descartável.

O segundo porque está se tornando um melhor desenvolvedor/arquiteto aprendendo princípios sã é capaz de desenvolvimento de software e práticas recomendadas comuns. O desafio aqui é tudo em aprender a fazer coisas simples corretamente por padrão. Não tenha receio de injeção de dependência e de programação baseada em interface. Valide cada classe contra armadilhas comuns de OOP. Garanta a precisão por meio de código e a análise estática. Se você não tiver certeza sobre o funcionamento de um recurso, torná-lo testável e escrever testes. Manter seu código mais enxuto e média, a maioria dos métodos não mais que algumas linhas (com vencimento exceções, claro). Se essas práticas tornam-se parte do seu conjunto de ferramentas, o BBM fica um pouco mais longe longe de seus projetos.

O terceiro porque é sobre Noções básicas sobre o tempo de vida do projeto. Nem todo projeto tem que montar um sistema que dura por décadas. Projetos de curta duração não requerem o mesmo cuidado de design. Você pode conseguir mais rapidez neles e colocar cuidados em torná-los funcionar antes de torná-los à direita. No software, complexidade deve ser controlado onde ele existe realmente, não criada onde ele não existe e não deveria para estar. O perigo, no entanto, é quando inicial crença de que o projeto teve um curto período de tempo é invalidada surpreendente sucesso por demanda e a criação de um mercado. Se a versão subseqüente acontecer muito lentamente, você corre o risco de um concorrente snatching do mercado — ou você corre o risco de criação de um BBM devido às demandas dos negócios de realmente forte (e desesperado).

Recuperação de desastres de projeto de software

O BBM é um antipadrão comum, mas, até certo ponto, ele é um atributo que pode ser aplicado a praticamente todos os projetos de software. Se originou usando as ferramentas erradas para controlar a complexidade. Neste artigo, usei uma expressão — recuperação de desastres — que é popular em IT. O mantra dos especialistas de recuperação de desastres, no entanto, pode ser aplicado a projetos de software muito: dólar gasto na prevenção valem mais de dólar gasto na recuperação. Corra em office do seu gerente hoje!

Dino Esposito é o autor de "Programming Microsoft ASP.NET MVC"(Microsoft Press, 2010) e co-autor do"Microsoft.NET: Arquitetando aplicativos corporativos "(Microsoft Press, 2008). Residente na Itália, Esposito é um palestrante sempre presente em eventos do setor no mundo inteiro. Siga-lhe Twitter no twitter.com/despos.

Graças ao seguir técnico especialista para revisar este artigo: Mircea Trofin