¿Son típicas las malas prácticas de programación dentro de la industria del software? [cerrado]

Acabo de comenzar mi primer trabajo como desarrollador de software hace más de un mes. Todo lo que he aprendido sobre OOP, SOLID , DRY , YAGNI, patrones de diseño, SRP , etc. se puede tirar por la ventana.

Usan formularios web de C # .NET y hacen casi todo dentro del Código detrás con muy pocas clases externas, definitivamente no se llaman objetos. Utilizan controles personalizados y los reutilizan. Los únicos objetos utilizados son Entity Framework . Reutilizan el código detrás para cada cliente. Tienen métodos que tienen 400 líneas de largo haciendo todo tipo de cosas. Para los nuevos clientes, toman el aspx y el aspx.cs y quitan el código del cliente y comienzan a agregar el nuevo código específico del cliente.

Su primera excusa sería que agrega mantenimiento adicional, y más código es más mantenimiento. Es una pequeña tienda de tres desarrolladores, incluido yo mismo. Un desarrollador tiene más de 30 años de experiencia y el otro tiene más de 20 años de experiencia. Uno solía ser desarrollador de juegos y el otro siempre ha trabajado en C y C ++.

¿Qué tan común es esto dentro de la industria del software? ¿Cómo puedo asegurarme de estar al tanto de la POO y los principios relacionados? Practico en mi tiempo libre, y siento que realmente necesito trabajar con un desarrollador más experimentado para mejorar en OOP.

1. Los principios que citó en su pregunta son solo eso ... principios. No son mandatos, leyes u órdenes.
2. Si bien las personas que idearon estos principios son muy inteligentes, no son autoridades absolutas. Son solo personas que ofrecen sus ideas y orientación.
3. No hay una forma "correcta" de programar. Esto se evidencia por el hecho de que la forma "aceptada" de hacerlo ha cambiado y continúa cambiando radicalmente con el tiempo.
4. El envío de un producto a menudo puede tener prioridad sobre hacerlo de la manera "correcta". Esta es una práctica tan frecuente que tiene un nombre: Deuda técnica.

5. Algunas arquitecturas de software de uso común no son ideales. Las mejores prácticas están evolucionando desde aplicaciones grandes y monolíticas hacia colecciones de módulos acoplados libremente.

6. El contexto es importante. Muchos principios arquitectónicos solo demuestran su valía cuando trabaja con programas grandes o dominios específicos. Por ejemplo, la herencia es principalmente útil para las jerarquías de la interfaz de usuario y otras estructuras que se benefician de arreglos estrechamente anidados.

Entonces, ¿cómo sigue un camino "correcto", un camino de principios, para que pueda salir del desierto?

1. Estudie lo apropiado, en lugar de lo correcto. La forma "correcta" de hacer cualquier cosa en el desarrollo de software es la que mejor cumple con sus requisitos específicos.
2. Estudie las compensaciones. Todo en el desarrollo de software es una compensación. ¿Quieres más velocidad o menos uso de memoria? ¿Quieres un lenguaje de programación muy expresivo con pocos profesionales, o un lenguaje menos expresivo que muchos desarrolladores conozcan?

3. Estudia la atemporalidad. Algunos principios han resistido la prueba del tiempo y siempre serán relevantes. Los sistemas de tipos son universales. Las funciones de primera clase son universales. Las estructuras de datos son universales.

4. Aprende el pragmatismo. Ser práctico es importante. La pureza matemática, las arquitecturas de la catedral de cristal y los principios de la torre de marfil son inútiles si no puedes enviar.

5. Sé un artesano, no un fanático. Los mejores desarrolladores de software son los que conocen las reglas y luego saben cómo romperlas cuando tiene sentido hacerlo. Ellos son los que aún saben cómo resolver problemas y pensar por sí mismos. Usan principios para informar y guiar sus elecciones, no para dictarlas.
6. Escribir código Montones. Los principios de diseño de software son optimizaciones prematuras hasta que haya escrito mucho código y haya desarrollado un instinto sobre cómo aplicarlos correctamente.

