¿Cómo le dices a alguien que está escribiendo un código incorrecto? [cerrado]

He estado trabajando con un pequeño grupo de personas en un proyecto de codificación por diversión. Es un grupo organizado y bastante cohesionado. Todas las personas con las que trabajo tienen varios conjuntos de habilidades relacionadas con la programación, pero algunas de ellas usan métodos más antiguos o totalmente erróneos, como variables globales excesivas, convenciones de nomenclatura deficientes y otras cosas. Si bien las cosas funcionan, la implementación es deficiente. ¿Cuál es una buena manera de pedirles o presentarles cortésmente que usen una mejor metodología, sin que esto parezca cuestionar (o insultar) su experiencia y / o educación?

Presente preguntas para que se den cuenta de que lo que están haciendo está mal. Por ejemplo, haga este tipo de preguntas:

¿Por qué decidiste hacer de eso una variable global?

¿Por qué le pusiste ese nombre?

Eso es interesante. Usualmente hago el mío de esta manera porque [Inserte la razón por la que está mejor]

¿Funciona así? Por lo general, [inserte cómo los haría parecer tontos]

Creo que la forma ideal de hacerlo es preguntarles sutilmente por qué codifican de cierta manera. Puede descubrir que creen que hay beneficios para otros métodos. A menos que supiera que la razón de su estilo de codificación se debió a información errónea, nunca juzgaría mi camino mejor sin una buena razón. La mejor manera de hacerlo es preguntarles por qué eligieron esa forma; asegúrese de parecer interesado en su razonamiento, porque eso es lo que necesita para atacar, no su habilidad.

Un estándar de codificación definitivamente ayudará, pero si fuera la respuesta a cada proyecto de software, todos estaríamos bebiendo cócteles en nuestras islas privadas en el paraíso. En realidad, todos somos propensos a problemas y los proyectos de software aún tienen una baja tasa de éxito. Creo que el problema se originaría principalmente en la capacidad individual en lugar de un problema con la convención, por lo que sugeriría trabajar en los problemas como un grupo cuando un problema levanta su cabeza fea.

Lo más importante, NO asuma de inmediato que su camino es mejor . En realidad, probablemente lo sea, pero estamos tratando con la opinión de otra persona y para ellos solo hay una solución. Nunca digas que tu camino es la mejor manera de hacerlo a menos que quieras que te vean como un perdedor presumido.

Comience a hacer revisiones de código o programar pares.

Si el equipo no quiere esos, intente revisiones de diseño semanales. Cada semana, reúnanse durante una hora y hablen sobre una pieza de código. Si las personas parecen estar a la defensiva, elija un código antiguo al que ya nadie esté apegado emocionalmente, al menos al principio.

Como @JesperE: dijo, concéntrese en el código, no en el codificador.

Cuando ve algo que cree que debería ser diferente, pero otros no lo ven de la misma manera, entonces comience haciendo preguntas que conduzcan a las deficiencias, en lugar de señalarlas. Por ejemplo:

Globales : ¿Crees que alguna vez querremos tener más de uno de estos? ¿Crees que queremos controlar el acceso a esto?

Estado mutable : ¿Crees que queremos manipular esto desde otro hilo?

También me parece útil concentrarme en mi limitaciones, que pueden ayudar a las personas a relajarse. Por ejemplo:

funciones largas : mi cerebro no es lo suficientemente grande como para contener todo esto a la vez. ¿Cómo podemos hacer piezas más pequeñas que pueda manejar?

malos nombres : me confundo fácilmente cuando leo un código claro; cuando los nombres son engañosos, no hay esperanza para mí.

En última instancia, el objetivo no es que le enseñes a tu equipo cómo codificar mejor. Es establecer una cultura de aprendizaje en su equipo. Donde cada persona busca ayuda de los demás para convertirse en un mejor programador.

Presente la idea de un código estándar. Lo más importante acerca de un estándar de código es que propone la idea de coherencia en la base del código ( idealmente , todo el código debería parecer que fue escrito por una persona en una sola sesión) lo que conducirá a un código más comprensible y sostenible.

Tienes que explicar por qué tu camino es mejor .

Explica por qué una función es mejor que cortar y pegar.

Explica por qué una matriz es mejor que $ foo1, $ foo2, $ foo3.

Explique por qué las variables globales son peligrosas y que las variables locales facilitarán la vida.

Simplemente sacar un estándar de codificación y decir "haz esto" no sirve para nada porque no explica al programador por qué es algo bueno.

Primero, tendría cuidado de no juzgar demasiado rápido. Es fácil descartar algún código como malo, cuando puede haber buenas razones por las cuales es así (por ejemplo: trabajar con código heredado con convenciones extrañas). Pero supongamos por el momento que son realmente malos.

Podría sugerir establecer un estándar de codificación, basado en la aportación del equipo. Pero realmente debe tener en cuenta sus opiniones, no solo imponer su visión de lo que debería ser un buen código.

Otra opción es traer libros técnicos a la oficina (Code Complete, Effective C ++, Pragmatic Programmer ...) y ofrecer prestarlos a otros ("Oye, ya terminé con esto, ¿a alguien le gustaría pedirlo prestado?" )

Si es posible, asegúrese de que entiendan que está criticando su código , no personalmente.

Sugerir una mejor alternativa de una manera no conflictiva.

"Oye, creo que de esta manera también funcionará. ¿Qué piensan ustedes?" [Gesto para obviamente un mejor código en su pantalla]

Tener revisiones de código y comenzar revisando SU código.

Tranquilizará a las personas con todo el proceso de revisión del código porque está comenzando el proceso revisando su propio código en lugar del suyo. Comenzar con su código también les dará buenos ejemplos de cómo hacer las cosas.

Pueden pensar que tu estilo también apesta. Reúna al equipo para discutir un conjunto consistente de pautas de estilo de codificación. De acuerdo con algo. Si eso se adapta a su estilo no es el problema, lo que importa es decidirse por cualquier estilo siempre que sea consistente.

Por ejemplo. Muéstrales el camino correcto.

Tomar con calma. No los golpees por cada pequeño error desde el principio, solo comienza con las cosas que realmente importan.

La idea estándar del código es buena.

Pero considere no decir nada, especialmente porque es por diversión, presumiblemente, con personas con las que es amigo. Es solo código ...

Hay algunos consejos realmente buenos en el libro de Gerry Weinberg "La psicología de la programación de computadoras": toda su noción de "programación sin ego" se trata de cómo ayudar a las personas a aceptar las críticas de su código a diferencia de las críticas de ellos mismos.

Malas prácticas de nombres: siempre inexcusable.

Y sí, no siempre asuma que su camino es mejor ... Puede ser difícil, pero debe mantenerse la objetividad.

He tenido una experiencia con un codificador que tenía un nombre de funciones tan horrible que el código era peor que ilegible. Las funciones mintieron sobre lo que hicieron, el código no tenía sentido. Y fueron protectores / resistentes a que alguien más cambiara su código. cuando se enfrentaron muy cortésmente, admitieron que tenía un nombre mal, pero querían conservar su propiedad del código y volverían y lo arreglarían "en una fecha posterior". Esto está en el pasado ahora, pero ¿cómo lidiar con una situación en la que el error es RECONOCIDO, pero luego protegido? Esto continuó durante mucho tiempo y no tenía idea de cómo romper esa barrera.

Variables globales: yo mismo no soy TAN aficionado a las variables globales, pero conozco a algunos programadores excelentes que les gustan MUCHO. Tanto es así que he llegado a creer que en realidad no son tan malos en muchas situaciones, ya que permiten claridad, facilidad de depuración. (por favor, no me llamen / denuncien :) :) Todo se reduce a, he visto muchos códigos muy buenos, efectivos y libres de errores que utilizan variables globales (¡no las he introducido yo!) y muchos errores, imposible de leer / mantener / corregir el código que utiliza meticulosamente los patrones adecuados. Tal vez ahí ES un lugar (aunque tal vez la reducción) para las variables globales? Estoy considerando repensar mi posición con base en la evidencia.

Inicie un wiki en su red utilizando algún software wiki.

Comience una categoría en su sitio llamada "mejores prácticas" o "estándares de codificación" o algo así.

Señale a todos a ello. Permitir comentarios.

Cuando realice lanzamientos del software, haga que la persona cuyo trabajo es poner el código en la compilación empuje a los desarrolladores, señalando las páginas Wiki en él.

Lo hice en mi organización y la gente tardó varios meses en acostumbrarse a usar el Wiki, pero ahora es este recurso indispensable.

Si tiene un estándar de codificación flojo, puede valer la pena señalar eso o indicar que no puede seguir el código porque no es el formato correcto.

Si no tiene un formato de codificación, ahora sería un buen momento para instalar uno. Algo parecido a las respuestas a esta pregunta puede ser útil: /programming/4121/team-coding-styles

