Fazendo uma apresentação sobre “estilo de código e padrões de design” [fechado]

Minha empresa (pequena, cerca de 40 pessoas em três escritórios) ocasionalmente realiza "workshops para desenvolvedores" on-line, onde um dos desenvolvedores realiza uma apresentação sobre algum tópico técnico. Não é necessariamente sobre o nosso trabalho, mas apenas para ajudar todos a melhorar suas habilidades e compreensão.

Me pediram para hospedar o próximo, e o tópico (escolhido em uma lista que forneci) é estilo de código e padrões de design. Eu sei que essas coisas não estão tão intimamente relacionadas, mas têm paciência comigo. Eu já vi muitos lugares em nossa base de código que poderiam ser aprimorados, alguns que podem até se qualificar para o DailyWTF, por isso quero que esta apresentação seja o mais eficaz possível. O problema é que simplesmente não sei exatamente o que cobrir em uma hora.

Minha primeira idéia é usar nosso próprio código como exemplo, para mostrar o ponto "por favor, aplique isso ao seu trabalho". Mas o tópico é tão amplo.

Algumas coisas erradas em nosso código (PHP) incluem:

• OO mínimo. Ultimamente vem melhorando, mas ainda existem toneladas de funções globais. Leva um tempo para encontrar coisas.
• Configuração global (opinião eu acho). Você pode encontrar $ GLOBALS ['blah'] espalhados em quase todos os arquivos.
• Estilo de chave inconsistente. Parece mínimo, mas na verdade isso fez com que um erro de sintaxe fosse originado cinco dias atrás, o que ainda não foi corrigido até ontem.
• Construções ineficientes. Consegui fazer algumas melhorias básicas que reduziram o tempo de execução em algumas áreas em 70%.

Quero que isso seja o mais útil possível, sem parecer condescendente com meus colegas de trabalho. Então, em quais aspectos do "estilo" devo me concentrar e quais padrões de design podem ser mais úteis para explicar?

Seja extremamente cuidadoso ao usar código real em uma apresentação na frente das pessoas que escrevem esse código.

Na melhor das hipóteses, você vai incomodar sua equipe apontando o dedo para eles na frente de todos. E o que você receberá em vez de "Você realmente abriu meus olhos" é "WTF na frente de todos? Você olhou para o seu próprio código dumbA .."

Tome o exemplo real, mas modifique-o ou certifique-se de que não possa ser rastreado por quem o escreveu. Ou pegue um código real de pessoas que você conhece, mas também pegue um pouco do SEU código antigo e faça piadas com essas pessoas, estilo stand-up :)

Para responder às suas perguntas originais: Tudo sobre legibilidade: funções com o mínimo de argumentos possível, POO, nome e comentários longos e detalhados das variáveis.

Suponho que você tenha um sistema de rastreamento de erros em sua organização. Retire alguns dos bugs mais desagradáveis ​​do repositório, veja o relatório de correção sobre o motivo (variáveis ​​globais deram errado, funções fazendo coisas para as quais eles não foram feitos etc.) e depois discuta estilos de codificação e padrões de design que poderiam ter ajudado a evitar esse problema .

É um trabalho árduo fazer essa parte da pesquisa, mas essa é a maneira mais forte de levar para casa o que você está apresentando realmente funciona .

"ainda toneladas de funções globais".

Primeiro, pegue uma lista. Completo é ideal.

Segundo, particione esta lista em possíveis classes. Pense nas definições de classe.

Durante a apresentação real, escolha a classe potencial maior, mais óbvia, mais flagrante e menos disputável que absorveria várias dessas funções globais.

Como tópico de discussão. Você tem uma ideia. Você precisa obter consenso. E responda a perguntas ao longo do caminho. E ajude-os a entender por que é uma única classe de objetos, não um monte de funções aleatórias compartilhando globais.

Depois, depois de discutir isso até o ponto em que eles entendem exatamente essa classe e como você chegou ao conteúdo ...

Ligue o projetor.

Começe a digitar.

Corrija o código. Execute novamente seus testes de unidade.

Crie padrões e estilo de codificação e trabalho a ser realizado. Tudo em um pacote.

em 1 hora, você estará se saindo bem para entender completamente o básico.

eu sugiro escolher 3 coisas de cada tópico e focar nelas; limite os slides a 5-7 palavras, para que as pessoas o ouçam em vez de lê-los; use exemplos inventados (para não pisar no pé das pessoas, conforme as sugestões dos outros); forneça referências no final (URLs são melhores que livros) como um exercício para quem quer aprender mais; publique seus slides na intranet após a sua apresentação. (Quanto à questão dos aparelhos, use um formatador de código; provavelmente essa não é uma batalha que vale a pena travar)

Tópicos sugeridos:

• Estilo de codificação

  • O Zen do OOP no PHP: codificando com estilo!
  • 5 razões pelas quais funções globais causam câncer de código
  • O que há em um nome? Convenções e bom senso (ou não me faça pensar!)

• Padrões de design

  • Alguns padrões GoF em nosso código; uma introdução
  • Padrões são apenas ferramentas, não evangelho
  • Os melhores e os piores: padrões e antipadrões

nota: configurações globais às vezes são difíceis de evitar; Um remédio fácil é colocar todas as referências a eles em uma função init

advertência: Eu sei apenas PHP suficiente para quebrar o wordpress e executar pequenas correções no site

Sobre o uso de código real na apresentação - se usado, use-o apenas para bons exemplos, NUNCA para maus exemplos. Para o mal, crie seu próprio ou encontre-o na web. Isso permite que seus colegas de trabalho se orgulhem de seu trabalho e obtenham reconhecimento por isso. Também evita o cenário em que eles podem ficar irritados / envergonhados por serem apontados como um desenvolvedor ruim.

Estilos de codificação são maus hábitos. Difícil de se livrar. Melhor maneira de deixar alguém largar um mau hábito? Que ele veja em primeira mão como é feio, repugnante ou prejudicial.

Mostre a eles um código incorreto, pergunte a eles o que há de ruim nisso. Deixe-os pensar por um segundo, depois dê a eles um "Aaahaaa!" momento, mostrando-lhes um caso de ponta (problema do Fencepost, talvez?) ou um caso em que seu mau design desmorona todo o resto.

Parece que vocês sofrem com problemas regulares de design ruim. Mostre a eles um exemplo de como uma função global alterada de maneira inocente prejudica outras funções, dependendo dela, mas sem saber que foi alterada. Mostre a eles um problema clássico de sincronização com a variável global.

Faça isso de uma maneira engraçada para envolvê-los, em vez de entediá-los ou fazê-los tomar posições defensivas (quem é esse cara para nos criticar?); por exemplo, mostre a eles uma função que faz seu trabalho em duas etapas (1 - digite o nome da esposa) (2 - armazene no global) (3 - digite o nome do marido e leve o nome da esposa de global para armazenar no banco de dados) (4 - ria como uma má sincronização resulta em homens que têm 'novas' esposas), como uma piada que propõe escrever uma função estatística de divórcio.

Acreditamos que o estilo de programação é irrelevante, porque programamos o que pensamos e, quando o design de programação é criticado, algumas pessoas o consideram um insulto ao seu modo de pensar e, portanto, à sua inteligência, portanto, você deve adotar uma abordagem divertida.

Assuma suas funções ruins, oculte-o com algumas alterações para não embaraçar o proprietário do código e trabalhe e interaja com o público para melhorá-lo. Resultado: seu sistema de controle de código-fonte na manhã seguinte estará tão ocupado, então tome um café e sorria para os registros de alterações.