No es poco común. Una cosa a tener en cuenta es que la industria del software es increíblemente diversa. Algunas empresas son de vanguardia. Las principales universidades y compañías de software innovadoras (¡incluso algunos laboratorios en las grandes!), Así como personas o grupos bendecidos como la pandilla de cuatro analizan los problemas que ocurren con las formas comunes de hacer las cosas e inventan nuevos lenguajes, máquinas, herramientas y patrones. Las nuevas empresas, a menudo derivadas o escindidas, intentan utilizarlas comercialmente y, a veces, tienen un éxito sorprendente. Piensa en Facebook o Google.

Pero el software se usa en casi todas partes en estos días, quizás principalmente en compañías que en realidad no son compañías de software. He trabajado principalmente en la industria del transporte (automotriz y ferroviario), y hay una mezcla de experiencias. Pero ninguno de ellos estaba cerca de la "vanguardia". A veces no pueden ser; el software relevante para la seguridad depende de herramientas bien verificadas (actualmente estamos utilizando un compilador C ++ validado de la década de 1990). A veces no tienen las personas adecuadas. A menudo, el software es desarrollado por ingenieros en otros campos que simplemente se deslizaron hacia el desarrollo de software en su empresa cuando el software se volvió cada vez más importante. No se puede esperar que sepan o usen principios de ingeniería de software.

Otra cosa a considerar es lo que es importante en un ingeniero en el mundo real. A menudo, la tarea en cuestión es, literalmente, no ciencia espacial. Los problemas generales en las compañías que no son de software pueden resolverse con medios de software modestos. Lo que hace que un ingeniero de software sea útil, quizás incluso bueno, es en parte lo que lo hace un buen ingeniero general: Sea confiable; organizar y documentar su trabajo de manera responsable; ser cooperativo; hacer buenas estimaciones de costo y tiempo (¡la validez de la estimación es más importante que el costo y tiempo real!); entiende lo que puedes y no puedes hacer. Es evidente que aquí falta "conocer y utilizar herramientas y procedimientos de vanguardia". Lo que usted describe es una compañía que ha establecido un conjunto de herramientas y un proceso que funciona para ellos. Probablemente nunca producirán nada sexy o extraordinario, pero satisfacen las demandas de los clientes lo suficientemente bien como para generar un flujo constante de ingresos suficientes. Esa podría ser la definición de ingeniería ;-).

Entonces sí: lo que aprendes en la universidad en realidad no es común en gran parte del campo.

Quiero agregar un poco de consuelo, o una nota más optimista. Lo que aprendiste no se debe tirar por la ventana. Puede aplicar mejores principios en su trabajo diario donde no rompa las cosas. Quizás habrá una oportunidad para introducir una nueva herramienta o patrón de diseño. Las posibilidades son mejores cuando la antigua forma de hacer las cosas es desagradable para los colegas, o si se encuentran con problemas para gestionar la complejidad o el mantenimiento (los dos problemas más virulentos abordados por las innovaciones). Esté preparado para ofrecer mejoras cuando haya una oportunidad. Sea una influencia positiva y mejore gradualmente los métodos y herramientas; difundir el conocimiento donde se aprecia.

Utilizan formularios web de C # .Net y hacen casi todo dentro del código detrás con muy pocas clases externas

Ahí está tu explicación. Si no lo sabe, el código listo para usar de Web Forms es prácticamente el polo opuesto de OOP, SOLID, DRY, YAGNI, Design Patterns, SRP , etc. Incluso los ejemplos oficiales de Microsoft de hace unos años. te haría temblar hoy.

Web Forms se empuja hacia un flujo de procedimientos, con algunos "eventos" falsos activados por clics de control y similares. Los desarrolladores que pasaron mucho tiempo haciendo Web Forms también parecen reacios a apartarse de él también, probablemente porque dedicaron tanto tiempo a aprender el ciclo de vida de la página y cómo hacer controles dinámicamente prestados que detestan tirar ese conocimiento ahora. frente a nuevos / mejores métodos. Una versión inconsciente de la falacia de costo hundido. Estos desarrolladores han pasado los años aprendiendo cómo lidiar con Web Forms, y ahora no se apartarán fácilmente de esa experiencia, de ahí su conversación sobre el tiempo de "mantenimiento".

Y esto es bastante común en el espacio .NET Web Forms, por cierto.

¿Qué tan común es esto dentro de la industria del software?

Muy común. Casi lo mismo que hacer que un plomero destruya su plomería, un carpintero que entrega basura o un sastre barato que hace un traje que no le queda bien. Es decir, todo es humano.