Siempre voy con la línea 'Esto es lo que haría'. No trato de darles una conferencia y decirles que su código es basura, pero solo les doy un punto de vista alternativo que espero les muestre algo que obviamente es un poco más ordenado.

Haga que la (s) persona (s) en cuestión preparen una presentación para el resto del grupo sobre el código para un módulo representativo que hayan escrito, y deje que las Preguntas y Respuestas se encarguen de él (créanme, lo hará, y si es un buen grupo, ni siquiera debería ponerse feo).

Me encanta el código, y nunca tuve un curso en mi vida sobre nada relacionado con la informática. Empecé muy mal y comencé a aprender de los ejemplos, pero lo que siempre recuerdo y recuerdo siempre que leí el libro "Gang Of Four" fue :

"Todos pueden escribir código que es entendido por una máquina, pero no todos pueden escribir código que es entendido por un ser humano"

Con esto en mente, hay mucho por hacer en el código;)

No puedo enfatizar lo suficiente la paciencia. He visto este tipo de cosas exactamente completamente contraproducentes principalmente porque alguien quería que los cambios ocurrieran AHORA. Muchos entornos necesitan los beneficios de la evolución, no la revolución.Y al forzar el cambio hoy, puede crear un entorno muy infeliz para todos.

La aceptación es clave. Y su enfoque debe tener en cuenta el entorno en el que se encuentra.

Parece que estás en un entorno que tiene mucha "individualidad". Entonces ... no sugeriría un conjunto de estándares de codificación. Se dará cuenta de que desea tomar este proyecto "divertido" y convertirlo en un proyecto de trabajo altamente estructurado (oh, genial, ¿qué sigue ... documentos funcionales?). En cambio, como dijo alguien más, tendrás que lidiar con eso hasta cierto punto.

Sea paciente y trabaje para educar a otros en su dirección. Comience con los bordes (puntos donde su código interactúa con otros) y cuando interactúe con su código intente aprovecharlo como una oportunidad para discutir la interfaz que han creado y preguntarles si estaría bien si se modificara (por usted o ellos) Y explique completamente por qué quiere el cambio ("ayudará a lidiar mejor con los atributos cambiantes del subsistema" o lo que sea). No hagas tonterías y trata de cambiar todo lo que ves como incorrecto. Una vez que interactúes con otros en el límite, deberían comenzar a ver cómo les beneficiaría en el núcleo de su código (y si obtienes suficiente impulso, profundiza y comienza a discutir verdaderamente las técnicas modernas y los beneficios de los estándares de codificación). Si todavía no lo ven ... tal vez tú '

Paciencia. Evolución, no revolución.

Buena suerte.

Me pongo una toga y abro una lata de método socrático.

El método socrático que lleva el nombre del filósofo griego clásico Sócrates, es una forma de investigación filosófica en la que el interlocutor explora las implicaciones de las posiciones de los demás, para estimular el pensamiento racional e iluminar ideas. Este método dialéctico a menudo implica una discusión de oposición en la que la defensa de un punto de vista se enfrenta a otro; un participante puede llevar a otro a contradecirse de alguna manera, fortaleciendo el propio punto del investigador.

Muchas de las respuestas aquí se relacionan con el formato de código que en estos días no es particularmente relevante, ya que la mayoría de los IDE reformatearán su código en el estilo que elija. Lo que realmente importa es cómo funciona el código, y el póster es correcto para mirar las variables globales, copiar y pegar el código, y mi motivo favorito, convenciones de nombres. Existe un código incorrecto y tiene poco que ver con el formato.

Lo bueno es que la mayor parte es mala por una muy buena razón, y estas razones son generalmente cuantificables y explicables. Entonces, de manera no conflictiva, explique las razones. En muchos casos, incluso puede darle al escritor escenarios donde los problemas se vuelven obvios.

No soy el desarrollador principal de mi proyecto y, por lo tanto, no puedo imponer estándares de codificación, pero he descubierto que el código incorrecto generalmente causa un problema más temprano que tarde, y cuando lo hace, estoy allí con una idea o solución más limpia.

Al no intervenir en ese momento y adoptar un enfoque más natural, he ganado más confianza con el líder y, a menudo, recurre a mí para obtener ideas y me incluye en el diseño arquitectónico y la estrategia de implementación utilizada para el proyecto.

Las personas que escriben códigos incorrectos son solo un síntoma de ignorancia (que es diferente de ser tonto). Aquí hay algunos consejos para tratar con esas personas.

