Impactos da descontinuação de determinados dados no SAURON

2. Introdução

2.3. Desenvolvimento

using Microsoft.AspNetCore.Http;
using SID.Extensions;
using SID.Interfaces;
using System.Security.Claims;

namespace SID.Services
{
    public class UserService : IUserService
    {
        private readonly ClaimsPrincipal user;

        public UserService(IHttpContextAccessor httpContextAccessor)
        {
            this.user = httpContextAccessor.HttpContext.User;
        }

        public int ObterQuantidadePerfis() => user.BuscarPerfis().Count;

        public string ObterCpfCnpj() => user.CpfCnpjSauron();

        public bool VerificarSePossuiPerfilChefeImediato() => user.PossuiPerfilChefeImediato();

        public bool VerificarSePossuiPerfilTitularDaPasta() => user.PossuiPerfilTitularDaPasta();
    }
}

A utilização do SAURON em sua maneira tradicional, viola um dos princípios do design orientado a objetos, que preza pela responsabilidade única em suas funcionalidades, em resumo o SAURON não pode entregar informações ao solicitante que não seja da sua área de responsabilidade.

Alguns sistemas não exploram o SAURON em sua totalidade, o que é bom pois nesses caso se usa atributos que não seja de sua responsabilidade, mas o SKALA que é um dos sistemas que está sob responsabilidade do time TITÃS merece certa atenção quanto a essa demanda, o sistema possui integração com o SAURON e em prévia análise se utiliza de atributos que possivelmente serão descontinuados.

Portanto, para atendimento deste tipo de demanda é necessário fazer um relatório que levante todos os sistemas dependentes do SAURON e que aborde a prioridade de migração de cada um, para que o trabalho seja realizado pela equipe de forma eficiente e de objetiva.

2.3.1. Complexidade de cada funcionalidade

Para atendimento desta demanda, será necessário deslocar o time integralmente ou parcialmente, visto que, após a descontinuação dos dados do SAURON, sistemas que dependem de forma acoplada serão afetados diretamente e dependendo do nível de importância do serviço, a sua priorização de correção seria mais alta. O esforço empreendido para solução do problema será focado em sua totalidade para atendimento da demanda, cuja complexidade pode atingir a disponibilidade das aplicações.

2.3.2. Possíveis problemas

Uma das situações que pode ocorrer quando optado pela não adaptação imediata, seria problemas da disponibilidade das aplicações, provavelmente entrariam em colapso e não funcionaria corretamente. Visto a quantidade de sistemas da SETIC os problemas vindos as mudanças no SAURON possivelmente seriam:

• Alertas inconsistentes para "Sem conexão com o servidor"
• Carregamentos que nunca param
• Miniaturas que nunca carregam
• Sistema de Autenticação não funcional ou com erro

Então, antes da descontinuação ocorrer, todos os sistema devem estarem sob aptidão de que suas implementações estejam totalmente atualizadas.

2.3.3. Valor agregado

A melhor maneira de arruinar a reputação de um sistema é manter uma péssima documentação da API ou manter a codificação sem revisão ou atualizada. A documentação por exemplo, é uma janela para os produtos da SETIC. Documentos que detalham recursos obsoletos ou não mencionam atualizações importantes, serão vistos como sinais de alerta de que o código dos produtos não estão funcionando ou estão em conformidade.  Mas muitas vezes a documentação falha por causa da má comunicação. Manter o código atualizado e os bons princípios de desenvolvimento parece bobagem burocrática, mas funciona. E não há relação com manuais, na verdade o que há é esclarecimento de padrões. Cada desenvolvedor pode manter a documentação e o código em um padrão de qualidade diferente, por isso é vital que todos estejam na mesma linha de raciocínio.

3.4. Conclusão