¿Qué tienen que ver Star Wars, el grupo Tatu y la combinación Ctrl-Alt-Del con el código Legacy? ¿Qué hacer cuando llegas a un gran proyecto y te encuentras con un abismo de código antiguo incomprensible? ¿Y cómo es más eficiente transmitir a las autoridades que los costos laborales para eliminar la deuda técnica están dando resultado?
Los informes de
Dylan Beatty no están exentos de bromas, pero estas bromas acompañan discusiones bastante serias sobre los principales problemas de desarrollo. Esto es muy adecuado para el final de la conferencia: cuando la audiencia ya ha escuchado mucho hardcore y ya no puede percibir diapositivas de código, es hora de preguntas más generales y una presentación brillante. Y cuando nuestra conferencia DotNext 2018 Moscú .NET se completó con el discurso de Dylan sobre el código Legacy, al público le gustó más.
Por lo tanto, ahora para Habr, hemos hecho una versión traducida del texto de este discurso: para los donantes y para todos los demás. Además del texto, debajo del corte hay una grabación de video original en inglés.
Hola, mi nombre es Dylan Beatty. El tema de conversación es muy cercano a mí y, en mi opinión, es extremadamente importante para todos los involucrados en el desarrollo de software: hablaremos sobre el código heredado.
Primero, diré algunas palabras sobre mí. Comencé a desarrollar sitios web en 1992, según los estándares de nuestra industria, en tiempos prehistóricos. Ahora soy CTO de la compañía londinense SkillsMatter. Comencé a trabajar allí este año, heredando así la base del código: 75 mil líneas de código no escritas por mí se convirtieron en mi responsabilidad. Parte de mi informe se basa en esta experiencia. Además, soy el MVP de Microsoft y el jefe del grupo de usuarios de .NET de Londres.
¿Qué tienen en común el Doctor Who, la moderna Guerra de las Galaxias, Sherlock y Paddington? Al trabajar en ellos, se utilizó un código heredado. Sé esto porque durante 15 años trabajé en Spotlight. Esta es una empresa con sede en Londres que proporciona una herramienta en línea para actores profesionales que actúan en películas y en televisión. El software, escrito por mí y mi equipo, se utilizó en el trabajo en todos los proyectos mencionados y muchos otros.
En la nueva Guerra de las Galaxias, a algunos no les gustaban los actores, a otros no les gustaba la trama. Pero nadie salió del cine con las palabras "¡No me gusta que se haya usado el ASP clásico en la creación!"
Porque no importa Esta base de código ha estado en producción durante mucho tiempo, y sí, hay un código ASP clásico, que es más antiguo que el .NET completo, que todavía se usa hoy en día para emitir películas y programas de televisión. Es necesario poner énfasis correctamente: son estas películas y programas de televisión los que son importantes, y el código existe solo para resolver problemas. Hasta que lo ejecute, el código en sí no significa nada. El valor solo surge cuando lo lanzas y haces algo con él. Eso es lo que la gente paga: Netflix o DVD. El problema es que es muy fácil olvidarlo.
En general, hoy quiero, entre otras cosas, compartir con ustedes mi experiencia con la misma base de código durante muchos años. Vi cómo evolucionó y cómo otras personas lo conocieron y aprendieron a usarlo. Y el otro lado de esta ecuación es mi nuevo trabajo, que me permitió ver el mismo proceso desde el otro lado, cuando tuve que familiarizarme con el código de otra persona.
Pero primero, hablemos sobre qué tan rápido están cambiando las cosas en TI.
Eche un vistazo al primer iPhone: hoy se ve completamente antiguo y voluminoso. Y este modelo tiene solo 11 años, apareció en 2007 y luego costó $ 800. Si compró una lavadora, guitarra o bicicleta en 2007, hoy todavía podría usarlas. Pero el primer iPhone ya no funciona, incluso si logras encontrar una copia con una batería y un cargador, todas las cosas que hicieron del teléfono inteligente un dispositivo tan increíble no funcionarán en él.
No podrá abrir el mapa porque los servidores de mapas ya no existen. No podrá acceder a Twitter porque las últimas versiones de la aplicación de Twitter requieren una versión de iOS que no se puede instalar en el iPhone 1. El cliente de Twitter simplemente le responderá: "punto final no encontrado". En esencia, tendrás un fósil en tus manos. Y lo único que funcionará en él es la función de un teléfono normal, aún puede llamarlo. Porque en esta área, a diferencia de TI, los estándares durante 11 años no han cambiado.
Hagamos un pequeño viaje en el tiempo. ¿Recuerdas este?
¿Recuerdas de qué año fue? Tatu actuó en el Festival de Eurovisión en 2003. Y en 2003, escribí el código ASP, que ahora todavía se usa en producción.
Nos parece que esto fue hace mucho tiempo, pero este código aún funciona. Los fabricantes de teléfonos móviles lograron que la gente comprara un teléfono nuevo cada dos años, para que puedan deshacerse de los desarrollos antiguos, deshabilitar las API, los puntos finales y los servicios. Pero muchas compañías no tienen esa oportunidad y, por lo tanto, continúan apoyando el código escrito cuando Tatu actuó en Eurovisión. Este código es importante porque aún realiza funciones importantes, genera ingresos, es decir, es un código heredado.
Y aunque todos estamos de acuerdo en que Legacy existe, la pregunta sigue siendo: ¿qué es exactamente? Aquí hay un código de muestra:
Mira, piensa: ¿es legado o no? Que piensas
Inventé el dispositivo, quiero vender el año que viene. ¡Lo inserta en el puerto USB, selecciona un código y el dispositivo le dice si es heredado o no!
El código que acabas de ver no es heredado. Fue escrito por
Andrey Akinshin (
DreamWalker ) hace cuatro días. Esto
está tomado de BenchmarkDotNet.
El hecho del asunto es que es imposible determinar si el código es Legacy simplemente mirándolo. Además, el código en sí no tiene nada que ver con eso. Lo importante es lo que sucede a su alrededor: personas, cultura, procesos, pruebas, etc.
Si abre el artículo "Código heredado" en la Wikipedia en inglés, puede leer lo siguiente: "Este es el código fuente relacionado con el sistema operativo o cualquier otra tecnología informática, cuyo soporte o producción ha sido descontinuado. Somos como: "está bien". Y luego está escrito: "Este término fue utilizado por primera vez por George Olivetti en relación con un código respaldado por un administrador que él mismo no escribió este código".
Al final de esta oración hay un enlace al blog de cierto Samuel Mullen. Pensamos: "Interesante, ya veremos". Pero si abrimos la
publicación , ¡veremos que este Mullen, a su vez, se refiere a Wikipedia!
Y, al parecer, nadie más sabe quién era este George Olivetti. Entonces parece que deberíamos buscar una mejor definición.
Michael Faethers dio una de las definiciones más populares de la industria: "El legado es simplemente código sin pruebas". Y Michael escribió un
libro completo sobre este tema, por lo que definitivamente sabe de qué está hablando. Pero aún así, no estoy completamente de acuerdo con su definición.
Por lo tanto, he estado usando mi definición durante varios años: "El código heredado es un código que es demasiado aterrador para actualizar, pero demasiado rentable para eliminarlo".
Más tarde resultó que una definición muy similar ya se
daba independientemente de mí: "un código muy rentable que tenemos miedo de cambiar". Me pregunto de dónde viene este miedo. ¿Qué hay en las pruebas que convierten el código sin ellos en legado?
Una de las herramientas comerciales más antiguas del mundo es un sistema de contabilidad de doble entrada. Tiene muchos cientos de años, y en él cada transacción de un banco o empresa se cuenta dos veces: en una columna escribo cuánto dinero pagué y en la otra, el valor que recibí por ellos. Además, las sumas de ambas columnas deben ser iguales, si hay una discrepancia, se comete un error en alguna parte.
Me parece que la idea fundamental de este enfoque parece muy importante: todas las decisiones que tomamos tienen su efecto dos veces, y si cambia una cosa, en otro lugar definitivamente también tendrá cambios que deben ser monitoreados. Este enfoque dual se puede aplicar al código y las pruebas, o al código y un sistema de monitoreo, o al código y la documentación.
Muchos sistemas que consideramos heredados también existen en dos versiones, pero estas son versiones "en código y en la cabeza de alguien". Y aquí, en mi opinión, se encuentra una de nuestras principales dificultades.
Recuerdo la
tira cómica de una página "Por eso no debes interrumpir a un programador". El desarrollador observa una línea de código simple e inmediatamente comienza a pensar en su cabeza sobre lo que debe reescribirse en el menú de navegación ahora, cómo esto afectará al depurador, que luego deberá cambiarse en el código. Alguien se le acerca y le pregunta: "¿Recibiste mi carta?", Y luego todo este complejo árbol de ediciones sale volando de mi cabeza.
Cuando trabajamos, entramos en un estado alterado de conciencia, nuestro cerebro construye modelos complejos que explican cómo funciona el código. Cuando el código está escrito por una persona (por ejemplo, en un proyecto de inicio o de código abierto), a menudo, además del modelo en la cabeza y el modelo en el código, no hay nada. Esto le permite trabajar muy rápidamente: simplemente traduce lo que tiene en mente al código. El modelo que está en la cabeza es correcto, así que si algo está mal en el código, solo míralo, compáralo con lo que está en la cabeza y el error será visible de inmediato. Y cuando encuentra un error, a menudo esto le muestra que no ha pensado lo suficiente en ningún aspecto, y primero actualiza el modelo en la cabeza y luego el código.
Hay una
publicación maravillosa
de Jessica Kerr , donde ella, entre otras cosas, dice que la invención es cómo correr por una montaña, y el análisis es cómo escalar una montaña. Nos gusta escribir código, es interesante y fácil: comienzas desde cero e inventas algo nuevo, resuelves problemas, escribes algoritmos, métodos y clases. Pero leer el código es difícil: frente a usted desde el principio hay una gran variedad de código de otra persona, y este es un personaje completamente diferente.
Por lo tanto, en muchas organizaciones se puede observar un fenómeno que Alberto Brandolini llamó el "maestro de mazmorras": esta es la persona que escribió la primera versión del sistema. Era esta persona en Spotlight: escribí una parte importante de la primera versión solo, y lo escribí en un ASP clásico, sin documentación y sin pruebas unitarias. Comenzaron a hacer películas con esta herramienta, hicieron Star Wars, obtuvimos dinero y todo fue genial. Pero luego comenzamos a contratar nuevos empleados que al principio no sabían cómo funcionaba todo, y durante dos o tres meses tuvieron que familiarizarse con el sistema.
Pronto, se comenzó a hablar sobre portar el sistema a .NET, porque el ASP clásico no es lo suficientemente confiable ni lo suficientemente rápido. Tales conversaciones siempre serán: sin importar el código que escriba, alguien insistirá en que debe reescribirse. Esto sucede porque esta persona no entiende su código, y escribir código nuevo es más interesante que profundizar en el antiguo. La programación es un trabajo que trae placer, realmente nos gusta. Por lo tanto, es bastante natural que, al presentar una opción, nos inclinaremos a favor de la opción que sea más fascinante.
El propietario de la mazmorra es una persona que conoce todas las trampas del código. Él sabe sobre el botón que no se puede presionar, de lo contrario la aplicación se bloqueará; en el que cuelga TODO desde 2014, al que nadie ha llegado a sus manos. Nosotros en nuestra industria hemos aprendido a no crear más tales sistemas. Es por eso que me encantan los eventos como DotNext, grupo de usuarios, comunidad y StackOverflow: cuando comience un nuevo proyecto, definitivamente se le dirá que necesita escribir pruebas, hacer especificaciones por ejemplo, integración, monitoreo. Por lo tanto, nuestro futuro son los microservicios sin servidor en F # con una cobertura cien por ciento del código con pruebas.
Pero el problema no es el software que tenemos que escribir: nuestro mundo ya está lleno de software. Y, si imagina este software en forma de pirámide, F # sin servidor ocupará solo la parte superior. Un poco más será ASP.NET, de alguna manera cubierto en pruebas. Aún más: Visual Basic en Windows XP. Pero la plataforma de desarrollo de productos comerciales más popular en la historia son las hojas de cálculo de Excel.
Estoy dispuesto a apostar que cada vez que compre un boleto de avión o se aloje en un hotel, de una forma u otra, su nombre aparecerá en algún tipo de hoja de cálculo de Excel. El desarrollo mediante pruebas no tiene en cuenta este enorme bagaje de código ya escrito.
Pero, ¿por qué insistir en reescribir el código antiguo? Al principio, a las personas no les gusta el ASP clásico y quieren reescribir todo en .NET. Luego resulta que necesita reescribir todo en la versión 4.5, luego 4.6, luego .NET Core. JQuery no es bueno, por lo que definitivamente debe cambiar a Angular, después de lo cual aparecerá la línea React, luego Vue.
Sospecho que al menos una de las razones aquí radica en la búsqueda de la moda. Todos nos comunicamos entre nosotros, y una parte importante del trabajo de más alta calidad en nuestra industria se realizó porque los autores querían lograr el reconocimiento y el respeto por las personas de su profesión. Me parece que en nuestra industria hay una adicción excesiva a todo lo nuevo y brillante, y los lenguajes de programación están sujetos a las tendencias de la moda. Pero después de todo, aquellos en los que pasa la moda, por sí mismos, no han cambiado de ninguna manera, todas sus ventajas se han mantenido igual.
Imagine que hay dos hojas de vida en frente de usted:
No tengo ninguna duda de cuál de ellos será mejor para trabajar en problemas realmente importantes. Pero si habla con personas de Recursos Humanos, o con aquellos que acaban de completar un curso de programación, verá que pueden ganar mucho dinero con las habilidades del primer programador, y consideran que las habilidades del segundo son obsoletas. Pero no están desactualizados en absoluto, todavía hay muchos problemas en los que esta persona puede trabajar.
Creo que una de las razones de esta actitud es que la gente tiene miedo. Algunos de mis colegas dejaron nuestro equipo porque querían trabajar en Angular o NodeJS. Cuando les pregunté por qué lo necesitaban, respondieron que si continúan trabajando solo en .NET, después de dos años no podrán encontrar trabajo. Les respondo: ¡muchachos, nosotros con nuestro .NET solo ayudamos a hacer Star Wars! Y dicen: sí, pero todavía no es angular.
No me malinterpreten, respeto su decisión. No se puede hablar de corrupción, solo las personas se preocupan por su futuro y el futuro de su familia si tienen que buscar trabajo. Y en nuestra industria, este problema de seguridad generalmente se interpreta en el sentido de que necesita aprender todo desde cero cada año y medio, de lo contrario perderá competitividad. Muy a menudo, estamos mucho más interesados en la tecnología en sí misma que en nuestra capacidad para resolver problemas.
Además del miedo de quedarse atrás y quedar obsoleto aquí, en mi opinión, el miedo juega un papel importante en el cambio de un sistema que no comprende. Le dan un código del que no sabe nada, pero si algo se rompe, será su responsabilidad, y si cae en medio de la noche, lo despertarán. De ahí surge el miedo.
Como sabemos por la misma Star Wars, el miedo conduce a la ira, la ira conduce al odio, el odio conduce al sufrimiento, el sufrimiento conduce a JavaScript. ¿Cómo trabajamos con nuestro miedo y el miedo de nuestros colegas? En mi opinión, hay tres aspectos principales:
comprensión ,
confianza y
control .
La confianza es tanto la más simple como la más difícil de las tres. Confío en esta computadora portátil porque nunca se ha bloqueado durante una presentación. Tan pronto como esto suceda, mi confianza en él desaparecerá. En el idioma inglés hay un dicho, "la confianza se gana gota a gota, pero se pierde por cubos". Después de un mes de trabajar con una persona, estará listo para admitir que él puede estar bien versado en su negocio, en dos dirá que está bien versado, en tres estará de acuerdo en que él conoce muy bien su negocio. Y después de tres meses y un día, la vulnerabilidad a las inyecciones SQL se revelará en su código, y usted dirá: "Ah, siempre dije que no tenía sentido".
Confiar en otras personas siempre es difícil, porque siempre significa renunciar a cierto grado de control. La confianza en el código también es un tema importante. Después de haber trabajado con el sistema durante cierto tiempo, desea creer que funcionará de acuerdo con sus expectativas. Sus sistemas operativos son estables y confiables, y espera que no se caigan. Confía en las bases de datos de su información y espera que no la pierdan. Espera que los proveedores de la nube garanticen el funcionamiento continuo de su sitio y no vendan la información de sus clientes en el mercado negro.
No hay una forma rápida de ganar confianza. Es cierto que la confianza es transitiva: si confío en ti y tú confías en alguien más, entonces lo más probable es que yo también pueda confiar en esta persona. Si escucho tu opinión y crees que puedes confiar en Amazon, AWS, Azure o Google App Engine, estaré listo para creer que estos son buenos servicios. Pero no hay una forma rápida de ganar confianza.
Pasemos a la
comprensión . En la universidad estudié informática durante tres años. Si los ingenieros civiles siguieran el principio subyacente de nuestra educación, en el primer año construirían cobertizos de madera, en el segundo metal y en el tercero, vidrio avanzado.
En el primer año escribimos pequeños programas en Lisp, en el segundo, pequeños programas en Java, en el tercero, pequeños programas en Scheme y Prolog. No escribimos programas grandes y, lo que es más importante, no intentamos resolverlos.
Pero a los ingenieros civiles no se les enseña el ejemplo de los cobertizos, se ven obligados a comprender rascacielos, puentes, sociedades filarmónicas y edificios como el que estamos ahora. Estos estudiantes aprenden de los proyectos más grandes e impresionantes de su industria. Y si estudiaran de acuerdo con el mismo principio que enseñan ciencias de la computación, entonces el estudiante, enfrentado a un orden real de un rascacielos, no habría pensado en otra cosa que poner cobertizos uno encima del otro hasta que las torres de Petronas se convirtieran.
Es en esta situación que un estudiante que completa un curso de informática se encuentra y se le asigna la tarea de escribir un sistema de adquisición comercial distribuido. Una parte importante del software existente se escribió aproximadamente de la misma manera. Las personas que lo escribieron no eran irresponsables, sino simplemente inexpertas. Hicieron muy bien todo lo que hicieron en la universidad, y esto creó una falsa confianza en sí mismo. Eso fue exactamente lo que fui en un momento y, estoy seguro, muchos de ustedes fueron iguales al mismo tiempo. Actuamos así: escribimos una página web, hacemos un enlace a otra página, luego otra, copiamos el código y todos estarán felices: nuestros clientes tienen un producto, nuestra empresa tiene dinero, nosotros tenemos un bono. Cinco años después, miras esta pesadilla y piensas: ¿cómo podría escribirse esto?
Parte del problema es la capacidad de aprender software. Los ingenieros civiles son buenos para estudiar edificios, los ingenieros de aviación son buenos para aprender sobre aviones. Tomemos literatura: en Guerra y paz puede haber 45 mil líneas (dependiendo de la publicación). Este es uno de los libros más grandes del mundo, requiere un estudio muy serio por parte de personas que se dedican a la crítica literaria. En otras palabras, estudiar un objeto tan grande es un trabajo. El tamaño de la obra más larga de Shakespeare, Hamlet, es de 6 mil líneas. Ahora piense: el kernel de Linux es tres veces más largo que War and Peace. Y estamos hablando de un código muy compacto, bien organizado, con una extensa documentación y una gran comunidad. Sin embargo, entenderlo es similar a tener que entender "Guerra y paz" tres veces.
Mire este gráfico, que muestra el número de líneas en los libros Hamlet, Moby Dick, The Brothers Karamazov, The Lord of the Rings, Atlas Shrugged y War and Peace, así como los núcleos Linux y Mono .
¿Te parece realista esta relación? Por favor, perdóname por engañarte. Este gráfico es en realidad exponencial.
Un gráfico lineal en la siguiente diapositiva:
La idea aquí es muy simple: el software es enorme, simplemente sentarse y leerlo es imposible. Pídale a alguien que se familiarice con el kernel de Linux de la misma manera que le pide a una persona que lea Guerra y paz, Atlas Shrugged, El señor de los anillos y todos los Harry Potter seguidos. Imagina que viniste a una nueva compañía y te dicen desde el umbral que necesitas estudiar todos estos libros, y solo entonces podrás acceder al código. Por supuesto que no.
Leer el código puede ser muy útil: puede comprender cómo funcionan algunos patrones y aprender algunos ejemplos. Pero no puedes imaginar un sistema grande si lo lees como lees un libro. Quizás este enfoque tiene algo noble, pero no conduce a nada, como me parece. Hay demasiado código, y está escrito peor que estos libros.
Si solo leer el código es ineficiente, ¿cómo estudiarlo correctamente? Recordemos a Richard Feynman, Premio Nobel de Física. Para él, el tema de la enseñanza de la ciencia era de gran importancia. Él creía que era necesario enseñar a las personas, no a la ciencia, sino a cómo hacer ciencia adecuadamente. Fue invitado a la Universidad de São Paulo en Brasil, porque en Brasil los estudiantes recibieron calificaciones muy altas, pero al mismo tiempo no fue posible establecer una producción de alta tecnología. Se le pidió a Feynman que ayudara a descubrir cuál era el problema.
Durante varios años, vino a Brasil todos los años durante varias semanas y habló con los estudiantes. Vio que los estudiantes brasileños sabían perfectamente bien, por ejemplo, el nombre del fenómeno que ocurre cuando se aplica presión a un cuerpo cristalino: la triboluminiscencia. Pero ninguno de ellos sabía que si aplastas un trozo de azúcar con un par de alicates en casa en una habitación oscura, verás chispas deslizándose, y esto es triboluminiscencia. Feynman explicó que los estudiantes solo fueron entrenados en libros de texto para aprobar los exámenes, pero no organizaron ningún experimento.
En mi opinión, esto contiene una importante lección para nuestra industria. , . , , , . , .
—
. , , , .
—
. , , . , , - .
. ,
.
.
, , .
, — , , . , , - , ? .
- , , - . .
- «I love LAMP», , , . — , , , . : , , , .
, , , . , . , DLL. , , . , — , . , , — .
— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? Y así sucesivamente.
, , . , , , .
, . , , DLL api.payments.mycompany.com. DLL, , , , , DLL , .
: .
,
: , . . , : , .
. , , . , , . : , , , . , - , . .
Spotlight, ASP Amazon Web Services. , GitHub - « ». , , , , .
- , , . Windows 2016 , ASP, 2003 .
, , , «» , « » Windows 2016 , . ASP.NET MVC 2 , , 3, 4. DLL, , ASP.NET MVC 2, - - microsoft.com, , , Nuget , . Program Files. ASP.NET MVC 2, , .
, . , , - . , : , -?
: , , -?
, , , , . - — -, , . — . , !
, , , - — , .
, . 50 000 , . — 100 000, 200 000… , Int32. , , - id -. , - , , , int, .
, , , . — . , , , .
, , . , , 32 64, . , , . . , , , . , , . , , , .
, 80- 90-, -, , . , . , .
. , — , . , , , , . , .
, . , , . , , . , — « » . , , , . : «, - ?»
, - — , . , , . , ; , — , . . , , . , .
, . , , . , . , . , , , , — , 12 , , , 3 .
, , , . , . , , .
, — ? «definition of done»?
, , GitHub , , , .
, . , . Google Analytics , , . . - , . «», , . — , . , JavaScript, . , .
, , — , . — , 20 . — , .
: , . , . , . GitHub, . - , .
: , .
-. , , , , , , , COBOL. MUMPS? , . , 1960- , 26 . — . , , - .
- , « -» « ». .
:
(control), (alter) (delete) - .
Gracias por su atencion
, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .