Este artigo foi traduzido por máquina.

Nota do editor

Seguindo um princípio

Michael Desmond

É uma coisa de escrever código. É completamente outra para escrever código que não se tornará difícil e caro para gerenciar alguns anos abaixo da estrada.

Jason Bock sabe a diferença. Como uma prática levar para app dev em roupa de desenvolvimento de software Magenic, e co-autor do livro "Metaprogramação em .NET" (Manning Publications, 2013), Bock tem visto mais que sua parte de projetos de software promissor correu mal devido a práticas de pobres. Ele diz que não precisa ser assim.

No próximo Visual Studio Live! Conferência (vslive.com), Nov. 18-22, em Orlando, Flórida, Bock apresentará a sessão, ".NET desenvolvimento práticas e princípios modernos," que visa obter os desenvolvedores até a velocidade sobre conceitos-chave como rigidez, testes de unidade e princípios sólidos. Interface sólido significa substituição de Liskov aberto-fechado, única responsabilidade, segregação e inversão de dependência. Ele descreve cinco princípios fundamentais da programação orientada a objeto projetado para maximizar a capacidade de manutenção e extensibilidade do código.

"Uma quantidade razoável de sistemas são produzidos muito rapidamente, e o custo a longo prazo é uma base de código que pode ser muito difícil de manter," diz Bock. "Às vezes os desenvolvedores desviar os conceitos de injeção de dependência e zombando porque não compreendiam-los."

Na verdade, cerca de metade as urnas de Bock desenvolvedores falharem a empregar os conceitos fundamentais e os princípios que ele descreve em sua apresentação. A coisa é que, até há seis anos, Bock se estava dentre os desenvolvedores.

"Levei um tempo para realmente mergulhar e saber como funcionam esses conceitos, mas uma vez eu fiz, coisas clicadas muito rapidamente, e agora é apenas um hábito de incorporar essas idéias para os projetos estou," diz Bock. "Se pode motivar os participantes a dar os primeiros passos, então consegui o que já propusemos a fazer."

Adicionar testes de unidade para uma base de código dá trabalho, diz Bock, mas existem desenvolvedores de coisas podem fazer para facilitar a transição. Ele diz codificadores para começar pequeno e testes de unidade alvo em áreas-chave, tais como o código que é frequentemente acessado por outras partes do sistema. Ele também convida desenvolvedores para adicionar testes unitários para o novo código. Isto pode ser difícil de fazer quando o próprio sistema não é voltado para testes de unidade a ter lugar, diz Bock, "mas pelo menos é um começo."

Bock adverte que "não há mágica resposta aqui." Sistemas que não possuem camadas distintas e testes automatizados são susceptíveis de ser algo de uma confusão. Testes de unidade em projetos como este quase certamente vai ser difícil. Em última análise, ele diz, o sucesso é sobre o compromisso.

"Você tem que fazê-lo desde o início, e você tem que se comprometer a escrever os testes," ele diz. "Os dois últimos projetos em que eu estive tem tido milhares de testes de unidade. Isso significa que eles eram perfeitos? N. º Mas eu tinha muito mais garantia de que, quando eu mudei alguma coisa no código eu saberia se quebrei alguma coisa ou não. - E todos eles com um simples pressionamento de tecla (CTRL + R, A Visual Studio 2012). Isso compensa a longo prazo. Mesmo se um desenvolvedor está sob pressão para produzir código rapidamente, também devem-se ter um conjunto de testes no local, então, no futuro, não acabam em um lugar de desespero."

Michael Desmond é o editor-chefe da MSDN Magazine.