¿Existe un paradigma de programación que promueva hacer que las dependencias sean extremadamente obvias para otros programadores?

Trabajo en un Data Warehouse que genera múltiples sistemas a través de muchas corrientes y capas con dependencias tipo laberinto que vinculan varios artefactos. Casi todos los días me encuentro con situaciones como esta: ejecuto algo, no funciona, reviso un montón de código, pero horas después me doy cuenta de que he logrado conceptualizar el mapa de proceso de una pequeña porción de lo que ahora sé se requiere más tarde en el día, así que le pregunto a alguien y me dicen que esta otra secuencia debe ejecutarse primero y que si marcara aquí (indicando una porción aparentemente arbitraria de una enorme pila de otras dependencias codificadas), entonces habría visto esto. Es increíblemente frustrante.

Si pudiera sugerirle al equipo que tal vez sería una buena idea hacer más para hacer que las dependencias entre los objetos sean más visibles y obvias, en lugar de incorporarlas profundamente en niveles recursivos de código, o incluso en los datos que tiene que estar presente debido a que está poblado por otra secuencia, tal vez al referirse a un paradigma de software bien conocido, probado y probado, entonces podría ser capaz de simplificar mi trabajo y el de todos los demás.

Es un poco difícil explicar los beneficios de esto a mi equipo. Tienden a aceptar las cosas tal como son y no "piensan en grande" en términos de ver los beneficios de poder conceptualizar todo el sistema de una manera nueva; realmente no ven eso si puede modelar un sistema enorme eficientemente, entonces hace que sea menos probable que encuentre ineficiencias de memoria, restricciones únicas de flujo y claves duplicadas, datos sin sentido porque es mucho más fácil diseñarlo de acuerdo con la visión original y luego no se encontrará con todos estos problemas que ahora estamos experimentando, lo que sé que es inusual en trabajos anteriores, pero que parecen considerar inevitable.

Entonces, ¿alguien sabe de un paradigma de software que enfatiza las dependencias y también promueve un modelo conceptual común de un sistema con el fin de garantizar la adhesión a largo plazo a un ideal? Por el momento, tenemos un desastre gigante y la solución de cada sprint parece ser "simplemente agreguen esto aquí y aquí y aquí", y yo soy el único preocupado de que las cosas realmente estén empezando a desmoronarse.

Descubrimiento

Su ausencia afecta a muchas organizaciones. ¿Dónde está esa herramienta que Fred construyó nuevamente? En el repositorio de Git, claro. ¿Dónde?

El patrón de software que viene a la mente es Model-View-ViewModel. Para los no iniciados, este patrón es un completo misterio. Se lo expliqué a mi esposa como "cinco artilugios que flotan sobre la mesa hablando entre sí a través de una fuerza misteriosa". Comprenda el patrón y comprenderá el software.

Muchos sistemas de software no documentan su arquitectura porque suponen que se explica por sí misma o que surge naturalmente del código. No lo es, y no lo hace. A menos que esté utilizando una arquitectura bien definida, las personas nuevas se perderán. Si no está documentado (o bien conocido), se perderán nuevas personas. Y los veteranos también se perderán, una vez que hayan estado alejados del código durante unos meses.

Es responsabilidad del equipo crear una arquitectura organizacional sensata y documentarla. Esto incluye cosas como

• Organización de la carpeta
• Referencias del proyecto
• Documentación de clase (qué es, qué hace, por qué existe, cómo se usa)
• Proyecto, módulo, montaje, cualquier documentación.

Es responsabilidad del equipo hacer que las cosas estén organizadas y sean reconocibles para que el equipo no reinvente constantemente la rueda.

Por cierto, la noción de que "el código debe autodocumentarse" es solo parcialmente correcta. Si bien es cierto que su código debe ser lo suficientemente claro para que no tenga que explicar cada línea de código con un comentario, las relaciones entre artefactos como clases, proyectos, ensamblajes, interfaces y similares no son obvias, y aún así necesita ser documentado

La mejor manera de abordar este tipo de problemas es de forma incremental. No se frustre y proponga cambios arquitectónicos amplios y radicales. Esos nunca serán aprobados, y el código nunca mejorará. Eso supone que incluso puede determinar los cambios arquitectónicos amplios y amplios correctos para hacer, lo cual es poco probable.

Lo que es probable es que se puede determinar un cambio más pequeño que le han ayudado con el problema específico que acabamos de resolver. Tal inversión de algunas dependencias, añadiendo un poco de documentación, la creación de una interfaz, escribiendo un guión que advierte de que falta una dependencia, etc Por lo tanto proponer que el cambio más pequeño en su lugar. Aún mejor, dependiendo de la cultura de su empresa, pueden tolerar o incluso esperar que realice mejoras como esa como parte de su tarea original.

