Dez práticas para um melhor trabalho de codificação
2 de Maio de 2009 @ 16:57 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
01. Monte a melhor equipe que puder
02. Estabeleça uma declaração de visão
03. Planeje e atenha-se ao planejamento
04. Troque o “temos que” para “como podemos”
05. Abstraia o PMI da vida dos desenvolvedores
06. Ouça seu time, constantemente
07. Faça gestão de riscos e pendências internas e externas ao projeto
08. Facilite acesso à informação
09. Use ferramentas para automatizar tarefas repetidas
10. Utilize o custo produtivo como parâmetro nas tomadas de decisão
SAP Community Day
5 de Março de 2009 @ 20:53 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Como alguns de vocês já sabem, o SAP Community Day foi realizado no dia de hoje, na sede da SAP em São Paulo.
A agenda foi:
09:00 - SAP executive keynote by Singh Mecker
09:50 - SAP NetWeaver technology Overview by Rogério Tambellini, Bruno Ambrózio and Eduardo De Angeli.
10:40 - SAP NetWeaver Process Integration (XI / PI) Overview by Rogério Tambellini.
11:30 - Web Dynpro ABAP vs Web Dynpro Java - How to help you to choose by Flávio Luis da Silva Mendes.
12:20 - Intervalo para o Almoço.
13:30 - The Pragmatic Programmer Applied to ABAP Development by Bruno Lucattelli.
14:20 - NWDI by Marlo J. P. Simon.
15:10 - Início dos Debates.
Parabéns aos organizadores do evento, em especial: Marcelo Ramos, Fernando Corbi, Cecilia Marshall. Também gostaria de dizer que espero ansiosamente pelos próximos eventos.
Conforme prometido, a apresentação encontra-se disponível para download em formato PDF, uma vez que foi gerada usando o Keynote, da Apple.
Se alguém desejar a apresentação original Keynote, em full hd, por favor me mande um e-mail.
PS: Aos demais que apresentaram e que desejarem hospedar seu material, posso colocar aqui e atualizar o artigo para conter também o link das demais apresentações.
UPDATE: Algumas fotos do evento estão disponíveis na conta do Marcelo Ramos no Picasa.
DRY - Don’t Repeat Yourself!
4 de Fevereiro de 2009 @ 01:03 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
E eu virei mais um dos babões pelo livro Pragmatic Programmer. Nele, praticamente todos os princípios são aplicáveis ao dia-a-dia.
No site do livro você pode obter uma relação de todos os princípios. Também tem acesso a alguns trechos do livro on-line. Se você se considera um desenvolvedor de software sério, não importa em qual linguagem, você DEVE LER ESTE LIVRO!
Bom, alguns deles em particular me chamaram mais a atenção para o desenvolvimento de software em ABAP. Um deles é o DRY:
DRY—Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Todo ABAP sabe que inventar rotinas para ações que o código standard do SAP já faz é errado e uma perda de tempo.
Reinventar a roda é errado, ponto final!
Mas o que um BOM desenvolvedor ABAP deve saber é que esta sentença não se aplica somente ao standard. Durante a vida útil de um ambiente SAP, muito código ABAP Z é gerado. Ocorre que a maioria deste código é escrito, reescrito, copiado, duplicado e reinventado várias vezes.
Alguns exemplos de rotinas que invariavelmente são duplicadas por consultorias e funcionários de qualquer empresa que utiliza SAP:
- Programas/rotinas para envio de e-mails
- Programas que exportam dados para PDF, Excel, Word, CSV, etc
- Aplicações que executam batch-input (podendo ou não gerar pastas)
- Logs de erros e de aplicação em geral
- Rotinas criadas dentro de eventos de tela (PBO/PAI) e que precisam ser executadas via RFC/IDOC/Batch
- Workflow de atividades
- Autorização e validação de perfil (authority-checks)
Será que a vida não é curta demais para que, toda vez que precisarmos de um batch-input, tivermos de escrever as macros abaixo?
DEFINE bdc_dynpro.
clear gt_bdcdata.
gt_bdcdata-program = &1.
gt_bdcdata-dynpro = &2.
gt_bdcdata-dynbegin = 'X'.
append gt_bdcdata.
END-OF-DEFINITION.
DEFINE bdc_field.
clear gt_bdcdata.
gt_bdcdata-fnam = &1.
gt_bdcdata-fval = &2.
append gt_bdcdata.
END-OF-DEFINITION.
E manter essas rotinas em um arquivo .txt em seu notebook não é bom o bastante! Se você tiver 10 batch-inputs para desenvolver, vai copiar 10 vezes as macros acima? Pense muito bem antes de responder!
Mas aí você pode até dizer:
Mas eu não serei o primeiro, nem o último a fazer isso! Além do mais, o próprio cliente não liga se copiamos código ou não! Eu posso não duplicar código, mas os outros vão continuar duplicando, não tem jeito!
É verdade! O cliente não exige que façamos o máximo de reuso em seu ambiente, embora devesse! Na maioria das vezes trata-se de um problema cultural, que começa lá na implementação.
A partir de dezenas de especificações funcionais, detalhando gaps que precisam de desenvolvimento, chegamos a centenas de especificações técnicas, as quais invariavalmente pedem coisas semelhantes. Adam Baryla fala em seu blog na SDN sobre este fenômeno.
Mas a linha de racicínio aqui é: Não te interessa se o cliente usa ou não usa boas práticas de desenvolvimento! VOCÊ USA! E este tipo de exemplo se aplica a coisas pequenas, como um simples REPORT de exemplo baixado da internet:
REPORT YPROGIND.
DATA: A LIKE SY-UCOMM.
DO 100 TIMES.
DO 300 TIMES.
GET TIME.
ENDDO.
A(3) = SY-INDEX.A+3 = '%'.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = SY-INDEX
TEXT = A.
ENDDO.
Fonte: http://www.guidancetech.com/people/holland/sap/abap/yprogind.htm
Agora, esta é uma rotina bem simples! Você faz um ajuste rápido, e está pronto para copiá-la diversas vezes em sua aplicação:
data w_step_current type i.
data w_step_total type i.
data w_step_percent type i.
data w_step_text type string.
w_step_current = 10 .
w_step_total = 150.
w_step_percent = ( w_step_current * 100 ) / w_step_total.
w_step_text = 'Hey, running step 10 of 150 here!'.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = w_step_percent
TEXT = w_step_text.
Agora, a primeira pergunta a fazer é:
O que diz respeito à minha rotina, e a ela somente?
A função desta rotina é exibir no SAPgui uma barra de progresso, sendo assim precisamos de duas informações variáveis (e que não fazem parte do escopo desta rotina) apenas:
- O texto que deve ser apresentado
- O percentual que deve ser representado no relógio de progresso
Portanto, vamos criar um FORM que trate as variáveis como parâmetros. Assim, o caller poderá se decidir sobre o texto e o percentual apresentado.
data w_step_current type i.
data w_step_total type i.
data w_step_percent type i.
data w_step_text type string.
w_step_current = 10 .
w_step_total = 150.
w_step_percent = ( w_step_current * 100 ) / w_step_total.
w_step_text = 'Hey, running step 10 of 150 here!'.
perform l_progress_indicator using w_step_percent w_step_text.
form l_progress_indicator using percent text.
check percent gt 0 and text ne space.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = w_step_percent
TEXT = w_step_text.
endform.
Ótimo, mas ainda sem muita inteligência. O trabalho e chamar um FORM ou chamar uma FUNCTION é praticamente o mesmo, então porque alguém usaria isso? Acho que ainda há mais para ser feito! Afinal, de qualquer forma ainda preciso calcular o percentual antes de toda vez que quiser chamar esta função.
OPA, Don’t Repeat Yourself!!!!!!!
Faça um outro FORM para cálculo percentual (você SEMPRE precisa disso em algum canto).
data w_step_percent type i.
perform l_calculate_percentual using 150 50 changing w_step_percent.
perform l_progress_indicator using w_step_percent 'Hey, running step 10 of 150 here!'.
form l_calculate_percentual using total partial changing percent.
check total gt 0.
percent = ( partial * 100 ) / total.
endform.
form l_progress_indicator using percent text.
check percent gt 0 and text ne space.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = percent
TEXT = text.
endform.
Melhorou! De lambuja, ainda adicionamos uma verificação para prevenir divisão por zero (você havia notado esse bug antes?) e removemos algumas variáveis que já não são mais necessárias!
Isso responde à segunda pergunta que você deve fazer:
Quais outros problemas a minha rotina resolve, além daquele para o qual ela foi projetada?
Mas ainda tem uma coisa pendente. Aqui, é tudo questão de gosto. Eu sou muito preguiçoso, então não vou gostar de ter que calcular o percentual ANTES de ter que chamar o progress indicator. Além disso, não gosto da idéia de precisar declarar uma variável em meu programa só pra chamar a rotina.
Por isso, fiz mais alguns ajustes!
form l_progress_indicator using total partial text.
check total gt 0 and partial gt 0 and text ne space.
data lv_step_percent type i.
perform g_calculate_percentual using total partial changing lv_step_percent.
perform g_progress_indicator using lv_step_percent text.
endform.
form g_calculate_percentual using total partial changing percent.
check total gt 0 and partial gt 0.
percent = ( partial * 100 ) / total.
endform.
form g_progress_indicator using percent text.
check percent gt 0 and text ne space.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
PERCENTAGE = percent
TEXT = text.
endform.
Também aproveitamos para dar uma geral nas variáveis (nomenclatura).
Bom, pra mim agora ficou claro que, o l_progress_indicator deve ser usado para a minha aplicação, e que ele depende do global g_progress_indicator e do g_calculate_percentual. Portanto, é natural que um desenvolvedor ABAP os coloque juntos no mesmo include.
Isto pode facilitar a implementação, mas dificulta o controle de versão do software. Imagine que você tem um change request com o include ZxxxxF01, contendo os três FORMs acima, dentro de um change request. Como dizer se a alteração aqui afeta outros objetos, ou se trata-se apenas de uma alteração local? Só por comparação remote!
Então, vem a terceira pergunta:
É possível realizar alterações e medir o impacto das mudanças rapidamente?
Mais importante que desenvolver, é manter! Joel Spolsky tem um artigo que fala sobre a dificuldade geral dos desenvolvedores em ler código para oferecer manutenção.
Por isso, tome o cuidado de inserir comentários (úteis) e separe CADA FORM EM UM INCLUDE. O próprio standard SAP faz isso frequentemente. A MM01 por exemplo, tem grupos de função aonde cada rotina FORM tem um include separado.
Neste caso, ao invés de ter um ZxxxF01, você teria:
- Z_G_CALCULATE_PERCENTUAL
- Z_G_PROGRESS_INDICATOR
- Z_L_PROGRESS_INDICATOR
Você também pode nomear o include Z_L_PROGRESS_INDICATOR para algo relacionado à sua aplicação.
Sendo assim, você está dizendo claramente aos demais desenvolvedores o seguinte:
Usem os G_*, pois estes são de domínio público, e podem ser usados por qualquer um, ao passo que a rotina L_* é proprietária de uma determinada aplicação. O desenvolvedor que desejar utilziar pode, mas você não se compromete com futura compatibilidade da função.
Além disso, se muitas outras aplicações começarem a usar a sua rotina, talvez seja a hora de mudá-la para G_*, e torná-la de domínio público de uma vez.
PS: Fica claro que rotinas estruturadas não te protegem de que qualquer pessoa as utilize. Grupos de função podem ser uma boa idéia na hora de proteger código. Outra alternativa (mais acertada ainda) é utilizar classes e métodos.
One Laptop per Child goes to Colombia
2 de Janeiro de 2009 @ 19:01 - BrunoArquivado sob Off-Topic | 2 Comentários | Link desta publicação | Enviar por e-mail
I’ve spent my whole life worrying about the human-computer interface, so I don’t want to suggest that what we have today is even close to acceptable.
Você já ouviu falar em Nicholas Negroponte? Aqui vai um pouco de informação a respeito dele:
- Nascido em 01 de Dezembro de 1943
- Irmão do diplomata americano John Negroponte
- Fundou o MIT’s Architecture Machine Group em 1967
- Fez sua primeira apresentação no TED
- Fundou o MIT Media Lab em 1985
- Foi um dos fundadores da Revista WIRED, em 1992
- Escreveu artigos para a WIRED de 1993 até 1998
- É autor do livro Being Digital, publicado em 1995
- Em 2006, deixou o MIT Media Lab e colocou todo seu foco no projeto OLPC
Negroponte é antigo no TED, fez sua primeira apresentação em 1984 (acompanhe nos vídeos abaixo).
Eu acompanho a história deste projeto desde 2006, quando Negroponte voltou ao TED para anunciar os seus planos para o projeto One Laptop per Child.
Depois, em Junho de 2008, Negroponte retornou ao TED para uma atualização do seu projeto.
Por fim, Negroponte compõe junto ao TED um vídeo de 7 minutos para mostrar na prática a distribuição dos seus laptops na Colômbia.
Vida longa, Negroponte!
Referências:
Negroponte no TED
Entrevista para a WIRED, 1995 (a citação acima vem daqui)
Negroponte na Wikipedia
“Z” ABAP Unit para versões antigas do SAP
1 de Janeiro de 2009 @ 19:23 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Se você é desenvolvedor ABAP e já tem familiaridade com o ECC 6.0, já conhece as vantagens de usar o ABAP Unit. Mas o que acontece se você precisa realizar testes unitários em ambientes mais antigos, os quais não trabalham ainda com o ABAP Unit?
Bem, eu estou em um projeto aonde usamos SAP R/3 4.7 Enterprise, e aqui não há como construir classes de teste unitário, pois simplesmente não há o framework disponível nesta versão ainda.
Como o projeto aqui é grande, usei de algum tempo meu para escrever um interpretador de testes bem simples. O suficiente para testar minhas classes.
O objetivo desta aplicação não é concorrer com o ABAP Unit. Não temos nada avançado como relatórios de cobertura de código-fonte ou classes ASSERT. Na verdade, o objetivo é tentar levar a experiência de uma ferramenta de testes unitários em ambientes aonde o ABAP Unit não está disponível.
O desenvolvimento desta ferramenta teve dois objetivos:
- Simples Distribuição
- Simples Utilização
Sendo assim, usei as diretrizes abaixo como balizadores para tomada de decisão durante a fase de construção (que foi bem curta, por sinal):
Ser totalmente compatível com ABAP clássico
Esta solução deve se permitir ser executada tanto em ECC 6.0 quanto SAP R/3 4.0. Sendo assim, não podemos nos dar ao luxo de usar comendos modernos do ABAP como RTTS, RegEx, etc. A solução deve ter código simples, arroz com feijão, para que a compatibilidade com o kernel do ABAP seja possível, independente da versão do mesmo, ou do ambiente.
Também não podemos abusar do framework. Evitamos implementar funcionalidades do ABAP standard que poderiam ser alteradas, ampliadas ou descontinuadas conforme as versões fossem mudando. Assim, reduzimos ao máximo a utilização de:
- Estruturas de dados e categorias de tabelas do ABAP Data Dictionary
- Pools de tipos, Elementos de dados e domínios standard (ex: slis)
- Tabelas transparentes e visões standard
- BAPI’s, classes públicas e FM’s standard
- Suporte a UNICODE
Tomamos todos estes cuidados para focar na facilidade para distribuição da solução. A preocupação é com o desenvolvedor que vai fazer uso desta solução. Ele pode, se quiser, olhar todo o código-fonte, debugar, alterar, melhorar, etc.
Entretanto, ele não precisa! Como desenvolvedor ABAP, cansei de encontrar exemplos de solução para problemas complexos, os quais eu não conseguia fazer funcionar pelo simples fato de que os programas não ativavam. E na maior parte das vezes, o problema estava em estruturas, tabelas transparentes, funções e comandos que não existiam no meu ambiente, ou estavam diferentes (mais ou menos evoluídos).
Sendo assim, quanto menos dependermos do ambiente, mais provável é a chance do programa ativar logo de primeira, sem que o desenvolvedor fique quebrando a cabeça, simplesmente pelo fato de que é um erro. O desenvolvedor, como cliente da solução, não deve precisar entender seu funcionamento completo para poder utilizá-la.
Sustentar-se em poucos objetos ABAP
Além de evitar fazer uso de funcionalidades do framework ABAP, também evitei quebrar a solução em 290 grupos de função com 4812 módulos de função, usando 173 tabelas transparentes, etc.
Não adianta termos uma solução que é compatível com qualquer versão do ambiente, mas que é impossível de instalar, uma vez que é grande e segmentada demais.
Sendo assim, focamos em construir o mínimo possível de código, e separá-lo em sessões dos mesmos programas, ao invés de abrir includes e grupos de função ou classes em separado.
Esta versão não faz uso de SAPlink para instalação. Particularmente, eu tive mais problemas para tentar fazer o SAPlink funcionar em ambientes mais antigos do que eu gostaria. Sendo assim, não adianta a solução toda ser 100% compatível com o ambiente do desenvolvedor que pretende usá-la se o seu instalador não é.
Na verdade, esta versão não dispõe de instaladores, apenas o código-fonte para execução e um manual de instalação (mas eu apreciaria muito se você escrevesse um instalador para esta aplicação).
Possibilitar a execução completa dos testes com apenas um clique
Usando ABAP Unit, sempre senti falta de duas coisas:
- Completa separação das classes de testes para as classes de negócio.
- Possibilidade de executar todas as classes de teste de uma única vez.
A primeira das duas já é atendida pela forma como a solução foi construída. A segunda foi cuidadosamente preparada. A partir de uma tabela transparente do banco de dados, são configurados os programas que contém os testes unitários para o sistema. Sendo assim, a execução de uma bateria de testes consiste em uma varredura nesta tabela Z, resgatando todos os programas de testes. A partir dos resultados, a solução executa os testes contidos em cada programa, retornando os resultados ao usuário final. Assim, com apenas um clique do mouse é possível realizar um teste unitário em todo o sistema.
Segue abaixo o passo-a-passo para instalação e utilização:
1 - Criando a tabela de configuração
Basta criar no seu ambiente uma tabela Z que contenha a seguinte estrutura de dados:
Utilize as seguintes Configurações técnicas:
Se julgar interessante, gere também um diálogo de atualização de tabelas (SM30) e crie uma transação para ela.
2 - Criar a aplicação de execução dos testes.
Crie na SE38 um novo REPORT para execução dos testes. Segue código-fonte abaixo:
REPORT z22f_unittest.
* Declaração de tipos.
TYPES: BEGIN OF ty_source,
line(72),
END OF ty_source.
TYPES: BEGIN OF ty_forms,
formname(30),
END OF ty_forms.
* Declaração de WA para testes unitários.
DATA gw_unit_tests TYPE z22f_unittest.
DATA gt_unit_tests TYPE TABLE OF z22f_unittest.
* Tela de seleção.
SELECTION-SCREEN BEGIN OF BLOCK b1.
PARAMETERS p_doit TYPE flag AS CHECKBOX.
PARAMETERS p_debug TYPE flag AS CHECKBOX.
SELECTION-SCREEN END OF BLOCK b1.
START-OF-SELECTION.
PERFORM get_tests TABLES gt_unit_tests USING p_doit.
LOOP AT gt_unit_tests INTO gw_unit_tests.
PERFORM run_tests USING p_doit p_debug gw_unit_tests-progn.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Form get_tests
*&---------------------------------------------------------------------*
FORM get_tests TABLES table_return STRUCTURE z22f_unittest USING i_doit.
DATA lw_unit_tests TYPE z22f_unittest .
DATA lt_unit_tests TYPE TABLE OF z22f_unittest .
SELECT * FROM z22f_unittest
INTO TABLE lt_unit_tests
WHERE active EQ 'X'.
MOVE lt_unit_tests[] TO table_return[].
ENDFORM. "get_tests
*&---------------------------------------------------------------------*
*& Form run_tests
*&---------------------------------------------------------------------*
FORM run_tests USING i_doit i_debug i_prog.
DATA lw_forms TYPE ty_forms.
DATA lt_forms TYPE TABLE OF ty_forms.
DATA lv_perc TYPE i.
DATA lv_log_out TYPE string.
IF NOT i_doit IS INITIAL.
PERFORM read_report TABLES lt_forms USING i_prog.
IF NOT lt_forms[] IS INITIAL.
NEW-LINE.
MOVE 'Tests Pool: 'TO lv_log_out.
CONCATENATE lv_log_out '.........................................'
INTO lv_log_out.
WRITE AT / lv_log_out(50).
WRITE i_prog.
NEW-LINE. NEW-LINE.
ENDIF.
LOOP AT lt_forms INTO lw_forms.
PERFORM get_perc TABLES lt_forms USING sy-tabix CHANGING lv_perc.
PERFORM do_splash USING lw_forms-formname i_prog lv_perc.
PERFORM do_test USING lw_forms-formname i_prog i_debug.
ENDLOOP.
ENDIF.
ENDFORM. "run_tests
*&---------------------------------------------------------------------*
*& Form read_report
*&---------------------------------------------------------------------*
FORM read_report TABLES table_forms USING i_program.
DATA lt_source TYPE STANDARD TABLE OF ty_source
WITH NON-UNIQUE DEFAULT KEY INITIAL SIZE 500.
DATA lt_forms TYPE TABLE OF ty_forms.
DATA lw_forms TYPE ty_forms.
DATA lw_source TYPE ty_source.
DATA lv_dummy TYPE string.
READ REPORT i_program INTO lt_source.
CHECK sy-subrc IS INITIAL.
LOOP AT lt_source INTO lw_source.
CONDENSE lw_source.
IF lw_source-line(4) = 'FORM'.
CLEAR lw_forms.
SPLIT lw_source-line AT space INTO lv_dummy lw_forms-formname.
SPLIT lw_forms-formname AT space INTO lw_forms-formname lv_dummy.
TRANSLATE lw_forms-formname TO UPPER CASE.
APPEND lw_forms TO lt_forms.
ENDIF.
ENDLOOP.
table_forms[] = lt_forms[].
ENDFORM. "read_report
*&---------------------------------------------------------------------*
*& Form check_result
*&---------------------------------------------------------------------*
FORM check_result USING i_form_name i_flag_ok.
DATA lv_log_out TYPE string.
NEW-LINE.
CONCATENATE 'Testing:' i_form_name
INTO lv_log_out SEPARATED BY space.
CONCATENATE lv_log_out '.........................................'
INTO lv_log_out.
WRITE AT / lv_log_out(50).
IF i_flag_ok IS INITIAL.
WRITE 'ERRO.' COLOR 6.
ELSE.
WRITE 'OK.' COLOR 5.
ENDIF.
ENDFORM. "check_result
*&---------------------------------------------------------------------*
*& Form do_test
*&---------------------------------------------------------------------*
FORM do_test USING i_form_name i_prog_name i_debug.
DATA lv_ok TYPE flag.
DATA lv_form_name TYPE string.
DATA lv_prog_name TYPE string.
lv_ok = space.
lv_form_name = i_form_name.
lv_prog_name = i_prog_name.
IF NOT i_debug IS INITIAL.
BREAK-POINT.
ENDIF.
PERFORM (lv_form_name) IN PROGRAM (lv_prog_name) CHANGING lv_ok.
PERFORM check_result USING lv_form_name lv_ok.
ENDFORM. "do_test
*&---------------------------------------------------------------------*
*& Form do_splash
*&---------------------------------------------------------------------*
FORM do_splash USING i_form_name i_prog_name i_percentage.
DATA lv_text TYPE string.
CONCATENATE 'Testing:' i_form_name 'in program' i_prog_name
INTO lv_text
SEPARATED BY space.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
percentage = i_percentage
text = lv_text.
ENDFORM. "do_splash
*&---------------------------------------------------------------------*
*& Form get_perc
*&---------------------------------------------------------------------*
FORM get_perc TABLES table_forms
USING actual_index
CHANGING return_perc.
DATA lt_forms TYPE TABLE OF ty_forms.
DATA lv_descr TYPE i.
MOVE table_forms[] TO lt_forms[].
DESCRIBE TABLE lt_forms LINES lv_descr.
return_perc = ( actual_index * 100 ) / lv_descr.
ENDFORM. "get_perc
3 - Crie os programas de testes e cadastre-os na tabela Z22F_UNITTEST
Exemplo de REPORT contendo testes:
REPORT z22f_cl_mt_util_unittest.
*&---------------------------------------------------------------------*
*& Form get_mat_classes_valid
*&---------------------------------------------------------------------*
FORM get_mat_classes_valid CHANGING ok.
DATA lt_classes TYPE z22f_table_sclass.
CLEAR ok.
CALL METHOD z22f_cl_mt_util=>get_mat_classes
EXPORTING
i_matnr = '000000000003137836'
RECEIVING
table_classes = lt_classes.
IF NOT lt_classes[] IS INITIAL.
ok = 'X'.
ENDIF.
ENDFORM. "get_mat_classes_valid
*&---------------------------------------------------------------------*
*& Form get_mat_classes_invalid
*&---------------------------------------------------------------------*
FORM get_mat_classes_invalid CHANGING ok.
DATA lt_classes TYPE z22f_table_sclass.
CLEAR ok.
CALL METHOD z22f_cl_mt_util=>get_mat_classes
EXPORTING
i_matnr = '000000000000000000'
RECEIVING
table_classes = lt_classes.
IF lt_classes[] IS INITIAL.
ok = 'X'.
ENDIF.
ENDFORM. "get_mat_classes_invalid
Programa cadastrado na tabela Z:
4 - Execute o Z22F_UNITTEST e verifique os resultados.
Oops, parece que há um método com erro no teste. Uma vez corrigido, vamos executar novamente:
Ah, muito melhor!
Por fim, gostaria de dizer que esta aplicação está bem crua (eu diria que ainda é um Pre-Alpha). Sendo assim, toda a ajuda na sua melhoria é bem-vinda. Críticas e sugestões também!
29-30/12 - Working!
30 de Dezembro de 2008 @ 14:50 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Algumas fotos do pessoal trabalhando aqui ontem e hoje.
WIRED’s Top 10 Breakthroughs of 2008
26 de Dezembro de 2008 @ 19:02 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Big Bang? Faseado? Qual é a sua? - Parte I - BIG BANG
28 de Novembro de 2008 @ 00:48 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Os dois métodos mais utilizados para desenvolver e entregar software. Seja você desenvolvedor de software para uma empresa de tecnologia (ex: SAP, Microsoft, Apple, etc), seja você desenvolvedor para uma consultoria de serviços em desenvolvimento de software, seja você membro da equipe de TI de uma empresa que não tem TI como principal negócio, nem de longe!
BIG BANG
O método do big bang é o mais usado por empresas de software comercial. A idéia é manter o máximo de segredo possível, e só liberar o software para aquisição quando cada pequena parte dele estiver funcionando bem.
Investe-se uma grande quantidade de dinheiro em pesquisa de mercado, entrevistas com possíveis (e às vezes atuais) clientes, testes e mais testes de usabilidade, provas de conceito, protótipos e mais protótipos. Tudo para tentar entender qual é o real problema o qual o sistema se propõe a resolver, bem como quais são os diferenciais que os usuários vão apreciar na ferramenta.
Uma outra grande quantia de dinheiro vai para desenvolver e estabilizar a solução. Preparar material de ajuda ao usuário final considerando que este nunca viu o software na sua frente, e portanto, o sistema de ajuda precisa de informações das mais básicas às mais avançadas. É aqui também aonde se elaboram os treinamentos oficiais, academias, certificações, etc.
E também tem o Marketing. Preparar uma campanha grandiosa de lançamento, material publicitário, comerciais, promoções, website, etc. Se possível, fazer o lançamento parecer com um show de rock, como a exemplo da Microsoft, quando lançou o Windows Vista, ou da Apple, quando lançou o Mac OS X.
Estas empresas também investem uma boa quantia de dinheiro em gerenciar a qualidade do produto. Todas elas (com exceção da indústria de games, a qual não tem o privilégio de errar grande) olham para os resultados dos testes, cheio de bugs, e escolhem aqueles aonde o custo de correção é pago pelo benefício imediato de ter a funcionalidade implementada na solução no momento do lançamento. O resto dos bugs ficam na solução, e são corrigidos ao longo do tempo através de hot-fixes, service packs e updates em geral.
Assim, todas elas entregam software com bugs, e elas sabem disso! Escolhem propositadamente cada bug que você vai certamente encontrar, quebrar a cabeça e se irritar até descobrir que não há nada mais que possa fazer, a não ser esperar por uma correção.
Elas traçam um plano para corrigir estes bugs usando o dinheiro das primeiras vendas, através de um processo de suporte ao produto, ao invés de gastar mais tempo e orçamento do projeto de desenvolvimento.
Mas big bang também é usado por corporações aonde desenvolvimento de software está longe de ser o seu principal negócio. Software corporativo tende a ter os mesmos moldes de entrega do software comercial. Entretanto, o processo (e o investimento principalmente) é bastante reduzido. E isto põe em risco a saúde da corporação.
Quando falamos em pequenos sistemas internos, dificilmente se vê no time de projeto qualquer preocupação com questões como usabilidade, acessibilidade, tradução, segurança, etc.
Além disso, a estabilidade da solução dificilmente é garantida. Testes unitários simples são realizados normalmente pelos próprios desenvolvedores, enquanto os usuários são obrigados a fazerem o papel de testadores (mesmo não tendo formação adequada para tal) em curtos e pouco numerosos ciclos de teste integrado. As correções, trabalho que deveria intermediar os ciclos de teste, são na verdade, compostos por dois ou três dias, com sorte uma semana.
Para dificultar, a documentação dos testes é pobre em detalhes, e o usuário sempre acaba reproduzindo um mesmo bug várias vezes (e levando para a produção com ele em alguns casos) até que o mesmo seja corrigido.
O suporte pós-implementação é outra deficiência. Terminar o projeto deveria ter o significado de focar a equipe em estabilizar aqueles bugs que subiram com a ferramenta para a produção por não serem impeditivos. Na realidade, o que ocorre é um debandar total.
TI tem projetos demais, e este já acabou! Tire toda a equipe imediatamente, pois preciso dela em outra empreitada.
E estas forças todas juntas geram a situação mais comum em projetos de software, mais particularmente na fase de testes e estabilização. A eterna briga entre os usuários, que querem TUDO corrigido antes de ir para a produção, gerando listas e mais listas de erros (e novas funcionalidades também) que parecem não ter fim.
Do outro lado, temos um time de desenvolvedores desgastado com o projeto, geralmente por conta dos meses trabalhando 12, 14 horas por dia para entregar o projeto, aonde os bugs, considerados impeditivos pelos usuários, para os desenvolvedores não passam de frescuras e medo dos usuários de perder o emprego ou sacrificar o emprego de outros colaboradores.
Alguém aí já esteve na pele deste time de desenvolvimento? Pois bem, os usuários não querem largar os desenvolvedores, pois todos eles dão a nítida sensação de que, ao menor discuido, vão desaparecer e deixar os usuários com o sistema em produção e com tudo aquilo que eles gostariam de fazer.
Sendo assim, mesmo que algo seja mesmo frescura, o usuário trata como impeditivo, e aproveita a presença do time de desenvolvimento para extrair o máximo que puder.
A reação de TI, por outro lado, é a de se proteger. Criar em volta de si um escudo, composto por metodologias, documentação e burocracia. Aí os projetos ficam mais caros, mais lentos, e cada vez mais, o cenário se repete.
Portanto, se olharmos o BIG BANG de maneira fria, podemos concluir que tem:
PRÓS:
- Gerenciar um time de desenvolvimento com uma única agenda é mais fácil. Datas de início de desenvolvimento, início de testes, início de correções, etc únicas para a equipe e para o projeto é mais simples do que gerenciar vários ciclos de cada.
- Gerenciar o tempo dos membros da equipe ao longo de vários projetos em um portfolio é mais fácil, pois temos datas fechadas para início e término.
- Prever custos também parece mais fácil, afinal é só pegar o número de desenvolvedores necessários, multiplicar pelo número de semanas do projeto e multiplicar por 40 horas semanais (mesmo que o normal seja 60).
CONTRAS:
- Aceite! Nem você, nem ninguém gosta de mudanças. O modelo BIG BANG oferece sempre um grande volume de funcionalidades sendo publicado de uma só vez. Isto significa um alto impacto em gestão de mudanças, processos, treinamento, suporte, etc. E isto é caro e desconfortável para qualquer um.
- Qualquer funcionalidade que não esteja estável, mesmo após várias baterias de teste e correção, pode ser um impeditivo e um problemão para a entrada em produção. Mesmo que não seja crítica, a idéia de entregar o software só quando estiver pronto acaba contribuindo para o projeto se alongar mais que o necessário.
- O modelo BIG BANG precisa de uma porção de mecanismos de gestão e muita preparação antes da execução do projeto. Em desenvolvimento corporativo, é raro conseguirmos um time de projeto que desenvolva todas estas faculdades, a fim de obter sucesso. Primeiro porque é caro, segundo porque demora mais.
- O risco da aceitação dos usuários finais não ser o que se espera é alto, pois a grande maioria dos usuários não tem nenhum contato com o software até o dia em que este é liberado para utilização, seja box, seja corporativo. Um bom exemplo foi o Windows Me, o qual pareceu uma boa jogada por parte da Microsoft, mas que se mostrou insatisfatório, forçando-a a liberar o Windows XP mais cedo do que o previsto inicialmente.
Delegação
13 de Outubro de 2008 @ 13:42 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Primeiro porque eu consegui ler em aproximadamente duas horas. Depois porque, de maneira muito rápida, elenca os principais pontos sobre delegação. O livro mostra como é fácil distribuir tarefas e acompanhá-las junto a sua equipe. Mas melhor que isso, mostra os estágios da delegação. Se você é novo em gestão de pessoas, eu recomendo a sua leitura.
Muito bom!
@McCarran International Airport
14 de Setembro de 2008 @ 14:42 - BrunoArquivado sob Off-Topic, SAP | 1 Comentário | Link desta publicação | Enviar por e-mail
Aproveitando o WI-FI de graça do aeroporto de Las Vegas.
Bom, sexta-feira saímos do TechEd 2008, passamos no hotel e de lá fomos para o Premium Outlet comprar camisa e sapato para sairmos à noite (aqui a maioria dos lugares exigem sapato e camisa). Depois, passamos no hotel e dormimos um pouco. Daí saímos para conhecer a PURE no Ceasar Palace. Muito bacana o lugar! Valeu conhecer. Saí de lá cansado (eu já estava cansado antes de chegar lá hehe) e fui direto pro hotel dormir. O Carlos ainda foi pra outro lugar, nem sei que horas chegou no hotel.
Na sexta-feira, acordei e já arrumei as malas, deixando de fora só as roupas que eu iria precisar. Deu um baita trabalho por conta das coisas que eu comprei aqui, mas fechou! Coitada da mala da minha namorada, não sei se ela aguenta até o final da viagem hahah.
Bom, depois das malas feitas, descemos para o hotel para conseguirmos mais uma diária (eu explico, da primeira vez que reservamos o hotel, nosso vôo saía no dia 13 à tarde. Depois mudamos para o dia 14 de manhã, e não mudamos o hotel) e foi bem simples. Depois disso, batemos perna o dia todo. Conhecemos vários casinos e passeamos de ônibus para o sul e para o oeste. Tiramos muitas fotos (depois eu posto aqui, pois a câmera tá sem bateria de novo).
Voltamos do centro por volta das 7 da noite. Nos arrumamos para o Cirque du Soleil “O”. Depois, destino ao Bellagio. Chegando lá, o Carlos se deu conta de que tinha deixado o passaporte no hotel, e não poderíamos retirar os ingressos. Numa correria danada, mesmo com as pernas doendo de andar o dia todo, voltamos pro hotel para buscar o tal do passaporte e de lá voltamos para o Bellagio antes das 21:30 (o espetáculo começa às 22:30, mas tínhamos até uma hora antes do espetáculo para retirar os ingressos). Enfim, deu tempo e assistimos ao show. Só tenho uma coisa pra dizer: CARA, MUITO BOOOOOOM!. Valeu cada centavo.
De lá, famintos porque não pudemos jantar antes do show em virtude da correria, passamos num casino perto do nosso hotel aonde tinha um restaurante 24h. De lá foi hotel e cama.
Agora estamos aqui no McCarran, esperando nosso vôo. O horário era 10:20(14:20 no Brasil), mas atrasou em virtude do mau tempo em Chicago, local aonde a gente faz conexão para Nova Iorque. Pelo menos, segundo o pessoal da American Airlines, não vamos ter problemas com conexão, pois elas também atrasaram.
Nós deveríamos chegar em Chicago às 15:55(17:55 no Brasil, pois de Las Vegas para Chicago são duas horas a mais no fuso horário) e então embarcar para Nova Iorque no vôo das 17:10(19:10 no Brasil) pra chegar em Nova Iorque às 20:35 (21:35 no Brasil, pois temos mais uma hora de fuso). Agora a gente deve chegar lá por volta das 21:35 (22:35 no Brasil).
Vai ser bom pra manter contato com o Brasil, pois ao invés de 4 horas de diferença, vai ser uma só :D.
Ah, também preciso contar que o Carlos conseguiu, mesmo depois de checar DUAS VEZES o quarto todinho, esquecer seu iPhone lá e só perceber depois de fazer check-in aqui no aeroporto. Conviver com os esquecimentos dele tem sido emocionante haha.
Bom pessoal, acho que é só isso mesmo. Agora o próximo POST deve ser de Nova Iorque, porque fazer a conexão em Chicago vai ser beeem corrido.
Acabou!!!
12 de Setembro de 2008 @ 16:46 - BrunoArquivado sob SAP | Sem Comentários | Link desta publicação | Enviar por e-mail
Final de jogo no Venetian. Depois de uma semana acordando cedo e dormindo tarde (evento puxado!) chega ao fim o SAP TechEd 2008 :D
To preparando um resumão do que eu vi para postar aqui! (Além de mais fotos!)
Programação pra hoje é: conhecer a cidade além do caminho Hotel -> Evento e Evento -> Hotel hehe :D
9/11
12 de Setembro de 2008 @ 12:30 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
Agora que eu percebi!!! 11 de Setembro nos EUA (ontem) haha.
Ninguém deu a mínima aqui :S
SAP Press
11 de Setembro de 2008 @ 02:14 - BrunoArquivado sob Off-Topic | Sem Comentários | Link desta publicação | Enviar por e-mail
No TechEd tem uma loja da SAP Press. Dei um pulo lá hoje e não aguentei. Comprei dois livros:
Developing SAP Applications with Adobe Flex
Isso que eu queria o de BPM, mas disseram que ainda não saiu :(
O jeito é esperar :S
Primeiras fotos de Las Vegas
10 de Setembro de 2008 @ 21:21 - BrunoArquivado sob SAP | Sem Comentários | Link desta publicação | Enviar por e-mail
Notícias de Las Vegas! Eu estou vivo! Apesar de muito corrido, e só agora ter dado um tempinho para postar, aí vai.
O evento está ótimo, muito material mesmo. A cidade é absurdamente quente e completamente diferente de qualquer outra coisa.
O McDonalds tem o mesmo gosto, assim como a Coca-Cola. Só a pizza que tem uma massa diferente. Você não acha comida boa tão fácil assim, então é na base da porcaria mesmo!
Tirei algumas fotos ontem, pois minha câmera estava sem bateria, e eu não tinha o adaptador para a tomada americana. Estas fotos são do segundo dia do TechEd. Hoje vamos visitar um outlet aqui após o evento, e aí aproveito para fotografar mais a cidade.
Bom, é isso. Seguem algumas fotos (clique para ampliar). Vou abrir em seguida (conforme der tempo) outros tópicos com mais fotos.
Valeu!
O teatro do show The Blue Man Group
Saindo do Hotel Venetian, aonde acontece o SAP TechEd’08
Algumas fotos do próprio Venetian
Entrada do TAO Club, balada dentro do Venetian (aqui isso é normal)
Algumas da Las Vegas Boulevard St.
Um update (quase real-time) de Las Vegas
9 de Setembro de 2008 @ 22:00 - BrunoArquivado sob SAP | 1 Comentário | Link desta publicação | Enviar por e-mail
Bom, vou aproveitar os 20 minutos que eu tenho enquanto o workshop do Carlos não acaba.
Primeiro, para quem não sabe, estamos Carlos (que trabalha comigo na Go-Live) e eu participando esta semana do SAP TechEd 2008 em Las Vegas!
Embarcamos no Sábado a noite no aeroporto de Guarulhos, em São Paulo. Na verdade, quase não embarcamos, Problemas com filas imensas e desorganização quase deixaram a gente de fora do vôo. Mas conseguimos! O avião decolou por volta das 22:00 do sábado e só desceu às 07:40 em Dallas (com o fuso horário em Dallas eram 5:40 ainda, e portanto, tivemos que esperar a alfândega abrir).
Passamos pela alfândega, recolhemos nossa bagagem e já a despachamos no vôo das 10:50 para Las Vegas. Aproveitamos para conhecer o Aeroporto de Dallas, que é absurdamente grande. Também comemos um sanduíche, tipo Subway. Bom, mas nada demais para custar USD 8,00, enfim!
O avião atrasou a chegada, mudaram o portão e tudo aquilo que a gente vê no Brasil também acontece aqui! Quando subimos no avião, descobrimos que nosso vôo, aparentemente de 50 minutos, era mais longa. Las Vegas tem duas horas a menos que Dallas. Portanto, agora pra mim são 18:00, e no Brasil são 22:00 :D
Mas continuando, já em Las Vegas, ao sair do aeroporto deu pra sentir o mormaço. Que lugar QUENTE! Pegamos a van para o hotel. Fizemos check-in, deixamos as coisas e saímos para conhecer a cidade debaixo de sol mesmo.
Fomos até o Fashion Show, que é um shopping que fica aqui perto. Passamos na Apple Store (uhu!) e comemos uma pizza (super saudável até aqui). O cara do restaurante não acreditou que eu tinha mais de 21 anos e resistiu a servir cerveja, mas depois de alguma conversa deu tudo certo.
Depois da comida, voltamos pro hotel andando (ainda muito quente, apesar de já ser 7 da noite) e dormimos até umas 11 da noite (o fuso e a noite mal-dormida no avião acabou com a gente). Depois saímos para conhecer a cidade. Visitamos um Casino e dois bares daqui. Muito bacana! A cidade é diferente de qualquer outra coisa. Chegamos tarde no hotel, mas sem problemas!
Na segunda-feira acordamos de manhã para vir ao evento. Chegando aqui, fizemos o check-in, recebemos nossos kits e aproveitamos o intervalo para fecharmos nossa agenda para o dia (deu um baita trabalho, saímos daqui às 9 da noite). Daí apenas jantamos e depois cama.
Hoje começaram mesmo os workshops, e tem muita coisa bacana. Aqui no evento tem de tudo à vontade. Café, refrigerante, cerveja, chocolates, bolacha, etc. Vou acabar um balão aqui.
Agora estou esperando o Carlos terminar a apresentação para irmos ao happy-hour do evento, que começa agora às 17:30 até as 20:30, aonde teremos o Demo Jam. Depois é cama! Tô morrendo de sono!
Ah, depois eu posto umas fotos aqui pra vocês terem uma idéia de como é por aqui (e aproveitem pra comentar dizendo do que vcs querem que eu tire foto haha).
Até +
BRFplus for ABAP – The Framework for Business Rules
9 de Setembro de 2008 @ 20:48 - BrunoArquivado sob SAP | Sem Comentários | Link desta publicação | Enviar por e-mail
Péssima apresentação. A ferramenta até parece boa, mas o inglês, a didática e a preparação deixaram a desejar!
SAP NetWeaver UI Strategy and Roadmap
9 de Setembro de 2008 @ 17:30 - BrunoArquivado sob SAP | Sem Comentários | Link desta publicação | Enviar por e-mail
Começando agora… Por enquanto, todas as sessões foram boas ou ótimas!
Tem Demo Jam hoje!
Volto com notícias mais tarde.
Pausa para um Fenômeno
9 de Agosto de 2008 @ 16:50 - BrunoArquivado sob Off-Topic | 2 Comentários | Link desta publicação | Enviar por e-mail
Não me perguntem COMO nós descobrimos isso!
Apresentações
6 de Julho de 2008 @ 03:34 - BrunoArquivado sob Off-Topic | 465 Comentários | Link desta publicação | Enviar por e-mail
O quê é?
Meu nome é Bruno Lucattelli, sou desenvolvedor de software e trabalho na GoLive como desenvolvedor e arquiteto de soluções. Sou fanático por construção de software, marrento e perfeccionista.
O termo Software Simples se tornou minha obsessão. O objetivo é atingir as melhores práticas de projeto, design, construção e manutenção de software para utilização pelo segmento corporativo. Com este blog, quero colocar “pulgas atrás da orelha” de desenvolvedores de software, clientes e fornecedores com os quais trabalho diariamente. Acredito que este seja um canal de discussão muito mais abrangente que conversas individuais, e muito mais interativo que palestras e livros.
A quem se destina este blog?
A todos aqueles que, de alguma forma, sentem-se desconfortáveis com os resultados obtidos em seus projetos de software. Seja um cliente de alguma consultoria ou empresa de tecnologia (ao longo dos próximos posts nós vamos entender um pouco da diferença entre os dois), seja um programador frustrado por perder finais de semana, noites, feriados e férias trabalhando em projetos sempre atrasados, desorganizados e que, ao final de todo o seu esforço, geram produtos de qualidade questionável, performance baixa e cheios de bugs.
Como este blog pretende ser atualizado?
Usando os conceitos de simplicidade, vou usar sempre linguagem simples e direta. Posts breves serão maioria, afinal eu tenho pouco tempo para escrever, e você, pouco tempo para ler. Em média, um post por semana parece bem razoável.
Eu posso interagir com os assuntos aqui levantados?
Claro! Você pode fazer comentários no próprio Post. Ficarei feliz em responder a dúvidas, ouvir sugestões, críticas, e principalmente, abrir a possibilidade de discussão entre leitores do blog. Mas caso você tenha algum assunto direto para tratar, pode fazer pelo e-mail bruno@lucattelli.com.
Mas eu ainda não entendi! Sobre o quê, exatamente, vamos falar aqui?
Sobre software adquirido, desenvolvido e customizado para empresas. Se você é cliente da SAP, aqui com certeza terá algo para aprender. Se trabalha com um landscape de sistemas em Microsoft.NET, Java, ou qualquer outra plataforma, também achará informações muito úteis sobre realização, manutenção, planejamento, etc.
Mas o negócio da minha empresa não é TI! Há algo de útil pra mim neste blog?
Claro que sim! Se você não vende software, compra! E quem adquire software (principalmente software desenvolvido de forma específica) compreende que seus processos de negócio, e portanto, seu negócio, depende do bom funcionamento contínuo deste mesmo software. Compreender qual é o real papel do cliente neste cenário é a coisa mais importante que você tem para buscar aqui.
Mas eu nunca ouvi falar de você. Por acaso você é um daqueles gurus de desenvolvimento de software?
Longe disso! Sou muito jovem, magro e cabeludo para já ser considerado guru. Deixe-me definhar mais alguns anos para isso! Ao contrário, vamos falar sobre assuntos que não são novos, usando muito material de apoio (outros sites, livros, blogs, etc) para isso. Você também pode contribuir para o blog com seus links, comentários e observações.
E se eu tiver dúvidas? Posso falar com você?
Mais uma vez, claro que sim! Seguem meus contatos, e até os próximos posts!
MSN: lucattelli@gmail.com
E-MAIL: bruno.lucattelli@golive.com.br / bruno@lucattelli.com
WEB: http://www.lucattelli.com/
Software Simples | http://blog.lucattelli.com