Métodos de código de depuração (situação do pesadelo)

Sou frequentemente encarregado de depurar um aplicativo no meu trabalho. É um Aplicativo de BI que implantamos nas empresas, que inclui um ambiente de teste e um ambiente de produção. Gostaria de saber se existem aplicativos / ferramentas / métodos que as pessoas possam sugerir, com base nessas restrições:

1. O depurador não pode ser usado no site do cliente ou localmente, porque o software depende de aplicativos de terceiros personalizados para os quais não temos ambientes de teste. (EDIT: para ser justo, é possível depurar localmente em alguns casos. Se não usarmos nada além do código principal. Grande parte do código problemático reside em uma dll que encapsula a comunicação específica de terceiros: soquetes, tubos de processo, chamadas de sabão, lógica personalizada que altera o comportamento do código principal. Normalmente, durante uma implementação ou aprimoramento para um cliente, estaríamos escrevendo um novo código nessa área.)

2. Praticamente não há registro feito em nossos aplicativos. Não há testes de unidade.

3. O controle de versão possui apenas 1 versão da solução completa (usando o source safe 2005). Portanto, não é possível obter uma versão anterior de toda a solução, apenas arquivos individuais. (A menos que alguém saiba maneiras de contornar isso).

4. Não é possível reproduzir localmente, muitas vezes não é possível reproduzir no ambiente de teste (alta chance de teste e produção não serem da mesma versão).

5. Há uma grande chance de que a versão que o cliente esteja usando seja diferente da versão segura no código-fonte. Isso ocorre porque os arquivos individuais são atualizados, que incorporaram lógica personalizada para esse cliente específico. Geralmente, o que acontece é que uma atualização é feita em um binário, o que requer alterações em vários outros binários, mas quando uma confirmação é concluída, ninguém tem nenhum registro ou conhecimento disso. Um erro um tanto comum que vejo é a 'Função / Método não encontrado' ou 'A chamada do método tem muitos / poucos parâmetros especificados' em um ambiente de clientes.

6. Esta é uma solução .net VB

7. Não é possível instalar nenhum software nos sites dos clientes, mas pode localmente

8. Nosso aplicativo é extremamente personalizável, mas, infelizmente, a lógica de personalização está espalhada por todas as classes e arquivos, desde o front-end até a camada de dados, incluindo alterações personalizadas feitas no banco de dados por cliente.

9. Praticamente não há comentários no código. Não há documentação sobre a arquitetura. Nenhuma documentação sobre a API. A única coisa que temos são centenas e centenas de cadeias de email que explicam o que está acontecendo. As únicas pessoas que conhecem o código são as que o escreveram originalmente, mas não são mais os desenvolvedores que dizem isso para não se envolverem tanto.

E antes que você diga ... sim eu sei; Eu quero me matar também. Não ajuda que exista código espaguete, centenas de avisos do compilador e polimorfismo quebrado que REALMENTE devam ser corrigidos, mas não tenho uma opinião a dizer.

Os tipos mais comuns de erros nos quais encontro erros de referência nulos, lançamentos inválidos e falta de correspondência de funções / assinatura de função. Às vezes, tenho sorte e o visualizador de eventos registra a classe, o método e a mensagem de exceção. Não é o mais útil, mas ainda é algo. O pior são os erros sem rastreamento, sem etapas de reprodução além de uma captura de tela e são mensagens de erro genéricas como as mencionadas acima. Às vezes, não é possível descobrir por que elas ocorreram, apenas para orar para que o ambiente não esteja configurado corretamente e que desapareça mais tarde.

Eu sei que isso parece um tanto divertido, e até certo ponto é. Mas estou desesperada por opções. Existem outros métodos / ferramentas que posso usar?

O conselho de Robert Harvey provavelmente é o melhor, mas como o conselho de carreira está fora de tópico, darei qual resposta pode ser dada:

Você está no fundo de uma montanha muito íngreme, coberta de arbustos, lama e cabras da montanha irritáveis. Não há caminho fácil. Se você quer chegar ao topo, precisa forçar um passo tremendamente doloroso de cada vez.

