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

1. Los principios que citó en su pregunta son solo eso ... principles. No son mandatos, leyes u órdenes.
2. Si bien las personas que crearon estos principios son muy inteligentes, no son autoridades absolutas. Solo son personas que ofrecen sus puntos de vista y orientación.
3. No hay una forma "correcta" de programar. Esto se evidencia en el hecho de que la forma "aceptada" en que lo hacemos 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 de las grandes aplicaciones monolíticas hacia colecciones de módulos de acoplamiento flexible.

6. El contexto es importante. Muchos principios de arquitectura solo demuestran su valía cuando trabajas con programas grandes o dominios específicos. Por ejemplo, la herencia es principalmente útil para las jerarquías de UI y otras estructuras que se benefician de acuerdos profundamente anidados y estrechamente acoplados.

Entonces, ¿cómo sigue un camino "correcto", un camino de principios, para que pueda emerger de la naturaleza?

1. Estudie la adecuación, en lugar de la corrección. La forma "correcta" de hacer cualquier cosa en el desarrollo de software es la que mejor cumple con sus requisitos específicos.
2. Estudiar las compensaciones. Todo en el desarrollo de software es una compensación. ¿Quieres más velocidad o menos uso de memoria? ¿Desea 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 pasado la prueba del tiempo y siempre serán relevantes. Los tipos de sistemas 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 las catedrales de cristal y los principios de la torre de marfil son inútiles si no puedes enviarlos.

5. Sea 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. Utilizan los principios para informar y guiar sus elecciones, no dictarlas.
6. Escribir código. Mucho. Los principios de diseño de software son optimizaciones prematuras hasta que hayas escrito un montón de código y hayas desarrollado un instinto sobre cómo aplicarlos correctamente.

No es infrecuente. Una cosa a tener en cuenta es que la industria del software es increíblemente diversa. Algunas empresas son de vanguardia. Universidades líderes y empresas de software innovadoras (¡incluso algunos laboratorios en las grandes!), Así como personas bendecidas o grupos como la pandilla de cuatro, analizan los problemas que surgen con las formas comunes de hacer cosas e inventar nuevos idiomas, máquinas, herramientas y patrones. Las nuevas compañías, a menudo derivadas o divididas, tratan de usarlas comercialmente y, a veces, tienen un éxito asombroso. 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 no son realmente compañías de software. He trabajado principalmente en la industria del transporte (automotriz y ferroviaria), y hay una mezcla de experiencias. Pero ninguno de ellos estaba cerca del "filo". A veces no pueden ser; el software relevante para la seguridad depende de herramientas bien verificadas (actualmente estamos utilizando un compilador validado de C ++ 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, por casualidad, se deslizaron hacia el desarrollo de software en su empresa cuando el software se hizo cada vez más importante. No se puede esperar que conozcan o utilicen los principios de ingeniería de software.

Otra cosa a considerar es lo que es importante para un ingeniero en el mundo real. A menudo, la tarea en cuestión es, literalmente, no una ciencia espacial. Los problemas de pan y mantequilla en empresas que no son de software se pueden resolver con medios de software modestos. Lo que hace a un ingeniero de software útil, quizás incluso bueno, es en parte lo que hace a un ingeniero general bueno: ser confiable; Organiza y documenta tu trabajo de manera responsable; ser cooperativo haga buenas estimaciones de costos y tiempo (la validez de la estimación es más importante que el costo real y el tiempo); Entiende lo que puedes y no puedes hacer. Lo que falta notoriamente aquí es "conocer y usar herramientas y procedimientos de vanguardia". Lo que describe es una compañía que ha establecido un conjunto de herramientas y un proceso que funciona para ellos. Probablemente nunca producirán nada atractivo 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 ;-).

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

Editar: quiero agregar un poco de consuelo o una nota más optimista. Lo que aprendiste no debe ser arrojado por la ventana. Puedes aplicar mejores principios en tu trabajo diario donde no rompa cosas. Quizás haya una ventana de oportunidad para introducir una nueva herramienta o patrón de diseño. Las posibilidades son mejores cuando la vieja forma de hacer las cosas es desagradable para los colegas, o si tienen problemas para manejar la complejidad o el mantenimiento (los dos problemas más virulentos que abordan las innovaciones). Esté preparado para ofrecer mejoras cuando haya una oportunidad. Ser una influencia positiva y mejorar incrementalmente los métodos y herramientas; difundir el conocimiento donde sea apreciado.

  

Utilizan los 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 está al tanto, el código de Web Forms listo para usar es el polo opuesto de OOP, SOLID, DRY, YAGNI, Design Patterns, SRP , etc. Incluso los ejemplos oficiales de Microsoft desde hace unos años te haría temblar hoy.

Web Forms se impulsa hacia un flujo de procedimientos, con algunos "eventos" falsos provocados por clics de control y similares. Los desarrolladores que pasaron mucho tiempo haciendo Web Forms también suelen mostrarse reacios a apartarse de él también, probablemente porque han perdido mucho tiempo aprendiendo el ciclo de vida de la página y cómo hacer controles dinámicos, por lo que ahora detestan deshacerse de ese conocimiento. frente a nuevos / mejores métodos. Una versión inconsciente de la falacia del coste hundido. Estos desarrolladores han pasado los años aprendiendo a lidiar con los Formularios Web, y ahora no se apartarán fácilmente de esa experiencia, de ahí que hablen sobre el tiempo de "mantenimiento".

