Como você diz a alguém que está escrevendo um código incorreto? [fechadas]

Eu tenho trabalhado com um pequeno grupo de pessoas em um projeto de codificação por diversão. É um grupo organizado e bastante coeso. As pessoas com quem trabalho têm vários conjuntos de habilidades relacionadas à programação, mas alguns deles usam métodos errados antigos ou totalmente errados, como variáveis ​​globais excessivas, más convenções de nomenclatura e outras coisas. Enquanto as coisas funcionam, a implementação é ruim. Qual é uma boa maneira de pedir ou apresentá-los educadamente para usar uma metodologia melhor, sem que ela pareça questionar (ou insultar) sua experiência e / ou educação?

Introduza perguntas para fazê-los perceber que o que estão fazendo está errado. Por exemplo, faça este tipo de pergunta:

Por que você decidiu fazer disso uma variável global?

Por que você deu esse nome?

Isso é interessante. Eu costumo fazer o meu assim porque [Insira o motivo pelo qual você é melhor]

Isso funciona? Eu normalmente [insira como você os faria parecer bobos]

Eu acho que a maneira ideal de fazer isso é sutilmente perguntar a eles por que eles codificam de uma certa maneira. Você pode achar que eles acreditam que existem benefícios para outros métodos. A menos que eu soubesse que o motivo de seu estilo de codificação era devido a informações erradas, eu nunca julgaria o meu caminho como melhor sem um bom motivo. A melhor maneira de fazer isso é perguntar-lhes por que eles escolheram esse caminho; certifique-se de parecer interessado no raciocínio deles, porque é isso que você precisa atacar, não a capacidade deles.

Um padrão de codificação definitivamente ajudará, mas se fosse a resposta para todos os projetos de software, estaríamos todos bebendo cocktails em nossas ilhas particulares no paraíso. Na realidade, somos todos propensos a problemas e os projetos de software ainda têm uma baixa taxa de sucesso. Penso que o problema deve-se principalmente à capacidade individual e não a convenções, e é por isso que sugiro trabalhar com os problemas em grupo quando um problema surge na cabeça feia.

Mais importante, NÃO presuma imediatamente que seu caminho é melhor . Na realidade, provavelmente é, mas estamos lidando com a opinião de outra pessoa e para ela existe apenas uma solução. Nunca diga que seu caminho é a melhor maneira de fazê-lo, a menos que você queira que eles o vejam como um perdedor presunçoso.

Comece a fazer revisões de código ou emparelhar a programação.

Se a equipe não aceitar isso, tente revisões semanais de design. Toda semana, reúna-se por uma hora e fale sobre um pedaço de código. Se as pessoas parecerem defensivas, escolha um código antigo ao qual ninguém mais se apegue emocionalmente, pelo menos no começo.

Como @JesperE: disse, concentre-se no código, não no codificador.

Quando você vê algo que acha que deveria ser diferente, mas outros não vêem da mesma maneira, comece fazendo perguntas que levem às deficiências, em vez de apontá-las. Por exemplo:

Globals : Você acha que vamos querer ter mais de um desses? Você acha que queremos controlar o acesso a isso?

Estado mutável : Você acha que queremos manipular isso de outro thread?

Também acho útil me concentrar nas minhas limitações, o que pode ajudar as pessoas a relaxar. Por exemplo:

funções longas : meu cérebro não é grande o suficiente para armazenar tudo isso de uma vez. Como podemos fazer pedaços menores com os quais eu possa lidar?

nomes ruins : fico confuso com bastante facilidade ao ler código claro; quando os nomes são enganosos, não há esperança para mim.

Por fim, o objetivo não é ensinar sua equipe a codificar melhor. É estabelecer uma cultura de aprendizado em sua equipe. Onde cada pessoa procura ajuda para se tornar um programador melhor.

Introduzir a idéia de um padrão de código. O mais importante sobre um padrão de código é que ele propõe a idéia de consistência na base de código ( idealmente , todo o código deve parecer que foi escrito por uma pessoa em uma sessão), o que levará a um código mais compreensível e sustentável.

Você tem que explicar por que seu caminho é melhor .

Explique por que uma função é melhor do que recortar e colar.

Explique por que uma matriz é melhor que $ foo1, $ foo2, $ foo3.

Explique por que variáveis ​​globais são perigosas e que variáveis ​​locais tornarão a vida mais fácil.

Simplesmente criar um padrão de codificação e dizer "faça isso" é inútil porque não explica ao programador por que é uma coisa boa.

