Desacuerdo con el líder del proyecto sobre estándares de codificación [cerrado]

Así que estoy trabajando en un nuevo proyecto junto con mi líder de proyecto durante el último año.

Inicialmente teníamos nuestros propios subproyectos que residían en repositorios de git separados, tuve poca interacción con su código, por lo que el olor del código no me molestó. Unos 6 meses después comencé a mantener y agregar características a su código, ya que estaba tomando un papel más importante en el proyecto.

Ahora que soy el desarrollador principal de ambos subproyectos (equipo a punto de crecer; él todavía está por encima de mí), estas cosas me molestaron y quise ocuparme de ellas, pero me rechazaron:

1. Sin llaves, funciones en mayúsculas, uso de comillas mixtas (doble y simple con lógica oculta), sin usar ===, clases enormes con funciones enormes. En pocas palabras, podría ser mejor.
2. Confianza en la opción de PHP para desactivar avisos / advertencias. El código está lleno de usos no verificados de variables y claves de matriz. Las variables se definen dentro de ifs.

Argumentos a los 2 temas anteriores:

1. No querer imponer un estilo de codificación en las personas.
2. Considerado como una función de lenguaje, que se presta a un código más corto / más eficiente.

Creo que se deben tener algunas reglas y el código debe ser defensivo. Ofrecí usar la configuración predeterminada de PHPStorm para el formateo, usar llaves y una convención de nomenclatura aceptada por la comunidad.

Quiero alinear ambos proyectos para usar las mismas pautas, ya que son inseparables.

¿Estoy equivocado? ¿Impongo mis preferencias personales?

Si puede presentar un argumento sólido de por qué el suyo es mejor (y qué problemas principales pueden surgir al usar el suyo), entonces no está imponiendo preferencias personales, creo, sino que está tratando de establecer un proyecto para el éxito.

Si él puede hacer un caso más fuerte de por qué el suyo es mejor y qué tipo de problemas evitará que el tuyo no pueda, entonces te tiene engañado.

La gerencia superior decente debería poder ver el mérito en eso, pero esos son los puntos que les interesarán (y deberían): no si es más fácil para los desarrolladores o "no quieren obligar a todos a trabajar como un robot" (que es un punto ridículo, pero no lo use como un punto de dolor para la administración superior). Deben (deberían) preocuparse por la estabilidad continua del proyecto.

Por mi comentario anterior:

Si él es el líder del proyecto, eso parece implicar que es básicamente su decisión.

Ese fue mi pensamiento. Si desea cambiar el estándar pero no se está moviendo, a) descubra cómo superarlo, b) vaya a otro lugar a trabajar, o c) pruebe las pequeñas cosas que podría hacer sin irritarlo. demasiado.

Superarlo solo funcionará si presenta un argumento sólido sobre por qué debería haber mejores estándares.

Básicamente:

• que no lo hace al igual que su estilo de codificación. Ese es tu derecho.
• él lo encuentra bien tal como está y encuentra que pasar días / semanas / más simplemente ajustando el estilo es una pérdida de tiempo . Ese es su derecho.

Ponte en su lugar. ¿Cuáles son los beneficios de su esfuerzo, además de costarle mucho dinero a la empresa (su salario)? ¿Siempre es tan quisquilloso? ¿No ve que hay cosas más importantes que hacer ahora?

Básicamente, debe encontrar algún tipo de compromiso con el que pueda vivir, o su relación se volverá amarga. También depende mucho de cómo te comuniques con él. Pon tu ego a un lado e intenta ser útil ... porque finalmente le preguntas cosas que te gustaría, no algo en lo que él esté interesado. En otras palabras, le estás pidiendo un favor .

También a menudo depende de cómo lo pidas. Ejemplos:

Lo que quieras:

haciendo el código más bonito

Que no decir:

tu código apesta como es

Qué decir:

Realmente lo agradecería si pudiera hacer que ambos proyectos sean consistentes, solo lo básico, y solo me llevará un día.

Lo que quieras:

no más advertencias no verificadas

Que no decir:

tu código apesta como es

Qué decir:

Sé una forma rápida de deshacerme de esto y de esa advertencia. Luego, al volver a habilitarlos, podríamos detectar más rápidamente si algo podría romperse en el futuro.

Y por último:

