c++ - tercera - ¿Cómo lidiar con el mal estilo/prácticas de codificación de los adultos mayores?

preguntas cerradas para adultos mayores (13)

Soy nuevo en el trabajo, pero la empresa en la que trabajo contrata a una gran cantidad de personas no científicas que son lo suficientemente inteligentes como para hacer el trabajo (complejo) pero que carecen del estilo y las prácticas que deberían ayudar a otras personas a leer su código.

Por ejemplo, adoptan C ++, pero siguen utilizando las funciones de la página C-like 3 que vuelven locos a las nuevas personas cuando intentan leer eso. También nos sentimos muy arriesgados al cambiarlo, ya que nunca es fácil estar seguro de que no estamos rompiendo algo.

Ahora, estoy involucrado en el proyecto con estos muchachos y no puedo cambiar la base de código completa o diseñar para que el código se vea bien, ¿qué puedo hacer en esta situación?

PD: en realidad tenemos funciones de 3 páginas y, como no tenemos un concepto de diseño, todo lo que podemos hacer es asumir lo que podrían haber pensado, ya que no hay manera de saber por qué está diseñado de la forma en que está.

No me estoy quejando. Estoy pidiendo una sugerencia, ya estoy leyendo algunos libros para resolver los problemas Pragmatic Programmer ; Diseño de parte de B.Stroustrup ; Programación y principios por B.Stroustrup ;

Así es como es, acostúmbrate o abandona y encuentra un lugar donde no sea así. Serás marginado si criticas sus esfuerzos y pueden sentirse amenazados si de hecho escribes tu propio código, mejora o mejora el de ellos. Al final del día, entregan el código y la administración ve una caja negra que funciona y eso es todo lo que importa. Además, serás un niño más de la universidad que cree que sabe algo sobre el desarrollo de un negocio y se rió y se negó cuando no estaba cerca. Honestamente, muchas veces estos sistemas se construyen de esta manera debido a requisitos inestables, muchas funcionalidades conectadas con el tiempo y la falta de respeto de las administraciones por un proceso de desarrollo de software estable.

No todas las empresas son así. Empezaría a buscar un nuevo trabajo para ser honesto.

El presente está incorporado en el hexagrama 47 - K''un (Opresión): a pesar del agotamiento, todavía puede haber progreso y éxito. Para el firme y correcto , el gran hombre, habrá buena fortuna. Él no caerá en ningún error. Si él hace discursos, sus palabras no se pueden hacer buenas .

El futuro está incorporado en el hexagrama 6 - Cantado (Conflicto): Aunque hay sinceridad en la disputa de uno, aún se encontrará con oposición y obstrucción . Si aprecia una precaución aprensiva , habrá buena fortuna. Si él procesa la disputa hasta el final amargo, habrá maldad. Será ventajoso ver al gran hombre. No será ventajoso cruzar la gran corriente.

Espero fervientemente, esta es la mejor oportunidad para crecer al enfrentar el desafío. Como dijo Robert, intente liderar con el ejemplo. Si es posible, permítales adoptar su patrón.

Esta es la razón más básica por la que es una buena idea establecer estándares de codificación y procesos de revisión de código.

No escribiré funciones de tres páginas sin importar qué estándares de codificación y procesos se establezcan, pero algunas personas lo harán. Crearán 20 variables locales al principio, sin inicializar ninguna de ellas. Tendrás punteros y enteros con valores no especificados. No sabrás el significado exacto y el alcance de cada variable. Etcétera etcétera.

Trate de convencer a su gerente y, luego, a su equipo, con argumentos sólidos. Tal vez podría comenzar con una lectura compartida de los estándares de codificación C ++ o C ++ vigentes . Intente enfatizar el punto de que, al trabajar de esta manera y crear un mejor código, todos ganan. Si ven esto como una situación de ganar-ganar, estarán más abiertos al cambio.

Lo mejor y más importante que puedes hacer es predicar con el ejemplo . Hacer las cosas de la manera correcta y tratar de mejorar las cosas lentamente. No vas a arreglar nada de la noche a la mañana.

Asegúrese de que cada pieza de código de la que usted es responsable sea mejor una vez que haya terminado con él. Con el tiempo, el sistema será tangiblemente mejor gracias a sus esfuerzos.

Después de crear una sólida reputación con sus compañeros de trabajo, intente comenzar algunas revisiones de código o sesiones de entrenamiento durante el almuerzo para que todos estén al tanto de las mejores maneras de hacer las cosas.

