Programação (II) - Modularização
Continuando a série sobre programação, vamos falar sobre modularização. Como dividir adequadamente um sistema? Qual a unidade ideal? Como quebrar funções? Como saber se um módulo está realmente bom? Esse artigo vai tentar responder algumas dessas questões e dar argumentos para pensarmos em muitas outras.
Parte 5: Critério nº 01: Reusabilidade / FAN-IN
Uma procedure (usarei esse termo indistintamente, seguindo a tendência atual) deve, idealmente, ser aproveitada em muitos lugares do programa. Isso significará uma melhor aproveitamento do código, evitando que repetição de trechos de código, o que costuma dificultar a manutenção.
Tomemos um exemplo:
Imagine que em diversos momentos da operação de um sistema, quero validar os dígitos verificadores de um número de CPF qualquer que é fornecido. Se eu escrever o código de verificação repetidamente em todos os lugares em que ele for necessário, terei vários problemas:
a) O esforço de escrever tudo novamente, diversas vezes;
b) A possibilidade de, ao escrever tudo novamente, introduzir acidentalmente erros (claro que não estou levando em conta aqui o velho Ctrl-C/Ctrl-V, que diminui essa possibilidade);
c) Um pesadelo de manutenção, pois se um dia a Receita Federal resolver mudar a fórmula de cálculo dos dígitos verificadores do CPF, eu terei de sair como um maluco procurando em cada trecho do meu código os lugares em que aquele cálculo aparece e reescrevendo tudo. E se eu esquecer em um único lugar, certamente terei clientes furiosos correndo atrás de mim muito em breve...
Por isso é boa prática escrever essa rotina de verificação na forma de uma procedure e invocar essa procedure sempre que necessário, fornecendo a ela o CPF que se que verificar e recebendo dela um informe sobre a validade ou não daquele CPF.
Quando uma função é utilizada por muitos pontos do sistema, diz-se que ela tem um bom FAN-IN.
Assim, quando planejamos nossos módulos, devemos buscar para cada um deles um fan-in elevado.
Tomemos um exemplo:
Imagine que em diversos momentos da operação de um sistema, quero validar os dígitos verificadores de um número de CPF qualquer que é fornecido. Se eu escrever o código de verificação repetidamente em todos os lugares em que ele for necessário, terei vários problemas:
a) O esforço de escrever tudo novamente, diversas vezes;
b) A possibilidade de, ao escrever tudo novamente, introduzir acidentalmente erros (claro que não estou levando em conta aqui o velho Ctrl-C/Ctrl-V, que diminui essa possibilidade);
c) Um pesadelo de manutenção, pois se um dia a Receita Federal resolver mudar a fórmula de cálculo dos dígitos verificadores do CPF, eu terei de sair como um maluco procurando em cada trecho do meu código os lugares em que aquele cálculo aparece e reescrevendo tudo. E se eu esquecer em um único lugar, certamente terei clientes furiosos correndo atrás de mim muito em breve...
Por isso é boa prática escrever essa rotina de verificação na forma de uma procedure e invocar essa procedure sempre que necessário, fornecendo a ela o CPF que se que verificar e recebendo dela um informe sobre a validade ou não daquele CPF.
Quando uma função é utilizada por muitos pontos do sistema, diz-se que ela tem um bom FAN-IN.
Assim, quando planejamos nossos módulos, devemos buscar para cada um deles um fan-in elevado.