Quando, se alguma vez, os padrões de código podem ser ignorados? [fechadas]

Minha empresa decidiu usar procedimentos armazenados para tudo que lida com o banco de dados (porque eles não sabiam de outra maneira além do SQL bruto) e, como diz o ditado "When in Rome ...", então tento seguir. Recentemente, tive que adicionar uma correção de hack que exigia a captura de um valor de banco de dados e, como era um valor único de uma única tabela, escrevi-o como SQL embutido (parametrizado, é claro), pois não parecia haver necessidade de um procedimento armazenado para uma linha de código trivial usada em uma única parte do aplicativo como um kludge.

Obviamente, agora me disseram para corrigi-lo e só usar o Stored Procs para qualquer coisa relacionada ao banco de dados. Parece um pouco como seguir cegamente o dogma em vez de usar o bom senso. Não me interpretem mal, eu entendo o propósito de ter padrões de codificação, mas também sou um defensor de ignorar os padrões quando eles não fazem sentido, e não apenas segui-los cegamente como se fossem evangelho.

Os padrões de código geralmente são apenas diretrizes. No entanto, parece que sua empresa possui uma política e essas políticas normalmente não podem ser ignoradas. Se você o trouxe à tona e foi instruído a usar um Procedimento Armazenado, eu faria isso mesmo que tomaria uma decisão diferente se tivesse autoridade para fazê-lo.

Eu acho que eles estão realmente tentando separar o contrato entre o código do aplicativo e o banco de dados. Portanto, se eles precisassem alterar o nome de uma coluna, por exemplo, precisariam apenas garantir que os contratos (SPs) funcionassem.

Get_Costumer (), ou qualquer outra coisa, é uma maneira de abstrair o código do aplicativo da estrutura do banco de dados e, na minha opinião, é uma prática recomendada real que você deve considerar em seguir. Em termos de arquitetura, você quase sempre deseja que seu código de banco de dados e aplicativo seja dissociado.

A princípio, pode parecer um exagero ser tão rígido quanto a diretrizes como essa, mas acho importante seguir as diretrizes, a menos que você tenha uma boa razão . Digo isso por causa da teoria das janelas quebradas . Isso é particularmente verdade se você tiver desenvolvedores juniores que ainda precisem das boas práticas e hábitos neles aplicados.

O fato de sua correção ter sido rápida ou um hack realmente é uma razão suficientemente boa para quebrar uma janela?

Considere um desenvolvedor inexperiente que mantém seu código; talvez eles alterem a consulta ou adicionem outro de maneira semelhante e, de repente, haja uma exploração de segurança, porque eles não perceberam que alterar a consulta exigia também alterar a maneira como ela é executada.

Nota: É uma questão separada se as diretrizes são coisas que sempre devem ser usadas em primeiro lugar, mas esse é um problema a ser considerado ao definir as diretrizes. O que quero dizer é que, depois de se decidir por coisas que são sempre boas, é importante mantê-las.

RECAPITAR EM OUTRAS RESPOSTAS

Aqui está um rápido resumo do que os outros disseram aqui antes.

Política profissional da empresa:

• Permite rastrear dependências entre objetos de banco de dados e ter uma visão geral de como as mudanças planejadas afetam o esquema;
• A equipe do DBA pode revisar e controlar os direitos de acesso ao aplicativo;
• A equipe do DBA é capaz de prever o impacto no desempenho das mudanças;
• Desacopla o banco de dados do código do aplicativo;
• Teoria da janela quebrada ... significa que é assim que eles organizam seu código e a quebra da consistência dificulta a compreensão da infraestrutura para os recém-chegados, o que os faz respeitar e se esforçar para obter menos qualidade;
• Você recebe seu salário para fazer o que foi solicitado. Esta é uma política da empresa e, no momento, você não tem autoridade para alterá-la, portanto é melhor conviver com ela.

Contra a política da empresa:

• Essa mentalidade da empresa é muito rígida e dogmática, e a política torna o trabalho do desenvolvedor desnecessariamente pesado. Infelizmente, veja o último ponto na seção Pros;
• Como o back2dos se refere a ele dizendo "Para todas as consultas feitas no banco de dados, é necessário procurar o procedimento armazenado" , uma política somente sprocs geralmente resulta em duplicação de código, porque diferentes desenvolvedores não têm idéia de quais sprocs poderiam ser reutilizados para seus problema em questão;
• Além disso, ironicamente, o contrário do caso anterior também cria problemas, quando um aplicativo é dono de um sproc, depois outro o reutiliza; o primeiro o atualiza sem o conhecimento de quem mais começou a confiar nele. Os DBAs rastreiam as dependências não além das paredes da sala do servidor de banco de dados, portanto, não espere que eles dêem a mínima para que aplicativo se baseie em que fora disso. Se as equipes de aplicativos não acompanharem o problema entre si, os DBAs serão cobertos.

AQUELES 2 CENTROS

Primeiramente, muitas respostas aqui usam a palavra padrão . A prática de proibir consultas diretas e apenas permitir sprocs não é chamada de padrão. É uma política (veja a resposta do jzd ).

Em segundo lugar, específico para o seu problema: meu principal contra-argumento contra uma política tão restritiva de usar procedimentos armazenados exclusivamente seria a própria linguagem SQL , e não necessariamente a infraestrutura centralizada de repositório de lógica de negócios que ela promove (embora isso também tenha contra-argumentos) .

O SQL é uma linguagem bastante rígida e não compostável, com poder expressivo bastante limitado . Isso significa que você atingirá um beco sem saída muito cedo no que diz respeito à reutilização do código . Uma das razões dessa rigidez é que não há meios de passar funções de primeira classe de maneira alguma (como nas linguagens OOP usando polimorfismo), o que limita significativamente a composição . O mais próximo que você pode chegar disso em poder expressivo é escrever consultas SQL dinâmicas construídas usando concatenação de cadeias. Não é uma coisa legal. As consultas dinâmicas anulam alguns dos pontos da seção "profissionais", como as dependências de rastreamento entre objetos do banco de dados, e geralmente apresentam desempenho pior, propenso a erros, difíceis de depurar e aumentam orisco de ataques de injeção de SQL . Infelizmente, com o SQL, você descobrirá que não pode ir muito longe extraindo lógica reutilizável comum entre sprocs sem bater no muro e ser forçado a recorrer a consultas executadas dinamicamente.

UPDATE: Outra grande limitação dos procedimentos armazenados, além da função de primeira classe, é a passagem e o retorno de tipos de dados compostos como argumentos, sejam listas, conjuntos, registros ou pares de valores-chave. Isso também prejudica a composição.

Finalmente, eu não concordo necessariamente com um dos pro pontos acima, a "dissociação DB da aplicação" por Jorge : O principal princípio que eu sinto se aplica aqui é preferir estruturas de dados primitivos com grande conjunto de reutilizável comum e operações combináveis, em vez de trabalhar com APIs personalizadas . Sprocs são essas APIs personalizadas aqui, que ficam entre o usuário e os dados relacionais primitivos para consultá-lo usando primitivas comuns de manipulação de dados composíveis ( selecione, junte-se, onde, agrupe poretc). Agora, o próprio SQL não é a escolha ideal para ser o DSL para primitivas de manipulação de dados composíveis, devido à rigidez mencionada acima, mas com uma opção de linguagem mais sensata (como .NET Linq ... ou Lisp / Clojure!), Você pode executar seu lógica em uma lista simples da mesma maneira que em um resultado de banco de dados DB. Obviamente, isso o torna facilmente testável, o que é uma coisa boa. Eu digo que prefiro que seu armazenamento de dados seja burro, simples e primitivo, de modo que possa ser removido com CSVs simples. Como você vê, esse modelo também desacopla o banco de dados do aplicativo, apenas desenha a linha em um nível mais baixo de abstração.

O QUE FAZER A SEGUIR?

É um pouco não relacionado à questão, mas encorajo você a dar uma olhada no Datomic , que tem uma abordagem interessante para armazenar e consultar dados, de acordo com algumas das observações acima. (Obviamente, quero dizer, observe-o estritamente fora do ambiente de trabalho primeiro ... definitivamente NÃO vá ao escritório do CTO no dia seguinte e diga "Ei, pessoal, eu reescrevi alguns de seus sprocs no Datomic e o implantei nesse brilhante servidor de prod. lá, é muito legal dar uma olhada! " Eles podem não apreciar a emoção completamente compreensível;)

O único lugar em que eu rotineiramente ignoro os padrões de codificação é no código gerado automaticamente, caso contrário, ele geralmente é tratado caso a caso e verificado duas vezes em uma revisão de código. Você não pode ser escravo dos padrões de codificação, mas as exceções são bem raras na minha experiência.

Se você não usar procs armazenados, seu dbas fará alterações na estrutura de dados sem saber qual o impacto que eles podem ter no seu código embutido que eles não conhecem. É um grande problema de manutenção quando um codificador de cowboy não segue o design. Não se trata de padrões de codificação - é sobre o design. Você nem sempre tem que gostar do design ou querer segui-lo, mas não é sua escolha, então faça o que for solicitado. Eu daria a você um passe livre para algo assim e depois o demitiria.

Como codificador de longa data e líder de equipe, devo ser capaz de pensar fora da caixa. Os padrões de codificação ajudam a manter as coisas boas, mas quando elas atrapalham, pode haver um inferno a pagar. Nesse caso, depende de sua definição de procedimento. Se for restritivo em vez de permissivo, cabe aos leads mostrar onde há problemas.

A qualidade do código pode ser medida por sua legibilidade. O que você quer é olhar para o código e ver o que ele faz.

O objetivo principal dos padrões de codificação é reforçar a legibilidade de uma equipe, porque você deseja procurar o código de um colega e ver o que ele faz.
Idealmente, isso leva ao código, que todos podem ler. É como esperar que as pessoas falem inglês limpo em vez de resmungar com seu próprio sotaque e que escrevam com um nível decente de ortografia e gramática, em vez de escrever tudo em lolcat- ou leetspeek.

Agora, o que sua empresa concebeu como padrão não impõe legibilidade a uma equipe, mas reduz-a. Para todas as consultas feitas no banco de dados, é necessário procurar o procedimento armazenado.
É como esperar que as pessoas digam frases normais como "Gostaria de tomar um café?" para dizer "Você tem um e-mail com o assunto 'Café' na sua caixa de entrada" para uma comunicação normal. Isso não aumenta a compreensão em toda a equipe, porque o procedimento armazenado (ou o conteúdo do email) pode ser apenas completo.

Portanto, não é um padrão de codificação (sensato), mas apenas uma formalidade estúpida. O único ponto de formalidades estúpidas é que elas ajudam a limitar a quantidade de besteira que uma pessoa pode criar por tempo, mas atrapalham as pessoas que têm uma contribuição real a dar.

Você deve tentar falar com quem é responsável por isso (e ser muito mais educado do que eu;)).

Se você simplesmente não conseguir fazê-lo funcionar, acho que você encontrará sua exceção. Em algum momento, a equipe identifica que fazê-lo no contexto de seus padrões, exige muito esforço ou produz uma solução ruim; você faz uma exceção documentada. Você altera os padrões quando isso começa a acontecer com muita frequência.

Você está usando isso apenas como exemplo, mas é realmente difícil envolver uma instrução select em um procedimento armazenado? Obviamente, você pratica muita prática em sua loja. Existem outros padrões que provavelmente são mais difíceis de seguir do que isso. Não sei por que os programadores não preferem passar isso para um dba (eu sei, não é o seu caso). Pessoalmente, o sql na maioria dos ide de programação parece uma porcaria, mas como todo o resto, você se acostuma ou começa a usar o ORM.

Os padrões podem ser ignorados nas seguintes circunstâncias:

Quando você conversou com seus colegas desenvolvedores e obteve um contrato ou estabeleceu uma política a ser aplicada ou sua empresa decide que não seguir os padrões é a decisão comercial correta (por exemplo, milhões de dólares podem estar em risco por uma correção "agora", independentemente de estar em conflito com os padrões).

Isso se aplicará às regras se;

• eles foram ignorados e abusados ​​a ponto de uma grande parte do código não os seguir.

• existem vários conjuntos de padrões concorrentes e não está claro qual aplicar.

• o padrão local vai contra o padrão do setor, por exemplo, uma empresa diz que usamos 9 espaços para recuar (!)

Mas mesmo nos três exemplos acima, a regra GOLDEN é, sempre que possível, você fala com todos os envolvidos PRIMEIRO. No mínimo (por exemplo, correção das 2 da manhã), você deve discutir sua decisão o mais rápido possível - e discuti-la, não apenas enviar informações sobre o que você fez. Esteja preparado para críticas e para fazer mudanças.

É sempre bom violar os padrões de codificação; no entanto, ao fazer isso, você sempre deve escrever um comentário mencionando que a violação foi deliberada e fornecer algum tipo de justificativa.