Este artigo foi traduzido por máquina.
Limpeza de código
9 táticas úteis para pagar as dívidas técnicas
David Laribee
Na edição de dezembro de 2009 da MSDN Magazine I deu conselhos para a identificação e um case para lidar com dívidas técnicas. Em resumo, acho que é importante identificar o débito que pode prejudicar você em breve. Introdução técnica excelência raramente tocadas partes da sua base de código não ajudará perceber os ganhos de produtividade no futuro.
Além disso, espero que você compreender a importância de se obter licença e compra-in do gerenciamento sobre a importância de volta pagar dívidas e tem algumas ferramentas básicas para começar a criar um caso sólida para o mesmo.
Agora let’s voltar nossa atenção para táticas que possam ajudar volta pagar dívidas técnico alto interesse. Há muitas táticas comprovadas em lidar com técnica dívida. Um catálogo completo de padrões, ferramentas e técnicas para código difícil wrangling está muito além do escopo deste artigo. Em vez disso, eu irá fornecer alguns dos truques mais aplicáveis que adicionei à minha repertório ao longo dos anos.
Saiba, aprender, aprendizado
Se você souber que você tiver problemas, mas você não estiver certo de como corrigi-los, talvez seja hora de adquirir novos conhecimentos e habilidades que o ajudará a aumentar seu código fora da muck. Aprendizagem, como dizem, é fundamental.
Aprendizado pode assumir várias formas. Você pode precisar de ajuda externa na forma de consultores ou treinamento em sala de aula. Talvez você possa obter, com livros.
Tente envolver a equipe no processo de aprendizagem. Talvez você poderia iniciar um clube do livro dentro de sua equipe. Talvez você pode trazer novamente os benefícios de um curso ou conferência na forma de uma apresentação instrutivo.
Uma técnica de colaboração e prática para que envolve toda a equipe é dojo codificação. Um dojo codificação básica envolve um desafio de programação de separação e que lidar com como um grupo. Eu já experimented com um par de rotação observado por uma galeria Delícia. Nesse método, dois membros da equipe trabalham juntos em uma tarefa de programação, com intervalos de “ marca ”, onde outros membros da equipe de inserir o dojo enquanto outra pessoa sai dele.
Se você aprendem melhor no seu próprio ritmo, ou se quiser iniciar um clube do livro, existem alguns bons textos que recomendo sobre o assunto de melhorar a capacidade de manutenção de código herdado.
Volume apropriadamente entitulado ’ Michael difusões, Trabalhando com eficiência com o código herdado (Prentice Hall 2004), fornece uma abordagem baseada em padrões para implicando código herdado. O autor fizer a instrução que o código herdado é código não testado. É difícil alterar e você não terá certeza de que suas alterações não estão apresentando defeitos de regressão. Este livro você encontrará inúmeros concentradas estratégias e táticas para reduzir o acoplamento em seu código e tornando mais testável.
Kyle Baley e Donald Belcham têm um dos livros mais recentes na cena, Brownfield Application Development in.NE T (Manning Publications, 2010). Eles utilizam uma abordagem sistemático Melhoramento brownfield chamado (em vez de desenvolvimento de novos. ou greenfield) bases de código. Uma vantagem deste livro é que, embora as abordagens que recomendam que eles se aplicam amplamente, seus exemplos de código foram projetados em torno do Microsoft .NET Framework, um provável benefício para os leitores deste artigo. Eu gosto bastante como eles utilizam uma abordagem de práticas de equipe também. Ou seja, enquanto você estiver fazendo alterações em uma base de código selvagem, a confiança que você obterá com a implementação de algumas noções básicas, como a integração contínua e controle de versão vale seu peso em ouro.
Diplomacia
Há uma probabilidade alta o código confuso com que precisam lidar foi escrito por alguém no momento da sua equipe. É importante que você levar isso em conta ao raciocínio sobre o código em seu estado atual. Gerar sentimentos hurt defensiveness que, por sua vez, leva para diminuir o treinamento do aperfeiçoamento em andamento.
Tente difusão a situação com relatos de erros que fez no passado. Permanecer profissional, evitar ataques pessoais e incentivar o autor do código original para fazer sugestões sobre como você pode para melhorá-lo.
Em seguida, novamente, é bem possível estiver dentre os desenvolvedores que contribuíram com a bagunça. Quero que você repita depois me: “ Não tenho meu código. Eu estou aprender todos os dias e estou dedicado a encontrar uma maneira melhor no futuro. Eu não permitirá que críticas meus colegas ’ ou minha própria ego suporte de esforço do minha equipe para melhorar. ”
Na verdade, leva tempo para obter sobre esses problemas. Encontrar a melhor maneira de razão e falar sobre aperfeiçoamentos é enfocar o presente e quase futuras em vez de passado. O que esse código poderia ser? O que você deseja vê-lo a evoluir em?
Um pouco de diplomacia e consideração para investimento emocional de outras pessoas no trabalho já foi comprometida será ir um longo longo caminho para o futuro.
Introduzir uma forma
Alguns códigos é tão horrendous que é difícil compreender o que está acontecendo em todas as. Talvez todas as classes estão em um único espaço para nome. Talvez a base de código é em tal uma tangled web das dependências que seguindo a pilha muito excede a capacidade da memória do curto prazo para manter o local.
Sintomas como essas geralmente implicam um diagnóstico de dívidas na arquitetura e design níveis em vez de em um nível de implementação. Isso, contanto que estou preocupado, é o tipo mais traiçoeiro de dívidas e geralmente leva os custos maiores de alteração.
Brian Foote e Joseph Yoder chamada arquiteturas com nenhuma forma perceptível, onde tudo depende em todo o resto, “ grande bola de lama ” (de laputan.org/mud ):
“ É um indicador grande de lama ao acaso, até mesmo aleatoriamente, estruturados de sistema. Sua organização, se um pode chamá-lo, é ditada mais pelo expediency de design. Ainda assim, sua popularidade enduring não pode simplesmente ser indicar que um ignorar geral para a arquitetura. ”
Seria aposto que minha última dólar que a maioria dos aplicativos de software em produção hoje sejam grandes bolas de lama. Isso não é necessariamente um julgamento de valor. Há bilhões de linhas de código terrível por aí no mundo tornando as pessoas muitas e muito dinheiro. Ele significa motivo que grande bolas de lama estão atendendo a sonhos champanhe e caviar desejos de muitas um proprietário de negócios e acionistas.
O problema é que aplicativos bola de lama se tornam cada vez mais caro de alterar. Enquanto o ambiente de negócios permanece dinâmico, o software torna-se inflexíveis. A estratégia típica para lidar com isso é o software equivalente a uma bomba nuclear: reconfiguração grande. Existem muitos riscos associados à regravações grandes e muitas vezes é melhor aprimorar o design do sistema específicos.
Antes de começar a utilizar algumas das técnicas de nível inferior, geralmente é valioso para apresentar uma forma ao seu sistema. O exemplo típico é que uma arquitetura em camadas. Isso significa, de modo clássico fala a UI para serviços e serviços falar com algum tipo de modelo e comunica-se o modelo, por sua vez, com a camada de persistência.
Modelagem de seu código em camadas pode ser uma atividade de baixa fidelidade. Iniciar a organização de código em namespaces nomeado de acordo com as camadas da arquitetura.
Agora você tem seus pedidos marching: imponha a regra que camadas de nível mais alto (camada de interface do usuário) só podem depender o próximo nível acima (camada de serviços). Como forma simples de aplicar a regra é mover as camadas para projetos separados no Visual Studio. A solução não compilar se você violar a regra.
Tornando a passagem de regra, diminuíram acoplamento. O modelo não está acoplado aos modos de exibição do seu aplicativo. Com a introdução de uma forma aumentaram coesão. Classes dentro de sua camada todos trabalham para a mesma finalidade sejam para exibir dados para um usuário final ou para encapsular o comportamento de negócios.
Apresente fachadas entre camadas e fazer as camadas de nível superiores, como a interface do usuário dependem fachadas fornecidas por camadas de nível inferiores, em vez de classes granulares dentro das camadas. Você pode aplicar essa técnica esse processo incremental e oportunamente.
A potência de uma imposição de uma forma em que a bola grande monolítica de lama está que agora você pode começar a identificar mais oportunidades-alvo para volta pagar dívidas técnica. Ou seja, se você estiver fazendo muito trabalho, digamos, CompanyX.ProductY.Model, você pode aprofundar com uma ferramenta de análise estática para localizar o máximo combinado ou complicado classes.
Fechar suporte ar com testes
O processo de fazer alterações sem alterar o comportamento do sistema é chamado de refatoração. Há todo refatoração linguagens de padrões dedicadas para ambos e orientada a objeto (de refactoring.com ) e código relacionais de banco de dados (de agiledata.org/essays/databaseRefactoringCatalog.html ): Extrair método, dividir a tabela e assim por diante. O fato da questão é que é difícil aplicar esses métodos granulares e seguros quando você Don compreende totalmente a base de código.
Então, como você começa fazer alterações em um projeto legado? A primeira coisa a observar é que, dada uma opção, é sempre mais seguro para que os testes de alterações que você fizer. Quando você altera o código, você pode introduzir erros. Mas quando você abordar seu código com testes antes de alterar o código, você estará mais chances de capturar erros.
A prática de cirurgia shotgun, plunging headlong em código sem qualquer confiança real que as alterações que você está apresentando também não apresentar defeitos perigosos, não é a única maneira de forçar uma alteração.
Antes de começar a alterar código, determine se há uma interface de disco rígida do sistema no qual você pode escrever testes. Esses testes são da variedade caixa-preta. Ou seja, você está alimentando um sistema de entradas e inspecionando as saídas. Quando você faz a alteração, execute continuamente os testes para verificar que as alterações ainda não tiver quebrado comportamento existente.
Aplicação dessa tática pode ser desafiador quando estiver responder partes de seu sistema rigidamente acoplados. O custo de teste muito bem pode exceder o benefício de remoção de débito. Essa análise de custo-benefício constante permeates o processo de transformar uma base de código ao redor e, às vezes, é mais econômico para cima de reconfiguração de um aplicativo ou uma seção grande base de código do aplicativo.
Efeitos de ObservableCollection medida
Crie medidas ao redor da área de código que você está melhorando. Para fins de argumento, let’s dizer que você está tentando organizar melhor a lógica de negócios principais de seu aplicativo. Há vários caminhos através de membros em tipos deste espaço para nome: Alternar instruções, aninhadas se instruções e assim por diante. Uma medida, como complexidade cyclomatic pode lhe dar uma idéia aproximada de se esforços de aprimoramento estão simplificando o seu código.
Você pode obter medidas extremamente específicas de partes específicas de sua base de código com a ferramenta de análise de código NDepend (de ndepend.com ). NDepend oferece uma poderosa código Query Language (CQL) sobre namespaces, tipos e membros nos seus assemblies .NET.
Considere as declarações de CQL Figura 1. Observe que eu estou investigando medidas como acoplamento e a complexidade (apenas algumas das muitas métricas NDepend torna disponível) dentro de um namespace específico. Isso implica que eu já introduziu uma forma para que eu possa se concentrar esforços em áreas definíveis do meu código. Se estou bem-sucedido ao introduzir alterações positivas, eu verá medidas como acoplamento e diminuir a complexidade ao longo do tempo.
Figura 1 NDepend CQL
-- Efferent coupling outside a namespace
SELECT TYPES
WHERE TypeCe > 0
AND (FullNameLike "MyCompany.MyProduct.Web")
-- Afferent coupling inside a namespace
SELECT TYPES
WHERE TypeCa > 0
AND (FullNameLike "MyCompany.MyProduct.Web")
-- Top 20 most complicated methods
SELECT TOP 20 METHODS
WHERE CyclomaticComplexity > 4
AND FullNameLike "MyCompany.MyProduct.Web"
Um bom efeito colateral essa tática é que as medidas podem ajudar você mantenha a linha e manter disciplina depois dívida foi removida.Elas lhe dará um sistema de aviso antecipado em direção a reintroduction de débito novo em uma área já aprimorada.
Fluxo de aprimoramento dedicado
Don em tempo real no vácuo.As chances são, durante seus esforços de aprimoramento, você será solicitado para continuar a fornecer novos recursos e modificações em recursos existentes.Pressão da entrega faz com que sentimentos de ser sob pressão.Mas a manutenção é um fato da vida que devem adotar em vez de tentar ignorar.
Uma maneira de lidar com isso é proteger a aprovação da empresa para dedicar recursos — uma pessoa, um par ou toda a equipe — para melhorar o débito itens simultaneamente com o fornecimento de novos recursos.
Isso pode ser uma estratégia altamente eficiente, mas é melhor quando toda a equipe (todos os desenvolvedores e testadores que fazer modificações a base de código) tem uma participação em aprimoramentos feitos.Tente girando regularmente indivíduos como pares.O desenvolvedor que tenha sido no fluxo de melhoria mais longa gira, deixando o outro desenvolvedor breve novo par no que está acontecendo.
Distribuindo o conhecimento você obtém mais perto de propriedade coletiva, reduzindo o risco e aprimorando designs.Às vezes, você encontrará oportunidades de aperfeiçoamento que se encontram diretamente de alguns novos recursos que você está tentando entregar.Sempre que iniciar o trabalho em um recurso novo ou modificado, é recomendável para examinar a lista para determinar se a equipe já não tenha identificado uma área de aperfeiçoamento que faz interseção com o trabalho que você está prestes a fazer.
Oportunidades de aperfeiçoamento ocorrerem o tempo, geralmente identificado-o sistema em funcionamento e alcançado com algumas refatorações simples que fazem uma diferença na próxima vez que um funcionário encontra o código.
Há uma constante análise de custo-benefício entre no quando está melhorando a base ao mesmo tempo, oferece novos recursos de código existente.Se a melhoria parecer muito cara, adicione-volta à sua lista e discuta-lo em seu planejamento de melhoria.
Fazer uma iteração, Avançar, Avançar
Se já back payed alguns dívida.Tempo para retornar à etapa um e identificar, priorizar e consenso o próximo item que precisa corrigir, certo?
Sim, mas há é um pouco mais a ele que mindlessly plowing pela sua lista.Você precisa não se esqueça de que você não estiver incorrer em dívida mais que a correção.Você deve incorporar também regularmente seu learnings em futuros esforços no desenvolvimento de novos e esforços de aprimoramento semelhantes.
Oportunidades de melhorar uma base de código alterar regularmente.Eles surgem e sua importância ebbs e fluxos.Motivos para a natureza dinâmica de dívida alto interesse alterar versão de lançamento.
O que é funcionou bem para mim está agendando um curto período semanal de reunião com desenvolvedores analisar novos itens de débito e priorizar a lista de pendências de itens existentes de débito.Isso mantém o consenso criados funcionamento e a lista nova.Novamente, eu poderia dar prioridade a corrigindo o débito que pode retardar a sua versão atual ou projeto.
Iniciar a reunião ao analisar novos itens.Ter o identificador com densidade de sua ocorrência e colocá-lo para votar: Ele mereçam inclusão na lista de pendências ou não?Depois que você tenha passado pelo novos itens, reveja os itens antigos.Há trabalho que não se aplica mais?Haverá valor imediato quando esse trabalho, ou seja, removerá impedimentos diários?Por último, priorizar a oportunidade de outras pessoas — fileira re sua lista.O item superior da lista deve ser a melhoria muito próxima para fazer.
Mantenha a linha
Enquanto você e sua equipe estão pagando merrily pressionada dívida técnica alto interesse, você irá provavelmente também ser fornecendo novos softwares.À medida que você conheça as técnicas de programação sólidas e introduzir novos padrões no seu código, aplica esse conhecimento no futuro.É possível que trabalho aditiva serão empilhadas em dívida técnica existente criando uma inércia inevitável.
É importante que você defina as expectativas de stakeholder seu negócios para o novo trabalho.Maior qualidade leva mais tempo para alcançar de instrutores get it-feito-código de estilo.Esse fato me leva de volta para o conceito de pensamento sistemas introduzido novamente em meu artigo de dezembro de 2009.Para mim, isso é um atributo cultural.Ou seja, as organizações podem sustainably pense a longo prazo ou continuar uma compra agora, pagar mentalidade posterior — o AH tão fertile Terra breeding do débito técnico.Jamais se esqueça de pergunta central, como podemos acabar aqui em primeiro lugar?
Enquanto está aprendendo como aprimorar uma base de código, muito provavelmente você desenvolverá algumas normas de equipe que se aplicam ao novo código.Sugiro que captura em uma ferramenta como um wiki e mantendo pequenos e informais sessões de aprendizagem onde compartilhar suas descobertas com sua equipe.Você também desenvolverá técnicas para lidar com itens de melhoria semelhante.Quando observar você fez a mesma coisa para corrigir um design defeituoso ou limpar a implementação de três ou quatro vezes, ele codify em doctrine da sua equipe.Isto é, anotá-la em um local conhecido e, muito simplesmente, dizer às pessoas é lá.
Trabalhar em conjunto
Dívida técnica é um problema de pessoas.Pessoas por meio de falta de conhecimento ou irreal expectativas, criado a bagunça e agora estão lidando com as conseqüências.E vai levar pessoas trabalhando como um grupo para corrigi-lo.
Dar conselhos assim é tudo bem, e eu ficaria surpreso se você, um software profissional e provavelmente uma que é apaixonado pelo seu trabalho, não em contrato concluído.
Um retorno bem-sucedido requer alterações fundamentais no sistema de valor de todos os envolvidos — toda a equipe.A economia da qualidade comprovadamente volta de pagamento ao final, mas você terá que dão aquele passo fé a curto prazo.Você tem que ganhar os corações e mentes para alterar uma cultura, e que pode ser um trabalho difícil de fato.A sugestão mais úteis que posso fazer é: Don faça isso sozinho.A equipe de esforço de obter e certifique-se de que todos têm uma stake nos resultados.
Definir uma meta como “ queremos 90 % de cobertura ” ou “ queremos fazer desenvolvimento controlado por teste (TDD) sempre ” é relativamente sem sentido.Lidar com as áreas problemáticas que estão diminuindo você no momento e no futuro próximo.Que pode significar apresentando TDD e vivendo pelo relatório de cobertura — ou pode não ocorrer.Ele pode ser algo mais primitivos como certificando-se de que sua equipe conhece as noções básicas de análise orientada a objeto e design.
Iniciar fazer uma diferença
Enquanto espero que eu tenha dado a você algumas ferramentas e técnicas para lidar com dívidas ou, na pior das hipóteses, fazer algumas o implícitas idéias e experiências que você já teve explícita, é importante perceber que lidar com dívidas técnica é muito mais um problema de produto para produto.Você pode, por exemplo, ser em um ambiente onde não há muita confiança entre as partes de desenvolvimento e de negócios e encontrar você precisará com densidade seu caso com a preparação de um advogado avaliação.
Não há um processo de out-of-box verá o como de redução de débito, mas, como para o Quando e o onde , hoje é um dia para começar a fazer uma diferença.Março em direção a excelência técnica pode ser lenta e áspero vai no início.É apenas por meio de esforço contínuo, constante aprendizado e, acima de tudo, uma atitude earnest que você irá puxar por meio de difícil vezes, levar VirtualPC dívida código volta para o preto.Eu recomendo que você fique com o programa.Não apenas irá aumentar o valor dos seus clientes, você será bastante expanda caixa de ferramentas da seu profissional de fabricação.
Dave Laribee coaches a equipe de desenvolvimento a VersionOne Inc. Ele é palestrante assíduo em eventos para desenvolvedores locais e nacionais e recebeu o prêmio umMicrosoft MVP de arquitetura para 2007 e 2008. Ele escreve na rede CodeBetter blog em thebeelog.com.