Dar una presentación sobre "estilo de código y patrones de diseño" [cerrado]

Mi empresa (pequeña, unas 40 personas en 3 oficinas) ocasionalmente realiza "talleres para desarrolladores" en línea donde uno de los desarrolladores realiza una presentación sobre algún tema tecnológico. No se trata necesariamente de nuestro trabajo, sino solo para ayudar a todos a mejorar sus habilidades y comprensión.

Me han pedido que aloje el siguiente, y el tema (elegido de una lista que proporcioné) es el estilo de código y los patrones de diseño. Sé que esas cosas no están tan relacionadas, pero ten paciencia conmigo. He visto muchos lugares en nuestra base de código que podrían mejorarse, algunos incluso pueden calificar para DailyWTF, por lo que quiero que esta presentación sea lo más efectiva posible. El problema es que no sé exactamente qué cubrir en una hora.

Mi primera idea es usar nuestro propio código como ejemplo, para llevar a casa el punto de "por favor, aplique esto a su trabajo". Pero el tema es muy amplio.

Algunas cosas que están mal con nuestro código (PHP) incluyen:

• Mínimo OO. Ha estado mejorando últimamente, pero todavía hay toneladas de funciones globales. Me lleva un tiempo encontrar cosas.
• Configuración global (opinión, supongo). Puede encontrar $ GLOBALS ['blah'] dispersos en casi todos los archivos.
• Estilo de corsé inconsistente. Suena mínimo, pero esto en realidad provocó que un error de sintaxis se enviara a su origen hace cinco días, que aún no se corrigió hasta ayer.
• Construcciones ineficientes. Pude hacer algunas mejoras básicas que redujeron el tiempo de ejecución en algunas áreas en un 70%.

Quiero que esto sea lo más útil posible, sin sonar condescendiente con mis compañeros de trabajo. Entonces, ¿en qué aspectos del "estilo" debería centrarme, y qué patrones de diseño podrían ser más útiles para explicar?

Tenga mucho cuidado al usar código real en una presentación frente a las personas que escriben este código.

En el mejor de los casos, vas a molestar a tu equipo al señalarlos con el dedo delante de todos. Y lo que obtendrás en lugar de "Realmente abriste mis ojos" es "¿WTF frente a todos? ¿Incluso miraste tu propio código tonto ..."?

Tome un ejemplo real, pero modifíquelo o asegúrese de que no se pueda rastrear a quien lo escribió. O tome el código real de personas que conoce, pero también tome algo de SU código antiguo y juegue humor y bromas internas con estas personas, estilo standup :)

Para responder a sus preguntas originales: Todo lo que se trata de legibilidad: funciones con la menor cantidad de argumentos posible, POO, nombre de variable largo y detallado y comentarios.

Supongo que tiene un sistema de seguimiento de errores en su organización. Saque algunos de los errores más desagradables del repositorio, vea el informe de reparación de por qué sucedió (las variables globales se salieron mal, las funciones hicieron cosas que no estaban destinadas a hacer, etc.) y luego analice los estilos de codificación y los patrones de diseño que podrían haber ayudado a evitar este problema .

Hacer un poco de investigación es un trabajo duro, pero esta es la forma más sólida de llevar a casa lo que presenta realmente funciona .

"Todavía toneladas de funciones globales".

Primero, obtenga una lista. Completo es ideal.

Segundo, divida esta lista en clases potenciales. Piensa en las definiciones de clase.

Durante la presentación real, elija la clase potencial más grande, más obvia, más evidente y menos discutible que absorbería un montón de esas funciones globales.

Como tema de discusión. Tienes una idea Necesitas llegar a un consenso. Y responde preguntas en el camino. Y ayúdelos a entender por qué es una clase única de objetos, no un montón de funciones aleatorias que comparten globales.

Luego, después de discutir esto hasta el punto en que entienden solo esta clase y cómo llegaste al contenido ...

