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