Razões para não ter um sistema flexível de gerenciamento de funções

5

Nosso aplicativo da web .NET tem a capacidade de adicionar funções dinamicamente e atribuir funcionalidades (as definimos em um enum de aplicativo) a essa função. Então essas funcionalidades são definidas por nós (nosso cliente) com base em seus requisitos de negócios. Alguns deles podem ser realmente específicos e tornam o código realmente impossível de manter e não há possibilidade de ter algo genérico em nosso aplicativo.

Então, minha pergunta é quais são as principais razões, além da abordagem de código atual, que é inatingível e que eu sei que é um grande motivo para não ir com isso, mas estou mais interessado em razões que podem ser entendidas por alguém que não está familiarizado os aspectos técnicos da programação.

    
por Aleks 07.03.2016 / 00:15
fonte

1 resposta

5

Comece com os requisitos de domínio

Esquecendo-se de por que você não deseja que as funções dos usuários e as permissões associadas sejam dinâmicas, é necessário abordar isso da perspectiva "do que a empresa / usuário precisa".

Então, pergunte a si mesmo:

  1. Esse negócio tem regras de permissão refinadas? Isso geralmente é verdade para empresas que lidam com informações de alta sensibilidade; por exemplo. bancos, qualquer organização com grande volume de negócios ou uma grande força de trabalho, etc.

  2. As regras de permissão são altamente livres ou aplicadas a partir de um conjunto consistente de regras? ou seja, o cargo da pessoa dita suas permissões ou varia de projeto para projeto ou arquivo para arquivo, et al.

etc.

Esta é uma discussão que você deve ter com o proprietário do negócio / software. Durante a discussão, esqueça suas preocupações com a implementação, apenas fale sobre o que sua empresa precisa .

Em seguida, observe a implementação

Você precisa implementar os requisitos de domínio do seu software da melhor maneira possível para sua situação. Idealmente, você poderá definir um conjunto de funções de usuário que atribuam permissões básicas e, em seguida, permitir algumas atribuições de permissão dinâmicas onde necessário.

Se você ainda não conseguir encontrar uma maneira de implementá-lo sem uma base de código extremamente difícil de lidar, simplesmente retorne a decisão ao proprietário do negócio / software :

"Eu posso implementar suas regras de domínio atuais conforme discutimos ou posso fornecer um sistema fixo simplificado baseado em funções. As implicações disso são: mais tempo de desenvolvimento, manutenção mais cara, etc. O que você deseja fazer? "

Tente manter a discussão para as coisas que eles entenderão; tempos de entrega aproximados, custos associados, etc.

Conclusão

O ponto simples é que você não pode tomar decisões sobre regras de negócios (por exemplo, como as permissões são atribuídas) devido a um problema de implementação. Modele as regras como elas são ou explique o caso de negócios para alterá-las; isto é, porque você acha que é do interesse do negócio simplificar o sistema de permissões.

    
por 07.03.2016 / 00:51
fonte