No puedo programar porque el código que estoy usando usa viejos estilos de codificación. ¿Es esto normal para los programadores?

Tengo mi primer trabajo real como programador, pero no puedo resolver ningún problema debido al estilo de codificación utilizado. El código aquí:

• No tiene comentarios
• No tiene funciones (50, 100, 200, 300 o más líneas ejecutadas en secuencia)
• Utiliza muchas ifdeclaraciones con muchas rutas
• Existen diversas variables que no tienen sentido (por ejemplo .: cf_cfop, CF_Natop, lnom, r_procod)
• Utiliza un lenguaje antiguo (Visual FoxPro 8 de 2002), pero hay nuevas versiones de 2007.

Siento que he vuelto a 1970. ¿Es normal que un programador familiarizado con OOP, código limpio, patrones de diseño, etc. tenga problemas con la codificación de la manera tradicional?

EDITAR : Todas las respuestas son muy buenas. Para mi (no) esperanza, parece que hay mucho de este tipo de código base en todo el mundo. Un punto mencionado en todas las respuestas es refactorizar el código. Sí, realmente me gusta hacerlo. En mi proyecto personal, siempre hago esto, pero ... no puedo refactorizar el código. Los programadores solo pueden cambiar los archivos en la tarea para la que están diseñados.

Cada cambio en el código antiguo debe mantenerse comentado en el código (incluso con Subversion como control de versión), más la metainformación (fecha, programador, tarea) relacionada con ese cambio (esto se convirtió en un desastre, hay código con 3 líneas usadas y 50 líneas viejas comentadas). Estoy pensando que no es solo un problema de código, sino un problema de gestión del desarrollo de software.

Ok, seré directo. Ese es un mal lugar para trabajar ... He estado en tales situaciones, y generalmente termina con que te tragues este código. Después de un año más o menos, te acostumbrarás y perderás el control de cómo las alternativas modernas se pueden usar para lograr la misma tarea más fácilmente, de una manera más fácil de mantener y también, más rápido en tiempo de ejecución en mayoria de los casos.

Dejé un lugar de trabajo como ese, porque, después de solo un mes, sentí que me arrastraban a un viejo código de skool. Traté de intentarlo, pero decidí no hacerlo. No pude usar un código limpio y comencé a perder habilidades debido a la falta de práctica diaria. Cualquier enfoque moderno tenía que ser aprobado por 3 capas de desarrolladores, lo que nunca sucedió, porque la idea era que las cosas podrían romperse cuando se utilizan enfoques modernos. Y la naturaleza frágil del código que sale cuando no usas enfoques modernos da bastante miedo.

No me malinterpreten, hay casos en los que las personas diseñan soluciones en exceso, y estoy en contra. Pero ser arrastrado a las convenciones y al estilo de codificación del '80 por una cantidad de tiempo extensa detendrá su progreso y también, creo, las oportunidades profesionales.

Por otra parte, tienes que ganar dinero, así que a veces tienes que hacer lo que no te gusta exactamente. Sin embargo, vigile los síntomas de agotamiento y convierta la codificación en una tarea mundana en esos casos.

Este estilo de codificación (si incluso quiere llamarlo cualquier tipo de estilo) es un mal estilo de codificación.

Se pueden escribir funciones cortas con nombres de variables descriptivos y control de flujo sensato en la mayoría de los lenguajes modernos (Visual FoxPro es moderno, sí).

Los problemas que tiene son con una mala base de código, nada más y nada menos.

Tales bases de código existen y son muchas; el hecho de que tenga problemas con ellas atestigua lo mal que pueden ser (y que tiene una buena capacitación).

Lo que puede intentar y hacer es mejorar las cosas donde puede: renombrar variables, extraer elementos comunes y dividir funciones grandes en otras más pequeñas, etc. Obtenga una copia de Trabajar eficazmente con código heredado ...

Estoy en un proyecto de C # con una estructura muy mala, no muy lejos de lo que usted describe. Solo combiné 12 funciones separadas (copiar y pegar obvio) en una que toma un solo parámetro.

Eso no es realmente "anticuado", excepto en que las buenas prácticas de diseño (actuales) no siempre fueron tan populares. Eso es solo un mal código. El código incorrecto ralentiza a cualquiera. Eventualmente te acostumbras, pero eso es solo porque te acostumbras a peculiaridades específicas en tu sistema específico. Dado un nuevo proyecto, puede encontrar formas completamente nuevas de escribir código incorrecto. Lo bueno es que ya sabes cómo identificar estos olores de código.

