Recientemente, comí con varios amigos que trabajan en grandes empresas y, charlando, llegamos al tema de las normas de código. Uno de ellos, que trabaja como backend en un gigante del comercio electrónico en Hangzhou, dijo que su equipo había hecho recientemente una revisión de código y el resultado fue sorprendente: lo que más problemas generó no fueron fallos lógicos ni problemas de rendimiento, sino SQL escrito de forma demasiado descuidada. Mezclaban mayúsculas y minúsculas en las palabras clave, la indentación era un desastre, los saltos de línea iban según el estado de ánimo, y una consulta medianamente compleja se convertía en un laberinto. El jefe dijo en el momento: a partir de ahora el SQL debe estar formateado, y lo que no pase la revisión se devuelve para reescribir.
Esto no es un caso aislado. Pregunté a varios amigos de empresas de internet en Pekín y Shenzhen y todos dijeron que allí también se han puesto serios. Antes, cuando escribíamos SQL, siempre que funcionara y el resultado fuera correcto, a nadie le importaba cómo se veía. Pero ahora es diferente: las normas de código pasaron de ser una "recomendación" a un "requisito", y el formateo de SQL se ha señalado específicamente como un indicador obligatorio.
¿Por qué de repente son tan estrictos? En pocas palabras, el coste de la colaboración en equipo es demasiado alto. Piensa: en un proyecto hay más de diez personas; hoy uno escribe una subconsulta anidada en tres niveles, mañana otro escribe una consulta combinada con todas las palabras clave en mayúsculas, y pasado mañana llega otra con un JOIN complejo sin ningún comentario. Con el tiempo, nadie se atreve a tocar esa tabla, y modificar una línea de código cuesta media hora adivinando qué pretendía hacer quien la escribió. Y ni hablemos de cuando hay problemas en producción: quien investiga el fallo ve ese montón de SQL y le sube la presión de golpe.
Hay otra razón muy realista: muchas empresas ahora están implementando plataformas de revisión de SQL, que escanean automáticamente al enviar el código. Si tu formato no cumple las normas, ni siquiera pasa la solicitud de fusión. Algunos equipos incluso han incluido el formateo de SQL en la evaluación de desempeño; suena exagerado, pero ha ocurrido. Mi amigo de Hangzhou decía que su equipo ahora calcula semanalmente la tasa de aprobación de las normas de SQL, y quien quede en último lugar de forma consecutiva tiene que invitar a todo el equipo a té con leche.
Entonces, ¿qué hacer? No podemos estar ajustando manualmente espacios y saltos de línea cada vez que escribimos SQL; es demasiado ineficiente. Ahí es donde entran en juego las herramientas de formateo de SQL. Escribes la sentencia, la pegas en la herramienta y con un clic puedes ordenar ese SQL desordenado y dejarlo impecable. Palabras clave en mayúsculas uniformes, indentación alineada, saltos de línea donde corresponda y espacios donde hagan falta. Las consultas complejas incluso se descomponen automáticamente en una estructura clara por cláusulas, y la lógica se entiende de un vistazo.
No subestimes esta acción. Una vez unificado el formato, la eficiencia de la revisión de código puede mejorar bastante. Antes, revisar una sentencia SQL requería primero cinco minutos para entender la estructura; ahora basta un vistazo para saber si hay problemas. Cuando alguien nuevo hereda código antiguo, ya no tiene que preocuparse por ese montón de "jeroglíficos". Incluso un amigo me dijo que, después de que su equipo usara una herramienta de formateo de SQL, los incidentes en producción disminuyeron varias veces, porque algunos errores lógicos se volvían especialmente evidentes tras el formateo y se detectaban a simple vista.
Por supuesto, las herramientas son solo un medio auxiliar; lo esencial es adquirir el hábito. Mi propia práctica es que, después de escribir una sentencia SQL algo compleja, la paso primero por una herramienta de formateo para ver si la estructura ordenada coincide con lo que tenía en mente. A veces, después de formatear, descubro que había escrito un anidamiento innecesario o que alguna condición JOIN estaba mal colocada. Este efecto de autocomprobación es mucho mejor que confiar solo en la vista.
En definitiva, que las grandes empresas empiecen a revisar las normas de SQL no es por el formato en sí, sino por la actitud rigurosa que hay detrás. SQL es la herramienta más directa para tratar con datos; si se escribe bien o mal, afecta directamente a la estabilidad del sistema y a la eficiencia de la colaboración del equipo. Antes se pensaba que bastaba con que funcionara; ahora no, tiene que funcionar bien y que los demás también puedan entenderlo.
Si aún no has usado una herramienta de formateo de SQL, te sugiero que busques una y la pruebes ahora. Hay de código abierto y en línea; elige la que te resulte más cómoda. No te llevará más de unos minutos, pero una vez que adquieras el hábito, descubrirás que tu nivel de SQL sube sin darte cuenta. Después de todo, en este entorno cada vez más competitivo, si ni siquiera puedes cuidar el formato de tu SQL, realmente no da para decir que eres programador.