Sé que no es una prioridad. Así que con mucho gusto puedo hacerlo una vez que las cosas de alta prioridad estén fuera de la mesa primero.

O, si eso no funciona o si tienes una mala relación con él, considera irte. Si no puede resolver las cosas ahora, es poco probable que mejore en el futuro ... y deje de lado su ego.

Nota al margen

Creo que es más común que las personas mayores sean más indulgentes. Saben que el código será destruido en una década o dos de todos modos (porque la tecnología cambia, las API también, los equipos, los socios comerciales, los requisitos, las decisiones globales, lo que sea ...). Tienen menos ego y se centran en que funcione en lugar de ser perfecto. Aunque tiendo a la perfección, no puedo culparlos.

Esto probablemente será controvertido pero ...

Hablamos y acordamos estar en desacuerdo y escalarlo a la alta gerencia

Nunca. Nunca. Hacer. Esta. NUNCA. Cada vez que haces esto, todos nos retrasamos una década. Así es como se desarrollará esto:

• Gerente senior 1: "Se nos ha pedido que abordemos este problema, bla, bla, bla, algo sobre los estándares de codificación y la pérdida de tiempo".

• Gerente senior de 2: "Y están pidiendo a nosotros para resolver sus guerras empollón de césped porque?"

• Gerente Senior 3: "¿Porque son bebés llorones que no pueden comunicarse y no les importa / entienden cuál es el valor comercial? *"

• Gerente senior 2: "Eso debe ser. ¿Quién está preparado para el golf?"

Luego viene el tiempo de revisión de desempeño de usted y su jefe:

"[Gerente superior de su jefe]: lo siento, pero hay cierta preocupación de que no pueda administrar sus informes directos y que no esté siguiendo las mejores prácticas (aunque no tengo idea de lo que hace, excepto escribir algunos mumbo jumbo eso hace que el software funcione) "

"[Gerente principal para usted]: lo siento, pero hay cierta preocupación de que no se relacione bien con sus compañeros y tenga problemas para seguir las instrucciones de su supervisor inmediato".

Y es por eso que en su mayoría estamos mal pagados en comparación con el valor que creamos. **

Debe A) superarlo o B) pasar a una tienda que tenga los estándares ajustados un poco más a su gusto. FWIW, haría B (y espero pasar a un lenguaje que no permita tales atrocidades). Pero nunca escale una disputa técnica a las demandas a menos que implique algo ilegal o potencialmente catastrófico (gran agujero de seguridad). Simplemente molesto no es suficiente ***.

* Por el bien de las personas que leerán esto y entenderán mal, no estoy diciendo que el OP y su jefe sean así (me doy cuenta de que la calidad / legibilidad del código tiene un impacto directo en el resultado final del negocio), estoy diciendo que serán percibidos así por la gerencia no técnica.

** Para las personas que piensan que mi retrato de la alta gerencia como un problema sin idea no es realista, comprendan que los gerentes se preocupan (idealmente) por manejar a las personas de la manera en que nos preocupamos por administrar el código. Es posible que no tengan idea de los asuntos técnicos, pero conocen a las personas, y esa es una razón más que les lleva a una disputa que A) probablemente no están calificados para resolver y B) posiblemente ustedes dos deberían haber podido resolver sin ayuda te hace quedar mal.

*** Sí, me doy cuenta de que la deuda técnica puede acumularse hasta el punto de hundir el negocio. Simplemente no creo que las llaves se salven (dicho esto, nunca omito las llaves y prefiero que otras tampoco).

En mi humilde opinión, te enfrentas a un desarrollador 'está funcionando', no uno que se preocuparía por el próximo que vaya tras ellos. Sus argumentos simplemente no valen nada.

Todo lo que dices sobre su código es pura pereza de su parte. Tener proyectos que sigan el mismo estándar de codificación se trata de rigor. No eres robots; ustedes son ingenieros; Se supone que eres riguroso.

Con algunos ejemplos, podría señalar que le está costando seguir la lectura de su código, y eso es una gran pérdida de productividad para usted, pero no tengo una idea real de cómo llevarle eso.

Pero es probable que te responda que algo es el tono:

Está funcionando, no tiene sentido cambiar

Mi consejo: si es realmente contundente y no quiere encabezar nada, déjalo ir. Espere a que ocurran errores / errores / evolución en su proyecto. Cuando llegue, solo arregle y reescriba la parte del código modificada / agregada de manera adecuada; no vayas a decirle nada al respecto. Él no te impondrá su estilo de codificación, ya que no eres un robot de todos modos ...