• La propia experiencia de la gente deja una impresión más fuerte que algo que dirás.
• A algunas personas no les apasiona el código que producen y no escuchan nada de lo que dices
• La programación por pares puede ayudar a compartir ideas, pero cambiar quién conduce o simplemente revisarán el correo electrónico en su teléfono
• No los ahogue con demasiado, he encontrado que incluso la Integración Continua necesitaba explicarse algunas veces a algunos desarrolladores mayores
• Haz que se emocionen nuevamente y querrán aprender. Podría ser algo tan simple como programar robots por un día
• CONFÍE EN SU EQUIPO, los estándares de codificación y las herramientas que los verifican en el momento de la construcción a menudo nunca son leídos o molestos.
• Eliminar la propiedad del código, en algunos proyectos verás silos de código o hormigueros donde la gente dice que ese es mi código y no puedes cambiarlo, esto es muy malo y puedes usar programación emparejada para eliminar esto.

En lugar de hacer que escriban código, haga que mantengan su código.

Hasta que tengan que mantener su pila humeante de espagueti, nunca entenderán lo mal que están codificando.

A nadie le gusta escuchar a alguien decir que su trabajo es una mierda, pero cualquier persona sensata agradecería la tutoría y las formas de evitar el trabajo innecesario.

Una escuela de enseñanza incluso dice que no debes señalar los errores, sino enfocarte en lo que se hace bien. Por ejemplo, en lugar de señalar que el código incomprensible es malo, debe indicar dónde es particularmente fácil de leer. En el primer caso, está preparando a otros para pensar y actuar como programadores de mierda. En el último caso, estás preparado para pensar como un profesional calificado.

Tengo un senario similar con los chicos con los que trabajo. No están tan expuestos a la codificación como yo, pero siguen siendo útiles para la codificación.

En lugar de que yo deje que hagan lo que quieren y regresen y editen todo. Por lo general, simplemente me siento y les muestro dos formas de hacer las cosas. A su manera y a mi manera, a partir de esto, discutimos los pros y los contras de cada método y, por lo tanto, llegamos a una mejor comprensión y una mejor conclusión sobre cómo debemos proceder con la programación.

Aquí está la parte realmente sorprendente. A veces, surgen preguntas que incluso yo no tengo respuestas, y después de la investigación, todos obtenemos un mejor concepto de metodología y estructura.

1. Discutir.
2. Muéstrales por qué
3. Ni siquiera pienses que siempre tienes razón. A veces, incluso ellos te enseñarán algo nuevo.

Eso es lo que haría si fuera usted: D

Probablemente un poco tarde después del efecto, pero ahí es donde un estándar de codificación acordado es algo bueno.

Francamente, creo que el código de alguien es mejor cuando es más fácil cambiar, depurar, navegar, comprender, configurar, probar y publicar (whew).

Dicho esto, creo que es imposible decirle a alguien que su código es malo sin tener que intentar explicarle qué hace o cómo se supone que alguien lo mejorará después (como crear una nueva funcionalidad o depurarlo).

Solo entonces su mente se rompe y cualquiera podrá ver eso:

• Los cambios en el valor de las variables globales son casi siempre imposibles de rastrear
• Las enormes funciones son difíciles de leer y comprender.
• Los patrones hacen que su código sea más fácil de mejorar (siempre que cumpla con sus reglas)
• (etc ...)

Quizás una sesión de programación en pareja debería hacer el truco. En cuanto a la aplicación de estándares de codificación, ayuda, pero están demasiado lejos de definir realmente qué es un buen código.

Probablemente desee centrarse en el impacto del código incorrecto, en lugar de lo que podría descartarse como su opinión subjetiva de si es un estilo bueno o malo.

Pregunte en privado sobre algunos de los segmentos de código "incorrecto" con miras a la posibilidad de que sea realmente razonable código (no importa cuán predispuesto esté), o que tal vez existan circunstancias atenuantes. Si todavía está convencido de que el código es simplemente malo, y que la fuente en realidad es esta persona, simplemente vaya. Puede suceder una de varias cosas: 1) la persona se da cuenta y toma alguna acción correctiva, 2) la persona no hace nada (es ajena o no le importa tanto como a usted).

Si el # 2 sucede, o el # 1 no resulta en una mejora suficiente desde su punto de vista, Y está dañando el proyecto, y / o lo está afectando lo suficiente, entonces puede ser el momento de comenzar una campaña para establecer / hacer cumplir los estándares dentro de el equipo. Eso requiere la aceptación de la gerencia, pero es más efectivo cuando se instiga desde la base.

Buena suerte con eso. Siento tu dolor hermano.