Como convencer minha equipe a usar classes / métodos menores?

Isenção de responsabilidade: Sou novato (este é o meu terceiro dia de trabalho) e a maioria dos meus colegas de equipe é mais experiente do que eu.

Quando olho para o nosso código, vejo alguns odores de código e práticas inadequadas de engenharia, como as seguintes:

• Diretrizes de nomenclatura um tanto inconsistentes
• Propriedades não marcadas como somente leitura quando possível
• Classes grandes - notei uma classe de utilitário que consistia em centenas de métodos de extensão (para muitos tipos). Tinha mais de 2500 linhas de comprimento!
• Métodos grandes - estou tentando refatorar um método com 150 linhas de comprimento.

Os dois últimos parecem ser um problema real. Quero convencer meus colegas de equipe a usar classes e métodos menores. Mas devo fazer isso? Se sim, então como?

Minha equipe conseguiu um mentor da equipe principal (somos uma equipe satélite). Devo ir com ele primeiro?

ATUALIZAÇÃO : Como algumas respostas foram perguntadas sobre o projeto, saiba que é um projeto funcional. E IMHO, grandes classes / métodos desse tamanho são sempre ruins.

De qualquer forma, nunca quero irritar minha equipe. Foi por isso que perguntei - devo fazer isso e, se sim, como faço isso suavemente?

ATUALIZAÇÃO : Decidi fazer algo com base na resposta aceita: porque sou recém-chegado, então vejo tudo em "novos olhos". Anotarei todos os cheiros de código que encontrei (posição, por que está ruim, como podemos fazer isso) melhor, ...), mas no momento, apenas tento reunir aspectos da minha equipe: escreva "código melhor", conheça pessoas, saiba por que fizemos isso ... Quando for a hora certa, tentarei para perguntar à minha equipe sobre algumas novas políticas de código (diretrizes de nomenclatura, classes menores, métodos menores, ...) e, se possível, refatorar algum código antigo. Deve funcionar, IMHO.

Obrigado.

Você tem o benefício de visualizar o código com novos olhos. Faça anotações para documentar o que você descobre sobre más práticas. Então, ao se estabelecer com a equipe, retire suas anotações em um momento oportuno, como na hora da refatoração.

O Code Complete, de Steve McConnell, tem várias boas estatísticas sobre o mesmo assunto de que você está falando. Não me lembro de todos os números, mas ele fala sobre como o número de bugs aumenta com métodos / classes mais longos, quanto tempo leva para depurar etc.

Você pode comprar uma cópia do livro e mostrar a seus colegas alguns dos estudos ... as estatísticas (embora elas permaneçam o tempo todo) tendem a convencer as pessoas.

Isenção de responsabilidade: sou um novato (este é o meu terceiro dia de trabalho) e a maioria da minha equipe é mais experiente do que eu.

Você pode desacelerar um pouco, ouvir e aprender com sua equipe antes de sugerir muitas mudanças. Pode ou não haver boas razões para o código estar estruturado, mas, de qualquer forma, dedicar um tempo para ouvir e aprender primeiro pode ajudar.

Depois disso, todas as sugestões que você fizer serão certamente vistas mais positivamente e serão recebidas com menos resistência.

Suas chances de introduzir mudanças com sucesso aumentam muito se você ganhar o respeito, ou pelo menos não perder o respeito, de seus colegas de trabalho primeiro.

Como está indo? "Meça duas vezes cortar uma vez .." Algo assim.

A menos que você tenha sido contratado com a intenção específica de revisar a maneira como sua equipe escreve o código, você pode querer moderar seu entusiasmo por revisões drásticas. A maioria dos códigos funcionais funciona por uma razão :) não importa o quão ruim seja, e às vezes revisões drásticas tornam esses casos irritantes de canto ainda mais feios.

Eu acho que a alavanca mais fácil para escrever código menor seria pedir aos desenvolvedores que se concentrassem no teste de unidade . Nada força o código conciso como ser solicitado a testá- lo; é incrível como os desenvolvedores repentinamente têm aversão às estruturas globais de dados, passando objetos demais em camadas demais, quando sabem que precisam escrever testes para tudo isso.

Eu não sou um grande fã de TDD, mas eu não amo o fato de que ele força os desenvolvedores a considerar como eles escrevem testes. E que muitas vezes é porque o código é melhor, não alguma mágica sobre realmente ter os testes. (Embora isso certamente seja útil quando você fizer alterações posteriormente.)

Boa sorte.

Você não deve convencer sua equipe. Como recém-chegado, você não será levado a sério - portanto, desperdiçando tempo.

