Hola Habr!
No hay fin a hablar de
c贸digo limpio , pero el pr贸ximo art铆culo de Dave Nicoletta es muy metaf贸rico y, con suerte, realmente digno de traducci贸n. Que sea un poco "edificante", como el autor advierte a los lectores de antemano en el art铆culo original.
Que tengas una buena lectura.
En casa, a lo largo de los a帽os, se ha establecido un mal h谩bito. Usando cualquier herramienta, nos olvidamos de ponerlo en su lugar. La pr贸xima vez que alguien lo necesit贸, tuvieron que pasar m谩s tiempo buscando una herramienta que resolviendo un problema. Lo m谩s triste es que incluso el que tom贸 el instrumento por 煤ltima vez y lo arroj贸 a cualquier lugar estaba condenado a exactamente las mismas b煤squedas. A menudo result贸 que era m谩s r谩pido comprar nuevos equipos que buscar la herramienta que tenemos, 隆lo sabemos con certeza! - En alg煤n lugar por ah铆.
As铆 que obtuvimos cuatro destornilladores Phillips de tama帽o medio de Philips, tres con una ranura plana, un mont贸n de pinzas y llaves adicionales, juegos de adaptadores. Sin mencionar la impresionante colecci贸n de bol铆grafos, madejas de cinta, bater铆as y otras cosas buenas diseminadas por todas partes.
Una vez que decidimos: 隆eso es suficiente! Asign贸 su lugar para todas las cosas y orden贸 las cosas con nuestro inventario. Herramientas entregadas donadas a la caridad. Hicimos todo lo posible para cultivar la autodisciplina y siempre colocamos las herramientas solo en su lugar despu茅s de trabajar con ellas. La calidad y el volumen de trabajo por unidad de tiempo aumentaron considerablemente. El estr茅s, el desperdicio de dinero y el mal humor se hicieron mucho menos.
Poner orden en el garaje corporativo
驴Qu茅 pasar铆a si los mec谩nicos de autom贸viles que trabajan en un garaje corporativo soltar铆an herramientas en cualquier lugar? Pasar铆an m谩s tiempo buscando herramientas que trabajando realmente. Los detalles se colocar铆an en el lugar equivocado, se perder铆an, oxidar铆an, estropear铆an, simplemente ser铆an robados. Los costos de suministro aumentar铆an enormemente.
Tomar铆a m谩s tiempo completar las tareas, pero la calidad del trabajo disminuir铆a. Cuando un mec谩nico tiene que trabajar con herramientas oxidadas, desgastadas y rotas, es dif铆cil para 茅l ajustar y sujetar las piezas adecuadamente. Adem谩s, el h谩bito de organizar un desastre en el taller afectar谩 inevitablemente la calidad del trabajo.
Los clientes estar谩n hartos de transferencias interminables de trabajos finales. Pronto ir谩n a talleres m谩s confiables. De alguna manera prescindir de ti. Quiz谩s las analog铆as con el desarrollo y soporte de software ya son obvias.
Poner orden en el desarrollo de software
Veamos un ejemplo espec铆fico: refactorizaci贸n incremental.
Esta expresi贸n es desconcertante para muchos. No s茅 qu茅 palabra los confunde: "incremental" o "refactorizaci贸n".
La refactorizaci贸n incremental (gradual) es fundamentalmente diferente de la gran escala. A muchos les parece que cualquier refactorizaci贸n es necesariamente "a gran escala", que debe ser "autorizada" por alguien y, por lo tanto, supuestamente, el trabajo debe ser arrastrado. De hecho, si se descuida la refactorizaci贸n en el curso del trabajo, entonces todo se retrasa significativamente.
La mayor铆a de los entrenadores t茅cnicos, incluido yo mismo, apenas explican la diferencia en este caso; no porque esta diferencia sea, por definici贸n, complicada, sino porque es realmente dif铆cil de formular con palabras. Sin embargo, creo que la costumbre de considerar cuidadosamente el inventario disponible y monitorear el suministro es una buena analog铆a en este caso.
Refactorizaci贸n gradual
Hacer una refactorizaci贸n gradual es como mantener el orden en un banco de trabajo incluso a la altura del trabajo. Us贸 un destornillador - p贸ngalo en su lugar. Antes de cada nueva tarea, no reconstruiremos un taller para esto. El punto, m谩s bien, es la capacidad de terminar ... c贸mo terminar lo que comenzaste. Pelar los extremos.
La refactorizaci贸n gradual no requiere mucho tiempo extra y no requiere el permiso de alguien de arriba. Para el caso, debe pedir permiso para no limpiar el c贸digo, si necesita apresurarse. De hecho, la capacidad de mantener constantemente limpio el c贸digo deber铆a considerarse la habilidad profesional b谩sica de un programador. Es una pena que hoy en d铆a, el "c贸digo limpio" necesite propaganda, y algunos programadores incluso se oponen a traer tanta pureza. La refactorizaci贸n gradual no tiene absolutamente nada con la refactorizaci贸n arquitect贸nica a gran escala, que realmente requiere una planificaci贸n cuidadosa, asignando tiempo, dinero y personas para ello.
Regla Scout
En la programaci贸n, existe una llamada "regla de exploraci贸n": mantenga el c贸digo al menos tan limpio como se recibi贸. Lo mismo se aplica al almacenamiento de herramientas de trabajo en el hogar. Si estamos buscando alicates, pero notamos que el destornillador ranurado accidentalmente lleg贸 a la cruz y el destornillador cruzado lleg贸 a la ranura, nosotros, en el proceso, los colocamos en su lugar. No necesitamos aprobaci贸n oficial para hacer esto.
As铆 es como funciona la refactorizaci贸n gradual. Ante nosotros hay una pieza de c贸digo, y necesitamos agregar una nueva condici贸n a la lista de construcciones disponibles. Notamos que la lista se implementa como un gran bloque if / else. Decidimos que necesita ser redise帽ado como un interruptor o un operador de selecci贸n, mientras agregamos una condici贸n. Se puede argumentar: 驴esto es realmente mucho mejor que el bloque if / else? S铆, tienes raz贸n: no mucho. Pero un poquito mejor. La pr贸xima vez que alguien lea este c贸digo despu茅s de usted, podr谩 refinarlo a煤n mejor, ya que usted ha mejorado su posici贸n inicial. Si alguna vez has hecho algo como esto antes, probablemente te hayas dado cuenta de que solo leyendo cuidadosamente todas las condiciones, a veces encuentras construcciones duplicadas, luego el orden no 贸ptimo de las expresiones; tal vez se encontr贸 con alguna condici贸n que nunca se puede cumplir, o incluso un "agujero" l贸gico a trav茅s del cual toda la secuencia de control caer谩 a trav茅s del bloque if / else, y alg煤n caso no se procesar谩 en absoluto. Al茅grate de haberlo descubierto ahora, y no tarde en la noche, cuando recibas el ticket correspondiente del servicio de soporte t茅cnico. En ese momento, cuando los ojos se unen, no hay absolutamente ning煤n deseo de entender el c贸digo confuso.
Tal vez agregaremos alguna funcionalidad nueva a la aplicaci贸n y notaremos que la funci贸n / m茅todo que escribimos es muy similar a otra (otra) que ya tenemos en la base del c贸digo. Habiendo pasado solo unos segundos, nos libraremos de esa duplicaci贸n, incluso sin las herramientas adicionales que se ofrecen en nuestros servicios en IDEs elegantes. Puede refactorizar sin dudarlo, ya que nos hemos acostumbrado a la autodisciplina y garantizamos que los microtests (pruebas unitarias) que cubren este caso ya se han escrito. Entonces la refactorizaci贸n manual no es terrible. Al final, invente al menos una raz贸n por la que no.
"A largo plazo" generalmente no es tan largo como parece
A menudo escucho de diferentes personas que la refactorizaci贸n trae beneficios "a largo plazo". Aunque, en teor铆a, es, aqu铆, en el mundo real, constantemente tienes que entregar el trabajo en t茅rminos estrictos. Sin embargo, si hablamos de mantener la pureza del c贸digo mediante una peque帽a refactorizaci贸n gradual, el "largo plazo" dura exactamente hasta el momento en que alguien m谩s toca la base del c贸digo. Exactamente hasta la pr贸xima.
La mala noticia es que lo contrario es cierto. Si no limpia el c贸digo mientras trabaja, se deteriora r谩pidamente. No tenemos una "bolsa de aire" de diez a帽os que nos permita acumular matrimonio impunemente hasta que comiencen los problemas. El pr贸ximo cambio que deber谩 realizarse llevar谩 un tiempo inaceptablemente largo de nuestra parte, el riesgo de regresi贸n del c贸digo aumentar谩 y la situaci贸n sin la atenci贸n adecuada solo empeorar谩.
Si estamos pirateando solo para satisfacer el deseo del cliente (y 茅l quiere que el producto terminado sea m谩s r谩pido), 驴c贸mo vamos a seguir atendiendo estas solicitudes despu茅s de asegurarnos de que no se realicen cambios r谩pidos, ya que llevamos el c贸digo al estado? confusi贸n, y es imposible mantenerlo?
驴Qu茅 es r谩pido, qu茅 es lento?
Los clientes siempre querr谩n que trabaje m谩s duro, sin importar qu茅 tan r谩pido organice. La forma m谩s efectiva de reducir el tiempo de lanzamiento es hacer todo bien; hacer bien constantemente limpia los extremos, siempre, sin excepci贸n. Cortando esquinas para "acelerar", en la pr谩ctica solo disminuimos la velocidad, y no en la ef铆mera "perspectiva a largo plazo", sino aqu铆 y ahora.
Cuando el cliente le exige que trabaje m谩s r谩pido, esto no significa que le permita trabajar descuidadamente. Naturalmente, le parece obvio que no debe, despu茅s de cada solicitud, recordarnos que est谩 interesado en la alta calidad. La alta calidad est谩 impl铆cita como uno de los componentes de nuestro trabajo.
Como ingenieros, nosotros mismos elegimos si consideramos la refactorizaci贸n gradual como el elemento b谩sico de nuestra actividad profesional. No preguntamos si podemos trabajar como deber铆a, as铆 como el cirujano no le pregunta al contador si tiene tiempo de lavarse las manos antes de la operaci贸n. El tiempo dedicado a la operaci贸n es exactamente el tiempo necesario para que la operaci贸n sea exitosa. El paciente necesita ser retirado cuidadosamente del ap茅ndice, y despu茅s del alta, la persona podr铆a volver a la vida normal, sin infecci贸n de la herida y sin un tamp贸n en el abdomen. Solo empeorar谩 si se saca a una persona del quir贸fano diez minutos antes de lo necesario, y luego comienzan las complicaciones.
A menudo, en este caso, evitan que si "todo se hace de acuerdo con la ciencia", entonces resulta "demasiado largo". No, de hecho, "demasiado tiempo" es el tiempo que lleva corregir las consecuencias si el trabajo se realiz贸 a toda prisa y sin la profesionalidad adecuada. La recuperaci贸n de una infecci贸n es un verdadero shock para el paciente y su familia, esto inevitablemente afectar谩 su trabajo. Una segunda operaci贸n, en la que se debe cortar un tamp贸n olvidado del abdomen, es una intervenci贸n mucho m谩s seria, y se requerir谩 solo porque la persona fue operada con prisa por primera vez.
Al programar, si tiene que realizar cinco regresiones del c贸digo debido al hecho de que alguien lo escribi贸 r谩pidamente, no puede hablar sobre "ahorrar tiempo". Por el contrario, los cambios se hacen m谩s largos. El trabajo no se "hace" hasta que se hace correctamente. Si el equipo tuvo que pasar horas y d铆as corrigiendo errores despu茅s de la "preparaci贸n del borrador", entonces este es un tiempo perdido que podr铆a dedicarse a otro trabajo 煤til. Esta es una ganancia perdida.
Dichos errores tienen consecuencias similares a las de una ola y conducen a p茅rdidas de tiempo y dinero a largo plazo, y a veces a la p茅rdida de clientes. El estr茅s adicional recae sobre los hombros de los propios ingenieros; baja moral, alta rotaci贸n de personal. Por lo tanto, un atornillado cada vez m谩s duro y una mayor disminuci贸n de la moral y la participaci贸n en el trabajo.
La deuda t茅cnica como met谩fora
Cada vez que recurra al tema de la refactorizaci贸n gradual, alguien definitivamente le recordar谩 la deuda t茅cnica. Dir谩n: "Tenemos una fecha l铆mite tal que es necesario cortar atajos". Agregar谩n que en este caso, el equipo acumula conscientemente deudas t茅cnicas, guiado por las necesidades del negocio.
Aquellos que lo dicen no entienden esta met谩fora, y tal vez ninguna met谩fora.
La met谩fora no pretende ser una descripci贸n completa y completa de la cosa que se caracteriza.
Una met谩fora ayuda en general a delinear una impresi贸n de un aspecto de esta cosa.
Las personas tienden a sustituir una cosa con su met谩fora, y luego operan con una met谩fora como si ella y
Lo descrito es una misma cosa. No, esto no es lo mismo. El punto
Adem谩s, es com煤n que las personas interpreten ampliamente una met谩fora m谩s all谩 de su contexto original. Por lo tanto, el significado de la met谩fora es borroso y se vuelve cada vez menos 煤til.
Ward Cunningham propuso una met谩fora de la deuda t茅cnica, describiendo las interacciones con los clientes en la industria financiera. Busc贸 una met谩fora adecuada para este contexto particular, para enfatizar c贸mo la realizaci贸n gradual de oportunidades ayuda a crear un ciclo de retroalimentaci贸n durante el cual el programa se optimiza constantemente. No quiso decir "cortar esquinas para crear la ilusi贸n de un r谩pido desarrollo".
El concepto original de la met谩fora de la deuda t茅cnica implicaba que el c贸digo se manten铆a necesariamente limpio. Las personas que entienden el problema que queda en el c贸digo se mueven paso a paso hacia su soluci贸n, y el c贸digo siempre ser谩 lo suficientemente preciso como para que se le puedan hacer mejoras graduales. No se trata del hecho de que algunas razones t茅cnicas pueden justificar por qu茅 el c贸digo es basura y requiere correcciones constantes.
Cortar esquinas en aras de entregar el trabajo r谩pidamente no es una acumulaci贸n de deuda t茅cnica. Este es un truco com煤n.
Quien es responsable?
Para lograr una entrega r谩pida, debe deshacerse de los problemas al trabajar. Uno de estos problemas es el c贸digo basura. Puede deshacerse de este obst谩culo paso a paso aprendiendo a trabajar la autodisciplina. En este caso, no importa c贸mo trabajes, seg煤n el modelo de "cascada" o seg煤n el "aggail". Nosotros mismos elegimos c贸mo trabajar cada vez que tocamos el teclado.
Resumo Si trabaja correctamente, incluida la limpieza de los extremos, solo beneficiar谩 al cliente, patrocinadores, gerentes, aquellos que respaldar谩n nuestro c贸digo en el futuro y, por supuesto, para nosotros mismos.