De un traductor: hoy estamos
publicando un art铆culo para usted por el experimentado probador de gamedev Richard Taylor. El art铆culo ser谩 煤til tanto para principiantes como para desarrolladores experimentados: definitivamente hay algo que discutir aqu铆.
He creado muchos juegos. Por lo general, la etapa final del desarrollo es muy dolorosa. Despu茅s de todo, es al final cuando encontramos errores, y solo despu茅s de eso podemos aportar brillo al producto por completo. La situaci贸n empeora cuando el desarrollador tiene un tiempo m铆nimo para completar el proyecto. Tienes que trabajar r谩pidamente, y los errores en este caso son invitados frecuentes. 驴C贸mo puedo tratar con ellos? Es muy simple: cometer menos errores, eso es todo (esta es la iron铆a del autor - nota del traductor).
Skillbox recomienda: Curso pr谩ctico de dos a帽os "Soy un desarrollador web PRO" .
Le recordamos: para todos los lectores de "Habr": un descuento de 10.000 rublos al registrarse en cualquier curso de Skillbox con el c贸digo de promoci贸n "Habr".
Reduce la cantidad de errores
Dado que todos los errores est谩n en el c贸digo, 驴es probable que sea suficiente pedirle al equipo de desarrollo que cometa menos errores?
Si eres divertido en este lugar, no me sorprender茅. Y realmente, porque nadie (bueno, o casi nadie) los hace por su propia voluntad. Entonces, 驴qu茅 puede ofrecerle al equipo para cometer menos errores en el c贸digo para que no haya errores?
Comenzamos un nuevo proyecto. Paso uno: no repita errores anteriores
Nuestro equipo ha trabajado en varios proyectos AAA. Antes de comenzar uno de ellos, decidimos hacer una lluvia de ideas sobre el tema "C贸mo cometer el m铆nimo n煤mero de errores". Ninguno de nosotros quer铆a pasar los 煤ltimos meses trabajando en un proyecto buscando errores y borrando c贸digo. Una de las tareas principales es la distribuci贸n de responsabilidades y responsabilidades. A cada tipo de trabajo se le asign贸 un senior.
El primer paso es decidir por qu茅 todo esto es necesario. El "por qu茅" del nivel superior se explica simplemente: queremos reducir la cantidad de tiempo requerida para eliminar errores, optimizar costos y mejorar la calidad general del proyecto.
Se trata de liberar tiempo para realizar tareas interesantes, aquellas que le permiten despertarse felizmente por la ma帽ana e inmediatamente asumir la implementaci贸n de la tarea. Esto es lo que nos hizo a todos los desarrolladores: 隆la oportunidad de usar nuestro tiempo para cosas realmente geniales!
Por cierto, incluso si hay una tarea clara para crear menos errores, es tan general que puede simplemente no tener sentido. Esta es una declaraci贸n de intenciones que debe aclararse y dividirse en una serie de tareas claras dirigidas a los miembros individuales del equipo.
Al responder la pregunta de c贸mo hacer esto, es necesario seguir los conceptos b谩sicos del m茅todo cient铆fico: observaci贸n, hip贸tesis, prueba, repetici贸n.
Observaci贸n
Categorizaci贸nAbra la base de datos de errores de su 煤ltimo proyecto y v茅alo. Hay muchas variedades de errores, as铆 que solo decir: menos errores es simplemente in煤til.
Para comprender mejor el problema, debe determinar los detalles. En primer lugar, es necesario reducir el n煤mero de esos problemas, cuya detecci贸n y soluci贸n requiere un avance de tiempo.
An谩lisisDespu茅s de compilar una lista de los errores que requieren m谩s tiempo, el siguiente paso es un intento de encontrar una base com煤n en estos errores, as铆 como comprender el motivo de su aparici贸n. 隆Analiza e interpreta!
Causa del problemaAl final, creamos una serie de plantillas para buscar errores espec铆ficos, lo que permiti贸 comprender por qu茅 su b煤squeda y eliminaci贸n lleva tanto tiempo. Despu茅s de eso, est谩bamos listos para ir al c贸digo fuente para encontrar la causa ra铆z del problema.
Trabajando con especialistas t茅cnicos, descubrimos m谩s cambios de arreglos. Luego compilamos nuevas listas de sistemas, archivos y l铆neas de c贸digo asociadas con errores importantes. Al final, hicimos una lista de los cambios de c贸digo necesarios que podr铆an discutirse con el equipo de desarrollo.
隆Te lo dijimos!Luego tuvimos una reuni贸n con los programadores para discutir nuestros hallazgos. Al final result贸 que, los chicos sab铆an sobre la mayor铆a de las 谩reas problem谩ticas en el c贸digo. Pero si es as铆, 驴cu谩l era el punto de tener una reuni贸n?
Respuesta: logramos establecer un paralelismo entre lugares espec铆ficos en el c贸digo y las p茅rdidas de tiempo asociadas con estos problemas. Y esto, a su vez, permiti贸 evaluar objetivamente cualquier propuesta de mantenimiento de c贸digo.
Por lo tanto, revisamos secciones del c贸digo que podr铆an llamarse aceptablemente malas. Cuando los evaluamos con nuestras mejores pr谩cticas, result贸 que necesit谩bamos una refactorizaci贸n. Al mismo tiempo, el equipo de ingenier铆a lo abandon贸 anteriormente porque "hay demasiado trabajo" o "es simplemente imposible".
De hecho, muchos problemas fueron sist茅micos. Muchos aspectos "invisibles" condujeron a una cadena de eventos que causaron la aparici贸n de un error. Por cierto, las causas de los problemas fueron tan sist茅micas que el proyecto tuvo que comenzar desde cero.
Como resultado, hemos acumulado suficientes resultados de observaciones y an谩lisis emp铆ricos para formar hip贸tesis. Todo el equipo particip贸 en este proceso.
Hip贸tesis
Hip贸tesis 1. Es probable que los patrones de codificaci贸n espec铆ficos conduzcan a la aparici贸n de errores en un gran proyecto de software.
Hip贸tesis 2. El tiempo requerido para corregir errores en un proyecto puede reducirse evitando los patrones de comportamiento definidos en la primera hip贸tesis.
Vamos a decidir qu茅 es un gran proyecto. Esto es alrededor de 25 programadores, 12 meses de desarrollo. Las siguientes declaraciones son ciertas para 茅l:
R. Cualquier c贸digo durar谩 lo suficiente, por lo que el costo de mantenimiento en 煤ltima instancia exceder谩 el costo del desarrollo en s铆.
B. La complejidad de conectar sistemas de proyectos individuales es mayor que la complejidad de un sistema en particular.
驴Por qu茅 es esto tan importante? En proyectos peque帽os, puede hacer frente a casi todo, aqu铆 la estructura del programa no es tan importante. El c贸digo est谩 a su disposici贸n.
Si el proyecto es grande, entonces todo cambia. Puede trabajar con un c贸digo cuyo prop贸sito no comprende, incluso puede no saber a qu茅 parte del proyecto pertenece un sitio en particular.
Despu茅s de nuestra discusi贸n, obtuvimos esta declaraci贸n de resultados: 鈥淟os datos muestran que estos patrones de programaci贸n espec铆ficos fueron un factor com煤n asociado con varios errores / problemas. Creemos que al evitar estos patrones, podemos reducir el tiempo que lleva corregir errores y al mismo tiempo mejorar la calidad ".
Ahora comenzamos a la implementaci贸n pr谩ctica.
Prueba
Al crear un nuevo proyecto, debe evitar los patrones de error identificados. Lo tuvimos:
- Sobrecarga del operador y mala denominaci贸n.
- Caracter铆sticas autom谩ticas, polim贸rficas y descuido de la seguridad de tipos.
- Aumentando la complejidad del c贸digo, por ejemplo, inyectando dependencias y devoluciones de llamada.
- Uso de mutexes, sem谩foros y similares en el c贸digo de alto nivel.
Que sigue
Y luego tuvimos la oportunidad de comenzar un nuevo proyecto, el desarrollo de un nuevo juego. Pudimos crear un motor de juego desde cero y completar todo a tiempo, con un equipo relativamente peque帽o de programadores. Hubo pocos errores, pero el c贸digo result贸 ser bueno. Al mismo tiempo, le llev贸 un poco de tiempo repararlo.
Todo esto se hizo posible porque no usamos patrones problem谩ticos, como si ya no existieran. Incluso tenemos el mantra "Complicar la apariencia de un error".
Todo el equipo estaba contento con tales resultados, se volvi贸 m谩s interesante trabajar, porque nuevamente fue posible dedicar tiempo a lo que te gusta.
Skillbox recomienda: