Recomendaciones para enseñar a los programadores junior un buen estilo de codificación [duplicado]

69

Soy un gran fan del buen estilo de codificación, que produce un código limpio y claro que funciona bien y es fácil de usar e integrar en sistemas más grandes. Creo que los programadores somos esencialmente artesanos y debemos sentirnos orgullosos de nuestro trabajo, cada línea. No me gusta el código con formato inconsistente, lleno de código experimental comentado, y lleno de funciones y nombres de variables poco útiles o engañosos. Pero a veces me cuesta discutir con un código como este que básicamente funciona.

Si crees que el estilo de codificación es importante, estoy buscando recomendaciones sobre formas de enseñar un buen estilo de codificación profesional a los programadores junior que tengo a mi cargo. Quiero que se sientan orgullosos de su trabajo, pero mi preocupación es que parecen estar satisfechos cuando su código apenas funciona, y parece que no tienen interés en producir lo que los profesionales como yo consideraría un código profesional. Por otro lado, si piensa que el estilo de codificación no es particularmente valioso, agradezco sus comentarios y estoy abierto a reconsiderar mis estándares y tolerancias.

Conozco los argumentos habituales a favor de un buen código: comprensibilidad, facilidad de mantenimiento, etc., pero también me gustaría escuchar algunas refutaciones a argumentos como "funciona, ¿qué más quieres?"

En nuestra industria podemos usar el compilador para ocultar una multitud de pecados. El código limpio y el código desordenado pueden llevar a programas que funcionan de manera idéntica, por lo que importa la limpieza, y si es así, ¿por qué?

[Si bien existen varias preguntas sobre el estilo de codificación, no encontré ninguna relacionada con los métodos de enseñanza y las formas de inculcar un buen estilo de codificación en los programadores junior.]

    
pregunta Randall Cook 01.05.2015 - 21:32

16 respuestas

51
  

Da una buena impresión

Toma algunos de los libros conocidos, por ejemplo, , Código Completo , Coders en el trabajo , The Coder limpio: un código de conducta para programadores profesionales etc. ( vea aquí las listas completas ) y deles un par de días para leer uno - en el trabajo, en una oficina privada. Sepárelos, digamos 1 libro por mes o trimestre. Verán por el esfuerzo que lo que usted personalmente dice es realmente importante, no solo "la línea de la compañía" para tomar con un grano de sal. Obviamente, asegúrate de tener una gestión en línea con esto; no querrás que digan "¿eh? ¿A qué se dedica la persona X con la puerta cerrada?"

Junto con clases de capacitación continua y más formal en las últimas tecnologías.

Además, a medida que las cosas se hacen "de la manera correcta" se generaron grandes estímulos e incluso recompensas. De lo contrario, puede ser más un entorno negativo, punitivo, más que positivo, gratificante. La mayoría de las personas quieren hacer y quieren ser conocidos por hacer "un buen trabajo" si tienen las herramientas para hacerlo.

  

Practica lo que predicas, predica lo que practicas

Hable sobre el código, hable sobre los buenos principios, hable sobre nuevas herramientas, se haga "conocido" por ello.

Proporcionar / apoyar / sugerir screencasts, videos, peepcodes y cualquier tutorial y clase en línea que pueda encontrar.

Apoye y sugiera grupos de usuarios locales apropiados, incluidos aquellos en sitios como enlace

Si está en la oficina (es decir, no es virtual), una estantería bien surtida de los libros reales que le gustaría que la gente use es buena. Encuentre una manera de hacer que esto sea "no solo la estantería polvorienta en la esquina", sino colocándolo de manera prominente, Moviendo los libros, etc. Usa tu imaginación también. ¡Tal vez cada programador obtiene un libro como "tarea" al mes y usted tiene una reunión mensual en la que pueden "presentar sus hallazgos"!

Esto dará más impresión de que solo una conversación de 10 minutos, lo eliminará del rol de "crítico" y les permitirá aprender a pescar por sí mismos (en lugar de darles pescado, usted sabe el trato) . Algunas personas jóvenes también sienten que es intimidante tener gente mayor que siempre explica cosas, cuando a veces todo lo que realmente quieren es algo de tiempo para estudiar, practicar y absorberlo.

  

Inculcar una cultura de aprendizaje y excelencia

Básicamente, deseas crear "una cultura de aprendizaje y excelencia" para que puedas practicar lo que enseñas e inspirar a otros a hacer lo mismo.

Esto debe hacerse junto con las revisiones de código para ver si / cómo los principios se aplican al trabajo real que se está realizando. A la inversa, las revisiones de código realizadas sin lo anterior pueden dar la impresión de que el alumno tiene sesiones de nalgadas, sin importar qué tan bien intencionadas estén con el profesor.

    
respondido por el Michael Durrant 23.05.2017 - 14:40
44

Todos los programadores siempre deben hacer revisiones de código con un programador senior antes de confirmar / fusionar sus cambios de código.

  1. Esto le da a los programadores de alto nivel la oportunidad de llegar a un consenso sobre qué estilos quieren aplicar (y reconocer cuáles son solo una cuestión de preferencia) entre ellos.
  2. Le da a los programadores junior la oportunidad de aprender qué prácticas se esperan de su equipo desde el principio. Dentro de un par de meses, el 90% del código que escriben ya seguirá esas prácticas antes de la revisión del código.

Además, la mayoría de los IDE tienen herramientas que puede configurar para imponer la gran mayoría de las preferencias de estilo de codificación con pequeños subrayados y opciones para corregir automáticamente el estilo en un archivo. Los programadores junior se darán cuenta de eso bastante rápido.

    
respondido por el StriplingWarrior 23.04.2012 - 03:28
12

Creo que la mejor manera de fomentar este comportamiento de los jóvenes desarrolladores es practicarlo usted mismo y ser un modelo a seguir para ellos. Si es posible, debe vincular el programa con ellos con frecuencia y poner énfasis en la calidad del código cuando programe con ellos. Durante el emparejamiento, puede explicar y justificar las buenas elecciones de codificación a medida que las realiza. Puede explorar las opciones "peores" y explicar por qué no son una buena solución a largo plazo. Formar parte de este tipo de desarrollo de forma práctica es probablemente una de las mejores maneras de enseñar a los nuevos desarrolladores la importancia de la calidad del código. Si todos en su equipo piensan que la calidad del código es importante, también aprenderán a respetarlo.

    
respondido por el Oleksi 23.04.2012 - 02:30
7

Parece que algo tan simple de aplicar como un estándar de codificación solo se manejará mediante:

  1. Contrata personas que estén de acuerdo contigo.
  2. Revisión de código
  3. Usa aplicaciones que puedan automatizar estas cosas.
  4. Hacer es una parte tan importante de hacer tu trabajo como aparecer. Tiene que haber consecuencias por no hacer tu trabajo.

Personalmente, estaría al tanto de un gerente que hizo que esto fuera una prioridad. Enfócate en lo que es importante y no te pongas nervioso. Debería poder justificar por qué, pero hay ocasiones en las que simplemente elige un estándar (quién sabe por qué una sangría de 4 espacios es mejor que 5 aparte de que solo está siendo mental).

Obtener un consenso del equipo sobre las normas. Esto mejorará la calidad y el nivel de adherencia. No pierdas demasiado tiempo en un debate. Finalmente, un líder toma una decisión basada en la cantidad de entrada.

    
respondido por el JeffO 23.04.2012 - 15:44
5

Déles una unidad de código realmente mal escrita para modificar (y probar) y luego reescribir (y probar) y luego darles una unidad de código realmente bien escrita con pruebas unitarias para modificar (y probar) y preguntarles sobre la experiencia.

Después de esto, dales una lista de estándares para leer y refactorizar su código (del ejercicio anterior) para que coincida con esos estándares como práctica.

Necesitará una documentación organizada de sus estándares antes de esto.

    
respondido por el Danny Varod 23.04.2012 - 19:20
2

Creo que no debes enseñar un estilo de codificación específico por las siguientes razones:

  • Los programadores junior necesitan aprender de sus errores. Mejorarán continuamente evaluando su trabajo y haciendo revisiones de código con desarrolladores senior.

  • Las pautas de codificación variarán según la cultura de la empresa para la que está trabajando. Podría argumentar contra lo que considera un código limpio.

  • Los programadores junior normalmente no se exponen mucho a los sistemas empresariales, y ahí es donde normalmente vive el código limpio.

  • Muy a menudo, los profesores universitarios han estado atrapados en el mundo académico durante décadas. Personalmente, he encontrado que sus directrices y comentarios son poco útiles y pobres en comparación con los estándares actuales de la industria. Algunos, por supuesto, son muy buenos.

Para resumir:

  • Creo que la solución no es enseñar directrices específicas o estilos de codificación, sino tratar de explicar su importancia en proyectos de varios tamaños.

  • Hay tanto que puedes explicar en el aula y en los libros.

  • Los desarrolladores tendrán que ensuciarse las manos para ver el beneficio real para los temas de si mismos.

  • Asigne desarrolladores junior al programa en pareja, luego revise su trabajo y bríndeles retroalimentación. Eventualmente deberían comenzar a ver el beneficio.

