¿Por qué mi jefe no me deja reescribir todos nuestros backends actuales en Node.js?

En términos generales, si sus backends funcionan, ¿por qué necesita reescribirlos?

    • Probablemente no entienda la complejidad del software de trabajo, lo verá como contaminado y lleno de cosas de la “vieja escuela” que podrían reescribirse copiando / pegando cosas de StackOverflow O invocando funciones de lindas bibliotecas .js. Probablemente parezca ser ofensivo aquí, pero esa es la causa más probable de que quieras hacer esa reescritura. ¿Por qué pienso eso? Porque quería hacer ese tipo de cosas varias veces por razones similares (irrazonables) hace varios años.
    • “Mirando su código, obviamente soy más inteligente que los viejos que crearon el software original”. Aunque nadie lo dice tan explícitamente, muchos desarrolladores piensan eso pero fallan cuando su nuevo código no es mejor que el anterior y no se escala.
    • Sus backends usan protocolos de comunicación de la vieja escuela, no los estándar utilizados en estos días: no REST, sino probablemente SOAP o secuencias de cadenas patentadas a través de sockets TCP desnudos, etc. y desea usar los protocolos de vanguardia. Esto se puede solucionar agregando capas de comunicación sobre las actuales. Si la comunicación entre sus backends es solo interna, entonces volvemos a: Si funciona, ¿por qué reescribirla?
    • Los backends de su empresa no son tan escalables como desearía y están compilados como un solo archivo ejecutable con un montón de bibliotecas compartidas. Dado que sus necesidades se ampliaron, también debe tener sus backends a escala. Esto se puede hacer a través de amplias refactorizaciones: puede comenzar a dividir sus servicios en varios servicios más pequeños que se pueden implementar en diferentes máquinas; o probablemente simplemente puede modificar su código para distribuir los DB o algo así. No es tan bueno como los microservicios, pero es una mejora.

Reescribir es una palabra muy pesada y costosa. Reescribir en realidad significa tener un equipo que mantenga el código actual funcionando y que otro equipo escriba desde cero la aplicación. Probablemente, este último nunca alcanzará el nivel de madurez encontrado en el primero que fue construido lentamente con muchos comentarios de los clientes, iteraciones y lanzamientos.

Lea este artículo, es muy interesante:

Cosas que nunca debes hacer, Parte I

Déjame contarte un poco de historia de la computadora.

A principios de la década de 1970, los pioneros informáticos diseñaron el software de procesamiento de datos más útil, como la planificación de contabilidad y fabricación (en contraste con el software utilizado en la automatización). Estos programas fueron escritos para mainframes que tienen hardware y sistema operativo propietarios y diferentes. La financiación fue realizada por GENERALS, que es General Motors, General Electries y General Dynamics. Todos emplean a los mejores especialistas en muchos campos diferentes.

Cuando surgieron las mini computadoras (tamaño de refrigerador) y PCS, estos programas tuvieron que ser reescritos.

Las reescrituras crearon tanto oportunidades como caosses ya que el trabajo se realizó con menos presupuestos, menos habilidades. Muchas empresas de software lo hicieron bien, pero muchas más se declararon en quiebra y desaparecieron. Más importante aún, muchas empresas usuarias fueron a la pared por invertir mal en las informatizaciones.

¡Me sorprendería mucho si alguna empresa eligiera reescribir su software sin un nuevo tipo de cambio revolucionario que lo hiciera necesario!

Por supuesto, supongo que si estás hablando de back end que tienes algo más complejo, entonces solo un sitio web muy simple. Entonces, ¿conoce el negocio de los usuarios, los requisitos de los usuarios, las experiencias de mantenimiento de los usuarios, los planes futuros de los usuarios, la planificación comercial de su empresa, la experiencia del personal y más que se pueden enumerar. Si no lo olvidas !!

Porque su jefe es, aparentemente, competente.

No tengo suficiente información, así que asegúrate, pero …

  • Porque beneficiará más al negocio si agrega funciones.
  • Su equipo existente contiene algunos expertos en la plataforma actual y ninguno para el nodo.
  • A su equipo actual le gusta la plataforma existente y no el nodo.
  • La aplicación existente continuará evolucionando mientras compites para ponerte al día. Como tal, cualquier cosa que liberes siempre estará detrás de lo que existe.
  • Tu jefe no confía en ti para que hagas un buen trabajo.
  • La plataforma existente se seleccionó para este problema y el nodo no coincide con el espacio del problema ni con la plataforma existente.

Tal vez fue porque escuchó sobre esta entrevista con Ryan Dahl, el tipo que inventó Node.js: Episodio 8: Entrevista con Ryan Dahl, Creador de Node.js – Mapping The Journey

En particular, la sección donde Dahl dice:

Dicho esto, creo que Node no es el mejor sistema para construir un servidor web masivo. Yo usaría Go para eso. Y honestamente, esa es la razón por la que dejé Node. Se dio cuenta de que: oh, en realidad, este no es el mejor sistema del lado del servidor.

Cuando el tipo que realmente inventó una herramienta comienza a hablar, eso envía una señal bastante inequívoca.

Voy a responder sin ningún prejuicio de idioma en particular por un momento:

Primero, ¿cuál es el backend actual escrito, qué tan grande es y qué tan complejo es?

¿Cuál es el valor comercial del software de back-end actual y cuánto costó desarrollarlo?

Cuando tenga TODAS ESAS respuestas, háganos saber y estaremos encantados de contarle todas las razones por las que volver a escribirlo en node.js es una mala, mala, mala idea.

Ignora mirar mi Descripción (enamorado de JS).

No puedes ir y reescribir el backend en un idioma diferente. Si aún no está roto, ¿por qué su jefe debería invertir su tiempo en reescribirlo? En cambio, si ya ha invertido tanto tiempo y recursos para hacer el backend en el idioma, es por eso que debería invertir más tiempo y recursos para reescribirlo todo.

Solo puede convencerlo de que lo haga si el modelo actual le está costando poco beneficio o si el rendimiento lo está matando y reescribirlo podría hacer que la ganancia vuele de cualquier manera; de lo contrario, acepte permitir que el equipo escriba su futuro backend en NodeJS

Reescribir un back-end en cualquier otro idioma rara vez es un caso positivo en términos de costos y beneficios. Tal vez si el back-end se desarrolla aún más, es una opción considerar escribir las partes adicionales en un lenguaje algo compatible (Java – Scala o Kotlin, etc.) pero volver a escribir un back-end completo es en gran medida un desperdicio de tiempo. Su jefe no le permite reescribir el back-end actual porque es racional. 🙂

Estoy seguro de que lo harían, si pudiera darles una proyección detallada de los beneficios de costo de hacerlo.

Debería mostrar cómo se aumentarían los ingresos o se reducirían los costos operativos.

También necesitaría una forma de demostrar que todas las funciones de back-end, incluidas las peculiaridades y los errores, se reprodujeron fielmente.

Todos los requisitos no funcionales deberán estar presentes, incluidas las habilidades del personal en operaciones y desarrollo.

Porque hay un costo involucrado, su tiempo, y porque su jefe no siente que ese costo sea justificable.

Además, puede ser un problema de los sistemas de soporte si se va o es despedido.

Porque probablemente no hay justificación para eso. Conociendo la “mentalidad” de node.js, probablemente la estaría reescribiendo cada 1 a 2 años a medida que salga un nuevo marco interesante. La reescritura es un proceso costoso y tiene que tener el beneficio de al menos un gran negocio (las nuevas características que generan ingresos o reducen los costos) como el costo de amortizarse.

Solo tu jefe puede saber la respuesta a esta pregunta.

Debe presentar el caso para una reescritura, no pedirle a su jefe que defienda no reescribir.

Si yo fuera tu jefe, incluso escuchar “js” como parte de lo que estabas diciendo provocaría una reacción instintiva de despedirte y quemar tu escritorio.

Creo que es bastante simple:

El beneficio no vale el costo.

Reescribir backends en nodeJS podría mejorar algunos aspectos pequeños de su rendimiento. No hará mágicamente más felices a los usuarios, y ni siquiera afectará marginalmente la satisfacción del usuario a menos que sus backends sean actualmente un problema importante. Probablemente no lo sean.

Si sus backends dependen de cálculos pesados, ¡escribirlo en el nodo será un paso atrás en el rendimiento!

Si sus backends dependen de la integración con muchos servicios antiguos, no solo tiene que volver a escribir su código anterior, sino toda la tubería para conectar su código a otras cosas que usa. Eso es mucho más trabajo de lo que piensas.

El nodo es genial, lo uso regularmente, pero no es la mejor solución para cada problema. Probablemente deberías aprender eso e ir a disculparte con tu jefe.

Si no está roto, no lo arregles. Tal vez su jefe haya escuchado este viejo consejo y lo considere más creíble que usted o sus propuestas. Él / ella podría tener razón. Como señalan otras respuestas, la reescritura necesita muy buena justificación.

Si está absolutamente seguro de que reescribir en Node.js es realmente necesario, y es la mejor opción, y puede hacerlo en un tiempo razonable, y luego puede demostrar que tenía razón, puede tomar riesgos personales y hacerlo sin permiso. Sin embargo, si está equivocado en alguna de sus suposiciones, o es demasiado lento, o si descuida sus deberes al hacerlo, su buena intención fracasa. Puede perder su trabajo y reputación, y probablemente se arrepentirá. Si tiene éxito y le hace un gran favor a su empleador y a su jefe, él / ella aún puede castigarlo por no obedecerlo y despedirlo, pero nadie puede quitarle su orgullo por su gran logro.

Una alternativa más segura es hacer lo que le dicen o encontrar otro empleador con un jefe que comparta su visión.

¿Cómo podríamos saber eso?

Probablemente porque la reescritura mítica rara vez funciona bien.

En el aspecto técnico, puede haber una serie de razones no exclusivas, incluido que Node podría no ser la mejor tecnología para ello (y diría que es casi seguro que no lo es, pero nunca se sabe).

Porque Node JavaScript es un lenguaje de aficionados para hacer aplicaciones de lista de tareas. Muchos pretendientes han ido y venido, pero PHP sigue siendo el verdadero rey del dominio de back-end.

No mencionaste en qué idioma / marco está escrito el backend ahora.

Sin embargo, denos una sola razón válida para hacerlo. ¿Cuál sería el beneficio para la empresa?