Parece que você sabe exatamente como as coisas devem funcionar. Se ninguém mais irá ajudá-lo (novamente, ignorando os conselhos de carreira), sua única opção é começar a consertar essas coisas sozinho.

Primeiro, por tudo o que é sagrado, coloque essas coisas em um sistema de controle de versão real . Praticamente qualquer coisa, exceto o Source Safe, que é conhecido como uma pilha fedorenta de lixo. gité gratuito e pode ser configurado facilmente. Você não pode corrigir problemas da falta anterior de controle de versão, mas pelo menos impedir que o problema continue no futuro.

Em seguida, examine o log. Encontre ou, na pior das hipóteses, escreva um sistema de registro e comece a usá-lo. Use um que também possa ser usado nos sites clientes; assim, quando as coisas derem errado, você terá pelo menos alguma coisa.

E comece a escrever testes, pelo menos para as novas alterações que você fizer.

Não há cobertura de açúcar: não há resposta aqui que não envolva muito trabalho, ou trate isso como uma questão de carreira.

1) O depurador não pode ser usado no site do cliente ...

Isso é perfeitamente normal.

... ou localmente

Agora isso é um problema.

2) Não há praticamente nenhum registro realizado em nossos aplicativos.

Log é a depuração da produção.

Não há testes de unidade.

Oh céus. Tudo em comum, no entanto.

3) O controle de versão possui apenas 1 versão da solução completa

Então você não está usando o Controle de versão.

4) Não é possível reproduzir localmente, muitas vezes não é possível reproduzir no ambiente de teste (alta chance de teste e produção não serem da mesma versão).

Portanto, apenas o ambiente do cliente implementado mostra os erros.

Nesse caso, você precisa de registro de diagnósticos embutidos no código do aplicativo que (a) armadilhas e [totalmente] registra erros [fatal] e (b) pode ser "discado-se" on demand para produzir adicionais, contínuos, diagnósticos que são úteis em rastreando o (s) problema (s).

5) Há uma grande chance de que a versão que o cliente esteja usando seja diferente da versão segura no código-fonte.

Novamente, você não está usando o controle de versão para sua vantagem.

8) Nossa aplicação é extremamente personalizável

Isso é bastante típico.

As diferenças específicas do site devem ser gerenciadas através do Controle de Versão "Ramificação".

9) Não há praticamente nenhum comentário no código.

Novamente, isso é muito comum, porque os desenvolvedores escrevem código de "auto-documentação", não é?
Ou, pelo menos, o código que eles entendem no dia em que o escrevem.

Não há documentação sobre a arquitetura.

Oh céus.

Nenhuma documentação sobre a API.

Oh querida, oh querida.

E antes que você diga ... sim eu sei; Eu quero me matar também.

Não; você quer filmar as pessoas que escreveram todas essas coisas, criaram uma bagunça indocumentada e inatingível e depois passaram para pastagens novas, deixando a bagunça incontrolável para trás.

Os tipos mais comuns de erros nos quais encontro erros de referência nulos, lançamentos inválidos e falta de correspondência de funções / assinatura de função.

Referências nulas e lançamentos inválidos são erros em tempo de execução; até certo ponto, você deveria estar esperando por eles e o fato de estarem obtendo-os com frequência sugere uma falta de programação defensiva (ou um excesso de otimismo) pelos autores originais.

Incompatibilidades de assinatura de função devem causar uma compilação quebrada ; aqueles devem causar "construções quebradas" e nunca devem sair da porta!

Comece com o log. Isso terá o maior impacto. Implemente uma estrutura de log na base de código, como Log4Net ou similar. Comece a registrar o que o código faz.

A depuração deve ser possível localmente. Caso contrário, trabalhe na obtenção dos arquivos de símbolo (PDBs) para poder depurar em DLLs de terceiros para obter uma imagem completa dos problemas que estão ocorrendo. Ferramentas como o WINDBG podem apontar quais DLLs são problemáticas se o sistema estiver travando. Pode-se configurar qualquer servidor para fazer um despejo de memória quando houver uma falha. É basicamente um instantâneo do que estava acontecendo quando o problema ocorreu. Pode-se examinar os lixões localmente para encontrar pistas sobre o que estava acontecendo. Se a depuração não for possível, trabalhe para torná-lo possível. Documente as etapas necessárias para depurar. Em algum momento em sistemas complexos, há muita configuração necessária para depurar completamente.

Rastreamento de bugs ... Se você não estiver usando um, comece a usar um. Isso anda de mãos dadas com um sistema de controle de versão adequado. Basicamente, comece a rastrear defeitos e revisões do seu código. Comece a construir um histórico do sistema.

Execute análise de código estático. Invista em uma ferramenta como ReSharper. Ele apontará rapidamente todas as possíveis exceções de referência nula e outras práticas incorretas de codificação. Ele pode ajudar a obter o código em melhor forma com apenas alguns cliques e automatizar itens tediosos, como formatação de código, nomeação de variáveis ​​etc.

Testes de refatoração e unidade. Eu vou assumir que provavelmente a maior parte do código escrito não é muito testável, então eu não me incomodaria em tentar adicionar testes para ele. Qualquer novo código, crie um projeto de testes e comece a escrever testes, unidade e integração. Se os testes de unidade falharem, falha na construção. Então, como você refatorar, deve haver testes. Uma coisa dos testes é que é possível escrever um teste para chamar qualquer método e depurar esse método sem carregar o aplicativo inteiro ou a base de código. Isso é útil para ajudar a solucionar problemas.

Documente qualquer conhecimento tribal, conforme necessário. O código deve ser auto-documentado, para que os comentários sejam escassos, mas muitos sistemas têm maneiras "incomuns" de fazer as coisas, apontam para aquelas em um WIKI de codificação ou outro tipo de repositório informal. Além disso, considere criar padrões e práticas de codificação. Aplique esses padrões por meio de um conjunto de ferramentas como o Resharper. Como a maioria do código provavelmente não segue nenhum padrão e diretrizes, implemente os padrões no novo código que está escrito.

Desde o seu novo, eu trataria isso como um passeio de serviço. 6 meses a 2 anos e, em seguida, escolha permanecer ou seguir em frente. Tenha satisfação em tornar as coisas um pouco melhores do que no dia anterior.

Primeiro, todos os itens acima ... idem.

Algumas heurísticas:

• Use o controle de origem no seu computador de desenvolvimento. É a melhor coisa que eu fiz. Não é um substituto para o controle de versão do projeto, que temos. É uma ferramenta que oferece incrível liberdade para experimentar, hackear, resolver problemas sem medo, simultaneamente, mas de forma independente, etc.
  • Qual é a diferença entre Git e Mecurial?
  • Git é Mcgyver, Mecurial é James Bond
• Na medida em que você adicionar comentários, priorize os elementos da interface pública, para aproveitar o intellisense. Faça isso ao decifrar durante suas aventuras de depuração.
• Seja persistente com pequenas refatorações. Mais cedo ou mais tarde, para um determinado pedaço de código, você chegará a uma massa crítica que permite grandes refatorações como DRYing código redundante entre classes.
• Não misture a reformatação de código e as alterações reais no mesmo controle de versão confirmadas.
• Princípios do SOLID
  • Nunca ignore a responsabilidade única. Muito bem, este é o caminho para a promessa de orientação a objetos; NA MINHA HUMILDE OPINIÃO.
  • Sempre ignore Aberto / Fechado.
  • Não estamos falando de novo código aqui.
  • Fazer interfaces sem design proposital dificulta a manutenção.
• Reestruturação
  • Existe uma metodologia para isso. Compre o livro.
  • Refatoração: aprimorando o design do código existente
• Alguns arquivos de código precisam de reformatação completa, renomeação de variáveis ​​etc. antes mesmo de tentar a depuração. Não tenha vergonha de usar o menu de refatoração do visual studio sem testes de unidade.
• A única documentação que não pode ser extraviada está nos arquivos de código.
• Quando você obtiver o controle de versão, preveja o planejamento do VC. E documente! E crie uma convenção de nomenclatura para ramos, tags que destacarão as principais versões e marcos do software.
• Use um bom equipamento
  • Obtenha um monitor que gire. Vertical é a maneira de ler código rapidamente.
  • Unidade externa para backups, teclado com o tipo certo de teclas , mouse multifuncional. Pelo menos 1 unidade USB realmente boa. Eu até tenho minha própria cadeira Herman Miller .
  • Obtenha um software de comparação muito bom. Estou feliz com o Beyond Compare .
• Pratique a depuração Ducky de borracha
• Às vezes, a pior coisa que pode acontecer é que eles não o demitam.

Editar

Desenvolvimento de aplicativos Brownfield em .NET

Experimente este livro. Uma capa inicial para cobrir a leitura é provavelmente a melhor. Este livro ajudará você a pensar no panorama geral, nas possibilidades e no desenvolvimento de planos de ataque estratégico e tático.

Saindo

Fique, digamos, 1,5 anos, se puder; tempo suficiente para saber se você está fazendo um progresso experimental. Você saberá se está adquirindo 2 anos de experiência ou 6 meses de experiência 4 vezes.

Sendo "júnior com 1/2 ano de experiência", estou preocupado que um empregador em potencial veja isso como um resgate antecipado, porque você não conseguiu invadir. Uma coisa é dizer que você aprendeu z, y, x, pegou alguns nomes e deu um chute no traseiro - mas não teve permissão para contribuir com suas capacidades; e outro simplesmente arriscando dissimular o trabalho, o código, o gerenciamento etc. a título de explicação.

Eu posso estar fora da base nisso, mas o meu "melhor dos tempos e o pior dos tempos" foi o meu primeiro emprego, que passou a ser um código literalmente impossível de manter. Eu tive um ótimo supervisor (todo o resto era do programa de criação de animais) que me deu espaço para reescrever alguns programas importantes. Essa experiência foi revelação.

end Editar

Eu diria que (5) é o que você precisa corrigir primeiro. Se você não souber qual código está em execução na produção, não há maneira segura de reproduzir e corrigir problemas. Isso faz com que qualquer outra alteração introduzida seja perigosa, pois pode causar problemas que você não pode prever e não pode reproduzir.

Talvez você precise fazer algum trabalho de detetive e talvez fazer engenharia reversa para descobrir quais versões do código e quais bibliotecas estão implantadas. (E você precisa ter um sistema consistente de compilação e implantação para alinhar todo o código implantado com o controle de origem daqui para frente.)

Pode ser necessário criar vários ambientes de teste para replicar as várias implantações. (É claro que a correção mais simples é criar uma nova compilação limpa e implantá-la consistentemente em todos os lugares, mas parece que isso não é possível?)

Somente quando você souber as versões exatas implementadas e os ambientes de teste correspondentes, você deverá começar a tentar corrigir / melhorar o código.

Sua próxima prioridade deve ser consolidar em uma única base de código que pode ser implantada em qualquer lugar. Parece que você tem várias versões de código implantadas devido à personalização? Você deve consolidar em uma única versão e, em seguida, usar opções de configuração para a lógica personalizada.

Depois disso, você pode começar a melhorar cuidadosamente a base de código para facilitar a depuração. A adição de log é provavelmente a melhoria menos arriscada.

Você deseja adicionar testes automatizados, mas é difícil adicionar unittests a um projeto que não foi projetado inicialmente para teste. Em vez disso, recomendo começar com testes automatizados de integração de ponta a ponta. Eles são mais complicados de configurar, mas não exigem que você reestruture a solução, portanto, são menos arriscados.

Ignorando os problemas que você tem em sua equipe, parece que o primeiro a ser solucionado é depurar o código correspondente ao que está em produção. Caso contrário, você pode estar procurando um bug que já foi corrigido no código que você possui no "Controle de origem". Como este é o .NET, você pode facilmente "descompilar" os binários de produção para comparar o código com o que você possui. Não é uma tarefa fácil, mas se você tiver sucesso, esse é um argumento forte para uma melhor ferramenta de controle de origem que pode marcar as versões lançadas.