Ayudar a alguien que no es y nunca será un programador profesional a escribir código que sea más legible y utilizable para usar e interpretar [cerrado]

Soy Elvis, tratando mucho de aprender a ser Einstein. Yo trabajo para Mort.

¿De qué demonios está hablando este loco idiota? (Solo necesita leer los primeros párrafos)

Si no tiene ganas de leer ese enlace, básicamente, soy un programador profesional y mi jefe es (esto es terriblemente preciso):

el programador profesional de línea de negocio que carece de un título en ciencias de la computación pero que está muy familiarizado con Office y VBA, y que normalmente escribe aplicaciones de productividad compartidas entre sus compañeros de trabajo

Dicho todo esto, una gran parte de mi trabajo consiste en tomar su código improvisado y prepararlo para la producción. Sin embargo, el estilo muy pobre y el culto a la carga lo hacen difícil. Esto se ve agravado por el hecho de que no está dispuesto a leer libros de programación o permitirme ayudarlo a refactorizar su código.

¿Existen otras estrategias para ayudar a alguien que no es un programador profesional, nunca será un programador profesional escribir código en el futuro que sea más legible y utilizable para que yo lo use e interprete?

Al mirar sus respuestas en varios de los comentarios, no sé si se da cuenta de que lo que está experimentando es bastante común, especialmente cuando trabaja en campos especializados donde se necesitan expertos en dominios (llamémoslos científicos) para descubrir cómo incorporar y adaptar algoritmos para los problemas en cuestión.

En lugar de quejarse del científico y esperar que cambien, solo tenga en cuenta que no debe esperar que al científico le importe mucho la "calidad del código". Con frecuencia es difícil lograr que otros desarrolladores de software se preocupen por la "calidad del código" y mucho menos por alguien cuyos intereses principales se encuentran en el dominio y no en la programación.

Adónde va desde aquí depende en gran medida del grado de confianza que el "científico" tenga en su capacidad para comprender su trabajo. Si tienen confianza en que puedes entender su código y no lo arruinarán cuando modifiques las cosas, entonces generalmente no hay problema. Confiarán en su experiencia.

Sin embargo, si el científico no quiere que cambie su código, es muy probable que aún no se haya "ganado" su confianza. Si ese es el caso, en lugar de enfocarse en arreglar al científico, debe enfocarse en "arreglarlo" usted mismo. Lo que quiero decir con eso es tomar medidas para ganar su confianza. Probablemente la forma más fácil de hacer esto es la siguiente:

Como parte de su proceso de prueba:

1. Comience a convertir los algoritmos en algo más fácil de entender (por ejemplo, diagramas, PDL, notación matemática)
2. Aprende a entender los algoritmos.
3. Asegúrese de identificar los casos extremos.
4. Pregúntele al científico si su representación "alternativa" simplificada es correcta
5. Y MÁS IMPORTANTE, identifique los problemas que encontró; Y sin sonar "acusatorio" decir algo como "Estaba mirando el algoritmo y noté que XYZ se supone que debe hacer esto o se supone que debe hacer eso". Nada ganará su confianza mejor que esta bala.

Una vez que comience a encontrar errores Y haya demostrado interés en su área de interés, las probabilidades serán mucho más altas que, al menos, le permitirán comenzar a modificar el código para hacerlo más "profesional". Con frecuencia, ni siquiera sentirán la necesidad de codificar un prototipo por más tiempo. Simplemente escribirán algo en una de esas anotaciones "alternativas" que les ha enseñado (sin que ellos se den cuenta) y tendrán la confianza de que sabrá lo que significan.

Por supuesto, mi primer intento sería ofrecer algunas sugerencias sobre cómo el científico podría ayudar mejor a "comunicarse" mejor para ayudarlo; Pero parece que lo has intentado. Entonces, el único paso sobre el que tienes control es lo que haces. Gana su confianza y casi siempre el experto en dominios se sentirá aliviado de pasar la codificación a otra persona y no tener que preocuparse por todos los pequeños detalles que se incluyen en la escritura del código. Prefieren centrarse en mejorar los algoritmos.

A veces, todo lo que puede hacer es ofrecer una sugerencia y dejarla después de eso. No impresionará a su jefe ni a un superior si sigue insistiendo en algo que ya rechazó o decidió que no quiere hacer, incluso si es 100% correcto. De hecho, esto dañará una relación, ya sea que usted sea el sugestor o el sugerido. Solo concéntrese en lo que USTED puede hacer para facilitar su trabajo.

Cuando realmente es "alguien que no es un programador profesional, nunca será un programador profesional" como usted dice, y cuando una gran parte de su trabajo es realmente "tomar su código improvisado y prepararlo para la producción", suena como su el equipo de dos personas sería más productivo cuando le dejara la programación a usted y se concentrara en la parte administrativa del proyecto.

Sin embargo, esto supone que tienes razón. Los programadores siempre tendemos a ignorar el código escrito por otras personas como mucho peor que el nuestro. Esta preconcepción es realmente difícil de vencer y nos lleva a subestimar a nuestros colegas. Lo que usted considera "programación de culto de carga" podría ser "mejores prácticas probadas" desde su perspectiva, y lo que usted considera "aplicación elegante de patrones orientados a objetos" podría ser "ingeniería excesiva innecesaria" para él. Difícil de contar para mí, porque solo conozco tu versión de la historia.

El desprecio por el código de otras personas se vuelve más fuerte cuanto más diferentes son nuestros estilos de programación. En ese caso, es un instinto positivo, porque mezclar diferentes estilos de programación en un proyecto hace que sea muy difícil de mantener.

Cuando ambos no pueden imitar el estilo del otro, pueden definir responsabilidades claras. Haga que una persona sea responsable de una parte de la aplicación y la otra persona de la otra. Defina interfaces claras entre ambos módulos juntos, pero deje la implementación interna al responsable. Para hacerlo más consciente de los errores en su código, puede escribir pruebas unitarias para él y señalar cuándo su código obviamente no se comporta de acuerdo con el contrato de interfaz que especificó juntos.

Al establecer una propiedad clara del código, puede alcanzar una mejor coexistencia de sus diferentes estilos. Además, cuando ambos son responsables de corregir los errores en su propio código, no tendrán que navegar el código de los demás a menudo.

Tienes que preguntarte: ¿cuál es tu objetivo final aquí? 1. para ayudar a tu jefe? 2. para ayudar a la empresa? 3. para ayudarte a ti mismo? Y antes de contestar "todo lo anterior", disminuya la velocidad. Su primera tarea es definir claramente su objetivo principal, porque la respuesta depende de ello.

Si su objetivo es:

1. Ayuda a tu jefe? Ríndete. Él no parece estar pidiéndolo. Usted dijo: "Él sabe que su código es malo, pero hace lo que necesita". Pues bien, fin de la discusión. A menos que y hasta que su jefe no esté satisfecho con la situación actual, él no va a cambiar, y se resentirá de sus esfuerzos para ayudarlo. Si en algún momento en el futuro "siente el dolor" del statu quo, con suerte se habrá establecido como un mentor confiable y él sabrá a dónde acudir en busca de ayuda.

2. ¿Ayuda a su empresa? ¿La situación actual amenaza el resultado final? ¿Están en riesgo los plazos? ¿La alta dirección está aumentando su calor? Si no, entonces ríndete. (Este es esencialmente el punto que Jimmy Hoffa hizo en su comentario a su publicación original). Sin embargo, si la situación actual representa un riesgo inaceptable para su departamento / empresa, entonces es necesario un cambio de proceso. En ese caso, le sugiero que se siente y describa un perfil diferenteDivisión del trabajo. La clave aquí es explicar que el tiempo que pasa refactorizando el código de su jefe sería mejor gastado escribiendo un código nuevo. Dices que no tienes tiempo para escribirlo todo tú mismo, pero eso no es lo que sugiero. Necesita descubrir cómo maximizar sus respectivas fortalezas. Deja de pensar en él como un Mort y piensa en él como un desarrollador junior con un conocimiento de dominio superior. Ese es un acuerdo de trabajo muy común en la industria, y le convendría aprender cómo prosperar en él. Por ejemplo, asegúrese de que él sepa que usted sabe cuán esencial es su experiencia (repita este paso a menudo), y luegosugiera humildemente la siguiente estrategia (o algo similar) como un camino más rápido para llevar su conocimiento al mercado: (a) divida el trabajo en sprints "ágiles", (b) colabore fuertemente desde el principio (en cada sprint) definiendo el over -todos los requisitos y arquitectura. (c) Deje que se vaya y construya el prototipo para resolver todas las decisiones algorítmicas, mientras construye la infraestructura que acordó en el paso anterior. (d) Implemente sus algoritmos en su estructura mientras construye pruebas para verificarlo. (e) Realice su V&V juntos en un entorno de programación de pares. (p. ej., "Esta prueba falló; ¿por qué? ¿error lógico algorítmico o error de codificación?"; repita aquí).

3. ¿Ayudar a sí mismo? Se honesto aquí. Si todo lo que está haciendo es quejarse de que no disfruta de su trabajo, le sugiero que pase más tiempo pensando en el n. ° 2 anterior. Si no te importa la compañía Y no disfrutas de tu trabajo, comienza a distribuir tu currículum. Si le importa su empresa pero no disfruta de su trabajo, centrarse en el n. ° 2 debería ayudar en AMBAS cuentas. Pero en ese caso, es un "ganar-ganar" solo si está claro para todos que su pasión realmente surge de un deseo de ayudar al equipo, y no solo de una frustración egocéntrica en su tarea.

No estoy seguro de que agregaré algo a esta discusión, pero después de haber trabajado en escenarios similares en los que una violación de acceso golpea una línea con ShowMessage('Hello');o similar, solo para descubrir que la misma línea tiene más código, fuera de la pantalla Derecha,

Creo que tienes dos opciones básicas:

1. Deje correr el código . Si el código funciona y está haciendo lo que debe hacer, a menos que su jefe le pida específicamente que corrija su código, simplemente déjelo como está. Eso también puede llevarlo a comprender que su código se ve mejor y dejarle el trabajo a usted (como también lo señaló Dunk en su respuesta).
2. Si está muy decidido a hacer que el código sea profesional, cree una biblioteca / marco que pueda usar. Si hay un patrón en los errores / estrategias que arregla habitualmente, puede envolverlos en unos pocos archivos de biblioteca y dárselo como una "biblioteca base para la empresa" , que también puede usar como interfaz común.