En pocas palabras: será difícil y frustrante, pero es posible. Buena suerte.

No estas solo. Yo también me enfrenté recientemente, por suerte contamos con el apoyo de la alta gerencia para revisiones de código. 1. Incluso un solo cambio de línea para la corrección de errores debe revisarse en línea.

Los comentarios sobre el código pueden clasificarse como CodingStandard / Suggestion / Clarification / Major / Minor, etc.
Mientras da comentarios a senior, puede comenzar con Clarification / CodingStandard en lugar de Major

Puede abordar el tema de "tenemos miedo de tocarlo por temor a romperlo" escribiendo pruebas de unidad exhaustivas. Una vez que haya realizado las pruebas de la unidad, será liberado para refactorear a voluntad. Si sus pruebas de unidad aún pasan después de la refactorización, puede estar seguro de que no ha roto nada.

Puedo empatizar

Estoy por debajo de dos programadores senior que tienen estilos muy únicos que me parecen frustrantes. Tenemos un código que consta de una función principal de 1000 líneas de longitud. (Eso no es un error tipográfico). Nuestros estándares de codificación desalientan a los globales, por lo que hacemos de cada programa un objeto de aplicación. Ahora nuestros globales son variables miembro! Cuando necesitamos una interfaz de iteración para las clases de C ++, ¿por qué deberíamos usar las convenciones begin , end y operator++ , cuando First , AtLast , y Next pueden usarse en su lugar? Hemos envuelto bibliotecas de terceros en interfaces personalizadas sin ningún motivo. (Hemos incluido log4cxx y la funcionalidad perdida sin ninguna razón que pueda decir, y una de nuestras clases de fecha consiste en un puntero compartido a un objeto boost :: date con una fracción de la funcionalidad).

Así es como he mantenido mi cordura. Me he centrado en los nuevos lenguajes y herramientas. Este es el primer proyecto de nuestra compañía que involucra a Python, y pasé mi tiempo escribiendo utilidades y programas allí. Mientras los programadores de alto nivel codifican con lo que están familiarizados, tengo casi la rienda libre de todo el código Python. No podía soportar las API de C ++ que usamos, así que duplicé la mayoría de las mismas funciones en Python de una manera mucho más amigable, y los otros desarrolladores también lo prefieren.

Del mismo modo, tenemos poca familiaridad con log4cxx y menos con boost-build, los cuales me he tomado el tiempo de estudiar en profundidad y saber lo suficiente como para que las personas acudan a mí con preguntas. He escrito un puñado de recursos en nuestro wiki con sugerencias de uso para log4cxx y numpy y otras herramientas.

Ser entusiasta de codificar correctamente es un buen rasgo que posee y en la industria del software siempre nos encontraremos con otros desarrolladores que escriben códigos que no están en línea con nuestra "manera perfecta" de codificación. Esto nunca debe interpretarse como código basura , o codificadores ineptos , porque todos comenzamos así en alguna forma o forma.

Siempre respeta a tus compañeros a tu alrededor como quieres que te respeten a ti. Ciertamente, no es fácil hacerlo en un entorno que tiene mucho que ver con el ego, pero intentar abordar un tema como este nunca es fácil.

Es como te comunicas

Pruebe diferentes ángulos de enfoque, recuerde que está allí para aprender tanto como para prestar un servicio.

Por lo tanto, comentar sobre el estilo de código "pobre" en un enfoque "en su cara" podría no ser el resultado que estaba buscando. Entonces, retroceda un poco y trate de abordar el tema con "Estaba considerando el estilo de código utilizado y tengo algunas sugerencias ..." y vea la diferencia que esto da.

Donde trabajo ahora, lo único que aprendí es que está bien comentar algo que podría no ser de buena calidad, pero entonces es mejor que tenga una mejor solución para presentar.

En otras palabras, prepárese para respaldar sus palabras con soluciones útiles y no porque se sienta así.

Si eres un desarrollador junior, entonces lo único que puedes hacer es escribir el código de la manera más elegante y legible posible.

Si su estilo es realmente mejor, otras personas lo notarán y dirán "hey, deberíamos adoptar esta fórmula".

Las acciones hablan más que las quejas, que es algo que noté.

Simplemente coloque una copia de "Clean Code" (Martin), "Refactoring: Mejorando el diseño de un código existente" (Fowler) o "Effective C ++" en algún lugar de la oficina donde las personas puedan comenzar a navegar por los libros. A partir de ahora, se correrá la voz. En serio, nunca es tarde para aprender! ;)

Tu mejor apuesta es NO manejarlo en absoluto. Aquí hay problemas potenciales si lo intentas:

Se lo criticará por hacer algo que no le dijeron (hace que las evaluaciones de desempeño sean realmente malas).
Tendrás menos tiempo para hacer tu propio trabajo.
No avanzará en su carrera limpiando el código de trabajo; si no está roto, no lo toque.
Nunca hagas enemigos con personas que controlan tu carrera, lo que implica sin querer que son idiotas obsoletos que no ayudan a tu causa (especialmente en una mala economía).

Enfócate en hacer tu propio código genial. Luchar contra un código mal escrito es parte del mal de ser un ingeniero de software. Usted está en la profesión equivocada si no lo va a defender.

Un poco fuera de lugar, pero importante: es posible que deba cambiar de trabajo o equipo si es posible una vez que la economía se recupere. La mezcla con un camión de codificadores malos que no se molestan en actualizar sus conocimientos y prácticas debilita sus propias habilidades de programación y debilita su capacidad de comercialización.

Yo estaba en los mismos zapatos antes. Me contrataron como programador de C ++ para ''liderar el equipo'' sobre cómo usar C ++ por un gerente entusiasta. Eso fue hace aproximadamente una década. Algunos de los ingenieros más nuevos me querían, los mayores me despreciaban. Nuestro sistema era básicamente un sistema pseudo-C ++. Era como C con las clases, pero parecía que la gente ni siquiera entendía la utilidad de las cosas como constructores, ya que apenas aparecían.

Te quejas de funciones de 3 páginas; teníamos funciones que eran 8000 líneas llenas de saltos largos, lanzamientos de punteros de función, etc. Uno de los seniors incluso formateó el código con sangrías de 2 espacios para que los bloques anidados super profundos puedan escribirse sin usar mucho espacio horizontal ya que los seniors parecían Ser alérgico a funciones de redacción y programación procesal en general. Alguien incluso incorporó una función de línea 2000 pensando que haría las cosas más rápidas. Puede que estés tratando con un código malo, pero yo estaba lidiando con el código de copiar y pegar más horrible que puedas imaginar.

Desafortunadamente yo era muy joven y arrogante. No me llevé bien con los adultos mayores, luché contra ellos en batallas territoriales sobre el código. Respondieron creando estándares de codificación que ningún programador de C ++ podría seguir (por ejemplo, está bien usar un operador nuevo, pero no usa el manejo de excepciones, no usa constructores o destructores, etc.). Como resultado, escribí el código de C ++ de solución de estándares más extraño y estúpido solo para ser un poco rebelde contra esos estándares, ya que me negué a escribir código de estilo C debido a la razón por la que fui contratado (no odiaba tanto a C, pero al escribir El código C no formaba parte de la descripción del trabajo: fui contratado esencialmente como consultor en C ++), aunque los estándares hicieron que la codificación de estilo C fuera la única forma práctica de hacer las cosas. Solo mantuve mi trabajo porque hice muchas horas extras para asegurarme de que mi código funciona muy bien a pesar de estos estándares de codificación ridículos.

No fue hasta años más tarde, cuando otros empezaron a ver las cosas a mi manera, levantamos los estúpidos estándares y comenzamos a escribir códigos C ++ más naturales y fáciles de leer con STL y potenciamos las golosinas, RAII, manejo de excepciones, etc. Eso aislaron a los adultos mayores que se negaron a escribir el código de una manera más sana y finalmente se vieron obligados a adaptarse.

En retrospectiva, podría haber hecho las cosas mucho mejor. Los estudiantes de último año tenían la intención de no permitirme que me pusieran en una posición de profesor, pero creo que me habría expresado mucho más rápido con la cabeza gacha. El mayor arrepentimiento que tengo es tratar de evitar los estándares de codificación imposibles de rebelar, en lugar de corregirlos mediante discusiones claras y racionales. Como resultado, tengo un código C ++ realmente estúpido y ofuscado en el sistema que la gente me atribuye, aunque no es así como normalmente escribo el código C ++. Los desarrolladores habituales con los que trabajo entienden esto, pero los seniors todavía lo señalan como un ejemplo de por qué C ++ es malo.

En resumen, te recomiendo que te concentres en hacer más amigos en lugar de enemigos . Tus amigos te apoyarán, y si tu camino es mejor y puedes demostrarlo claramente, puedes aislar a los pocos que nunca estarán de acuerdo.