No hay un estilo de codificación de bala de plata que siempre funcionará, como cualquier otra cosa en ingeniería de sistemas.

    
respondido por el CodeART 23.04.2012 - 19:25
1

El problema real es que las personas no están de acuerdo con qué es exactamente el código limpio. Una vez que haya escrito el código perfecto con todos los detalles exactamente correctos, la siguiente persona todavía va a pensar que es una porquería. Cada programador está observando diferentes partes del código y encontrando cosas que no le gustan, mientras que simultáneamente ignora todas las partes buenas. Esta es una parte necesaria de la programación, ya que los programadores deben encontrar las cosas malas antes de que vayan al control de versiones por primera vez. Así que los programadores pueden fácilmente reconocer un código malo. Es solo que es diferente para cada programador.

En un equipo, esta característica causará problemas, si hay reglas demasiado estrictas para las convenciones, o si las personas deben mantener y trabajar con el código escrito por otras personas. La mejor solución es mantener las convenciones, pero no hacerlas cumplir. Y luego, asegúrese de que todos sepan quién es responsable de cada parte del código.

Enseñar a programadores junior es complicado. La mayoría de los intentos terminan en un programador junior pensando que su último código fue algo malo y que la sesión de enseñanza es necesaria por eso. Como si fuera un castigo por algún error que sucedió antes.

    
respondido por el tp1 23.04.2012 - 03:03
1

Si es importante para ti, usa algo como checkstyle y colócalo en un gancho de confirmación previa. Si el estilo de verificación falla, el código no se puede confirmar. Checkstyle es bastante bueno para dar mensajes de retroalimentación. La gente descubrirá por qué su código no cumple con el estándar y qué deben hacer para cumplirlo.

    
respondido por el emory 23.04.2012 - 08:16
1

Aprendí un buen estilo de codificación de uno de los desarrolladores senior de uno de mis proyectos anteriores. Revisa mi código para cada compromiso durante la reunión de revisión de código y me explicará línea por línea si se puede mejorar algo allí.

  • Repasa cada nombre de las variables y métodos y explica cómo nombrarlos mejor.

  • Él va a través de cada método y me dice cómo hacer más legible y más eficiente.

  • Fue muy educado, pero su tutoría me ayudó mucho.

  • Me tomó solo tres meses alinearme con él y ahora él rara vez encuentra errores en mi código.

Sigo el mismo método de enseñar a mis desarrolladores junior y funciona.

    
respondido por el java_mouse 23.04.2012 - 16:28
1
  

El código limpio y el código desordenado pueden conducir a programas que funcionan de manera idéntica, por lo que importa la limpieza, y si es así, ¿por qué?

La diferencia entre el código limpio y desordenado es tan enorme:

  • cambiar un código desordenado siempre es una tarea desalentadora, porque generalmente no tiene una red segura llamada prueba de unidad
  • el código desordenado tiende a tener funciones y clases enormes y muy complejas. Tratar de entenderlos no tiene sentido y es muy difícil
  • el código desordenado generalmente tiene partes de código copiadas / pegadas, lo que aumenta aún más la complejidad

Por otro lado, al tener un código limpio, todos los integrantes del equipo pueden entender fácilmente la lógica subyacente y agregar nuevas funciones sin mucho esfuerzo.

    
respondido por el BЈовић 27.04.2012 - 22:26
0

Hacer revisiones de código

Especialmente señale los problemas que surgen de un estilo de codificación incorrecto o que se evitan con un buen estilo de codificación.

Habla mucho sobre por qué esto es importante.

Dependiendo de qué tan pequeños sean tus compañeros de trabajo, ten en cuenta que debes aprender a escribir un código antes de poder escribir un código hermoso.

    
respondido por el Jens Schauder 23.04.2012 - 08:21
0

Una idea: mostrarles cómo se vería el código si se hace deliberadamente para que no sea fácil de leer y comprender ( enlace es un ejemplo corto y agradable, por ejemplo). Pregunte si desea recibir un código como este para mantenerlo.

Resalta la importancia de

  

un lenguaje informático no es solo una forma de hacer que una computadora   realizar operaciones ... los programas deben estar escritos para que la gente los lea,   y solo de forma incidental para que las máquinas ejecuten.

(cita de SICP )

    
respondido por el hlovdal 23.04.2012 - 14:21
0

La primera vez que aprendí la programación me fue entregado un programa bien escrito y lo guié línea por línea. (Aprendí mucho en esas dos horas que no obtuve en todo mi programa de estudios). Intenta lo mismo con ellos, guíalos a través de uno de tus mejores módulos, señalando cómo y por qué está construido y estilizado de esa manera. Puedes hacer esto en una sesión de grupo.

Si puedes, juega un dictador benévolo. Dependiendo de su sistema de control de revisión, puede usarlo para ayudarlo. Sin embargo, podría terminar siendo el cuello de botella en el proceso de desarrollo.

Implemente un verificador de estilo automatizado para verificar tantas reglas de estilo como pueda. (Muchas reglas de estilo de verificación deben ser portátiles entre Java y C ++). Esto lo llevará a la mitad, pero no sustituirá las revisiones de código. Hacer que los desarrolladores revisen el código de revisión puede ayudar a reducir la carga.

Si implementa un verificador de estilo automatizado, es posible que también desee implementar una herramienta de análisis de código estático. Esto debería ayudar a eliminar algunos de los errores que pueden perderse en las revisiones de código. También le permitirá concentrarse en cuestiones estilísticas en lugar de buscar los errores que cubre la herramienta de análisis de código estático. Todavía puede haber casos comunes que necesitan ser revisados.

Desarrolle una lista de verificación para que los desarrolladores la usen antes de ingresar el código. Esto puede contener otras cosas que desee que ocurran antes del registro. Existe una creciente evidencia de que las listas de verificación pueden ayudar a reducir los errores. Aliente a los desarrolladores a crear su propia lista de control de los errores que comúnmente cometen, para que puedan evitar repetirlos.

    
respondido por el BillThor 24.04.2012 - 05:03
0

Hábleles sobre la programación literaria de D. Knuth.

  

Creo que ha llegado el momento de una mejor documentación de los programas, y que podemos lograrlo mejor considerando que los programas son obras de literatura. De ahí mi título: "Programación literaria".

     

Cambiemos nuestra actitud tradicional hacia la construcción de programas: En lugar de imaginar que nuestra tarea principal es instruir a una computadora sobre qué hacer, concentrémonos más bien en explicar a los seres humanos lo que queremos que haga una computadora

     

Donald Knuth, sobre programación alfabetizada .

En mi humilde opinión, el hecho de que el objetivo principal de un programa de computadora sea comunicar entidades intelectuales a otros programadores, es un argumento decisivo para la importancia del estilo de codificación.

    
respondido por el aram 26.04.2012 - 23:04
0

Creo que un aspecto subestimado del estilo de codificación es que se manifiesta de forma natural. Cuando veo un código fuente que escribí hace mucho tiempo, por lo general siento un deseo convincente de atravesar el continuo espacio-tiempo solo para golpearme en la cara por las (percibidas) monstruosidades que he realizado en dicha fuente. Ya que eres mentor de juniors, y tienden a aprender rápido (ya que lo necesitan), haz la solución más simple posible: permíteles que escriban un código erróneo (¡una vez!), Luego haz que lo mantengan. Es probable que, si son buenos en ingeniería de software, se arrepientan de sus pecados y refactoricen el código correctamente. Por supuesto, no lance su colección de espaguetis como código de grado de producción, estoy seguro de que hay muchas oportunidades para hacer que un dev menor escriba algo pequeño, casi 'desechable'.

No hay una escuela de software como la vida real

DRY tiene mucho sentido cuando has tenido que editar esa línea copiada y pegada 4 veces, y solo lo hiciste 3, por eso el código hace referencia a un puntero nulo y la aplicación se bloquea ...
Además, la energía que gastará tratando de transmitir metodologías "buenas" sobre ellos probablemente será mucha, y no es seguro que no la rechacen con un "Lo que sea, funciona" como usted señaló. Así que muéstreles en la práctica que el estilo del código es importante, demostrando que también es más legible para ellos mismos.

El software de soporte es mucho más útil para los programadores de lo que creen que es

Creo que es otro tema, pero la mayoría de las personas asumen instintivamente que escriben un buen código (me declaro culpable). Así que arreglar el desorden de otra persona puede ser bueno para los hábitos de uno: no pecarías si acabaras de regresar de unas vacaciones en el infierno, ¿verdad (las opiniones religiosas, aparte)?     

respondido por el K.Steff 29.04.2012 - 03:41
0

Creo que sería una excelente manera de entrenar a los nuevos programadores con la tecnología de convenciones de nomenclatura [es el estándar para nombrar una variable, método o clase]. Para un mejor seguimiento del flujo de programadores que tocan el código será fácil de manejar, por ejemplo, al conocer los nombres relevantes utilizados.

Por ejemplo: Variables estáticas comienza con s,         Las variables de argumento comienzan con a, etc.,

    
respondido por el Gnanam R 30.04.2012 - 06:29