Cuando trabajas en un proyecto, tienes que establecer prioridades.

La prioridad # 1 es llevarse bien con sus compañeros de trabajo. La prioridad # 1 es seguida por una gran brecha. Luego vienen las prioridades para cosas como el código que funciona, se puede probar, probar, documentar, mantener, etc. Luego viene otra gran brecha y luego vienen los estándares de codificación.

Y cambiar el código existente para cumplir con los nuevos estándares de codificación es realmente bajo en la lista de prioridades.

PD. "Microoptimización" frente a "computadoras súper rápidas": argumento totalmente erróneo. El argumento en contra de la microoptimización no es que las computadoras sean rápidas, el argumento es que el tiempo perdido en las microoptimizaciones significa que no tiene tiempo para obtener ahorros reales .

PD. Si solo le toma un día hacer cambios que hagan que el código se vea mejor para usted, pero moleste a su compañero de trabajo y lo convierta en un enemigo, entonces perdió un día en algo que es contraproducente.

PHP no es el grupo más elitista en nuestra profesión. En realidad, estás criticando su sistema de software probablemente difícil de ganar. Su nivel profesional es más alto que el suyo.

Entonces, si no tiene margen de maniobra para mejorar el código bajo sus responsabilidades, existe una única solución: seguir adelante .

No sé sobre el mercado PHP actual en su lugar, pero es posible que primero se diversifique un poco. Aprenda un poco de lenguaje publicitario o un nicho como C #.

Es posible que no obtenga un trabajo tan bueno, pero llegará más lejos, profesionalmente. Así que ten paciencia y estudia un poco. Dinero seguro. Luego, solicite un margen de maniobra en sus proyectos, o tome una oferta de trabajo.

Me resulta difícil creer que el # 1 sea su verdadera razón para no querer cambiar los estándares de codificación. Si posee la base de código, debería poder aplicar cualquier estándar de codificación que usted (y los otros desarrolladores) acepten. Si logra un consenso con los otros desarrolladores (suponiendo que el líder ya no está haciendo ningún trabajo de desarrollo), entonces no hay razón para que realmente se preocupe, excepto por este:

¿Corregir el estilo de la base del código es el mejor uso de tu tiempo en este momento?

Estoy seguro de que tienes entregables. ¿Cuánto tiempo costará revisar y mejorar el estilo en todas partes en la otra base de código? ¿Qué pasa si introduce errores al corregir el estilo incorrectamente? Del tío Bob:

Por supuesto, el código incorrecto se puede limpiar. Pero es muy caro. Como el código se pudre, los módulos se insinúan entre sí, creando muchas dependencias ocultas y enredadas. Encontrar y romper viejas dependencias es una tarea larga y ardua.

Mejorar un estilo de código como este casi nunca es un buen uso del tiempo como elemento de sprint independiente . La forma en que me gusta hacer este tipo de mejoras es lo que llamo la "Política del Buen Vecino": no andes arreglando todo el estilo y la estructura lógica que puedas encontrar, porque probablemente inviertas todo el tiempo que quieras y aún lo harás No se haga. En cambio: cada vez que realice un cambio en una parte del código, arregle el estilo mientras esté allí y déjelo mejor de lo que lo encontró. Si tiene dificultades para implementar una función porque el código está mal diseñado, corrija el estilo para desbloquearse en lugar de golpearse la cabeza contra él.

De esta manera, cada cambio:

1. Tiene una motivación comercial además de la motivación del perfeccionismo técnico.
2. No será visto como una gran inversión de tiempo (¡porque no lo es!)
3. Establecerá buenos hábitos estilísticos precisamente porque usted y su equipo lo están haciendo con el tiempo.
4. No presentará un gran riesgo para la base del código porque no está cambiando demasiado a la vez

Dentro de unos meses mirarás hacia arriba y notarás que el "paquete terrible" ya no es tan malo y tu jefe verá que su equipo está más feliz. Pero debido a que no fue una confrontación directa, ya se habrá hecho, y no tendrá nada de qué quejarse porque no perdió el tiempo (en su mente) al agregar un gran proyecto de refactorización a la lista de tareas pendientes. Probablemente nunca te dirá que tenías razón, pero ese no es el objetivo de todos modos (¿verdad?).