Em vez disso, escreva um código compacto e limpo. Esperamos que, depois de um tempo e algumas revisões de código, alguns colegas de equipe possam começar a imitar seu estilo.

Caso contrário, você ainda será mais produtivo e seu trabalho duro levará você a uma posição mais alta, onde poderá começar a aplicar algumas dessas regras.

E sim, por todos os meios, mostre coisas do Code Complete para todos.

Aqui estão alguns truques:

• Aprenda o estado e a história atual da equipe - parece que eles têm um mentor, quanta influência ele tem? Além disso, quão novo é o mentor e houve muito tempo sem mentor? Quando o código do problema se origina? Criticar o bebê da equipe atual pode ser muito diferente de criticar algum código antigo que ninguém se lembra de ter escrito.

• Uma coisa de cada vez - não jogue a bomba em seus pensamentos em uma reunião de equipe. Comece com algumas perguntas preliminares que vêm de sua perspectiva específica. Por exemplo - "Ei, como o novato, notei que algumas das classes de utilidade são realmente grandes, existe uma razão para isso?"

• Sugira etapas do bebê - quase nunca é possível fazer uma revisão total imediata, então descubra algumas etapas iniciais a serem sugeridas caso todos concordem que este é um bom plano.

• Sugira futuros mecanismos de prevenção - por exemplo, a equipe pode concordar com uma meta que nunca será adicionada às poucas maiores classes, mas será refatorada quando houver necessidade de aumentá-las ainda mais.

• Ouça as preocupações sobre riscos. Se esse é realmente um código legado, pode haver incógnitas e dependências suficientes para que a refatoração seja extremamente arriscada. Isso pode não ser um motivo para evitar a refatoração, mas pode significar que você precisa de melhores estratégias de teste ou de outra maneira de reduzir o risco antes de enfrentar o verdadeiro retrabalho.

• Esteja ciente da linguagem corporal e vá devagar. Você está apresentando um problema em uma base de código com a qual não tem muita experiência. Você tem uma nova janela de cara agora, onde pode fazer algumas perguntas ingênuas e obter respostas úteis, e pode usá-las para investigar a equipe e considerar suas próprias opções de design. Mas é nos dois sentidos - como o novato, você também não tem uma tonelada de "cred" ainda, então vá devagar e fique atento a rostos ou posturas fechados. Se as pessoas começarem a desligar, sugira uma maneira de adiar as decisões e procurar maneiras de conquistá-las.

Posso dizer que, como gerente e membro da equipe, fiquei feliz pelo New Guy Insights. Não aceitei todos os comentários construtivos que um novo membro da equipe me deu, mas geralmente estava disposto a ouvir se as críticas eram expressas como preocupação e curiosidade honestas, e não apresentadas como palestra. A marca do respeito ao novo cara vai quando ele pode oferecer a percepção e, em seguida, recuar e lidar com o que vier - é fácil se sentir bem quando suas decisões são ouvidas e adotadas, é mais difícil quando a equipe diz "não". Você ainda pode estar certo, o truque é descobrir o que fazer a seguir ... geralmente esperar um pouco e procurar mais informações é um bom próximo passo nesses casos.

Como convencer minha equipe a usar classes / métodos menores?

Não.

Compre uma licença de Resharper e lidere pelo exemplo. [Apoie-se bastante na refatoração de ' Método de extração '.]

Com o tempo, outras pessoas devem apreciar seu código mais legível e ser persuadidas a fazer o mesmo. *

• Sim - há uma chance de que eles não sejam persuadidos; mas ainda é sua melhor aposta.

IMO - Não vale a pena sílabas para tentar convencer seus colegas de equipe a se tornarem melhores programadores, leia ' Code Complete ', siga @Uncle Bob. princípios SOLID e torne-se um programador melhor se ainda não estiver convencido.

Lembre-se: você não pode usar a lógica para argumentar que alguém saiu de uma posição em que não usou a lógica para entrar em primeiro lugar.

Isso parece ser mais uma questão de gerenciamento do que técnica. Tudo o que você disse é válido, o que sua equipe realmente precisa é de um bom arquiteto, que possa garantir que todos se adaptem a um único padrão de design e imponha-o, a equipe precisa estar constantemente e regularmente refatorando o código.

No entanto, há outro princípio de que "você não vai precisar disso", se o que já existe funcionar por um tempo bastante longo, por mais feio que seja, mudá-lo nem sempre é uma boa idéia. Em vez disso, se sua equipe precisar reconstruir tudo ou reconstruir parte dela, acumule um documento de más práticas e problemas antes de executar a codificação.

Algumas equipes não fazem nenhum tipo de controle de qualidade para o código porque não conhecem as ferramentas certas para isso. Existem muitas ferramentas que podem ajudar uma equipe a codificar melhor.

O Visual Studio possui "Análise de código" que pode ajudar nas convenções de nomenclatura.

Métricas de código também podem ser usadas, como complexidade ciclomática. Isso ajuda a apontar classes e métodos que são muito complexos.

Manter registros também é uma boa ideia. Se os membros da equipe apenas expressam verbalmente o que precisa ser feito, as pessoas tendem a esquecer. Os seres humanos têm memórias muito frágeis! =)

Eu não faria muito barulho sobre isso ... A equipe de desenvolvimento de um programador é como sua própria família ... Se você apontar erros, as pessoas podem ficar com raiva de você. Esse tipo de mudança de cultura não requer apenas muita codificação, mas também exige um toque delicado com os seres humanos.

Como gerente, só quero acrescentar que quero que minha equipe escreva um bom código na primeira vez. Revisões de código, TDD e tudo isso. Mas, uma vez que esteja em produção e funcione, você teria que fazer um argumento forte para que voltássemos a ele.

Sigo os conselhos do tio Bob para sempre deixar o código melhor do que você o encontrou. Portanto, se tivermos bugs para corrigir ou pequenos aprimoramentos, espero que esteja fazendo alguma limpeza nesse momento.

Mas como está, o negócio realmente assiste seu dinheiro. Eu teria que argumentar com eles que a refatoração os beneficia o suficiente para que eles dessem tempo e recursos à minha equipe. Apenas não gostar da aparência do código não é suficiente.

Portanto, se funcionar, por mais que você odeie, pode ser necessário deixá-lo em paz.

Agora novo código, isso é diferente. Esse deve ser um bom código.

Métodos com 150 linhas ... Eu já vi métodos com 10.000 linhas de código.

Dois de seus problemas podem ser resolvidos com ferramentas externas :

• Diretrizes de nomenclatura um tanto inconsistentes
• Propriedades não são marcadas como somente leitura quando possível

No C #, o Resharper pode verificar os dois problemas. Os nomes que não seguem suas diretrizes são marcados como erros. As propriedades não marcadas como somente leitura também são exibidas como erros. O FxCop também pode ser uma ajuda.

Essas ferramentas também podem ajudar a dividir métodos enormes em vários métodos menores, graças à sua refatoração.

Eu não sei que grandes classes sempre são tão ruins se elas são bem estruturadas com métodos bem nomeados. Eu uso o Eclipse como meu IDE, para que ele tenha algo chamado de visualização "estrutura de tópicos", que é algo que todos os IDE têm apenas com um nome diferente, provavelmente, que fornece o nome e o link para cada método dentro da classe, você pode classificá-lo em ordem alfabética etc. Ao usar isso, é fácil navegar em uma classe grande, é mais difícil ter métodos realmente longos, acho que é mais difícil navegar de maneira inteligente nesse método, a menos que você esteja familiarizado com ele. Não estou advogando aulas longas, mas acho que elas são gerenciáveis ​​em alguns casos e não necessariamente precisam ser divididas em várias classes.

Traga o assunto com alguns dos membros da sua equipe e obtenha sua opinião sobre o tamanho dos métodos. Você pode se surpreender ao descobrir que eles concordam com você. O que você está vendo pode ser o resultado de práticas anteriores ruins, ex-desenvolvedores não estão mais na empresa ou essa parte era um trabalho urgente e agora eles contrataram alguém com tempo para refatorá-lo;)

Você ainda é o novo cara. Crie alguma reputação assumindo tarefas desafiadoras e concluindo-as rapidamente e sem erros. Se você tentar começar a mudar as coisas antes de ganhar o respeito de seus colegas, poderá ter muito mais dificuldade em comprar (e possivelmente alienar seus colegas de trabalho).

Se você puder encontrar maneiras de introduzir os melhores hábitos de codificação em seu próprio trabalho, demonstrando efetivamente como eles reduzem o tempo de desenvolvimento e resultam em soluções mais robustas, você pode até pedir para eles descobrirem como conseguiu isso.

Além de todas as outras ótimas respostas, talvez você possa matar dois coelhos com uma cajadada e fazer uma limpeza de código como um projeto destinado a entender melhor a base de código. Você pode vendê-lo para sua equipe / gerente como uma oportunidade de aprendizado para você e você receberá feedback de seus colegas quando eles analisarem suas alterações, o que o guiará em sua melhor abordagem para lidar com a questão do design deficiente.