Desenvolvimento

Ξ 9 comentários

Princípio KISS aplicado a Gestão de Softwares

publicado por Caio Azevedo

Dias atrás ganhei da minha madrinha um livro a princípio bobo pela simplicidade. (acho que ela me dá livros desde que aprendi a ler).

Trata-se do livro “Idéias Geniais” de Surendra Verma.  Ele aborta (pelo menos tenta) princípios, teorias, leis e princípios científicos – do Teorema de Pitágoras à Teoria de Tudo, mas de uma forma muito superficial – é uma blasfêmia falar do “Principia” em uma única página. Mas pela minha fixação no assunto e carinho pela minha adorável madrinha li o livro. E eis que deparo com “A Navalha de Ocam”, um princípio que remota do século 14 e resumidamente diz que “Entidades não devem ser multiplicadas desnecessariamente” do qual serviu de inspiração para, dentre outras aplicações, o princípio KISS.

O princípio KISS de “Keep It Simple, Stupid”, postula que a simplicidade deve ser a palavra de ordem em projetos (de engenharia civil, elétrica, mecânica ou computacional)  e que complexidades devem ser evitadas.

Em desenvolvimento de softwares, arquitetura de sistemas, modelagem de dados, design de websites, enfim em qualquer segmento esse principio deve ser lembrado, aliás é um mantra que repito para as equipes que lidero.

São inúmeros os exemplos que podemos apresentar para ilustrar os benefícios e aplicabilidades do principio KISS, a saber:

  • No paradigma procedural, temos o uso de bibliotecas com funções e procedures pequenas e SIMPLES reutilizáveis
  • O simples uso de CSS em um website
  • Acredito que a própria orientação a objetos foi movida pelo principio KISS

Caros colegas, simplicidade está longe de ser sinônimo de facilidade, alias é exatamente o oposto, soluções simples são EUREKAS de criatividade e genialidade.

Alguns anos atrás num desses trabalhos como arquiteto deparei com um sistema com sérios problemas de performance e manutenção. Diversos eram os problemas, mas o que de fato me chamou atenção e do qual tive meu momento EUREKA foi o seguinte:

No gerenciamento de eventos em uma agenda. Uma das características é a periodicidade, podendo ser, única, diária, semanal e mensal. Suponhamos que na periodicidade semanal, além de informar a quantidade de semanas de ocorrência do evento, seja necessário especificar os dias da semana de ocorrência do evento, por exemplo:

  • As aulas do curso de c# ocorrerão a partir do dia 20/01/2012, pelas próximas 4 semanas às segundas, quartas e sextas-feiras.
  • As reuniões de acompanhamento do projeto, ocorrerão a partir do dia 01/02/2012, pelos próximos 4 meses.
  • A apresentação do projeto será realizada dia 20/12/2012.

Uma modelagem de dados muito utilizada nesse tipo de cenário, (verifique o que você tem ai na sua empresa), seria algo semelhante ao apresentado abaixo, ou muito próximo a isso, com uma tabela somente com os dias da semana relacionada à tabela de eventos e foi exatamente isso que encontrei.

 

EVENTO_TIPO_FREQUENCIAChar
EVENTO_TOTAL_DIASInt
EVENTO_TOTAL_SEMANASInt
EVENTO_TOTAL_MESESInt
EVENTO_DIA_SEGUNDABit
EVENTO_DIA_TERCABit
EVENTO_DIA_QUARTABit
EVENTO_DIA_QUINTABit
EVENTO_DIA_SEXTABit
EVENTO_DIA_SABADOBit
EVENTO_DIA_DOMINGOBit

Tabela 1 – modelo parcial da tabela de eventos.

Onde, o atributo TIPO_FREQUANCIA, é definido em um domínio pré-estabelecido, por exemplo [1-único, 2 – diário, 3 – semanal, 4 – mensal].

Os atributos TOTAL_DIAS, TOTAL_SEMANAS, TOTAL_MESES, contabilizam o período de ocorrência do evento baseado no tipo da freqüência.

E finalmente os atributos DIA_XXX, especificam os dias da semana de ocorrência do evento.

 

Essa modelagem é fácil e até mesmo intuitiva, mas gera uma série de problemas, tais como:

  • Temos uma quantidade razoável de atributos, onde sempre teremos desperdício de espaço em nosso repositório de dados.
  • Toda codificação terá que contemplar todos esses conjuntos de atributos [procedures com muitos parâmetros, classes com todas essas propriedades, métodos de validação e operações de CRUD com vários parâmetros].
  • Processo de alteração mais complexo – um evento inicialmente cadastrado como semanal, 4 veses, às tercas, quintas e sábados ao ser modificado para mensal, 2 veses, será necessário atualizar todos os atributos.

 

Momento EUREKA:

Redução drástica na quantidade de atributos na tabela de eventos.

EVENTO_TIPO_FREQUENCIAChar
EVENTO_PERIODOInt
EVENTO_DIAS_DA_SEMANAByte

Tabela 2-  modelo parcial da tabela de eventos – solução proposta.

O atributo TIPO_FREQUENCIA, mantém a mesma definição da solução anterior.

Aqui, o atributo PERIODO, armazena o total de ocorrência do evento, seu sentido será dado em função do TIPO_FREQUENCIA.

E finalmente, a grande simplificação do cenário, em um único atributo, DIAS_DA_SEMANA, do tipo byte, armazenaremos os dias da semana e todas as suas combinações, caso tenhamos uma freqüência do tipo semanal. Obviamente ainda teremos “desperdício” de atributos, mas somente um, e ainda, somente para tipo da freqüência diferente de semanal.

Como isso é possível ??

Lembram do filme “Matrix” quando o personagem NEO, passou a ver o mundo decodificado?, eis o caminho para nossa solução, precisamos recorrer ao cerne do mundo digital – os bits.

Recordar é viver – “Os tipos de dados são formados por conjuntos de bits” – um inteiro tem 4 bytes x 8 bits = 32 bits, um double tem 8 bytes x 8 bits = 64 bits, etc. no nosso caso, onde temos que manipular 7 informações (os dias da semana), a melhor opção é um campo do tipo byte que tem 8 bits, tudo bem, ainda desperdiçamos 1, mas nem tudo é perfeito.

Decodificando um campo byte temos:

0000 0001 1
0000 00102
0000 01004
0000 10008
0001 000016
0010 000032
0100 000064

 

Atribuindo um dia da semana para cada valor:

0000 0001 1Domingo
0000 00102Segunda-Feria
0000 01004Terça-Feria
0000 10008Quarta-Feria
0001 000016Quinta-Feria
0010 000032Sexta-Feria
0100 000064Sábado

 

Matematizando os dias da semana:

0000 0001 01 ↔ 2 0Domingo
0000 001002 ↔ 2 1segunda-feira
0000 010004 ↔ 2 2terça-feria
0000 100008 ↔ 2 3Quarta-feira
0001 000016 ↔ 2 4Quinta-feira
0010 000032 ↔ 2 5sexta-feira
0100 000064 ↔ 2 6Sábado

 

Ora, concluímos que o valor associado a um dia corresponde à 2 elevado ao seu “peso”,  2 (dia da semana)

E para combinação de vários dias, como nos exemplos acima ?? Simples, é só “ligar” os bits correspondentes a cada dia, vejamos:

Segunda, Quarta e Sexta == 0010 1010 == 2 1 + 2 3 + 2 5 == 02 + 08 + 32 == 42

Terça, Quinta e Sábado   == 0101 0100 == 2 2 + 2 4 + 2 6 == 04 + 16 + 64 == 84

Logo ao invés de manipular diversos atributos, propriedades e parâmetros na codificação calculamos um único valor numérico que representa a combinação de todos os dias da semana e assim manipulamos somente um atributo, simplificando e otimizando nosso trabalho.

Finalmente a expressão para obtenção desse valor será : Valor += 2 (dia da semana) , onde o dia da semana será obtido de sua interface.

E o processo inverso:

Como recuperar o valor armazenado no repositório de dados e disponibilizá-lo ao usuário? Ora, precisamos desse valor representado em bits novamente, ou melhor, em um conjunto de bits (7), em seu devido estado fundamental – ligado x desligado, mais precisamente devido interação com a interface, true x false.

Mais uma vez recorremos à maravilhosa matemática. Nosso algoritmo foi baseado em funções exponenciais, onde uma das formas de análise dessas funções é o processo conhecido como fatoração, lembram ??

 

642
322
162
82
42
22
1

64 = 2 6

Pois bem, precisamos de um conjunto ou array de bits ligados e desligados,  correspondente ao valor armazenado, combinando as operações de fatoração e resto das divisões sucessivas teremos exatamente  as informações que precisamos:

42 = ?

O resto da divisão 42 / 2 = 0 (fatorando = 21)