Hay una buena razón por la cual esto sucede: las personas que no están realmente capacitadas (o no están entusiasmadas) tienen que implementar algo bajo presión.

Este no es un problema de esas personas, principalmente, sino generalmente de las estructuras que rodean el desarrollo de software en esa compañía. Por ejemplo, una compañía podría tener un grupo de pasantes desarrollando su software interno; incluso si esos pasantes son brillantes y conocedores, solo estarán allí durante unas pocas semanas o meses, y la propiedad cambiará con frecuencia.

O alguna persona que es excelente en el dominio, pero no un programador, podría piratear alguna aplicación de VBA, etc. porque parece ser bastante fácil al principio.

O una aplicación bien hecha termina en la fase de mantenimiento, todos los buenos desarrolladores continúan, y luego es desarrollada por pocas personas (el peor de los casos: uno) que saben poco al respecto, que no tienen documentación, etc.

¿Cómo puedo asegurarme de estar al tanto de la POO y los principios relacionados? Practico en mi tiempo libre y siento que realmente necesito trabajar con un desarrollador más experimentado para mejorar en OOP.

Hay dos respuestas posibles:

• O bien: discuta esto con su jefe y asegúrese de entrar en proyectos limpios. Si no es posible, encuentre un nuevo jefe.
• O: asuma la responsabilidad de esto usted mismo. Eso significa hacerlo por su cuenta, en su tiempo libre, o si puede, en la empresa, pero impulsado por usted mismo (poco probable).

Si la segunda respuesta te suena demasiado cínica, déjame asegurarte que no lo es. Un carpintero que tiene un taller de carpintería en su casa será más , sin duda, un carpintero mejor que uno que no lo hace.

Por ejemplo, es absolutamente posible y muy divertido para algunas personas, por ejemplo, profundizar en un nuevo idioma como Ruby, aprender no solo la sintaxis, sino también profundizar en aspectos especiales de OO de ese idioma y realmente profundizar. Todo en su tiempo libre, sin tener ninguna conexión con su trabajo. Solo será un pasatiempo, pero como eres el profesional capacitado que eres, puede ser tan efectivo (o más) como estar sentado junto a un desarrollador principal e intentar seguir lo que están haciendo. Esto será estrictamente para su desarrollo personal y su propia diversión. Si no te diviertes haciendo esto, o si encuentras que simplemente no puedes lograr ningún entendimiento, rasca eso y regresa a la primera respuesta.

Es muy probable que el desarrollador principal que te está entrenando haya aprendido esas cosas exactamente de esta manera ...

Creo que en España es una constante porque cuando un desarrollador pasa muchos años en una empresa, generalmente es promovido a más áreas de gestión como el análisis y la gestión de proyectos. Como resultado, no se realiza una revisión por pares y el código generalmente es escrito por personas menos experimentadas.

Las fallas de estas personas experimentadas nunca se corrigen: en cambio, su único enfoque es hacer el trabajo. Como resultado, se acumulan más y más prácticas incorrectas en el código.

Eventualmente, un asno inteligente dice que la mejor "solución" es cambiar a una tecnología emergente que generará un código más limpio y más sostenible, creando una nueva aplicación. Como si la tecnología por sí sola pudiera hacer eso.

Una vez más, los programadores sin experiencia se ponen a trabajar en esa nueva tecnología, nadie revisa el código y el círculo se cierra de nuevo ... por siempre ...

Algunas de las "mejores prácticas" que aprende en la escuela no son prácticas ni rentables en proyectos del mundo real. Uno de los cambios más importantes que noté fue en el formato y los comentarios. La mayoría de mis profesores enfatizaron la importancia de documentar extensamente su código, pero en el mundo real, un buen código a menudo (¡no siempre!) Se explica por sí mismo y, lo que es más importante, muchos jefes no quieren pagar para que pase más tiempo escribiendo comentarios

A veces verá programadores que están presionados por el tiempo utilizando atajos y antipatrones que requieren menos placa de caldera que las soluciones de calidad.

Sin embargo, uno de los mayores problemas que he notado en muchos equipos y proyectos es la falta de voluntad para aprender cosas nuevas.. Muchos de los programadores más antiguos con los que he hablado comenzaron sus carreras en un período de ingeniería de software en el 'Salvaje Oeste' cuando comenzaron las calificaciones y terminaron con la voluntad de escribir código. A menudo se especializaron en campos completamente diferentes y saltaron a la programación con poca o ninguna educación formal cuando surgió una oportunidad (por ejemplo, su empleador no tenía un programador y necesitaba a alguien para aprender a fin de construir un software interno). Algunos de estos programadores autodidactas de la vieja escuela nunca hacen el esfuerzo de aprender prácticas modernas de codificación, y continúan codificando aproximadamente con el estilo que aprendieron hace décadas. Cuando terminan a cargo de nuevos proyectos debido a la antigüedad, tienden a retrasar los proyectos y dañar la calidad general del código.

Por supuesto, lo anterior no se aplica a todos los programadores de más edad, y los codificadores de nueva generación pueden ser igualmente culpables. He trabajado con muchos programadores más jóvenes que adquirieron algunas herramientas y bibliotecas recién salidas de la universidad y luego dejaron de aprender por completo. Descargarán un IDE o una biblioteca una vez y nunca lo actualizarán a menos que su compañía lo requiera (a veces puede adivinar en qué año se graduó un programador en función de cuán desactualizadas están sus bibliotecas). No se mantienen al día con las nuevas funciones en su idioma o idiomas de elección, y nunca aprenden nuevos idiomas. No aprenden nuevas estrategias de programación y pueden hacer mal uso de patrones o paradigmas porque no conocen alternativas más apropiadas (oh MVC, cuánto abusa de ti). A medida que pasa el tiempo, su flujo de trabajo se vuelve cada vez más desactualizado, y se vuelven más un pasivo que un activo.

En resumen, dos de las principales causas de las bases de código desordenadas son los plazos apresurados y los programadores con conocimientos obsoletos o incompletos. Desafortunadamente, la responsabilidad de ambos asuntos puede recaer en gran medida en el jefe o el CTO, que debe asegurarse de que los plazos sean realistas y que el personal esté actualizado sobre sus conocimientos y habilidades. Si el jefe no sabe nada sobre buenas prácticas de programación, lo mejor que puede hacer es intentar sugerir cambios y esperar que estén abiertos a sugerencias. Desafortunadamente, pueden estar inclinados a confiar en la palabra de un programador más experimentado que no entiende OOP y le gusta escribir 10,000 clases de línea.

Algunas de las malas prácticas de programación resultan de tener que trabajar con software heredado que comenzó a desarrollarse hace décadas. Si hay una gran pieza de software compleja, reescribir todo podría no ser una opción. Incluso podría ser extremadamente difícil entender todo lo que el código realmente está haciendo. La mejor opción podría ser simplemente copiar lo que funciona al mismo tiempo que intentas integrar mejores prácticas de programación si puedes hacerlo sin romper nada.

Creo que es importante no solo distinguir lo correcto de lo incorrecto sino conocer las razones detrás de todo lo correcto y lo incorrecto. Cuando conoces razones puedes predecir consecuencias. ¿Por qué usar este o aquel principio no porque se describió en un libro, sino porque sabemos cómo ayuda y qué sucede exactamente si lo rompemos? Si sabe qué sucede cuándo puede sopesar los pros y los contras y tomar una decisión. Esto también te ayudará a discutir tu posición cada vez. SOLID y OOP también pueden reducir el mantenimiento si se usan bien.

SÓLIDO si se usa demasiado dogmáticamente conduce a demasiadas clases y métodos, lo que tampoco es tan bueno. No te excedas. Esto es en parte un gran problema con nuestros libros de texto y tutoriales, ya que a menudo intentan promover ideas sin una justificación adecuada. OOP también tiene sus contras. Muchos principios y paradigmas se contradicen entre sí. No necesita estar en la cima, debe hacer que todo sea razonable, justificado, elegante y simple.

Además, debido a que este es su primer trabajo, es probable que estos programadores no sean muy hábiles. Pero, de nuevo, es probable que se les confíe tareas no muy difíciles que se pueden hacer sin tanta habilidad y por un salario más bajo por parte de codificadores más baratos y menos calificados. Así funciona la economía. Cada lugar de trabajo es diferente.

Entiendo como te sientes. No entres en pánico . Necesitará lo que sabe, tal vez no de inmediato, pero lo ayudará. Tal vez en un lugar de trabajo diferente, tal vez en algunas ocasiones. Tienes tiempo por delante para ir más allá.