Y esto es bastante común en el espacio de .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 fontanero destruya su plomería, un carpintero que entregue chatarra o un sastre barato que haga un traje mal ajustado. Es decir, es todo humano.

Hay una buena razón por la que 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 de las estructuras que rodean el desarrollo de software en esa empresa. Por ejemplo, una empresa puede tener un grupo de internos que desarrollen su software interno; incluso si esos internos son brillantes y están bien informados, solo estarán allí por unas semanas o meses, y la propiedad cambiará con frecuencia.

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

O bien, una aplicación bien hecha termina en la fase de mantenimiento, todos los buenos desarrolladores siguen adelante, y luego son desarrolladas por pocas personas (en el peor de los casos: una) 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: discute esto con tu jefe y asegúrate de participar en proyectos limpios. Si no es posible, encuentra un nuevo jefe.
• O: asume la responsabilidad de esto tú mismo. Eso significa hacerlo por su cuenta, en su tiempo libre o, si puede, en la empresa, pero conducido por usted mismo (improbable).

Si la segunda respuesta te parece demasiado cínica, déjame asegurarte que no lo es. Un carpintero que tenga un taller de carpintería en su hogar será la mayoría y será mejor carpintero que uno que no la tenga.

Por ejemplo, es absolutamente posible y una gran cantidad de diversión para algunas personas, por ejemplo, profundizar en un nuevo lenguaje como Ruby, aprender no solo la sintaxis, sino también aspectos especiales de OO en profundidad de Ese lenguaje, y realmente bucear profundamente. Todo en tu tiempo libre, sin tener ninguna conexión con tu trabajo. Solo será un pasatiempo, pero al ser el profesional capacitado que es, puede ser tan efectivo (o más) como sentarse junto a un desarrollador líder y tratar de 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, tácalo y vuelve a la primera respuesta.

Es probable que ese desarrollador líder que te está capacitando bastante 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, él (o ella) suele ser 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 está escrito por personas menos experimentadas.

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

Finalmente, algunos expertos dicen que la mejor "solución" es cambiar a una tecnología emergente que genere un código más limpio y más mantenible, creando una nueva aplicación. Como si la tecnología por sí misma pudiera hacer eso.

Una vez más, los programadores inexpertos se ponen a trabajar en esa nueva tecnología, nadie revisa el código y el círculo se cierra nuevamente ... para siempre ...

Algunas de las "mejores prácticas" que aprendes en la escuela no son prácticas ni rentables en proyectos del mundo real. Uno de los cambios más grandes que noté fue en el formato y los comentarios. La mayoría de mis profesores enfatizaron la importancia de documentar ampliamente su código, pero en el mundo real, el buen código es a menudo (no siempre) autoexplicativo, y lo más importante es que muchos jefes no quieren pagar para que dedique más tiempo a escribir. comentarios

A veces verá programadores que están presionados por el tiempo usando atajos y antipatrones que requieren menos placa de calderas que 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 empezaron sus carreras en un período de 'Software' de software de Wild West cuando las calificaciones comenzaron y terminaron con la voluntad de escribir código. A menudo se especializaron en campos completamente diferentes y se lanzaron 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 que alguien aprendiera para construir software interno). Algunos de estos programadores autodidactas de la vieja escuela nunca hacen el esfuerzo de aprender las prácticas modernas de codificación, y continúan codificando aproximadamente 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 más antiguos, y los codificadores de las generaciones más nuevas pueden ser tan culpables. He trabajado con muchos programadores más jóvenes que recogieron 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 según la caducidad de sus bibliotecas). No se mantienen al día con las nuevas funciones en los idiomas de su 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án abusado estás). 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. Lamentablemente, la responsabilidad de ambos problemas puede recaer en gran medida sobre el jefe o CTO, que debe garantizar que los plazos sean realistas y que el personal esté actualizado sobre sus conocimientos y habilidades. Si el jefe no sabe nada acerca de las 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 inclinarse a confiar en la palabra de un programador más avanzado que no entiende la POO y le gusta escribir clases de 10,000 líneas.

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

Creo que es importante no solo distinguir lo correcto de lo incorrecto sino saber las razones detrás de todo bien y mal. 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 en caso de que lo rompamos? Si sabe qué sucede cuando 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.

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

Además, debido a que este es tu primer trabajo, es probable que estos programadores no tengan mucha habilidad. Pero, de nuevo, es probable que se confíe en ellas con tareas no muy difíciles que se pueden realizar sin tanta habilidad y por un salario más bajo por parte de codificadores menos calificados y menos calificados. Así funciona la economía. Cada lugar de trabajo es diferente.

Entiendo cómo te sientes. No te asustes . Necesitará lo que sabe, tal vez no de inmediato, pero le ayudará. Tal vez en un lugar de trabajo diferente, tal vez en algunas ocasiones. Tienes tiempo por delante para ir más lejos.