O resto da divisão 21 / 2 = 1 (fatorando = 10)

O resto da divisão 10 / 2 = 0 (fatorando = 5)

O resto da divisão 05 / 2 = 1 (fatorando = 2)

O resto da divisão 02 / 2 = 0 (fatorando = 1)

O resto da divisão 01         1 (fim)

E esses “zeros” e “uns” gerados, tomados de baixo para cima , corresponde exatamente ao nosso conjunto inicial de bits (10 1010), complementando-os com zeros à esquerda, bingo: 0010 1010, ou melhor, um array do tipo [false – false – true – false    true – false – true –false].

 

Concluindo:

É isso ai pessoal o principio KISS é de uma utilidade tremenda em nosso dia a dia, seja implementando, coordenado ou gerindo atividades relacionadas ao mundo de tecnologia. Espero com esse artigo ter lhes despertado a pensar de maneira KISS.

Nosso trabalho deve ir muito além de pesquisar no google códigos ou fórmulas para resolução de problemas. Precisamos, sim analisar, pensar um pouco e propor soluções da melhor forma possível, como vimos no exemplo apresentado, a codificação utilizada foi mínima, e é ai o grande mérito da proposta, conseguimos muito com bem pouco, uma amostra das leis naturais do mínimo esforço (não em vão, fizemos uso da matemática).

É claro que pensar de maneira a simplificar é ótimo, mas também devemos prestar atenção a Einstein que disse “Tudo deve ser tornado o mais simples possível, porém não mais simples que isso”.

Finalmente meu muito obrigado à minha madrinha que desde sempre me estimulou o hábito da leitura e fica a lição que não existe livro “bobo” temos sempre algo de interessante a ser aproveitado.

Autor

MBA - FGV Administração de Empresas, Graduado em Ciência da Computação, apaixonado por ciências exatas e fotografia. Web System Manager da Samsung e Arquiteto de Softwares. Palestrante, tecno-colunista e instrutor da treinando .net. Criador do aplicativo smartBuy Certificado Microsoftt - MCP, MCAD, MCSD, MCTS e MCPD. LinkedIn.

Caio Azevedo

Comentários

9 Comments

  • Ahhhhh, eu lembro disso, kkkkkkk. Boa Caião. KISS no código e no ouvido, hehehe. Abração. Parabéns.

    • hehehe é isso ai KISS sempre é bom..
      Pois é.. você vê como um problema deparado a tanto tempo é capaz de ser abordado sob diversas óticas.

      obrigado..

  • Aff..eu sempre usei o KISS de uma forma pragmática … agora o farei também de forma cientificamente correta..hehe

    muito bom..sucesso pra vc!!

    Anderson

    • Perfeito Anderson.. usar o princípio KISS de forma pragmática e intuitiva é uma expressão de genialidade e raciocínio otimizado meu colega ou você acha que a galinha sabe que y = a.cosh(x/a) define a curva de máxima resistência utilizada nos ovos que ela põe ??

      obrigado e grande abraço..

  • Muito bom Caio!

    Utilizo esse mesmo princípio para saber quais câmeras de um DVR quero receber imagens ou saber quais estão funcionando. Fica mais fácil para mandar via socket usando só um parâmetro para saber o status das 32 câmeras.

    Cada dia aprendemos alguma coisa… a vida é uma escola…

    Abs!

    • É isso ai meu velho.. a idéia é essa… as aplicações são inúmeras…. abraço..

  • Caio, parabéns pelo artigo.

    O elogio está atrasado, mas creio que ainda em tempo.

    Sou do tempo do onça – programador FORTRAN, COBOL, EIFFEL, LISP, DATAFLEX, CLIPPER e afins. Nesta época os bytes eram raros e caros. Os programas os disputavam a tapas.

    Sua solução binária foi um cheque-mate lógico no problema.

    Parabéns e sucesso.
    Abraço.
    Ramon

    • Olá Ramon muito obrigado pelo comentário, e tem nada de atrasado.. rs.
      Pois é.. por conta da fartura e muitas vezes da facilidade de utilização das ferramentas, seja de desenvolvimento ou banco de dados, tenho percebido uma certa displicência dos nossos colegas para alguns princípios de lógica dos inumeros problemas que deparamos no dia a dia e a idéia do artigo foi despertamos para isso…

      Enfim.. mais uma vez obrigado pelo comentário e parabéns pela sua coluna aqui no TI Especialistas.
      grande abraço,
      Caio Azevedo

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes