programación - Cómo transformar a los programadores COBOL en programadores de hoy en día

cobol ventajas y desventajas (8)

Estoy trabajando en un entorno corporativo donde la mentalidad está dominada por personas que comenzaron a programar con COBOL IMS y CICS. Hoy en día la mayoría de ellos programan con lenguajes más modernos como Java. Pero si miras su código y las decisiones de diseño, no ha cambiado mucho.

Métodos muchas pantallas largas
una gran cantidad de variables globales o su encarnación moderna del patrón de singleton
alrededor de 30 definiciones de variables al inicio del método
Globales en lugar de parámetros
En lugar de utilizar un método de fábrica, una gran instrucción de cambio
mal uso de las columnas de la tabla de la base de datos porque "quedaba suficiente espacio"
...

Estas personas no son tontas, la mayoría de ellas son muy inteligentes. Pero explicarles las prácticas modernas de codificación es como describir los colores a un hombre ciego. ¿Tiene alguna experiencia o consejos para enseñarles un enfoque más moderno sin ofenderlos?

¿Puedes hacer que empiecen a trabajar en buen código de alguna manera? ¿Haciendo pequeños cambios?

Además de Código Completo (probablemente después de eso), pídales que lean Refactoring: Mejorando el Diseño de Código Existente (al menos la introducción). Analiza tanto los olores de código estándar como la forma de solucionarlos.

Sin embargo, suena que lo que necesitan es una visión general de cómo pensar de una manera orientada a objetos. No estoy seguro de cuál es el mejor libro para eso.

Compre una copia de "Code Complete" y pídales que escriban un informe del libro.

Haga que escriban Java; y tienen fuertes normas de revisión de código. Cuando su método de varias páginas no pasa la revisión del código porque no es un buen código, explíqueles por qué no es un buen código. En algún momento, pueden enojarse; No creo que sea realmente posible cambiar los hábitos que se han "establecido" durante un largo período de tiempo sin ningún tipo de molestia. Pero mientras los revisores sigan siendo razonables y consistentes, comenzarán a ver el punto con el tiempo. La experiencia es realmente la única solución para este tipo de cosas, y esta es realmente la única forma de obtener la experiencia y dirigirla (en lugar de aprender de sus errores).

La mejor manera de aprender cómo debe verse el código es leer un buen código. Intente establecer un ejemplo con su propio estilo de codificación y señale suavemente sus errores durante las revisiones de códigos. Esencialmente es solo una cuestión de perspectiva; como dice el dicho, si la única herramienta que tienes es un martillo, cada problema parece un clavo. Estos programadores ven todo en términos de los lenguajes en los que tienen experiencia, e incluso cuando escriben Java, su proceso de pensamiento está en COBOL. Su estilo de codificación es simplemente un reflejo de su proceso de pensamiento.

Salvo eso, haga que todos lean el Código Completo.

Me di cuenta de que posiblemente nunca habría una reunión de mentes entre los programadores de COBOL y yo hace muchos años, cuando era instructor de cursos comerciales de capacitación en C y C ++. Acababa de completar la sección del curso en malloc () y free (), para satisfacción general de la mayoría de los apostadores, cuando el único jugador de COBOL en el curso se acercó y preguntó:

"¿Pero qué es esta cosa de ''memoria''? ¿Y por qué querría usarla?"

Para ser un poco más constructivo, mi experiencia es que los programadores de COBOL han sido entrenados para pensar en dos cosas:

el record
cosas que le haces al registro

En realidad, no está demasiado lejos de OO, y creo que la idea básica que debe transmitir es que habrá tipos de registro sutilmente diferentes, con diferentes cosas que debe hacerles y la mejor manera de lidiar con esto es para poner el registro y las cosas que deben hacerse juntos para crear objetos.

Sospecho fuertemente que su mentalidad es "lo que funciona", no una mentalidad "cuál es la mejor manera de hacer esto". Si lo que están haciendo parece funcionar, quizás no lo estén haciendo tan mal como crees.

Trabajo con COBOL y código .Net. Mi experiencia personal se ha reunido con muchos ejemplos en los que quería hacer algo de una manera mejor que mi supervisor, que está completamente en la mentalidad de COBOL. En muchos casos, abogó por una opción más simple que puede no haber sido elegante, pero fue la decisión correcta. Y por decisión correcta quiero decir, mejor para la empresa. Hay algunas cosas que debe tener en cuenta sobre lo que es bueno para el equipo y la aplicación:

¿Funciona? Si lo que están haciendo funciona, sin más problemas que su código, y pueden mantenerlo tan fácilmente como sea posible, entonces puede ser una preferencia. Si ese no es el caso, entonces puede apuntar a su código y decir: "Esto fue más fácil de mantener, ¿vio cómo solo le tomó 30 minutos arreglarlo y no tuvo problemas?" No intentes frotar sus narices en él, sino predicar con el ejemplo. Es mucho mejor decir "mira cómo funcionó esto para mí" que "deberías hacerlo de esta manera porque eso logrará algo para ti".
¿Pueden todos entenderlo? La programación con las metodologías más sofisticadas puede parecer genial, pero si la mitad del equipo no puede depurar su código sin presentar el doble de errores, es porque simplemente no saben cómo se supone que funciona la forma de hacer las cosas. Asegúrate de no introducir cosas nuevas más rápido de lo que el equipo puede asimilarlas. Esto puede agravarse cuando no se usa LINQ o lo que sea nuevo, pero es el movimiento correcto para la empresa.
¿Es necesario? BESO. O como Albert Einstein fue parafraseado: "Todo debería ser lo más simple posible, pero no más simple".

Use un contraejemplo a la vez con las palabras que explican por qué su camino es mejor, menos doloroso, les ayuda a llegar a casa con sus familias a tiempo, etc. Sin embargo, es muy importante ir uno por vez, si realmente lo está intentando. Cultivar orgánicamente una cultura. Algunos ejemplos:

Métodos muy largos : Mira, observé tu método largo y me di cuenta de que estás usando la misma lógica en dos lugares. Rompí eso y ahora no tienes que escribir el mismo código dos veces. Además, solo tenemos que probar esa parte una vez.
Variables globales y muchas definiciones al comienzo de cada método : Vea, he movido sus variables más cerca de su punto de uso. Ahora, este código de prueba en el que escribí ese efecto secundario de su código con un puntero nulo que mata el sistema no puede realizar un efecto secundario mío.
Interruptor gigante : a veces, un interruptor gigante es muy difícil de evitar (y otras veces no deberías). Dicho esto, si está intentando construir un objeto, la palabra "fábrica" lo indica. Vea, mi método de fábrica efectivamente hace lo mismo que su fábrica, pero permito que el polimorfismo (por ejemplo) reemplace parte de la administración de la caja del interruptor. Menos código = menos errores = llegamos a casa a tiempo.

Por cierto, nunca he tenido éxito en la asignación de tareas de lectura a los ingenieros (aunque Kathy menciona Refactoring, que es una fuente excelente para este tipo de cosas). Lo que me funciona es leer los libros, usar las técnicas sugeridas, demostrar el éxito y cómo me facilita la vida y luego , cuando surge la frustración de "¡¿cómo es que sabes cómo arreglar todas estas cosas ?!" establece, diles que hay un libro de instrucciones. La gente inteligente lo arrancará de tus manos tan rápido que perderás piel en el proceso.