Enciende el proyector.

Comience a escribir.

Arregla el código. Vuelva a ejecutar las pruebas de su unidad.

Diseña patrones y codifica el estilo y realiza el trabajo. Todo en un paquete.

en 1 hora, te irá bien para comprender los conceptos básicos.

sugiero elegir 3 cosas de cada tema y centrarse en ellas; limite las diapositivas a 5-7 palabras para que la gente lo escuche en lugar de leer las diapositivas; use ejemplos inventados (para no pisar los pies de las personas, según las sugerencias de otros); dar referencias al final (las URL son mejores que los libros) como un ejercicio para aquellos que quieran aprender más; publique sus diapositivas en su intranet después de su presentación. (En cuanto al problema de los frenos, use un formateador de código; probablemente no sea una batalla que valga la pena pelear)

Temas sugeridos:

• Estilo de codificación

  • El Zen de OOP en PHP: ¡Codificación con estilo!
  • 5 razones por las que las funciones globales causan cáncer de código
  • ¿Lo que hay en un nombre? Convenciones y sentido común (¡o no me hagas pensar!)

• Patrones de diseño

  • Algunos patrones de GoF en nuestro código; una introducción
  • Los patrones son solo herramientas, no evangelio
  • Lo mejor y lo peor: patrones y antipatrones

nota: las configuraciones globales a veces son difíciles de evitar; Una solución fácil es poner todas las referencias a ellos en una función init

advertencia: conozco solo PHP suficiente para romper wordpress y realizar pequeñas correcciones en el sitio web

Acerca del uso de código real en la presentación: si se usa, solo úselo para los buenos ejemplos, NUNCA los malos ejemplos. Para mal, inventa el tuyo o encuéntralo en la web. Esto permite que sus compañeros de trabajo se enorgullezcan de su trabajo y obtengan reconocimiento por ello. También evita el escenario en el que pueden estar enojados / avergonzados por ser señalados como malos desarrolladores.

Los estilos de codificación son malos hábitos. Difícil de deshacerse de él. ¿La mejor manera de dejar que alguien deje un mal hábito? Déjelo ver de primera mano lo feo, asqueroso o dañino que es.

Muéstreles un código incorrecto, pregúnteles qué tiene de malo. Deja que lo piensen por un segundo, luego dales un "¡Aaahaaa!" momento mostrándoles un caso de borde (¿problema de Fencepost, tal vez?) o un caso en el que su mal diseño colapsa todo lo demás.

Parece que sus muchachos tienen problemas de diseño habituales. Muéstreles un ejemplo de cómo una función global cambiada de manera inocente daña otras funciones dependiendo de ella, pero sin saber que fue cambiada. Muéstreles un problema clásico de sincronización con la variable global.

Hazlo de una manera divertida para involucrarlos, en lugar de aburrirlos o hacer que tomen posiciones defensivas (¿quién es este tipo para criticarnos?); por ejemplo, muéstreles una función que hace su trabajo en dos pasos (1- ingrese el nombre de la esposa) (2-guárdelo en global) (3-ingrese el nombre del esposo y tome el nombre de la esposa del global para almacenarlo en la base de datos) (4- ría como una mala sincronización da como resultado que los hombres tengan 'nuevas' esposas), como broma proponen escribir una función de estadísticas de divorcio.

Creer puede ser un fastidio sobre el estilo de programación, porque programamos lo que pensamos, y cuando se critica el diseño de la programación, algunas personas lo toman como un insulto a su forma de pensar y, por lo tanto, a su inteligencia, por lo que debe adoptar un enfoque divertido.

Asuma sus malas funciones, ocúltelo con algunos cambios para no avergonzar al propietario del código, y trabaje e interactúe con el público para mejorarlo. Resultado: su sistema de control de código fuente a la mañana siguiente estará tan ocupado, así que tome un café y sonría a los registros de cambios.