Cuando realiza estos cambios más pequeños en una parte regular de su trabajo, y con su ejemplo alienta a otros a que también lo hagan, realmente se acumulan con el tiempo. Mucho más efectivo que lloriquear sobre cambios individuales más grandes que no puedes hacer.

Arquitectura.

No existe un principio o práctica único, específico y universal que resuelva los problemas de descubrimiento y mantenibilidad que se aplican a todos los aspectos de todo el software. Pero, el término amplio para las cosas que hacen que un proyecto sea cuerdo es arquitectura.

Su arquitectura es el conjunto de decisiones en torno a cada punto de confusión potencial (o histórica), incluida la designación de cómo se toman y documentan las decisiones arquitectónicas. Todo lo relacionado con el proceso de desarrollo, la estructura de carpetas, la calidad del código, los patrones de diseño, etc., son todas las cosas que pueden entrar en su arquitectura, pero ninguna de ellas es una arquitectura.

Idealmente, esas reglas están unificadas por una singularidad mental.

Un pequeño equipo ciertamente puede crear arquitectura en colaboración. Pero, con diferentes opiniones, esto puede conducir rápidamente a un arquitectura muy esquizofrénica que no sirve para mantener la cordura. La forma más sencilla de garantizar que su arquitectura, y los muchos TLA y patrones que contiene, sirvan al éxito del equipo con una singularidad mental es hacer que una sola mente sea responsable de ellos.

Ahora, eso no necesariamente requiere un "arquitecto" para pontificar . Y, aunque algunos equipos pueden querer que una persona con experiencia simplemente tome esas decisiones, el punto principal es que alguien necesita ser dueño de la arquitectura, especialmente a medida que el equipo crece. Alguien mantiene el dedo en el pulso del equipo, modera las discusiones arquitectónicas, documenta las decisiones y supervisa las decisiones y trabaja en adelante para cumplir con la arquitectura y su espíritu.

No soy un gran admirador de ninguna persona que tome todas las decisiones; pero, identificar a un "arquitecto" o "propietario técnico del producto" que es responsable de moderar las discusiones arquitectónicas y documentar las decisiones combate un mal mayor: la difusión de la responsabilidad que no conduce a una arquitectura discernible.

Bienvenido a Ingeniería de Software (en ambos sentidos);) Esta es una buena pregunta, pero realmente no hay respuestas fáciles, como estoy seguro de que sabe. Realmente se trata de evolucionar hacia mejores prácticas con el tiempo, capacitar a las personas para que sean más hábiles (por definición, la mayoría de las personas en la industria son competencias mediocres) ...

La ingeniería de software como disciplina sufre de construirlo primero y diseñar la mentalidad sobre la marcha, en parte por conveniencia y en parte por necesidad. Es solo la naturaleza de la bestia. Y, por supuesto, los hacks se construyen sobre hacks con el tiempo, ya que los codificadores mencionados implementan soluciones funcionales rápidamente que resuelven la necesidad a corto plazo a menudo a costa de introducir una deuda técnica.

El paradigma que necesita usar es esencialmente obtener mejores personas, capacitar a las personas que tiene bien y enfatizar la importancia de dedicar tiempo a la planificación y la arquitectura. No se puede ser tan "ágil" fácilmente cuando se trabaja con un sistema monolítico. Puede tomar una planificación considerable implementar incluso pequeños cambios. Establecer un excelente proceso de documentación de alto nivel también ayudará a las personas clave a familiarizarse con el código más rápidamente.

Las ideas en las que podría centrarse serían (con el tiempo, gradualmente) aislar y refactorizar las partes clave del sistema de una manera que las haga más modulares y desacopladas, legibles y mantenibles. El truco está en trabajar para cumplir con los requisitos comerciales existentes, de modo que la reducción de la deuda técnica se pueda hacer simultáneamente con la entrega de un valor comercial visible. Por lo tanto, la solución es mejorar las prácticas y habilidades y tratar de avanzar más hacia el pensamiento arquitectónico a largo plazo, como puedo decir, ya lo están haciendo.

Tenga en cuenta que he respondido esta pregunta desde una perspectiva de metodología de desarrollo de software en lugar de una perspectiva de técnica de codificación porque realmente este es un problema mucho más grande que los detalles de codificación o incluso el estilo arquitectónico. Realmente es una cuestión de cómo planeas el cambio.

Me gusta la idea de convenciones de @ RobertHarvey y creo que ayudan. También me gusta la idea de @ KarlBielefeldt de "documentar sobre la marcha" y sé que es esencial porque esa es la única manera de mantener actualizada la documentación. Pero creo que la idea general es que documentar cómo encontrar todas las piezas de su código, construirlas e implementarlas es importante.

Hace poco envié un correo electrónico a un importante proyecto de código abierto que tenía una configuración XML que generaba código totalmente indocumentado. Le pregunté al responsable: "¿Dónde se documenta este proceso de generación de código XML? ¿Dónde se documenta la configuración de la base de datos de prueba?" y él dijo: "No lo es". Básicamente es un proyecto de contribución única y ahora sé por qué.

Mira, si eres esa persona y estás leyendo esto, realmente aprecio lo que estás haciendo. ¡Prácticamente adoro los frutos de tu trabajo! Pero si pasaste una hora documentando cómo se juntan tus cosas realmente creativas, podría pasar un par de días codificando nuevas funciones que podrían ayudarte. Cuando me enfrento a la pared de ladrillos de "la falta de documentación no es un problema", ni siquiera voy a intentarlo.

En una empresa, la falta de documentación es una gran pérdida de tiempo y energía. Proyectos como ese a menudo se destinan a consultores que cuestan aún más, solo para que puedan descubrir cosas básicas como "dónde están todas las piezas y cómo encajan".

En conclusión

Lo que se necesita no es tanto una tecnología o metodología, sino un cambio de cultura; Una creencia compartida de que documentar cómo se construyen las cosas y por qué es importante. Debería ser parte de las revisiones de código, un requisito para pasar a producción, vinculado a aumentos. Cuando todos crean eso y actúen en consecuencia, las cosas cambiarán. De lo contrario, será como mi contribución fallida de código abierto.

Para responder la pregunta tal como se plantea (en lugar de darle consejos para su situación particular):

El paradigma de programación conocido como programación funcional pura requiere que todo lo que afecta la salida de una función se especifique en los parámetros de entrada. No hay dependencias ocultas o variables globales u otras fuerzas misteriosas que actúen de manera invisible en la base del código. No hay un acoplamiento temporal "tienes que hacer esto primero".

Cada almacén de datos es diferente, pero hay muchas cosas que puede hacer para facilitarles las cosas.

Para empezar, cada fila de la base de datos tenía una columna DATE_ADDED y DATA_UPDATED para que pudiéramos ver cuándo se agregó a la base de datos y cuándo se modificó. También teníamos una columna SOURCE_CODE para poder rastrear dónde ingresaba cada bit de datos al sistema.

Luego, teníamos herramientas comunes que funcionaban en todos nuestros almacenes de datos, como géneros, coincidencias de tablas, rebanadoras y cortadoras de dados, etc.

El código a medida se mantuvo en un mínimo absoluto e incluso entonces, tuvo que confirmar varios estilos de codificación e informes.

Asumiré que ya estás familiarizado con las suites ETL . Hay muchas funciones que obtienes de forma gratuita en estos días que no estaban presentes cuando estuve en el juego hace aproximadamente una década.

También es posible que desee ver los data marts para presentar una versión más amigable y desinfectada de su almacén de datos. No es una bala de plata, por supuesto, pero podría ayudar con ciertos problemas en lugar de tener que reconstruir / corregir su almacén de datos.

No sé qué tan relevante es para su caso, hay algunas estrategias para hacer que las dependencias sean más visibles y el mantenimiento general del código.

• Evite las variables globales, use parámetros en su lugar. Esto se aplica también a las llamadas entre idiomas.
• Evite cambiar / mutar los valores de las variables, tanto como pueda. Cree una nueva variable y úsela cuando sea necesario cambiar el valor, si es posible.
• Haz el código modular. Si no es posible describir qué parte (no cómo) está haciendo realmente en una oración simple, divídala en módulos que satisfagan la condición.
• Nombre sus porciones de código correctamente. Cuando realmente puede describir lo que hace una porción de código en términos simples, esos términos se convierten en el nombre de la porción. Por lo tanto, el código se auto documenta a través de nombres de módulos / clases / funciones / procedimientos / métodos, etc.
• Prueba tu código. Pruebe si las entidades en su código justifican sus nombres, discutidos en el punto anterior.
• Registrar eventos en el código. Al menos mantenga dos niveles de registro. El primero siempre está habilitado (incluso en producción) y registra solo eventos críticos. Y use el otro para registrar básicamente todo, pero se puede activar o desactivar.
• Encuentre y use las herramientas adecuadas para navegar, mantener y desarrollar su base de código. Incluso una simple opción de "Buscar todo" de Visual Studio Code me facilitó mucho la vida en ciertos casos.