Resumen del problema:

En pocas palabras, heredé una base de código y un equipo de desarrollo que no puedo reemplazar y el uso de God Objects es un gran problema. De cara al futuro, quiero que refactoricemos las cosas, pero estoy recibiendo un rechazo de los equipos que quieren hacer todo con God Objects «porque es más fácil» y esto significa que no se me permitiría refactorizar. Retrocedí citando mis años de experiencia en desarrollo, que «soy el nuevo jefe que fue contratado para saber estas cosas, etc., y también lo hizo el representante de ventas de cuentas de compañías offshore, y esto ahora es a nivel ejecutivo y mi reunión es mañana y quiero ir con mucha munición técnica para defender las mejores prácticas porque siento que será más barato a largo plazo (y personalmente siento que eso es lo que preocupa al tercero) para la empresa.

Mi problema es a nivel técnico, sé que es bueno a largo plazo, pero estoy teniendo problemas con el ultra corto plazo y el plazo de 6 meses, y aunque es algo que «sé» con lo que no puedo «probarlo referencias y recursos citados fuera de una persona (Robert C. Martin, también conocido como el tío Bob), ya que eso es lo que se me pide que haga, ya que me han dicho que tener datos de una persona y solo una persona (Robert C Martin) no es un argumento suficientemente bueno.

Pregunta:

¿Qué son som Los recursos que puedo citar directamente (título, año de publicación, número de página, cita) de reconocidos expertos en el campo que dicen explícitamente que este uso de Objetos / Clases / Sistemas «Dios» es malo (o bueno, ya que estamos buscando el solución más técnicamente válida)?

Investigación que ya he realizado:

  1. Tengo varios libros aquí y he buscado en sus índices el uso de las palabras «objeto de dios» y «clase de dios». Encontré que, curiosamente, casi nunca se usa y la copia del libro de GoF que tengo, por ejemplo, nunca lo usa (al menos según el índice que tengo frente a mí) pero lo he encontrado en los dos libros a continuación, pero quiero más Puedo usar.
  2. Revisé la página de Wikipedia para «Objeto de Dios» y actualmente es un código auxiliar con pequeños enlaces de referencia, así que aunque personalmente Estoy de acuerdo con lo que dice, no tiene mucho que pueda usar en un entorno donde la experiencia personal no se considera válida. El libro citado también se considera demasiado antiguo para ser válido por las personas con las que estoy debatiendo estos puntos técnicos como argumento lo que están haciendo es que «alguna vez se pensó que era malo, pero nadie pudo probarlo, y ahora el software moderno dice que los objetos» dios «son buenos para usar». Personalmente creo que esta afirmación es incorrecta, pero quiero probar la verdad , sea lo que sea.
  3. En «Principios, patrones y prácticas ágiles en C #» de Robert C Martin (ISBN: 0-13-185725-8, tapa dura) donde En la página 266 dice «Todo el mundo sabe que las clases divinas son una mala idea. No queremos concentrar toda la inteligencia de un sistema en un solo objeto o una sola función. Uno de los objetivos de OOD es la partición y distribución del comportamiento en muchas clases y muchas funciones «. – Y luego continúa diciendo que a veces es mejor usar God Classes de todos modos (citando microcontroladores como ejemplo).
  4. En Código limpio de Robert C Martin: un manual de artesanía de software ágil «página 136 (Y solo esta página) habla sobre la» clase de Dios «y la señala como un excelente ejemplo de una violación de la regla» las clases deben ser pequeñas «que usa para promover el Principio de Responsabilidad Única» a partir de la página 138 .

El problema que tengo es que todas mis referencias y citas provienen de la misma persona (Robert C. Martin) y son de la misma persona / fuente. Me han dicho que debido a que él es solo una vista, mi deseo de no usar «Clases de Dios» no es válido y no se acepta como una mejor práctica estándar en la industria del software. ¿Es esto cierto? ¿Estoy haciendo las cosas mal desde una perspectiva técnica al tratar de seguir las enseñanzas del tío Bob?

Objetos de Dios y programación y diseño orientados a objetos:

Cuanto más pienso en esto, más creo que es algo que aprendes cuando estudias POO y nunca se menciona explícitamente; es implícito para bien el diseño es mi pensamiento (siéntase libre de corregirme, por favor, como quiero aprender), el problema es que «sé» esto, pero no todo el mundo lo sabe, así que en este caso no se considera un argumento válido porque efectivamente estoy llamando se considera una verdad universal cuando, de hecho, la mayoría de la gente la ignora estadísticamente, ya que estadísticamente la mayoría de las personas no son programadores.

Conclusión:

No sé qué buscar para obtener los mejores resultados adicionales para citar, ya que están haciendo una afirmación técnica y quiero saber la verdad y poder probarla con citas como un verdadero ingeniero / científico, incluso si estoy predispuesto en contra de los objetos divinos debido a mi experiencia con el código que los utilizó. Cualquier ayuda o cita será muy apreciada.

Comentarios

  • Pídales documentación de objetos de Dios como buena práctica.
  • ¡Huir! No ‘ no quiere trabajar allí.
  • Defina su comprensión de » Objeto de Dios » y cómo se relaciona con su pregunta. Gasta 4 párrafos diciendo que God Class no es ‘ t un término estándar en la literatura. Entonces, ¿por qué lo estás usando? Si usa términos estándar de la industria y puede mostrar cómo se aplican esos conceptos a su proyecto actual, entonces podría convencer a algunas personas de su punto. Usar palabras inventadas en una reunión de negocios solo socavará su argumento. Existen términos estándar de la industria: usted no es ‘ t la primera persona en ver una pesadilla de todo es global o de un solo objeto, o lo que sea que esté tratando de describir.
  • Te ‘ te falta el término » antipattern «. Al hacer una búsqueda en Google de » god object antipattern «, se obtienen toneladas de páginas sobre las razones por las que ‘ es malo.
  • No debes ‘ no estar atacando al objeto dios sino a los problemas que crea. Como: tenemos un acoplamiento muy estrecho entre todo y un cambio en A requiere también cambios en B, C y D. Entonces, para ayudar contra eso, ‘ vamos a extraer clases. O: queremos que el código esté en un marco de prueba y podemos ‘ hacer eso, ¿qué vamos a hacer? Además, trate de evitar el uso del término » Dios «, las personas que no sean receptivas pensarán que usted ‘ utilizar hipérboles.

Respuesta

El caso para cualquier cambio de práctica se fundamenta en la identificación de los puntos débiles creado por el diseño existente. Específicamente, necesita identificar qué es más difícil de lo que debería ser debido al diseño existente, qué es frágil, qué se está rompiendo ahora, qué comportamientos no se pueden implementar de una manera simple como resultado directo (o incluso algo indirecto) de la implementación actual o, en algunos casos, cómo se ve afectado el rendimiento, cuánto tiempo lleva poner al día a un nuevo miembro del equipo, etc.

En segundo lugar, el código de trabajo supera cualquier argumento sobre la teoría o el buen diseño Desafortunadamente, esto es cierto incluso para el código incorrecto. Por lo tanto, tendrá que proporcionar una alternativa mejor, lo que significa que usted, como defensor de mejores patrones y prácticas, tendrá que refactorizar para encontrar un mejor diseño. Encuentre un plano estrecho de estilo trazador de bala a través del diseño existente e implemente una solución que, quizás, para la iteración uno, mantenga la implementación del objeto divino funcionando, pero difiera la implementación real al nuevo diseño. Luego, escriba un código que aproveche este nuevo diseño y muestre lo que gana debido a este cambio, ya sea en rendimiento, facilidad de mantenimiento, características, corrección de errores o condiciones de carrera, o reducción de la carga cognitiva para el desarrollador.

A menudo es un desafío encontrar un área de superficie lo suficientemente pequeña para atacar en sistemas con una arquitectura deficiente, puede tomar más tiempo del que le gustaría entregar un valor inicial, y la recompensa inicial puede no ser tan impresionante para todos, pero también puede trabajar para encontrar algunos defensores de su nuevo enfoque si lo combina con miembros del equipo que sean al menos un poco comprensivos.

Lamentar el Objeto de Dios solo funciona cuando está predicando a el coro. Es una herramienta para nombrar un problema, y solo funciona para resolverlo cuando tienes una audiencia receptiva que es mayor y lo suficientemente motivada para hacer algo al respecto. Arreglar el objeto de Dios gana la discusión.

Dado que su preocupación inmediata parece ser la aceptación de los ejecutivos, creo que es mejor que defienda que reemplazar este código debe ser un objetivo estratégico y vincularlo con los objetivos comerciales de los que es responsable. Creo que Puede argumentar que puede proporcionar alguna dirección técnica trabajando primero en un aumento técnico en lo que cree que se debe hacer para reemplazarlo, preferiblemente con recursos de uno o dos técnicos que tengan reservas sobre el diseño actual.

Creo que ha encontrado suficientes recursos para justificar su argumento; las personas en tales reuniones solo prestarán atención al resumen de su investigación y dejarán de escuchar después de que mencione dos o tres fuentes que lo corroboran.Inicialmente, su enfoque debe estar en obtener una compensación para resolver el problema que ve, no necesariamente en demostrar que alguien más está equivocado o que usted tiene razón. Este es un problema social, no lógico.

En un rol de liderazgo tecnológico, debe vincular cualquiera de sus iniciativas con los objetivos comerciales, por lo que lo más importante para presentar su caso a los ejecutivos es cuál el trabajo servirá para esos objetivos. Debido a que también se le considera el «chico nuevo», no puede «simplemente esperar que la gente se deshaga de su trabajo o esperar que se alinee rápidamente; necesita generar confianza demostrando que puede cumplir. Como preocupación a largo plazo, en un rol de liderazgo, también debe aprender a concentrarse en los resultados, pero no necesariamente a estar apegado a los aspectos específicos del resultado. Ahora está allí para proporcionar una dirección estratégica, eliminar los obstáculos tácticos del progreso de su equipo y ofrecer orientación a su equipo, no para ganar batallas de credibilidad con los miembros de su propio equipo.

Tomar una decisión de arriba hacia abajo lo hará rara vez ser creíble a menos que tenga algo de piel en el juego; si se encuentra nuevamente en una situación similar, debe concentrarse más en la construcción de consenso dentro de su organización en lugar de escalar una vez que sienta que la situación está fuera de control.

Pero teniendo en cuenta dónde se encuentra ahora, diría que lo mejor que puede hacer es argumentar que su enfoque traerá beneficios medibles a largo plazo según su experiencia y que está en consonancia con el trabajo de profesionales reconocidos como tío Bob y compañía, y que le gustaría pasar unos días / semanas dando el ejemplo en una refactorización estrecha del aspecto más rentable, para demostrar cómo debería verse su visión del buen diseño. Sin embargo, tendrá que alinear su caso con objetivos comerciales específicos más allá de sus preferencias personales.

Comentarios

  • Un buen punto acerca de que es un problema social. Debe ser la razón por la que hay tanto código mal escrito y aplicaciones mal diseñadas.
  • +1 por vincularlo con ‘ business speak ‘ como tal; intenta hacerlo lo más relevante posible para tu audiencia. Si ‘ estás hablando con ejecutivos, haz hablar sobre cómo el estándar de código tiene un vínculo directo con el mantenimiento y el rendimiento, y discutir cómo esto se relaciona con las finanzas generales del proyecto, la estabilidad a largo plazo, etc. Parece que usted ‘ ha sido contratado por sus conocimientos; recuerde esto. (No ‘ no se convierta en un administrador idiota que piensa él siempre sabe más , pero en este caso ‘ estás 100% correcto.)
  • +1 para » el código de trabajo supera cualquier argumento sobre la teoría o el buen diseño. » Algo que a menudo olvidamos en nuestra búsqueda para un código perfecto.
  • Excelente respuesta, mucha sabiduría para los aspirantes a líderes de equipo.

Respuesta

Primero, debe presentar que cualquier organización medible debe adoptar las mejores prácticas de la industria. Diciendo que «¡simplemente funciona para nosotros!» no se puede medir, ni en tiempo ni en recursos, ya que es simplemente impredecible. La ingeniería de software es una ciencia tanto como cualquier otro campo de la ciencia, y estos conceptos se han estudiado, investigado, probado y documentado.

  1. el God Object es un anti-patrón que establece que

    En la ingeniería de software, un antipatrón (o antipatrón) es un patrón que se utiliza en operaciones sociales o comerciales o en ingeniería de software que puede ser de uso común, pero que es ineficaz y / o contraproducente en la práctica.

  2. En la conferencia Google IO de 2009 , este tema se explicó parcialmente cuando el MVP se explicó el patrón. Puede que no sea relevante para el Objeto Dios, pero puede darte algo de munición.

  3. Además, el uso de este anti-patrón viola la principio de responsabilidad única en diseños orientados a objetos, que establece que:

    cada clase debe tener una sola responsabilidad, y esa responsabilidad debe estar completamente encapsulado por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.

  4. El El blog Decaying Code también habla de esto y de su solución.

  5. No podemos hablar del principio de responsabilidad única sin hablar del objeto acoplamiento .

    […] acoplamiento o dependencia es el grado en que cada módulo de programa se basa en cada uno de los otros módulos.

    Donde tener un sistema estrechamente acoplado puede causar assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Un mayor nivel de acoplamiento de objetos significa menos cohesión y viceversa. Los objetos de Dios son un buen ejemplo de acoplamiento estrecho, ya que saben más de lo que deberían, por lo que los sobrecarga de responsabilidad y, por lo tanto, limita en gran medida la reutilización del código.

  6. Al diseñar una aplicación compleja, simplicidad debe venir a la mente. Los problemas grandes deben descomponerse en otros más pequeños, que son más fáciles de administrar, probar y documentar. Esto es especialmente cierto en un paradigma orientado a objetos.

    Con este argumento, regresamos al argumento anti-patrón, pero este paradigma se trata de patrones, representación de objetos del mundo real y, en última instancia, datos encapsulación.

  7. Usted tiene razón cuando dice que estas «buenas prácticas» son más existentes en las aulas. Sin embargo, tengo experiencias de enseñanza en la universidad (y en algunas universidades) y solo vi que estos principios se enseñaban en las universidades, especialmente en las facultades de ingeniería. Que es triste. Pero como cualquier buena práctica, aquellos que se esfuerzan por mejorar por lo general aprenden algunos patrones de diseño básicos y, finalmente, entienden cómo moverse entre el acoplamiento y la cohesión.

    Lo que suelo enseñar a los estudiantes es que puede parecer que se requieren más esfuerzos para adoptar buenos estándares de programación, pero siempre da sus frutos a largo plazo. Un buen ejemplo sería alguien que le pide a un programador que escriba una función de clasificación. El programador tiene dos opciones; 1) escriba una función de clasificación rápida de burbujas (menos de 5 minutos) que no será sostenible a medida que la lista de elementos crezca, o 2) escriba un algoritmo de clasificación más complejo (también conocido como optimizado) (clasificación rápida, etc.) que escale mejor con listas más grandes.

Comentarios

  • Los lenguajes de programación orientados a objetos a menudo requieren que si dos ensamblajes fuente independientes son responsables para diferentes aspectos del comportamiento de un objeto ‘ s, será necesario crear instancias de objetos independientes para encapsular esos comportamientos. Desafortunadamente, aunque en muchos casos las subdivisiones más lógicas de funcionalidad entre ensamblajes de código no ‘ t coinciden con la subdivisión más lógica de funcionalidad entre instancias de objetos, I ‘ no he visto mucha discusión sobre la distinción de los dos tipos de subdivisión.
  • Creo que esto está un poco fuera de tema para esta pregunta. Aquí ‘ no estamos hablando del antipatrón del Objeto Dios, sino del acoplamiento y la cohesión del código, que es un tema mucho más amplio y muy subjetivo.

Respuesta

Oh, aquí voy, necrondo otra vieja pregunta pero supongo que no ganaste este argumento y aquí «s por qué.

Suena como un problema cultural

Tú «eres su gerente, pero no puede reemplazarlos y tiene que ir a sus gerentes para que hagan lo que usted cree que deberían hacer, que en este caso supongo que es al menos eliminarlo con los objetos divinos avanzando. Me suena como un caso clásico de código que refleja la cultura en la que nació. En otras palabras, el objeto de Dios es cómo funciona esta empresa. ¿Quieres hacer algún tipo de cambio significativo? Siempre vas al mismo lugar para ello. en última instancia, ya que aparentemente todas las decisiones deben aclararse desde arriba.

Habiendo sido p rivido a múltiples intentos fallidos de limpieza de código heredado y cambios de política de código Ahora soy de la opinión de que no se puede luchar contra la cultura que hizo posible el código en primer lugar cuando esa cultura todavía está firmemente arraigada o, al menos, la cultura de lucha es un trabajo cuesta arriba muy difícil que es poco probable que alguien pueda pagarme lo suficiente o darme el poder suficiente para sentir que fue un esfuerzo que valió la pena y que probablemente volverá a tener éxito.