Haga estas preguntas sobre su plomo.

• ¿Están acostumbrados a trabajar solos o con un equipo muy pequeño?
• ¿Se han codificado principalmente en esta tienda?
• ¿Están acostumbrados a tomar las decisiones?
• ¿Están acostumbrados a "simplemente hacerlo"?
• ¿Escribieron la mayor parte del código?

Si las respuestas son "sí", entonces voy a pintar una imagen de un tipo particular de programador principal. Si coincide con lo que has experimentado, tal vez te ayude a entrar en su cabeza. Si no, ignora esta respuesta .

Este es alguien que ha estado allí desde el primer día, ha pasado años en el mismo trabajo trabajando en la misma base de código, está acostumbrado a salirse con la suya y no tiene mucha experiencia con otras formas.

No consideran a otras personas cuando escriben código, ya que todo tiene sentido para ellos. Por supuesto que sí, lo escribieron o han pasado años entendiéndolo.

Consideran que el estilo de codificación es una preferencia personal, no una herramienta para reducir el mantenimiento y los errores. Cuando discutan sobre el estilo de codificación, tendrán dificultades para escuchar sus argumentos porque probablemente nunca hayan pensado mucho sobre por qué hacen las cosas a su manera. Lo que oirán es "Quiero hacerlo a mi manera" o "Quiero hacerlo a la nueva, elegante y moderna moda".

Están establecidos en sus caminos. Debido a que lo han estado haciendo de la misma manera durante tanto tiempo, todas sus herramientas y editores y su cerebro están microconfigurados según su estilo. Cualquier desviación de este estilo entrará en conflicto con esta forma de trabajo cuidadosamente arreglada, pero muy frágil. Los intentos de cambio generarán quejas sobre su editor, herramientas, la forma en que les gusta trabajar o si es "difícil de leer". Rechazan el cambio porque se han enredado tanto en el statu quo que no pueden cambiar.

Este es alguien que nunca ha aprendido correctamente la ingeniería de software y la arquitectura de software. Simplemente golpean juntos lo que funciona.

Tienes un problema de personas, no tecnológico.

Tendrá que volver a capacitar a su líder o tendrá que renunciar.

Ir a la gerencia es el último recurso . Tanto por las razones que señaló @JaredSmith como porque perderás. Este tipo ha pasado años ganando dinero para ellos. Él escribió su compañía. Él se apagó en numerosos incendios. Para ti es un chef vaquero haciendo espagueti. Para ellos es un héroe que construyó y salvó a la compañía.

Para volver a entrenar tendrás que ...

• Gana su confianza.
• Averigua cómo piensa.
• Abordar sus temores sobre el cambio.
• Hacer el cambio más fácil.
• Muestre cómo esto es mejor para él .

Toma en serio su estilo y métete en su cabeza. Pregúntale al respecto. ¿Por qué hace las cosas como lo hace? ¿Qué ve él cuando lo lee? ¿Cómo interactúa con sus herramientas? ¿Cómo se mueve a través del código? Conocer todas estas cosas le permitirá comprender y abordar sus objeciones.

Encuentra la raíz objetiva de sus objeciones subjetivas, hazlas procesables. "Es difícil de leer" es subjetivo y no le brinda información. No puedes hacer nada al respecto. "Soy daltónico y el resaltado de sintaxis no funciona" es objetivo, le brinda información y puede hacer algo al respecto. Recomendaría un libro llamado Getting To Yes para obtener más información al respecto.

Una vez que llegue al problema raíz, el problema real que está experimentando, vea si puede solucionarlo o mitigarlo. Entonces no es un problema. Probablemente todavía tendrán problemas emocionales con el cambio, pero al menos ya no pueden argumentar que es un problema real.

Hazlo un poco a la vez. Es alguien que lo ha estado haciendo de la misma manera durante años. Está acostumbrado a ver ciertos patrones en el código y a usarlos para comprenderlo. Cambiar de repente todos esos patrones será confuso. Tan frustrante como será ponerlos al día lentamente con buenas prácticas conocidas, tienes que guiarlo a través de él.

Aboga por un estilo comunitario estándar. Esto elimina el argumento de que se trata de preferencias personales y ejerce presión sobre ellos para justificar por qué su estilo diferente es mucho mejor. Si planea contratar personal, facilita la integración de nuevos empleados.

Abogar por el estilo de código automatizado. Haga que siguiendo el estilo correcto presione un botón. Use una herramienta que comience con un estilo estándar, le permita configurarla a su gusto y pueda cambiar el estilo del código con solo presionar un botón. Hacer que el estilo sea lo más fácil posible elimina muchos argumentos sobre lo difícil que será seguirlo. Pueden codificar como quieran, y cuando terminan, presionan un botón y sigue un estilo que otros pueden leer.

Dado que esta persona no tiene la mentalidad de pensar en los demás, tendrá que mostrar cómo estos cambios los benefician. Puede ser tan simple como "dado que este es el estándar ahora, no tendrás que volver a luchar con la próxima persona que contrates". O puede ser "si tenemos pruebas, puede ser más agresivo al cambiar el código y preocuparse menos por cambiar las cosas". O "si hay buenos documentos, la gente no tendrá que molestarte con preguntas sobre cómo funciona el código". Para que esto sea efectivo, tendrá que saber lo que quieren: a algunas personas les gusta que las molesten, les hace sentir importantes.

Es un largo, largo camino. Tendrá que decidir si tiene la paciencia para administrar y volver a capacitar a su jefe. Piense en usted más como su maestro que como su subordinado frustrado, y podría sentirse mejor al respecto.

¿Estoy equivocado?

No conozco PHP, por lo que no puedo emitir un juicio directo, pero supongo por el argumento de que su estilo de codificación preferido es "mejor" que el código que ha encontrado, ya que el suyo está más en línea con herramientas automatizadas existentes.

Entonces no está equivocado al sugerir mejoras al estilo de codificación.

En pocas palabras, no es el código con el que quiero trabajar

Puede estar equivocado al negarse a trabajar con un código que no cumpla con sus estándares preferidos, pero solo en la medida en que al trabajar para la compañía acordó trabajar con su código en primer lugar. En última instancia, no es "incorrecto" renunciar a su trabajo si le exige algo que no es de su agrado, ya que ese es su derecho, y como resultado podría encontrar un trabajo mejor.

¿Impongo mis preferencias personales?

No. Él es el líder del proyecto y tú no. Es su decisión, aunque en este caso está "delegado hacia arriba".

También podría haber decidido delegar hacia usted, como desarrollador principal de los subproyectos, y darle la libertad de establecer los estándares de codificación para esos subproyectos y colegas que trabajan en ellos en el futuro. Pero por cualquier razón, él siente que no debes estandarizar. Incluso si está equivocado sobre el estilo de codificación, no puede esperar reclamar una autoridad que no le ha permitido.

Sin embargo, dado que dice "No me gusta aplicar estilos de codificación", al menos puede escribir código nuevo en su estilo preferido (y lo ha hecho). En última instancia, esto podría generar oportunidades para demostrar los beneficios objetivos de su estilo. Ese sería un buen momento para intentar por segunda vez presentar su caso.

También puede (creo) pedir razonablemente a las personas que editan archivos, que lo hagan en el estilo en que el archivo ya está escrito. Eso le permite mantener los estándares en los archivos que escribió. Desafortunadamente, la otra cara de esto es que tendrías que editar los archivos que escribió en algo similar a su estilo.

Incluso suponiendo que tenga un conjunto de pruebas realmente bueno y, por lo tanto, pueda refactorizar con relativa seguridad, todavía hay razones (ciertamente bastante marginales) para no abrir y cambiar el estilo de archivos completos. La principal es que es una pesadilla tratar de fusionar, reordenar o revertir los cambios realizados antes y después de un gran cambio estructural. Pero bien puede ser que en este proyecto en particular casi nunca ocurra.

[Mi gerente dice que no le gusta] imponer estilos de codificación a las personas [porque] no somos robots.

¿Alguna vez se ha preguntado por qué no solo descartamos el código fuente después de compilarlo y pasar todas las pruebas? El código fuente es para humanos y no solo para humanos, sino también para leer .

Tarde o temprano, alguien tendrá una razón para regresar y leer el código. Tal vez necesiten cambiarlo, tal vez documentarlo, tal vez reutilizarlo. Lo que sea. Va a suceder, y el código será mucho más fácil de leer y trabajar si todo está en un estilo consistente.

Incluso un mal estilo es mejor que ningún estilo.