Pgina 1 de 5

01 Prefacio
Reviso: 13/07/2002

Abrangncia
Verso 5.07

Verso 5.08

Verso 6.09

Verso 7.10

Verses Anteriores

Existe um ditado chins que diz: O Homem no tropea em montanhas, tropea em

pedregulhos, areia, pequenos buracos, mas nunca em uma montanha.
Isso nos remete a pensar que onde erramos exatamente no simples, naquele detalhe quase
imperceptvel e que tem um valor muito grande para o todo. Avaliemos do ponto de vista
humano; ser to difcil cumprimentar a todos, sermos mais amigos, mais serenos nas decises
e companheiros uns dos outros e trabalharmos em equipe? Por que muitas vezes no o
fazemos? Por que insistimos no individualismo e no mal-humor? No seria mais fcil, at
mesmo bvio, estarmos mais bem-humorados e dispostos a trabalhar em equipe, trocarmos
conhecimento e discernimento nas decises, pensarmos mais no todo porm se importando
com as partes que o compe?
Seria mais interessante se ao caminharmos por um parque, prestssemos mais ateno nas
rvores, no caminho, nas flores, no canto dos passarinhos sem se esquecer do objetivo do
passeio, sem perder a noo de tempo e distncia, mas curtindo muito a paisagem, o detalhe.
Agora vamos traar um paralelo com o nosso dia a dia. No seria melhor ao reservarmos um
fonte, verificarmos com mais ateno:
As condicionais? Afinal muitas vezes no testamos um ELSE.
Os filtros? Geralmente esquecemos de tentar otimizar a performance no SQL.
As mensagens? Afinal to comum nos depararmos com textos completamente sem sentido.
Os helps? Damos pouca ateno a eles e nos esquecemos que a primeira coisa que o usurio
tenta.
Imaginem algumas ligaes menos por causa de uma simples documentao a mais! Aquele
ponto de entrada que criamos e no pensamos nos supostos parmetros que nosso pessoal em
campo pode querer, ou mesmo no retorno mais adequado para aquela funo.
Lembrem-se tambm da documentao do novo campo; Ela realmente necessria? Se a
chave de ndice imprescindvel, por que no crio uma query? Ao responder um BOPS, no
seria melhor que fosse sua ltima argumentao para o problema? Se isto ficar claro e bem
resolvido no teremos mais aquela ocorrncia ou dvida. Se tivermos que explicar um processo
para algum, que o faamos de tal forma a no gerarmos incgnitas.
Por que ao invs de focarmos nossos esforos para matarmos o BOPS, no avaliamos o fonte
para evitarmos NOVOS BOPS? Ao resolver uma ocorrncia lembre-se de todos os pontos de
implicao da sua atividade. O que isso ir impactar no servio do outro? Sem falar em
documentar no Quark!
Vamos trazer o comportamento do parque para o nosso trabalho tambm. Ao programar vamos
nos ater aos detalhes, sermos mais crticos, pensarmos que aquela instruo a mais, significa
muito para o sistema e que l na frente, se tratado com descuido, pode causar problemas.
Tenha convico que, se agirmos de maneira mais focada aos nossos propsitos, o passeio ou
melhor a programao, ser muito mais entusiasmada, produtiva e com uma margem de erro

http://dem.microsiga.com.br/w_wEx011.apw?Cod=018272

24/8/2004

Pgina 2 de 5

bem menor. Com esse comportamento quem ganha somos ns; Microsiga!. S assim teremos
mais tempo de irmos ao parque no final de semana.
Lembre-se que no adianta decidirmos passear no parque do Ibirapuera no domingo, e no
estarmos com a cabea voltada para o passeio, ao invs disso pensarmos no trabalho, na DLLl
que no comunica, no BOPS que no foi baixado, pois se assim for, estaremos to voltados
para outros fins que no curtiremos o passeio. Pense que para passear, ou melhor, programar,
a regra tambm valida, no adianta nem ao menos tentarmos se no estivermos
concentrados para isso.
Enfim, quer uma prova de trabalho em equipe com um alto nvel de qualidade e detalhes; este
manual, que foi constitudo em apenas 2 dias, com a colaborao de mais de 20 pessoas,
focadas em seus objetivos, se atentando cada um com o seu tema. O resultado? Um trabalho
excelente, um documento para nos ajudar a sermos melhores e no errarmos no fcil!

O Que Fazer um Programa com Inteligncia

Precisamos entender, antes de mais nada, o que inteligncia.
Segundo o dicionrio Michaelis, inteligncia significa:
faculdade de entender, pensar, raciocinar e interpretar;
Compreenso, conhecimento profundo.
De acordo com essa definio, se pretendemos utilizar nosso bem mais precioso em nosso trabalho,
vamos precisar desenvolver alguns hbitos:
Devemos estudar o programa antes de comear a desenvolver. Imagine prestar um concurso ou fazer
uma prova sem estudar. Vai ganhar um zero na certa! No programa no ser diferente!
Fazer um levantamento dos programas que sofrero as conseqncias das alteraes realizadas.
Todos esses programas devero ser testados juntamente com o programa alterado.
Antes de criar uma funo, consulte o Help Microsiga ou os colegas de trabalho, pois esta funo j
pode ter sido criada.
Ao criar uma funo, certifique-se de que no cabealho conste algumas informaes bsicas como:
descrio da funo, sintaxe, definio dos parmetros e autor. comum ao desenvolver uma
funo, utilizarmos outra j pronta como exemplo, e neste momento o copiar/colar nos faz
esquecer de alterar estas informaes.
Imagine se algum desenvolver uma funo inconsistente e esquecer de trocar o seu nome no
cabealho. Devemos assumir a responsabilidade de nossos atos.
Ao fazer a documentao das alteraes realizadas, certifique-se de que as informaes esto claras,
no s para o seu entendimento mas para que os colegas no percam tempo tentando entender-las.
Ao realizar os testes, defina critrios. Antes de comear defina onde quer chegar. No basta consistir
suas alteraes. O fato de suas alteraes estarem funcionando como previstas no garante a no
existncia de erros.
No limite-se a testar sua alterao na base que voc utilizou durante o desenvolvimento, pois voc
criou o ambiente perfeito para que o programa funcione.

http://dem.microsiga.com.br/w_wEx011.apw?Cod=018272

24/8/2004

Pgina 3 de 5

Pode parecer um pouco trabalhoso passar por estes processos no decorrer do desenvolvimento do
sistema, mas se medidas como estas no forem tomadas, o que era extremamente simples se tornar
extremamente trabalhoso.
Programando Simples, mas Certo

Qual profissional da rea de informtica ainda no se deparou com um cdigo fonte que parecia estar
escrito em outro dialeto mesmo com todo conhecimento adquirido naquela linguagem, este fato
geralmente ocorre pela m utilizao de sintaxes complexas que nem sempre significam um bom
funcionamento do sistema.
Um profissional da rea de informtica no possui nenhum modelo padro para desenvolver os seus
algoritmos, porm necessria a aplicao da tica profissional para que se possa desenvolver
algoritmos de maneira simples e correta, este conceito se baseia nos seguintes aspectos :
Entender qual o objetivo do processo em questo
Analisar a melhor forma de desenvolver um algoritmo que seja de fcil manuteno.
Utilizar comandos e sintaxes que utilizem o mximo de simplicidade e clareza possvel.
Erros que Podem ser Evitados
Existem alguns erros que com um pouco de ateno, podem ser evitados, tais como:
Verifique se a varivel est declarada antes do uso;
Ao declarar uma varivel, verifique qual a necessidade de ter essa varivel e qual o tipo e a sua
classe;
Classifiquem as funes e os procedimentos conforme a necessidade, como por exemplo, na
declarao de um array, defina o seu tamanho e no uso verifique se o elemento existe;
Salve a ordem e a rea e o registro do arquivo que ser utilizadopara que no final do processo se
recupere estes valores;
Evite retornar da funo antes do seu final, ou seja, crie preferencialmente um nico retorno;
Valide sempre o retorno do ponto de entrada;
Quando for gravar um arquivo que utiliza campos de outros arquivos, posicione todos os arquivos e
registros antes de iniciar a gravao, e descreva o alias do campo;
Utilize de arquivo CH nas strings para localizao;
Quando possvel utilize a linguagem SQL, pois minimiza o tempo de execuo em muitos processos.
A Importncia de Programas Documentados
Todos sabemos o quanto difcil elaborar e manter uma documentao tcnica atualizada, ainda
mais aqui na Microsiga, cuja dinmica dos acontecimentos muitas vezes impede que isso seja