Lo más importante que puede hacer es no propagar el problema . No tome estas malas prácticas como una convención a menos que su equipo lo sea. Mantenga limpio el nuevo código de manera que no fuerce un refactorizador. Si es tan malo y tienes tiempo, considera un refactor importante ... pero en la práctica rara vez tienes ese lujo.

Considere agregar comentarios a medida que resuelve las cosas, y cambie pequeños trozos como piezas prácticas. A menos que esté codificando solo, necesita resolver esto con su equipo; si no hay convenciones, debería tomarse un tiempo para elaborarlas, y tal vez comprometerse a mejorar lentamente la base del código si de todos modos la mantiene regularmente.

Si encuentra una función totalmente aislada con nombres de variables incorrectos y la está arreglando de todos modos, también podría hacer que los nombres de variables sean algo útil, refactorice los ifs. No realice cambios en las características comunes a menos que vaya a refactorizar una gran parte de ellas.

• no tengo comentarios - arréglalo a medida que lo aprendas
• no tiene funciones (50, 100, 200, 300 o más líneas ejecutadas en secuencia)

Esto probablemente data de una iteración previa del código. En este punto, tendría cuidado con las sutiles diferencias entre los bloques de código de apariencia similar que se han convertido en "características". Pero independientemente de cuán mala sea la idea de este tipo de estructura, es bastante simple de entender ... así que no estoy seguro de dónde tendría problemas con ella.

• usa muchas declaraciones if con muchas rutas: en realidad no estoy seguro de lo que quieres decir aquí
• tiene variables que no tienen sentido (por ejemplo: cf_cfop, CF_Natop, lnom, r_procod) -

Enfatizaría la precaución con el bit 'renombrar variables'. Hay una buena posibilidad de que simplemente no entiendas la jerga todavía, y los nombres de las variables tendrán mucho más sentido después de que hayas estado allí por un tiempo. No quiere decir que no pueda haber nombres de variables problemáticos también, pero sus ejemplos parecen tener una lógica, si supiera cuáles son las siglas comunes en su sitio. Obviamente, esto no es tan importante si eres un equipo de 1.

• usa un lenguaje con el que no estoy familiarizado (Visual FoxPro 8 de 2002) - Este es su problema, no el código

Esto me suena como una oportunidad .

Está claro que ya puedes ver muchos problemas en cómo se hacen y se manejan las cosas. Puede quejarse de que todo es basura y que no puede hacer nada, O puede usar esto como una oportunidad de oro para mostrar realmente a su empleador lo que vale.

Ahora, no te va a ayudar si marchas a tu empleador y le dices que todo tiene que cambiar. Entonces, el truco es seguir el juego por un tiempo, hacer MUCHAS preguntas, y cuando se te pida que escribas código, tendrás que seguir sus reglas con todos los comentarios, etc., ya que tendrás que mantener a otros desarrolladores informado utilizando el sistema que prefiera actualmente, mientras que al mismo tiempo puede introducir refactorizaciones sensatas que no lo arriesgarán en nada. Puede extraer un par de métodos, y si su idioma lo admite, introduzca algunas pruebas unitarias. Cuando se le pregunte por qué lo hizo de esta manera, o si se le dice que está haciendo algo "incorrecto", evite ponerse a la defensiva o argumentativo mientras hace una presentación sólida de su posición para su estilo preferido de codificación. Por ejemplo, puede referirse a libros como el Código Limpio de Bob Martin, o puede consultar otros libros, artículos o incluso preguntas y respuestas que haya encontrado en Programmers.SE. Cualquier cosa que pueda encontrar útil para respaldar su posición con hechos que podrían estar más allá de su experiencia a los ojos de las personas con las que está trabajando.

Con respecto a los comentarios excesivos, algo de esto se puede aclarar si agrega algunos nombres descriptivos para las variables y métodos, pero también podría ser capaz de defender un buen sistema de control de versiones, y usar eso para mantener el registro de los cambios y las fechas, etc., y para el uso de una herramienta para comparar las diferentes versiones de sus archivos de origen si aún no viene con su VCS elegido.

Como dije, esta es una oportunidad para contribuir a la mejora de un equipo de desarrollo que parece que ha perdido el rumbo, por así decirlo. Tiene la oportunidad de destacarse como experto y experto, y como alguien que puede liderar con el ejemplo. Todas estas son cosas buenas para ayudarlo más adelante a medida que avanza su carrera.

Bienvenido a la jungla !

Desafortunadamente, a menudo comenzar a trabajar en una empresa significa comenzar a enfrentar este tipo de situaciones, a menos que trabaje para una empresa estructurada y bien organizada, estas situaciones son bastante habituales ...

Mi consejo es :

1. Comience a aprender y familiarícese con: lenguaje de programación utilizado (Clipper / dBase) y entorno (Visual FoxPro)

2. Lea y analice la base del código y comience a comentarlo

3. organizar / refactorizar el código (abordar el problema de demasiadas líneas ejecutadas en secuencia)

Tener problemas para enfrentar una base de código similar es normal, pero puede convertirse en un gran desafío al tratar de mejorar la calidad del código y darle "su toque" al programa mejorando la base de código y quizás convirtiéndolo en un mejor programa ...

Para responder a su pregunta: Sí, las personas / empresas de todo el mundo utilizan una infraestructura que puede construirse sobre códigos basura. Al integrarse en tales situaciones, puede ser muy difícil lidiar con ellas.

El verano pasado, trabajé como pasante desarrollando una aplicación para ser utilizada por el equipo de control de calidad adjunto a un departamento específico. El equipo de control de calidad usó muchos scripts independientes (VBScript, Perl, Bash) para ejecutar pruebas en bases de datos y demás, y querían reunirlos a todos en una sola aplicación. Sin embargo, el problema con esto es que esos scripts se usaron en otras partes de la empresa (por lo tanto, la funcionalidad principal / los nombres de las variables no se podían cambiar), y el código se "agregó a" durante casi 10 años; Se había acumulado mucha basura.

Sin embargo, esto es lo que puede hacer al respecto:

1. Pida ayuda: sus compañeros de trabajo que han tenido que mirar este código probablemente estén familiarizados con sus idiosincrasias. Lo que es obtuso y confuso para usted está perfectamente bien para ellos. ¡Así que pide ayuda!
2. Refactorice siempre que sea posible: si tiene que mirar / mantener este código durante un período prolongado, refactorícelo siempre que pueda. Incluso si está ejecutando una búsqueda y reemplazo en un nombre de variable, cada poquito ayuda. La compañía en la que hice la pasantía el verano pasado tuvo un problema similar al usar nombres de variables deficientes. Cada vez que podía, ejecutaba su código a través de un peine de dientes finos, cambiando nombres de variables, optimizando la lógica (agrupando varias funciones en 1, por ejemplo), etc. ¡Haz lo mismo cuando tengas la oportunidad!

Como es el caso en todas partes, siempre que las características externas del código funcionen correctamente, no importará cómo funcionan las partes internas.

Voy a hacer algunos comentarios que son diferentes de muchos de los que respondieron aquí. Muchos de mis comentarios pueden ser obvios para usted, pero es necesario decirlo de todos modos.

• Tenga cuidado de cambiar el código que no entiende, hasta que lo entienda.
• Si está trabajando en un entorno de equipo, con un código en el que trabajan sus compañeros de equipo, discuta sus cambios con ellos antes de realizarlos. A nadie le gusta que entre un "pistolero solitario" y cambie el código con el que todos los demás están familiarizados. Esto no quiere decir que sus cambios no están garantizados o que es lo "correcto".
• Obtenga adopción para sus ideas. Consiga a todos a bordo con sus ideas, luego puede usar las habilidades de su equipo para refactorizar, en lugar de cargar con toda la carga de trabajo.
• Ganar la aceptación de la administración. Es posible que puedan asignar fondos para que usted vaya y vuelva a factorizar el código.
• Hable con la gerencia en términos que entiendan sobre los beneficios de refactorizar su código base. Más código mantenible significa menos tiempo dedicado a resolver errores, agregar funciones, etc. Lo que significa un desarrollo rentable. Tiempo de respuesta más rápido, etc.

Es fácil agregar codificación pura, sugerencias de mejores prácticas sin comprender la política de su entorno. Es posible que las personas con las que trabaja no quieran cambiar o asignar el tiempo para cambiar su base de código, pero intente vender la idea a todos antes de saltar y cambiar todo (lo que tiene riesgos inherentes en sí mismo)

Espero que esto ayude.

Una de las cosas que sobresale es su comentario editado

Cada cambio en el código antiguo debe mantenerse comentado en el código, más la metainformación (fecha, programador, tarea) relacionada con ese cambio (esto se convirtió en un desastre, hay un código con 3 líneas usadas y 50 líneas antiguas comentadas). Estoy pensando que no es solo un problema de código, sino un problema de gestión del desarrollo de software.

También tengo un proyecto donde heredé una base de código FoxPro heredada con muchos de los problemas que usted describe. Una de las primeras cosas que presenté al proyecto fue un buen repositorio de código fuente. FoxPro puede integrarse con SourceSafe, pero ese producto es doloroso de usar.

Tomé una copia de la herramienta scx de Paul McNett http://paulmcnett.com/scX.php y la integré en mi ciclo de desarrollo. Hace un trabajo bastante bueno al extraer el código binario de FoxPro a un formato de texto que luego se puede colocar en un repositorio de origen, como Subversion, Mercurial o incluso git. (Puede encontrar útil el proyecto SubFox en http://vfpx.codeplex.com .

Estas herramientas proporcionan el historial y permiten a los programadores continuar con el trabajo de mantener el código. Definitivamente toma algún tiempo aprender a usar estas herramientas, pero como son todas gratuitas, realmente no tiene sentido no invertir algo de tiempo en ellas. (incluso si no puede hacer que los proyectos de Job se muevan de esa manera).

Voy a estar totalmente de acuerdo con la respuesta de funkymushroom. Si usted es un entorno de equipo, asegúrese de que otros sepan que está refactorizando o reorganizando el código, si alguna vez planea obtener buenas asignaciones futuras.

Por experiencia personal, sé que, si bien no es su estilo de codificación, si mantiene el código, que también modifica y mantiene, siga el estilo del código existente. Agregar comentarios y aclaraciones está bien, pero el diseño básico y las convenciones deben permanecer. Los viejos gurús / pistolas en el proyecto esperan que el código sea similar a lo que han estado viendo durante años.

Cuando un cliente grita sobre un error, su gerencia recurrirá a las armas viejas para solucionar el problema lo más rápido posible. Si estas armas viejas, cuando están bajo presión, lo encuentran "limpiado el código" y ahora tienen que dedicar tiempo a averiguar dónde se mudó o renombró esa variable que saben que necesita ajustes, su nombre en la compañía cambiará a " barro".

Una vez que la crisis haya terminado, primero el arma vieja te culpará lentamente por la actualización crítica. A continuación, encontrará que puede mantener el código limpio durante todo el tiempo que permanezca en la empresa. Finalmente, cuando estén disponibles nuevos proyectos interesantes, sus gerentes preguntarán a los gurús sobre quién debería trabajar en el proyecto, y si los ha atornillado una vez, nunca llegará al nuevo proyecto, hasta que su forraje sea arrojado al final para cumplir con un plazo.

Si aprendiste en la universidad la forma "correcta" de codificar, y ahora estás en la fuerza laboral, olvida esa forma "correcta". Estas no son tareas de la universidad, estos proyectos no duran solo un semestre, pueden vivir durante años y deberán ser mantenidos por un grupo de personas con diferentes niveles de experiencia y diferentes niveles de interés en la última tendencia de CS. Tienes que ser un jugador de equipo.

Puedes ser la mayor programación de tiro caliente en la escuela, pero en el lugar de trabajo, tu primer trabajo, eres un novato con cero credibilidad callejera. A las personas que han estado programando durante años no les importa mucho tu escuela o tus calificaciones, es lo bien que juegas con los demás y la cantidad de interrupciones que traes a sus vidas.

En mis 20 años, parece que varios programadores as fueron despedidos, principalmente porque exigen hacer las cosas a su manera "correcta". A menos que traigas algo muy, muy, muy exclusivo para el trabajo, eres reemplazable. Es posible que haya sido el mejor de su clase, pero el próximo año, alguien más será el mejor de su clase y buscará un trabajo.

Lo veo como su trabajo principal, es mantener su trabajo, hasta que decida cambiar de trabajo. Para mantener su trabajo significa que tiene que jugar bien en el patio de recreo que alguien más construyó y pagó.

Sé que sueno negativo, pero siempre hay esperanza. A medida que gane experiencia, tenga éxito, ganará influencia y podrá cambiar las cosas a una mejor manera. Al escribir un nuevo código o en un nuevo proyecto, presione los cambios que busca. Si es un código nuevo, las armas viejas no esperan que sea como lo dejaron, y cuando ven las ventajas, pueden aprender y adaptar la nueva forma.

El sistema antiguo puede cambiar, pero lleva tiempo. Cambiar algo introduce riesgo y riesgo de odio empresarial, y debe tomarse el tiempo y el trabajo para que la empresa se sienta cómoda con el cambio.