Una gran parte de mi pasantía de verano en 2011 la gasté refactorizando un trabajo MapReduce de siete años (en ese momento). El resultado final fue algo donde la ruta del código fue, en mi opinión, mucho más comprensible y algo que se ejecutó aproximadamente un 50% más rápido cuando el original tardó varios días en ejecutarse en miles de máquinas (eso es sobre todos los detalles que puedo revelar en rendimiento). En general un buen ahorro.
Hubo tres cosas que dificultaron la reescritura de este trabajo (tenga en cuenta que estaba tratando de hacer coincidir la salida del trabajo original lo más cerca posible):
- ¡No hubo pruebas unitarias! Google es realmente muy, muy bueno sobre escribir pruebas unitarias y prestar atención cuando realmente fallan en el código que está a punto de ser revisado (y escuché que han mejorado aún más desde que me fui). Sin embargo, aparentemente en 2004, Google no fue tan meticuloso al respecto. Una gran parte de mi trabajo estaba escribiendo pruebas de unidades específicas para el mapeador, el combinador y el reductor. Desafortunadamente, esto implicaba saber lo que se suponía que debía producir el original sin tener el beneficio de las pruebas unitarias o cualquier tipo de contrato especial en los comentarios para decirme qué pasaba.
- Sistema muy complicado con muchas partes móviles. Creo que las personas que diseñan un sistema orientado a objetos tienden a sobrediseñar mucho. El sistema en el que estaba trabajando era un ejemplo de esto: estaba tratando de agarrar pesos de diferentes cosas solo para descubrir que esos pesos estaban afectados por varios factores que estaban ocultos en las clases internas de clases de amigos que eran difíciles de descubrir de inmediato (y no había ningún documento de diseño que yo conociera). Mi reescritura eliminó muchas de estas clases de amigos y simplificó todo dentro del mapeador y el reductor en su mayor parte.
- Una ruta de código que necesitaba refactorización. El código original que me dieron estaba tratando de hacer algo que tenía tres pasos naturales en una serie de dos reducciones de mapa que dividían la tarea no a lo largo de los límites naturales. Creo que la división tuvo mucho más sentido cuando el trabajo tuvo que lidiar con muchos menos datos y con mucha menos paralelización, pero tomó algo de tiempo resolverlo y rediseñarlo.
En cuanto a causar problemas, es el caso de que casi todo el verano de un pasante pasara por arreglar este código. Entiendo que los pasantes son relativamente baratos, pero los pasantes de Google aún ganan bastante dinero.
- ¿Cómo es ser un probador de control de calidad en WhatsApp?
- ¿Qué especificaciones de computadora son las mejores para los desarrolladores de software y cuáles son los costos?
- ¿El cambio de contexto ocurre en el modo kernel?
- ¿Cómo es ser ingeniero en Nintendo?
- Para los ingenieros que dejaron su trabajo para obtener un MBA, ¿cómo es la vida después de un MBA?
Diría que, en mi experiencia, el código deficiente fue más la excepción que la norma en Google (como puede ver en la pregunta a la que hizo referencia). De hecho, la startup en la que estoy haciendo prácticas este verano está compuesta principalmente por ex-Googlers y la cultura de valorar la buena calidad del código se refleja realmente en su base de código. Sin embargo, creo que esta cultura creció con el tiempo en Google, y 2004 fue un período en el que los ingenieros de software estaban más preocupados por golpear cosas y enviarlas rápidamente que un código meticuloso. Dicho esto, incluso con los problemas anteriores, imagino que el código que vi fue aún mejor que el de muchas otras compañías.