Quais problemas o PostSharp resolve
As linguagens de programação convencionais perdem o conceito de padrão; portanto, os padrões são codificados manualmente e resultam em código padrão.
Alto esforço de desenvolvimento
Grandes bases de código. Alguns recursos do aplicativo exigem uma grande quantidade de código repetitivo (boilerplate) quando implementados com tecnologias de compilador convencionais existentes.
Reinventando a roda. Soluções para problemas como INotifyPropertyChanged estão sempre sendo reinventadas porque não existem opções reutilizáveis ​​nas linguagens de programação convencionais.
Software de baixa qualidade
Alto número de defeitos. Cada linha de código tem a possibilidade de defeito, mas o código resultante da programação copiar e colar tem maior probabilidade de apresentar erros porque diferenças sutis são frequentemente ignoradas.
Problemas de multithread. A programação orientada a objetos não agrega muito valor quando se trata de desenvolvimento de aplicações multithread, uma vez que aborda problemas em um baixo nível de abstração com bloqueios, eventos ou acessos interligados que podem facilmente resultar em deadlocks ou corridas aleatórias de dados.
Falta de robustez. Recursos de nível empresarial, como tratamento de exceções ou cache, são muitas vezes omitidos deliberadamente devido à grande quantidade de código-fonte que eles implicam, proibidos involuntariamente em algumas partes dos aplicativos, simplesmente deixados sem teste e não confiáveis.
Dificuldade para adicionar/modificar funcionalidades após a versão 1.0
Código ilegível e difícil de manter. O código comercial geralmente está repleto de requisitos não funcionais de baixo nível e é mais difícil de entender e manter, especialmente quando o desenvolvedor inicial sai.
Acoplamento forte. A má decomposição do problema resulta em código duplicado e forte acoplamento, tornando muito difícil alterar a implementação de recursos como registro, tratamento de exceções ou INotifyPropertyChanged porque geralmente está espalhado entre milhares de arquivos.
Aumento lento de novos membros da equipe
É necessário muito conhecimento. Quando novos membros da equipe começam a trabalhar em um recurso específico, muitas vezes eles precisam primeiro aprender sobre cache, threading e outras questões altamente técnicas antes de poderem contribuir para o valor do negócio: um exemplo de má divisão de trabalho.
Longos ciclos de feedback. Mesmo com equipes de desenvolvimento pequenas, padrões comuns como diagnóstico, registro em log, threading, INotifyPropertyChanged e desfazer/refazer podem ser tratados de maneira diferente por cada desenvolvedor. Os arquitetos precisam garantir que os novos membros da equipe entendam e sigam os padrões internos de design e gastem mais tempo em revisões manuais de código – atrasando o progresso enquanto os novos membros da equipe esperam para obter feedback da revisão do código.