Primeiro, eu teria cuidado para não julgar rápido demais. É fácil descartar um código como ruim, quando pode haver boas razões para isso (por exemplo: trabalhar com código legado com convenções estranhas). Mas vamos assumir por um momento que eles são realmente ruins.

Você pode sugerir o estabelecimento de um padrão de codificação, com base nas informações da equipe. Mas você realmente precisa levar em consideração as opiniões deles, e não apenas impor sua visão de como deve ser um bom código.

Outra opção é trazer livros técnicos para o escritório (Código Completo, C ++ Efetivo, Programador Pragmático ...) e oferecer emprestá-lo a outras pessoas ("Ei, eu terminei com isso, alguém gostaria de emprestá-lo?" )

Se possível, verifique se eles entendem que você está criticando o código deles , não eles pessoalmente.

Sugira uma alternativa melhor de maneira não conflituosa.

"Ei, acho que assim também funcionará. O que vocês acham?" [Gesticule para obviamente um código melhor na sua tela]

Faça revisões de código e comece revendo SEU código.

Isso deixará as pessoas à vontade com todo o processo de revisão de código, porque você está iniciando o processo revisando seu próprio código em vez do deles. Começar com o seu código também dará bons exemplos de como fazer as coisas.

Eles podem pensar que seu estilo fede também. Reúna a equipe para discutir um conjunto consistente de diretrizes de estilo de codificação. Concordo com alguma coisa. Se isso não se enquadra no seu estilo, o que importa é escolher um estilo, desde que consistente.

Por exemplo. Mostre a eles o caminho certo.

Vá devagar. Não os engane por todos os pequenos erros logo de cara, apenas comece com coisas que realmente importam.

A idéia padrão do código é boa.

Mas considere não dizer nada, principalmente porque é divertido, presumivelmente com pessoas de quem você é amigo. É apenas código ...

Há alguns conselhos realmente bons no livro de Gerry Weinberg, "A psicologia da programação de computadores" - toda a sua noção de "programação sem ego" é sobre como ajudar as pessoas a aceitar as críticas ao seu código como distintas das críticas a si mesmas.

Más práticas de nomeação: sempre imperdoável.

E sim, nem sempre assuma que seu caminho é melhor ... Pode ser difícil, mas a objetividade deve ser mantida.

Eu tive uma experiência com um codificador que tinha nomes de funções tão horríveis que o código era pior do que ilegível. As funções mentiram sobre o que eles fizeram, o código não fazia sentido. E eles eram protetores / resistentes a ter alguém para mudar seu código. quando confrontados de maneira muito educada, eles admitiram que o nome não era bom, mas queriam manter a propriedade do código e voltariam a corrigi-lo "posteriormente". Isso é passado agora, mas como você lida com uma situação em que o erro é RECONHECIDO, mas protegido? Isso continuou por um longo tempo e eu não tinha ideia de como romper essa barreira.

Variáveis ​​globais: Eu próprio não gosto muito de variáveis ​​globais, mas conheço alguns programadores excelentes que gostam muito deles. Tanto que acredito que eles não são tão ruins em muitas situações, pois permitem maior clareza e facilidade de depuração. (por favor, não me chame / faça voto negativo :)) Tudo se resume a, eu vi muitos códigos muito bons, eficazes e sem erros que usavam variáveis ​​globais (não inseridas por mim!) e uma grande quantidade de bugs, impossível ler / manter / corrigir códigos que usavam meticulosamente padrões adequados. Talvez lá é um lugar (embora encolhendo talvez) para variáveis globais? Estou pensando em repensar minha posição com base em evidências.

Inicie um wiki na sua rede usando algum software wiki.

Inicie uma categoria em seu site chamada "práticas recomendadas" ou "padrões de codificação" ou algo assim.

Aponte todos para isso. Permitir feedback.

Quando você faz lançamentos do software, peça à pessoa cujo trabalho é colocar o código na compilação pressionando os desenvolvedores, apontando-os para as páginas do Wiki nele.

Eu fiz isso na minha organização e demorou vários meses para as pessoas realmente se interessarem em usar o Wiki, mas agora esse recurso é indispensável.

Se você tem um padrão pouco amplo de codificação, é possível apontar para isso ou indicar que não pode seguir o código porque não é o formato correto.

Se você não possui um formato de codificação, agora seria um bom momento para instalá-lo. Algo como as respostas a esta pergunta pode ser útil: /programming/4121/team-coding-styles

Eu sempre vou com a linha 'Isto é o que eu faria'. Eu não tento dar uma palestra e dizer que o código é um lixo, mas apenas dou um ponto de vista alternativo que, esperançosamente, pode mostrar a eles algo que é obviamente um pouco melhor.

Peça às pessoas em questão que preparem uma apresentação para o restante do grupo no código de um módulo representativo que eles escreveram e deixe que as perguntas e respostas tomem conta dele (confie em mim, sim, e se for um bom grupo, nem deveria ficar feio).

Eu amo código, e nunca tive nenhum curso em minha vida sobre algo relacionado à informática. Comecei muito mal e comecei a aprender com exemplos, mas o que sempre me lembro e me lembrei desde que li o livro "Gang Of Four" era :

"Todos podem escrever código que é entendido por uma máquina, mas nem todos podem escrever código que é entendido por um ser humano"

com isso em mente, há muito a ser feito no código;)

Não consigo enfatizar paciência o suficiente. Eu vi esse tipo exato de coisa sair pela culatra principalmente porque alguém queria que as mudanças acontecessem AGORA. Poucos ambientes precisam dos benefícios da evolução, não da revolução. E, ao forçar a mudança hoje, pode criar um ambiente muito infeliz para todos.

O buy-in é fundamental. E sua abordagem precisa levar em consideração o ambiente em que você está.

Parece que você está em um ambiente que tem muita "individualidade". Então ... eu não sugeriria um conjunto de padrões de codificação. Acontece que você deseja pegar esse projeto "divertido" e transformá-lo em um projeto de trabalho altamente estruturado (oh, ótimo, o que vem a seguir ... documentos funcionais?). Em vez disso, como alguém disse, você terá que lidar com isso até certo ponto.

Seja paciente e trabalhe para educar os outros em sua direção. Comece com as arestas (pontos em que seu código interage com outras pessoas) e, ao interagir com o código, tente aproveitar a oportunidade para discutir a interface que eles criaram e pergunte se seria bom se eles fossem alterados (por você ou eles). E explique completamente por que você deseja a alteração ("ela ajudará a lidar melhor com a alteração dos atributos do subsistema" ou o que for). Não escolha nada e tente mudar tudo que você vê como errado. Depois que você interage com outras pessoas no limite, elas devem começar a ver como isso as beneficiaria no núcleo de seu código (e, se você conseguir impulso suficiente, vá mais fundo e comece a discutir técnicas modernas e os benefícios dos padrões de codificação). Se eles ainda não vêem ... talvez você '

Paciência. Evolução, não revolução.

Boa sorte.

Coloco uma toga e abro uma lata de método socrático.

O método socrático, nomeado em homenagem ao filósofo grego clássico Sócrates, é uma forma de investigação filosófica na qual o questionador explora as implicações das posições dos outros, para estimular o pensamento racional e iluminar idéias. Esse método dialético geralmente envolve uma discussão de oposição, na qual a defesa de um ponto de vista se opõe a outro; um participante pode levar outro a se contradizer de algum modo, reforçando o próprio ponto de vista do investigador.

Muitas das respostas aqui se referem à formatação de código que atualmente não é particularmente relevante, pois a maioria dos IDEs reformata seu código no estilo que você escolher. O que realmente importa é como o código funciona, e o pôster tem razão em examinar variáveis ​​globais, copiar e colar código e minha irritação, convenções de nomenclatura. Existe código ruim e pouco tem a ver com o formato.

A parte boa é que a maioria é ruim por um motivo muito bom, e esses motivos geralmente são quantificáveis ​​e explicáveis. Portanto, de uma maneira não conflituosa, explique os motivos. Em muitos casos, você pode até dar ao escritor cenários em que os problemas se tornam óbvios.

Eu não sou o desenvolvedor líder do meu projeto e, portanto, não posso impor padrões de codificação, mas descobri que o código incorreto geralmente causa um problema mais cedo ou mais tarde, e quando isso acontece, eu estou lá com uma ideia ou solução mais limpa.

Ao não injectar na época e adotar uma abordagem mais natural, ganhei mais confiança com o líder, e ele muitas vezes se volta para mim em busca de idéias e me inclui no design de arquitetura e na estratégia de implantação usada para o projeto.

As pessoas que escrevem códigos ruins são apenas um sintoma de ignorância (que é diferente de ser burra). Aqui estão algumas dicas para lidar com essas pessoas.

• A própria experiência dos povos deixa uma impressão mais forte do que você dirá.
• Algumas pessoas não são apaixonadas pelo código que produzem e não ouvem nada do que você diz
• A programação emparelhada pode ajudar a compartilhar idéias, mas mudar quem está dirigindo ou eles apenas verificam o email no telefone
• Não os afogue demais, eu achei que a Integração Contínua precisava ser explicada algumas vezes para alguns desenvolvedores mais antigos
• Deixe-os entusiasmados novamente e eles vão querer aprender. Pode ser algo tão simples quanto programar robôs por um dia
• CONFIE NA SUA EQUIPE, os padrões de codificação e as ferramentas que os verificam no momento da construção geralmente nunca são lidos ou irritantes.
• Remova a propriedade do código. Em alguns projetos, você verá silos de código ou formigueiros onde as pessoas dizem que esse é o meu código e você não pode alterá-lo. Isso é muito ruim e você pode usar a programação emparelhada para removê-lo.

Em vez de fazê-los escrever código, faça com que mantenham seu código.

Até que eles tenham que manter sua pilha de espaguete fumegante, eles nunca entenderão o quão ruim são na codificação.

Ninguém gosta de ouvir alguém dizendo que seu trabalho é péssimo, mas qualquer pessoa sã gostaria de receber orientação e maneiras de evitar trabalhos desnecessários.

Uma escola de ensino até diz que você não deve apontar erros, mas concentrar o que é feito da maneira correta. Por exemplo, em vez de apontar códigos incompreensíveis como ruins, você deve apontar onde o código deles é particularmente fácil de ler. No primeiro caso, você está preparando os outros para pensar e agir como programadores ruins. No caso posterior, você está começando a pensar como um profissional qualificado.

Eu tenho um senário semelhante com os caras com quem trabalho .. Eles não têm a exposição à codificação tanto quanto eu, mas ainda são úteis na codificação.

Em vez de eu deixar fazer o que eles querem e voltar e editar a coisa toda. Normalmente, apenas os sento e mostro duas maneiras de fazer as coisas. Do seu jeito e do meu jeito, a partir disso, discutimos os prós e contras de cada método e, portanto, chegamos a um melhor entendimento e uma melhor conclusão sobre como devemos programar.

Aqui está a parte realmente surpreendente. Às vezes, eles apresentam perguntas para as quais nem tenho respostas e, após a pesquisa, todos temos um melhor conceito de metodologia e estrutura.

1. Discutir.
2. Mostre a eles o porquê
3. Nem pense que você está sempre certo. Às vezes, até eles ensinam algo novo.

Isso é o que eu faria se fosse você: D

Provavelmente um pouco tarde após o efeito, mas é aí que um padrão de codificação acordado é uma coisa boa.

Eu sinceramente acredito que o código de alguém é melhor quando é mais fácil alterar, depurar, navegar, entender, configurar, testar e publicar (ufa).

Dito isso, acho que é impossível dizer a alguém que seu código é ruim sem que ele explique o que faz ou como alguém deve melhorá-lo depois (como criar uma nova funcionalidade ou depurar).

Só então a mente deles se encaixa e alguém será capaz de ver isso:

• Alterações no valor das variáveis ​​globais quase sempre não são rastreáveis
• Funções enormes são difíceis de ler e entender
• Os padrões facilitam o aprimoramento do seu código (desde que você obedeça às regras deles)
• (etc ...)

Talvez uma sessão de programação em pares deva fazer o truque. Quanto à imposição de padrões de codificação - isso ajuda, mas eles estão muito longe de realmente definir o que é um bom código.

Você provavelmente deseja se concentrar no impacto do código incorreto, e não no que pode ser descartado como apenas sua opinião subjetiva sobre se é um estilo bom ou ruim.

Informe-se sobre alguns dos segmentos de código "ruins" em particular, com a possibilidade de que seja realmente um código razoável (não importa o quão predisposto você seja), ou que talvez haja circunstâncias atenuantes. Se você ainda está convencido de que o código é simplesmente ruim - e que a fonte realmente é essa pessoa - vá embora. Uma das várias coisas pode acontecer: 1) a pessoa percebe e toma alguma ação corretiva; 2) a pessoa não faz nada (é inconsciente ou não se importa tanto quanto você).

Se o número 2 acontecer, ou o número 1 não resultar em melhoria suficiente do seu ponto de vista, e estiver prejudicando o projeto e / ou afetando você o suficiente, talvez seja a hora de iniciar uma campanha para estabelecer / aplicar padrões dentro O time. Isso requer adesão da gerência, mas é mais eficaz quando instigado a partir das bases.

Boa sorte com isso. Eu sinto sua dor irmão.