http://dem.microsiga.com.br/w_wEx011.apw?Cod=018272

24/8/2004

Pgina 4 de 5

viabilizado. Diante desse cenrio, o que nos resta? Obviamente que pelo menos os programas sejam
documentados, bem documentados.
Documentar bem, no significa que tenhamos que escrever dezenas de linhas de comentrios a cada
linha de cdigo. Significa que os comentrios tm passar alguma informao relevante. Vemos
comentrios assim: compara A com B e s. Isso bvio, a leitura do cdigo j nos diz isso. A
documentao deve se ater a conceitos, por exemplo: Se A for maior que B, o arquivo de saldos
ser atualizado, caso contrrio o registro ser rejeitado para que o saldo no fique negativo.. Isto
sim transmite alguma informao.
Tambm se pode utilizar desse recurso para fazer lembretes a fatos importantes que, se forem
deixados de lado, podem comprometer o funcionamento das rotinas.
Por exemplo: Ao acionar esta funo, o arquivo XXX DEVE estar posicionado no ndice 1.
E os cabealhos? Quantos programas so aproveitados e nem sequer o nome do autor trocado?
Se o analista X tivesse escrito todos programas que aparece como autor ele deveria ter comeado na
poca do Charles Babage. O cabealho das funes de conter o nome na dita cuja, autor, data de
criao, uma descrio sumria de sua funcionalidade, a sintaxe e por ltimo, mas no menos
importante, a descrio dos argumentos de entrada e sada. A respeito desse ltimo item deve-se ter
especial ateno nas manutenes, pois novos argumentos so criados e nem sempre so declarados
nessa seo da documentao do cabealho, isso muito grave.
No IDE do PROTHEUS existem opes bastante interessantes para nos auxiliar nessa tarefa.
Experimente as opes Inserir, Documentao de cabealho e Inserir, Documentao de Explicao.
Existe ainda um tipo de documentao que nem sempre observada, aquela inerente ao prprio
cdigo. Programas cujas variveis so declaradas como nX, cVAR1, dAUX, nNUM, etc., so
extremamente difceis de entender e pior, manter. conveniente que os nomes das variveis retratem
seu uso ou destino. Por exemplo: dDataDeS ou dDataDeE. Segundo as convenes da Microsiga,
variveis do tipo DATA devem ser iniciadas pela letra d. Assim Data, no acrescenta nada ao
entendimento do que a varivel representa. Nos sobrou o dES e o dEE para informar para que
diados serve a bendita varivel. Ser sada, soluo, saldo? Entrada, Estorno, Estoque? Que tal isso:
dSeguro e dEntrega?
Enfim, como foi dito, no preciso escrever um livro a cada programa, basta ser objetivo e se
colocar na posio de quem no conhece o programa to pouco o assunto. Algum dia voc mesmo
poder estar nessa posio.
Cabealho de Programa / Funo
O cabealho do programa utilizado para identificar informaes gerais sobre a rotina, seu autor,
data, entre outras informaes. importante que esteja preenchida de forma correta e atualizada.
Lembre-se de que nada adianta um cabealho que no informe nada ou pior ainda, com informaes
errneas.
Lembre-se que um bom livro comea com um bom prefcio, e um bom programa comea com um
cabealho til e legvel.
A manuteno/atualizao do cabealho de responsabilidade da ltima pessoa que alterou o fonte.
O cabealho de programa padro da Microsiga contm: rotina, autor, data do desenvolvimento,
comentrio sinttico e sintaxe.

http://dem.microsiga.com.br/w_wEx011.apw?Cod=018272

24/8/2004

Pgina 5 de 5

Grupos Relacionados
Principal / Guias de Referncia / Como programar Advpl no ERP

Topo da Pgina

http://dem.microsiga.com.br/w_wEx011.apw?Cod=018272

24/8/2004