Antes de que pueda haber un cambio, tienen que estar motivados para cambiar y, desafortunadamente, como programadores a quienes les importa lo suficiente leer Stack de vez en cuando, es difícil para nosotros entender que no todo el mundo está motivado por las mismas cosas. He ganado muchos argumentos racionales en mis experiencias, pero al final del día, la empresa sufre desarrolladores intelectualmente perezosos por una razón.

Tal vez las preocupaciones comerciales hayan estado motivadas a pensar solo en el mañana en lugar de la próxima semana o cinco años después (un escenario especialmente frustrante cuando eres hijo de inmigrantes de un país que construyó una bóveda de semillas en el Ártico en caso de apocalipsis). Quizás tengan miedo al cambio.Tal vez valoren demasiado la antigüedad hasta el punto de que la cadena de mando no tenga sentido, incluso cuando tienen que contratar de fuera para traer un líder o gerente del equipo de desarrollo porque reconocen que nadie en su equipo de por vida ha crecido lo suficiente en su tiempo. allí (o porque dichos vitalicios no quieren el riesgo asociado con la responsabilidad). O, y he visto esto, tal vez sea el fenómeno muy real y deprimente de la mediocridad que se defiende a sí misma porque sabe en el fondo que puede » Para competir con la calidad y cuando hay suficientes payasadas para todos, es imposible averiguar a quién culpar cuando todo se derrumba regularmente.

¿Cómo se combate los problemas que, en última instancia, están arraigados en el miedo o métricas rotas para el éxito? Te diré esto, se necesita mucho más que incluso un equipo de desarrollo comprometido y de calidad y tenías mucho menos que eso por el sonido en el momento en que se publicó esta Q.

En el evento no imposible de que no sea un problema cultural intratable …

Ahora asumiendo que hay personas en la parte superior son muy receptivos al cambio, y en realidad están dispuestos a confiar en usted para lograrlo, realmente solo necesita puntuar todos sus argumentos con dinero y oportunidades perdidas.

Cada vez que se necesita más tiempo para capacitar a alguien Como novedad en esta ridícula base de código, cada vez que se tarda más en modificar o agregar una nueva función a algo, cada vez que se vuelve prohibitivamente difícil exponer los puntos finales a otro sistema de una empresa con la que desea asociarse, está costando dinero. maldito dinero. Lo más importante es que deja una ventana abierta para que un competidor más pequeño y ágil se abalanza sobre ti, poniéndote en una posición en la que todo lo que puedes hacer es reaccionar demasiado lento. y finalmente arrebatárselo todo.

Simplemente reconozca que una cultura particularmente obstinada y estúpida mantendrá el status quo a toda costa, incluso si el techo físico real de la empresa está en llamas porque

Comentarios

  • Dejé la empresa poco después. intentaron contratarme a tiempo completo y hacer que me mudara a Nueva York desde Seattle para aceptar la oferta; Básicamente les dije » De ninguna manera, yo ‘ no me mudaré a Nueva York cuando el equipo que administraría esté en Bellevue, WA » y en ese momento básicamente crucé la calle y conseguí un trabajo en MSFT hasta que encontré algo mejor.
  • @honestduane Sí, ese conjunto de expectativas solo dice mucho. Bien por ti en GTFO.

Respuesta

Podrías citar algunos de los principios de programación orientados a objetos más básicos, como Acoplamiento flojo y alta cohesión. Un «objeto de Dios» suena como si emparejara clases no relacionadas y tiene poca cohesión.

Respuesta

Siempre puedes preguntarle al tío Bob .

La cosa es que es tan obvio para las personas con algún sentido que una vez que se explica, no necesita ser re-referenciado por una multitud de autores. Solo necesita ser una sola fuente.

Otros términos con los que puede comenzar a buscar fuentes son:

  • SÓLIDO
  • Ley de Demeter
  • Big Ball of Mud

Todos estos expresan conceptos relacionados que podrían generar fuentes de referencia viables, aunque en realidad no lo nombran como tal.

En última instancia sin embargo, usted es el jefe. La razón para hacerlo es porque usted lo dice, y aunque para ser considerado un buen gerente debe estar preparado para justificar sus decisiones; ya lo ha hecho, y si todavía hay resistencia, el curso de acción correcto es que su equipo haga lo que «se le indique.

Comentarios

  • » si todavía hay resistencia, el curso de acción correcto es que su equipo haga lo que ‘ se le haya dicho » Tal vez el curso de acción correcto sea renunciar en lugar de hacer que su equipo se sienta miserable ..?
  • El gerente ‘ s La decisión se ha justificado adecuadamente, y si el equipo no ‘ no está de acuerdo, entonces el problema es del equipo. El OP fue contratado por su experiencia y no se le permitió usarlo para beneficiar a la empresa porque los colegas no ‘ t se comportaron razonablemente no ‘ t aceptable. Dejemos que ‘ s le dé la vuelta a su afirmación: ¿por qué no ‘ t los miembros del equipo que se resisten a renunciar si su visión del trabajo es incompatible con ¿el de la empresa?
  • Punto justo. Depende de cómo quieras dirigir el equipo. Pero en mi experiencia, obligar a las personas a hacer cosas en contra de su voluntad solo conduce a la miseria. Prefiero ver God Objects en todo el código base que un miserable equipo de desarrollo. Quizás la respuesta sea enviarlos a un curso de formación. Todo el mundo ama un curso de formación. Ganar-ganar.
  • El desarrollador principal / gerente / lo que sea debe tomar todas las medidas razonables para garantizar que el equipo mantenga una buena relación de trabajo entre sí. Si la capacitación adicional es útil, entonces considérelo como una opción, pero esto parece ser como un caso de ignorancia intencional, y decirle a alguien que necesita ser capacitado para entender su idea cuando lo que ellos piensan que ‘ lo hecho está en desacuerdo, en lugar de no entender, podría ser contraproducente. Me cuesta imaginar formas de tratar con personas que ‘ no quieren aprender.

Responder

¿Cómo puedo probar o refutar que los objetos «dios» están equivocados?

No puedes.

Este tipo de conjetura no es susceptible de prueba matemática, y la prueba matemática es el único tipo de prueba que es sólida.

Incluso si intenta reemplazar la palabra emotiva «incorrecto» con medidas cuantificables de los efectos del uso de objetos divinos, encontrará que:

  1. las medidas disponibles son burdas,
  2. hay pocos estudios creíbles donde esas medidas se hayan cuantificado para el código producido por programadores profesionales
  3. hay pocos o ningún estudio creíble donde las construcciones del lenguaje o los (anti) patrones de diseño se hayan vinculado a esas medidas.

Y eso es ignorar la cuestión de decidir cuándo un objeto en particular es un objeto «dios».

En el mejor de los casos, este tipo de estudio solo podría demostrar una correlación empírica. No es una prueba genuina.

Lo que realmente estás haciendo es debatir los pros y los contras de los objetos «divinos» con el fin de cambiar las « opiniones de otras personas … y luego la práctica de su organización.

No use palabras como «prueba» o las personas con las que está debatiendo pueden reírse en su cara.

Respuesta

Es posible que desee ver al gurú de la semana n. ° 84 . Se trata de objetos divinos (monolitos) y cómo son malos.

Extracto:

(Mayor) Aísla funcionalidad potencialmente independiente dentro de una clase […] (Menor) Puede desalentar la ampliación de la clase con una nueva funcionalidad […]

Respuesta

No estoy seguro de que su equipo esté realmente interesado en la prueba académica de que «los objetos de Dios están mal».

Desde un punto de vista psicológico, su enfoque de refactorización puede malinterpretarse como un ataque a la competencia del equipo al estilo: «el equipo ha hecho un mal trabajo», aunque el programa está funcionando como se esperaba.

Lo que realmente quiere hacer es hacer frente a los efectos secundarios negativos del «código spagetti» y los «objetos de Dios»: explotar los costos de agregar nuevas funciones debido al aumento de errores causados por efectos secundarios.

Beeing muy Puede ser más útil hacer preguntas específicas y en lugar de dar respuestas: 

manager > Why did implement the new tax-calculation schema took more than 4 weeks team > because {reason a} manager > And why was {reason a}? team > because {reason b} manager > And why was {reason b}? ... team > because {reason z} manager > what could we do to avoid {reason z} ? team > refactor code

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *