¿Cuándo, si alguna vez, pueden ignorarse los estándares de código? [cerrado]

Mi compañía ha decidido usar procedimientos almacenados para todo lo relacionado con la base de datos (porque no sabían de otra manera además del SQL sin formato), y como dice el dicho "Cuando en Roma ...", entonces trato de seguir. Recientemente tuve que agregar una solución de pirateo que requería obtener un valor de base de datos, y dado que era un valor único de una sola tabla, lo escribí como SQL en línea (parametrizado, por supuesto), ya que no parecía ser necesario procedimiento almacenado para una línea de código trivial utilizada en una sola parte de la aplicación como kludge.

Por supuesto, ahora me han dicho que lo arregle y que solo use los Stored Procs para cualquier cosa relacionada con la base de datos. Esto se siente demasiado como seguir ciegamente el dogma en lugar de usar el sentido común. No me malinterpreten, entiendo el propósito de tener estándares de codificación, pero también soy partidario de ignorar los estándares cuando no tienen sentido, no solo seguirlos ciegamente como si fueran Evangelio.

Los estándares de código son típicamente solo pautas. Sin embargo, parece que su empresa tiene una política y las políticas generalmente no se pueden ignorar. Si lo mencionó y le dijeron que usara un Procedimiento almacenado, entonces seguiría adelante y lo haría a pesar de que tomaría una decisión diferente si tuviera la autoridad para hacerlo.

Creo que en realidad están tratando de separar el contrato entre el código de la aplicación y el DB. Por lo tanto, si alguna vez necesitaran cambiar el nombre de una columna, por ejemplo, solo tendrían que asegurarse de que los contratos (SP) funcionen.

Get_Costumer (), o lo que sea, es una forma de abstraer el código de la aplicación de la estructura de la base de datos y, en mi opinión, es una práctica recomendada que debería considerar a continuación. Desde el punto de vista arquitectónico, casi siempre desea que su DB y el código de la aplicación estén desacoplados.

Al principio puede parecer demasiado exagerado ser tan rígido con pautas como esta, pero creo que es importante apegarse a pautas a menos que tenga una muy buena razón . Digo esto debido a la teoría de la ventana rota . Esto es particularmente cierto si tiene desarrolladores junior que aún necesitan las buenas prácticas y hábitos que se les han aplicado.

¿Es el hecho de que su solución fue rápida o un hack realmente una buena razón para romper una ventana?

Considere un desarrollador inexperto que mantiene su código, tal vez cambien la consulta o agreguen otra de manera similar y de repente hay una vulnerabilidad de seguridad porque no se dieron cuenta de que cambiar la consulta también requería cambiar la forma en que se ejecuta.

Nota: Es un tema separado si las pautas son cosas que siempre deben usarse en primer lugar, pero ese es un tema a considerar al establecer las pautas. Mi punto es que una vez que se haya decidido por cosas que siempre son buenas, es importante mantenerlas.

RECUPERACIÓN DE OTRAS RESPUESTAS

Aquí hay un resumen rápido de lo que otros han dicho aquí antes.

Política de la empresa profesional:

• Permite rastrear las dependencias entre los objetos de la base de datos y la visión general de cómo los cambios planificados afectan el esquema;
• El equipo de DBA puede revisar y controlar los derechos de acceso a las aplicaciones;
• El equipo de DBA puede predecir el impacto en el rendimiento de los cambios;
• Desacopla la base de datos del código de la aplicación;
• Teoría de la ventana rota ... lo que significa que así es como organizan su código, y romper la consistencia hará que la infraestructura sea más difícil de comprender para los recién llegados, lo que hará que respeten y luchen por una calidad menor;
• Obtiene su cheque de pago para hacer lo que se le pidió que hiciera. Esta es una política de la empresa y en este momento no tiene la autoridad para cambiarla, por lo tanto, es mejor vivir con ella.

Política de la empresa contra:

• Esta mentalidad de la compañía es muy rígida y dogmática, y la política hace que el trabajo del desarrollador sea innecesariamente engorroso. Desafortunadamente, vea el último punto en la sección Pros;
• Como se refiere a back2dos diciendo "Para cada consulta realizada en la base de datos, debe buscar el procedimiento almacenado" , una política de solo sprocs a menudo da como resultado la duplicación de código, porque diferentes desarrolladores no tienen idea de qué sprocs podrían reutilizarse para su problema en mano;
• Además, irónicamente, lo contrario al caso anterior también crea problemas, cuando alguna aplicación posee un sproc, luego otra lo reutiliza, luego la primera lo actualiza sin saber quién más comenzó a confiar en él. Los DBA realizan un seguimiento de las dependencias no más allá de las paredes de la sala de servidores de DB, así que no esperes que les importe qué aplicación depende de qué fuera de eso. Si los equipos de aplicación no lo rastrean entre ellos, ese es su problema, los DBA están cubiertos.

AQUELLOS 2 CENTOS

En primer lugar, muchas respuestas aquí usan la palabra estándar . La práctica de prohibir consultas directas y solo permitir sprocs no se denomina estándar. Es una política (ver la respuesta de jzd ).

En segundo lugar, específico para su problema: mi principal argumento en contra de una política tan restrictiva de usar exclusivamente procedimientos almacenados sería el lenguaje SQL en sí mismo , y no necesariamente la infraestructura de repositorio de lógica de negocios centralizada que promueve (aunque también tiene sus contraargumentos) .

SQL es un lenguaje bastante rígido y no composable, con un poder expresivo bastante limitado . Esto significa que llegará a un callejón sin salida muy temprano con respecto a la reutilización del código . Una de las razones de esta rigidez es que no hay medios para pasar funciones de primera clase de ninguna manera (como con los lenguajes OOP que usan polimorfismo), lo que limita significativamente la componibilidad . Lo más cercano que puede llegar a eso en potencia expresiva es escribiendo consultas SQL dinámicas construidas utilizando la concatenación de cadenas. No es una buena cosa. Las consultas dinámicas anulan algunos de los puntos en la sección "pros", como las dependencias de seguimiento entre objetos de base de datos, y generalmente tienen un rendimiento peor, son propensos a errores, son difíciles de depurar y aumentanriesgo de ataques de inyección SQL . Desafortunadamente, con SQL encontrará que no puede llegar muy lejos extrayendo lógica reutilizable común entre sprocs sin golpear la pared y verse obligado a recurrir a consultas ejecutadas dinámicamente.

ACTUALIZACIÓN: Otra gran limitación de los procedimientos almacenados, además de la función de primera clase, es el paso y la devolución de tipos de datos compuestos como argumentos, ya sean listas, conjuntos, registros o pares clave-valor. Esto también perjudica la compostibilidad.

Finalmente, no estoy necesariamente de acuerdo con uno de los puntos pro anteriores, el "desacoplamiento de la base de datos de la aplicación" de Jorge : el principio principal que creo que se aplica aquí es preferir estructuras de datos primitivas con un gran conjunto de operaciones comunes reutilizables y componibles, en lugar de trabajar con API personalizadas . Los Sprocs son tales API personalizadas aquí, que se interponen entre el usuario y los datos relacionales primitivos para consultarlos utilizando primitivas comunes de manipulación de datos componibles ( seleccionar, unir, dónde, agrupar por, etc.) Ahora SQL en sí no es la opción ideal para ser el DSL para las primitivas de manipulación de datos componibles, debido a la rigidez mencionada anteriormente, pero con una elección de lenguaje más sensible (como .NET Linq ... o Lisp / Clojure!) Podría ejecutar su lógica contra una lista simple de la misma manera que contra un conjunto de resultados DB. Obviamente, eso lo hace fácilmente comprobable, lo cual es una buena cosa. Digo que prefiera que su almacén de datos sea tonto, simple y primitivo, de modo que se pueda tropezar con CSV simples. Como puede ver, este modelo también desacopla DB de la aplicación, solo que dibuja la línea en un nivel inferior de abstracción.

¿Qué hacer a continuación?

No está un poco relacionado con la pregunta, pero le animo a que le eche un vistazo a Datomic , que tiene un enfoque interesantemente novedoso para almacenar y consultar datos, en línea con algunas de las observaciones anteriores. (Obviamente, me refiero a mirarlo estrictamente fuera del entorno de trabajo primero ... definitivamente NO vaya a la oficina del CTO al día siguiente y diga "Hola chicos, reescribí algunos de sus sprocs en Datomic y los implementé en este brillante servidor de productos en allí, ¡es realmente genial echar un vistazo! " Es posible que no aprecien la emoción completamente comprensible;)

El único lugar donde ignoro rutinariamente los estándares de codificación es en el código autogenerado, de lo contrario, generalmente se maneja caso por caso y se verifica dos veces en una revisión de código. No puede ser esclavo de los estándares de codificación, pero las excepciones son bastante raras en mi experiencia.

Si no usa procs almacenados, su dbas realizará cambios en la estructura de datos sin saber qué impacto podrían tener en su código en línea que desconocen. Es un problema importante para el mantenimiento cuando un codificador de vaqueros no sigue el diseño. No se trata de estándares de codificación, sino del diseño. No siempre tiene que gustarle el diseño o desea seguirlo, pero no es su decisión, así que haga lo que le pidan. Te daría un pase gratis en algo como esto y luego te despediría.

Como codificador y líder de equipo desde hace mucho tiempo, debo ser capaz de pensar fuera de la caja. Los estándares de codificación ayudan a mantener las cosas agradables, pero cuando se interponen, puede haber un infierno que pagar. En este caso depende de su definición de procedimiento. Si es restrictivo en lugar de permisivo, depende de los conductores mostrar dónde hay problemas.

La calidad del código se puede medir por su legibilidad. Lo que quieres es mirar el código y ver qué hace.

El objetivo de los estándares de codificación es hacer cumplir la legibilidad en todo un equipo, porque desea mirar el código de un colega y ver qué hace.
Idealmente, esto lleva a un código que todos pueden leer. Es como esperar que las personas hablen inglés limpio en lugar de murmurar con su propio acento y que escriban con un buen nivel de ortografía y gramática, en lugar de escribir todo en lolcat- o leetspeek.

Ahora, lo que su empresa concibió como estándar no impone la legibilidad en todo un equipo, sino que lo reduce. Para cada consulta realizada en la base de datos, debe buscar el procedimiento almacenado.
Esto es como esperar que la gente en lugar de decir oraciones normales como "¿Quieres café?" para decir "Tiene un correo electrónico con el asunto 'Café' en su bandeja de entrada" para una comunicación normal. No aumenta la comprensión en todo su equipo, porque el procedimiento almacenado (o el contenido del correo electrónico) podría ser completo.

Por lo tanto, no es un estándar de codificación (sensible), sino más bien una formalidad estúpida. El único punto de las formalidades estúpidas es que ayudan a limitar la cantidad de tonterías que una persona puede crear por vez, pero se interponen en el camino de las personas que tienen una contribución real que hacer.

Deberías tratar de hablar con quien sea responsable de eso (y ser mucho más educado que yo).

Si no puede hacerlo funcionar, creo que habrá encontrado su excepción. En algún momento, el equipo identifica que hacerlo dentro del contexto de sus estándares, simplemente requiere demasiado esfuerzo o produce una solución deficiente, usted hace una excepción documentada. Cambia los estándares cuando esto comienza a suceder con demasiada frecuencia.

Solo está usando esto como ejemplo, pero ¿es realmente tan difícil envolver una declaración de selección en un procedimiento almacenado? Obviamente tienes mucha práctica en tu tienda. Hay otros estándares que probablemente sean más difíciles de seguir que este. No sé por qué los programadores no preferirían pasar esto a un dba (lo sé, no es tu caso). Personalmente, sql en la mayoría de las ideas de programación parece una mierda, pero como todo lo demás, te acostumbras o comienzas a usar ORM.

Las normas pueden ignorarse en las siguientes circunstancias:

Cuando ha hablado con sus colegas desarrolladores y ha obtenido un acuerdo o ha establecido una política que se debe hacer cumplir o su empresa decide que no seguir los estándares es la decisión comercial correcta (por ejemplo, millones de dólares podrían estar en juego por una solución "ahora" independientemente de si entra en conflicto con los estándares).

Esto se aplicará a las reglas si;

• han sido ignorados y abusados ​​hasta el punto de que una gran parte del código no los sigue.

• Hay varios conjuntos de estándares en competencia, y no está claro cuál aplicar.

• el estándar local va en contra del estándar de la industria, por ejemplo, una compañía dice que usamos 9 espacios para sangrar (!)

Pero incluso en los 3 ejemplos anteriores, la regla de ORO es, siempre que sea posible, que hable PRIMERO con todos los interesados. Como mínimo (p. Ej., Corrección de las 2 a. Esté preparado para las críticas y para hacer cambios.

Siempre está bien violar los estándares de codificación; sin embargo, cuando lo haga, siempre debe escribir un comentario mencionando que la violación fue deliberada y proporcionar algún tipo de justificación.