Donner une présentation sur «le style de code et les modèles de conception» [fermé]

Mon entreprise (petite, environ 40 personnes répartie sur 3 bureaux) organise occasionnellement des "ateliers pour développeurs" en ligne où l'un des développeurs organise une présentation sur un sujet technologique. Il ne s'agit pas nécessairement de notre travail, mais simplement d'aider chacun à améliorer ses compétences et sa compréhension.

On m'a demandé d'héberger le prochain, et le sujet (choisi dans une liste que j'ai fournie) est le style de code et les modèles de conception. Je sais que ces choses ne sont pas si étroitement liées, mais supportez-moi. J'ai vu de nombreux endroits dans notre base de code qui pourraient être améliorés, certains qui pourraient même être admissibles à DailyWTF, donc je veux que cette présentation soit aussi efficace que possible. Le problème est que je ne sais pas exactement quoi couvrir en une heure.

Ma première idée est d'utiliser notre propre code à titre d'exemple, pour ramener à la maison le point de «s'il vous plaît appliquer réellement cela à votre travail». Mais le sujet est tellement vaste.

Certaines choses qui ne vont pas avec notre code (PHP) incluent:

• OO minimal. Cela s'est amélioré récemment, mais il y a encore des tonnes de fonctions mondiales. Il me faut du temps pour trouver des choses.
• Config globale (avis je suppose). Vous pouvez trouver $ GLOBALS ['blah'] dispersés dans à peu près tous les fichiers.
• Style d'accolade incohérent. Cela semble minime, mais cela a en fait provoqué une erreur de syntaxe il y a cinq jours, qui n'a toujours pas été corrigée hier.
• Constructions inefficaces. J'ai pu faire quelques améliorations de base qui ont réduit le temps de fonctionnement de 70% dans certaines zones.

Je veux que cette chose soit aussi utile que possible, sans paraître condescendante à mes collègues. Alors, sur quels aspects du "style" dois-je me concentrer et quels modèles de conception pourraient être les plus utiles à expliquer?

Soyez extrêmement prudent en utilisant du vrai code dans une présentation devant les personnes qui écrivent ce code.

Au mieux, vous allez bouleverser votre équipe en pointant le doigt vers eux devant tout le monde. Et ce que vous obtiendrez au lieu de "Vous m'avez vraiment ouvert les yeux" est "WTF devant tout le monde? Avez-vous même regardé votre propre code stupide .."

Prenez un exemple réel mais modifiez-le ou assurez-vous qu'il ne peut pas être attribué à celui qui l'a écrit. Ou prenez du vrai code de personnes que vous connaissez, mais prenez également un peu de VOTRE ancien code et jouez de l'humour et des blagues avec ces personnes, style debout :)

Pour répondre à vos questions d'origine: Tout ce qui concerne la lisibilité: fonctions avec le moins d'arguments possible, POO, nom de variable long et détaillé et commentaires.

Je suppose que vous avez un système de suivi des bogues dans votre organisation. Sortez quelques-uns des bugs les plus désagréables du référentiel, consultez le rapport de correctif expliquant pourquoi cela s'est produit (les variables globales ont mal tourné, les fonctions font des choses auxquelles elles n'étaient pas destinées, etc.), puis discutez des styles de codage et des modèles de conception qui auraient pu aider à éviter ce problème. .

C'est un travail difficile de faire ce peu de recherche, mais c'est le moyen le plus efficace de ramener à la maison ce que vous présentez fonctionne vraiment .

"encore des tonnes de fonctions globales".

Tout d'abord, obtenez une liste. Complet est idéal.

Deuxièmement, partitionnez cette liste en classes potentielles. Pensez aux définitions de classe.

Au cours de la présentation, choisissez la classe potentielle la plus grande, la plus évidente, la plus flagrante et la moins contestable qui absorberait un tas de ces fonctions globales.

Comme sujet de discussion. Tu as une idée. Vous devez obtenir un consensus. Et répondez aux questions en cours de route. Et aidez-les à comprendre pourquoi il s'agit d'une seule classe d'objets, et non d'un tas de fonctions aléatoires partageant des globaux.

Ensuite, après en avoir discuté au point où ils comprennent juste cette classe et comment vous êtes arrivé au contenu ...

Allumez le projecteur.

Commencer à écrire.

Corrigez le code. Relancez vos tests unitaires.

Concevez des modèles et un style de codage et travaillez. Tout en un.

en 1 heure, vous vous débrouillerez bien pour obtenir une compréhension du strict minimum.

je suggère de choisir 3 choses dans chaque sujet et de me concentrer sur celles-ci; limiter les diapositives à 5-7 mots pour que les gens vous écoutent au lieu de lire les diapositives; utiliser des exemples inventés (pour ne pas marcher sur les orteils des gens, selon les suggestions des autres); donner des références à la fin (les URL sont meilleures que les livres) comme exercice pour ceux qui veulent en savoir plus; postez vos diapositives sur votre intranet après votre présentation. (Quant au problème des accolades, utilisez un formateur de code; ce n'est probablement pas une bataille qui mérite d'être menée)

Sujets suggérés:

• Style de codage

  • Le zen de la POO en PHP: coder avec style!
  • 5 raisons pour lesquelles les fonctions globales provoquent le cancer du code
  • Qu'est-ce qu'il y a dans un nom? Conventions et bon sens (ou ne me faites pas réfléchir!)

• Modèles de conception

  • Quelques modèles GoF dans notre code; une introduction
  • Les modèles ne sont que des outils, pas des évangiles
  • Le meilleur et le pire: les modèles et les anti-modèles

note: les configurations globales sont parfois difficiles à éviter; un remède simple consiste à mettre toutes les références à eux dans une fonction init

mise en garde: je ne connais que suffisamment de PHP pour casser wordpress et effectuer des corrections de site Web mineures

À propos de l'utilisation de code réel dans la présentation - si utilisé, utilisez-le uniquement pour les bons exemples, JAMAIS les mauvais exemples. Pour le mal, inventez le vôtre ou trouvez-le sur le Web. Cela permet à vos collègues d'être fiers de leur travail et de le reconnaître. Cela évite également le scénario où ils pourraient être en colère / embarrassés d'être identifiés comme un mauvais développeur.

Les styles de codage sont de mauvaises habitudes. Difficile de s'en débarrasser. La meilleure façon de laisser quelqu'un abandonner une mauvaise habitude? Faites-lui voir à quel point c'est laid, dégoûtant ou nocif.

Montrez-leur un mauvais code, demandez-leur ce qui est mauvais à ce sujet. Laissez-les y réfléchir pendant une seconde, puis donnez-leur un "Aaahaaa!" moment en leur montrant un cas de bord (problème Fencepost, peut-être?) ou un cas dans lequel leur mauvaise conception s'effondre tout le reste.

Vos gars souffrent régulièrement de mauvais problèmes de conception, semble-t-il. Montrez-leur un exemple de la façon dont une fonction globale a changé d'une manière innocente nuit à d'autres fonctions en fonction, mais sans savoir qu'elle a été modifiée. Montrez-leur un problème de synchronisation classique avec la variable globale.

Faites-le de manière amusante pour les engager, au lieu de les ennuyer ou de leur faire prendre des positions défensives (qui est ce type qui nous critique?); par exemple, montrez-leur une fonction qui fait son travail en deux étapes (1- entrez le nom de la femme) (2-stockez-le dans le global) (3-saisissez le nom du mari et prenez le nom de la femme du global pour le stocker dans la base de données) (4- rire comme une mauvaise synchronisation a pour conséquence que les hommes ont de «nouvelles» épouses), comme une blague propose d'écrire une fonction de statistiques de divorce.

Croire peut avoir un impact sur le style de programmation, car nous programmons ce que nous pensons, et lorsque la conception de la programmation est critiquée, certaines personnes la considèrent comme une insulte à leur façon de penser et donc à leur intelligence, vous devez donc adopter une approche amusante.

Assumez vos mauvaises fonctions, dissimulez-le avec quelques modifications afin de ne pas embarrasser le propriétaire du code, et travaillez et interagissez avec le public pour l'améliorer. Résultat: votre système de contrôle de code source le lendemain matin sera tellement occupé, alors prenez un café et souriez aux journaux des modifications.