O projeto já estava iniciando a fase de produção quando eu entrei pra
People. Dois estagiários passaram seis meses desenvolvendo o produto, e já
tinham aproximadamente 60% do código escrito.
Eu entrei basicamente para substituir os dois, e junto comigo entrou uma
"supervisora" do projeto, a Simone Yagui, que cuidaria da implantação do sistema, verificar
a interface e a usabilidade do sistema. (Sim, isso só foi pensado depois de
60% do código escrito!). Seguindo a Lei de Murphy, várias e profundas
alterações estruturais no programa foram acrescentadas, e foi minha tarefa,
e de mais um estagiário que só entrou um mês depois.
Inicialmente, o sistema estava totalmente baseado em plataforma Windows 2000,
pois os estagiários anteriores eram ignorantes em outra plataforma.
Mas problemas de "royalties" do Sistema Operacional (se é que me entendem), forçaram a adoção da
plataforma Linux. Sugeri o uso do Linux Debian, mas como o administrador da
rede já usava o Conectiva, foi decidido o uso deste. Toda a migração de
Windows para Linux ficou praticamente nas minhas mãos, com ajuda substancial
do administrador da rede.
Montei uma mini-intranet, com um micro Linux Conectiva
de servidor Oracle, SAMBA, NFS, Apache e JRun (servlets) a micros Linux e
Windows 98/2000. Grande parte da dificuldade residiu em fazer o Windows 2000
reconhecer um domínio de rede sediado em Linux/SAMBA. A ferramenta de
produção Java, Borland JBuilder, também não se portou muito bem com a
mudança.
Após dois meses de trabalho, uma companhia de design gráfico para sites de Internet, a
Ital, foi
contratada pra fazer a "cara", ou "interface" do produto na Internet.
Em um mês fizemos a transição de "cara" do produto, além de
outras pequenas finalizações. O prazo para colocar no "ar" o produto, pelo
menos a parte que ficaria visível a todos na Internet (cadastro de
currículos), era de 1o. de Agosto de 2001, acabou sendo prorrogado quando da minha saída da empresa
(em 10 de agosto de 2001), e até a conclusão desta monografia, continuava em fase de testes.
People Consulting
A People Consulting é uma empresa que presta consultoria no recrutamento e seleção de
profissionais, especializada na área de TI, ou Tecnologia de Informação.
Sua atuação inclui o recrutamento e seleção de profissionais e executivos,
outsourcing de processos de recrutamento e seleção, alocação de profissionais de tecnologia,
e desenvolvimento de programas para recrutamento de estagiários e recém-formados.
Possui entre seus clientes as empresas Accenture, Banco Itaú, Telesp Celular,
SAP, Laboratórios Fleury, Itautec Philco, Fotoptica, Itaú Seguros, SKF, Algorithmics,
Novabase, Gilbarco, Dinheiro Vivo, Manugistics, Brand Brasil, Zip.Net e Blue Life.
Na área de desenvolvimento, possui, entre seus produtos, o software de gestão empresarial
FINPAC, e o Finanças Soft, derivado do anterior,
desenvolvido em parceria com a Software Design, em Visual Basic e utilizando banco de dados Oracle.
Foi implementado em diversas empresas, como o Grupo Ajinomoto, Avon, Banco Cruzeiro do Sul, Banco Schahin,
Origin, Sanyo, Setal, Grupo Adriano Coselli, Drogacenter, Mogiana Alimentos, Positron Alarmes,
Adubos Trevo, Banco Econômico (Salvador), HapVida (Fortaleza), PUC do Rio Grande do Sul,
entre outros clientes.
ASP: Conceitos
Uma aplicação ASP, ou Application Solution Provider, é quando você desenvolve todo o sistema para que ele funcione integralmente via Internet, e geralmente através de um browser.
Se uma empresa opta por utilizar um serviço ASP, ela apenas utiliza o serviço, não precisando comprar computadores para rodar a aplicação, nem alocar pessoal para cuidar disso. É uma solução totalmente terceirizada.
A empresa paga apenas pelo uso, e, quando necessário, pelo treinamento. Toda a infra-estrutura fica sediada na empresa que fornece o serviço.
Tecnologias utilizadas
A base de dados era baseada em banco de dados Oracle, provavelmente porque a empresa, People,
já utilizava Oracle.
A base de dados foi modelada utilizando-se o ERWin, que já gerava todas as tabelas diretamente no Oracle.
A interface base de dados/aplicação era realizada diretamente em Java, via driver da Oracle específico para Java.
E para a parte Web, ao invés de JSP, existiam templates HTML que eram alterados diretamente pelos
Servlets, utilizando uma pequena classe de java (HothouseTags) que permitia a manipulação direta dos "tags" de HTML.
Organização da equipe
A forma de organização da equipe de trabalho era a seguinte: O "chefe" e idealizador do projeto era o Shuji Shimada,
também sócio da People Consulting, e foi ele que deu todas as especificações aos programadores
inicias, 2 estagiários, que saíram em abril de 2001. Um mês antes, uma consultora foi contratada
para supervisionar o projeto, verificar a usabilidade do sistema, e cuidar da implantação e testes.
Eu entrei 1 semana depois dela, ficando com a responsabilidade de cuidar da implementação propriamente
dita, e para isso tive que estudar o código já escrito, além de aprender algo sobre Servlets.
Prazos e andamento do projeto
O projeto foi iniciado em agosto de 2000, e ficou em fase de idealização até dezembro do mesmo ano,
e muito dessa demora foi por conta da idéia de fazer também um outro projeto paralelo, o PeopleHR,
que cuidaria da automação dos processos seletivos internos da People Consulting, que até a época
era feito na base das fichas em arquivos.
A estimativa inicial de prazo para o PeopleDB era de abril de 2001, prazo obviamente mal calculado
pelos estagiários, e quando eu entrei, em março, apenas 60% do código estava pronto, sem contar a fase de testes
e implementação. Um novo prazo foi dado para que apenas a parte do Candidato fosse terminada até
1o de agosto de 2001, mas quando atingida esta data, apesar de tecnicamente o projeto estar pronto,
uma série de problemas de infra-estrutura deixou o site no ar por apenas um fim de semana.
Quando eu sai, em 10 de agosto, o sistema ainda estava fora do ar.
Problemas, dificuldades e frustrações encontrados
A transição Windows/Linux
Esquecendo-se um pouco do código mal escrito, tive uma série de percalços.
Logo em abril, com menos de 2 semanas lá, a empresa decidiu legalizar todo o software.
O problema era que os dois computadores usados na programação possuiam Windows 2000,
sendo uma pequena intranet com um Windows 2000 Server pirata rodando Oracle (este sim, legalizado),
e um Windows 2000 Workstation também pirata, além de um ERWin surgido não se sabe de onde.
De legalizado possuiam o JBuilder, ferramenta muito boa de pacotes Java, e o JRun,
servidor de aplicações Java como Servlets, Beans e JSP.
Na hora de legalizar os Windows 2000, surgiu um impasse: o preço de um Windows 2000 Server,
na época, permitia a compra de dois novos micros. Como o JBuilder, o JRun e o Oracle, possuiam versões para Linux,
e eu acreditei dar conta da tarefa de tranferir tudo para Linux, foi decidio então que,
ao invés de comprar um Windows 2000 Server e um Workstation, comprariam a licença apenas para
um Workstation (necessário para testes em Windows), e ao invés de um Windows 2000 Server, foi comprado um
micro novinho para ser o servidor web, de arquivos, de JRun, e de Oracle.
O problema, então, era o seguinte: tínhamos que interligar 4 micros: Um servidor, rodando Linux,
dois micros de desenvolvimento, ambos "dual boot" rodando Linux e Windows 2000 Workstation,
e outro micro, de testes, da supervisora Simone, rodando Windows 98.
Propus utilizar o Linux Debian, mas a versão do Linux utilizada acabou sendo a
Conectiva, por já estar em uso na intranet da People Consulting.
A instalação do Oracle no servidor Linux (chamado de Guaraná) foi complicada, mas
transcorreu sem problemas, pois o administrador da intranet da People já tinha instalado uma vez,
e pode me ensinar muita coisa.
Instalei o Samba no Guaraná, como servidor de arquivos para os
micros Windows. Instalei também o Apache como servidor web, trabalhando junto com o JRun,
onde também pude ter algumas dicas do administrador local.
Ligar o micro com Windows 98 (chamado DietCoke)
à intranet criada no servidor Linux também transcorreu sem problemas.
O problema maior surgiu quando fui colocar os micros de desenvolvimento
com Windows 2000 na rede (Garapa e Tubaína).
Isso acabou se mostrando de uma dificuldade inesperada, e, pesquisando na Internet em grupos
de discussão, acabei descobrindo que o Windows 2000 simplesmente "se recusava" a ser um
cliente de um Servidor Samba (Cheguei mesmo a ler uma mensagem "dando risada" de um e-mail
perguntando se isso era possível). Parece que a Microsoft permitia que um Linux se conectasse
a uma rede Windows 2000, através da criação de um servidor SMB próprio. Mas por outro lado,
simplesmente não permitia o contrário (isso pôde ser lido no próprio site da Microsoft na época).
Tive que insistir na rede híbrida por três razões: Além da necessidade de se testar a interface
do projeto tanto em Windows Explorer, como Netscape e outros, e do fato da intranet da People ser
em Windows NT, o JBuilder não funcionava muito bem em Linux, e "travava" constantemente.
Felizmente, estudando mais o assunto, descobri que era possível "enganar" o Windows 2000,
fazendo-o pensar que estava se conectando a uma rede Windows NT, o que pediu uma série de alterações
nos registros do Windows, e a criação de usuários $GARAPA e $TUBAINA com a mesma senha do SAMBA,
por alguma razão obscura, além de diretórios idênticos aos do Windows 2000 na área do usuário.
Os problemas com o código já escrito
No inicio, me parecia que o código estava bem feito, pois lendo, eu percebia que estava bem
comentado, bem organizado. Aos poucos fui estranhando a falta de mais heranças entre as classes
e também o excesso de interfaces (algumas desnecessárias mesmo).
Fui percebendo também que, ao invés de o projeto ser dividido por métodos de objetos,
a prioridade maior era dada aos Servlets. Depois percebi que o que acontecia era que cada
tela estava amarrada a um Servlet, e cada Servlet produzia somente uma tela. Isso porque,
penso eu, os estagiários não tinham uma idéia muito clara do funcionamento de um Servlet,
e por isso faziam com que cada Servlet gerasse uma página HTML diretamente.
Isto era feito através de "templates" de páginas HTML, ou seja, cada Servlet lia um arquivo HTML,
e ia alterando onde fosse necessário, e depois redirecionava ao servidor web.
Qualquer pessoa que tenha estudado JSPs, sabe que isso é estupidez. E mais, ainda, cada Servlet estava,
pelo projeto, "amarrado" a um único template HTML.
Pensei, a esta altura (um mês lá, e ainda estava sozinho), em simplesmente refazer todo o código,
já tinham me falado que usar JSPs era mais esperto, e estava ainda querendo muito aprender sobre Java Beans.
Mas enfrentei uma resistência grande por parte do idealizador do projeto, e também de um dos ex-estagiários,
que ainda visitava lá, e era filho de um dos sócios da empresa.
Assim, me conformei e continuei com minha missão de terminar tão mal projetado "projeto".
O Sistema PeopleDB
Descrição
A aplicação PeopleDB é um sistema de coleta e triagem de currículos via Internet.
As empresas cadastram vagas no sistema e os candidatos se cadastram para essas vagas.
Existe também a possibilidade de se enviar um currículo para um grupo dentro da empresa. Esses grupos, organizados em forma de árvore, podem representar, por exemplo, os níveis hierárquicos dentro de uma empresa. Qualquer vaga publicada no sistema deve estar relacionada a um grupo da empresa. As vagas podem ser agrupadas para formar um programa de recrutamento.
O processo de triagem de currículos é dividido em fases. Para cada fase existe um formulário de questões a ser respondido. As respostas às questões do formulário serão utilizadas como parâmetro de busca na triagem. Caso o candidato não tenha atingido o mínimo em todas as questões, seu currículo não fica visível ao cliente.
Um formulário é um conjunto de matrizes de questões. Um formulário pode ser uma prova, testes e qualquer outro tipo de questionário. Os formulários podem ser elaborados pelo administrador do sistema ou pelo usuário administrador do cliente.
As questões são classificadas em grupos definidos pelo administrador do sistema. Algumas questões serão definidas pelo administrador e disponibilizados a todos os clientes. Os clientes poderão definir suas próprias questões, que serão visíveis somente para ele.
Os grupos nada mais são que níveis hierárquicos em uma empresa, que podem tanto ser verticais, como diretor, gerente, ou analista sênior ou analista júnior,
como podem ser horizontais, como departamento jurídico, desenvolvimento, etc.
Lado Candidato
Existem três maneiras do candidato cadastrar seu currículo no sistema: respondendo a uma vaga,
escolhendo um grupo de uma empresa para enviar seu currículo, ou cadastramento simples no sistema.
Quando o candidato especificar uma vaga ou um grupo, o formulário da 1a fase do grupo será disponibilizado no final do cadastramento das informações curriculares.
Para o cadastramento é necessário escolher um identificador (ou apelido, único no sistema),
senha, e e-mail válido. Opcionalmente pode-se informar o CPF. É necessário, após essa primeira parte,
cadastrar as informações pessoais. O e-mail pode ser repetido entre candidatos. O não cadastramento das informações pessoais implica em remoção automática do candidato do banco de dados (no dia seguinte). As outras informações, caso não preenchidas, geram um aviso na página inicial do usuário.
Quando o candidato estiver cadastrado no sistema, ele poderá realizar as seguintes operações:
Atualizar dados do currículo;
Gerar uma versão em PDF/HTML do seu currículo;
Visualizar histórico de vagas;
Alterar a visibilidade das informações do candidato a empresa;
Responder a novos formulários, quando houver;
Alterar a senha de acesso ao sistema;
Responder a anúncios de outras vagas ou empresas;
Remover o currículo do sistema.
Na listagem de formulário a serem respondidos, se uma fase possui mais de um formulário, esses aparecerão separados na listagem, mas serão respondidos em seqüência.
O histórico de vagas as quais o candidato respondeu será apenas da empresa por onde o candidato realizou o login. O histórico, portanto, é por empresa.
Se o candidato não realizar um login por um período determinado de tempo (3 meses configurado via arquivo), ele será removido do banco e um e-mail de notificação será ser enviado, tudo automaticamente. O candidato também pode solicitar a remoção de seu cadastro no banco de dados. Em ambos os casos, ele será removido de todas as empresas as quais se disponibilizou.
Todo isto estava organizado caoticamente, e fez parte do meu trabalho, junto com a Simone,
pensar como um candidato, e
tornar o sistema mais simples, eficiente e "simpático" possível.
O Cadastro
Esta parte foi a mais cuidadosamente analisada e exaustivamente refeita. O cadastro não pode ser
complicado, sob pena do candidato mais leigo em informática desistir de se cadastrar. Nem pode ser
muito extenso, sob pena do candidato mais apressado ou com conexão lenta desistir.
Além disso, diversos sistemas de controle de sessão tiveram que ser bolados para o caso de,
no meio do cadastro, a conexão a Internet do candidato cair. Assim, a primeira tela que o candidato
encontra teria que ser uma que, caso a conexão caia logo a seguir, pelo menos seu cadastro está armazenado
no sistema. Assim, uma longa discussão sobre a necessidade do CPF entrou em pauta.
O CPF é o identificador necessário, requisitado pelo Shuji, o idealizador do sistema. Mas pensamos que
muita gente simplesmente não sabe o CPF de cor, e entre pegar o CPF e completar o cadastro, a conexão poderia
cair, ou o candidato poderia simplesmente desistir.
Assim, ficou decidido que o candidato simplesmente entraria com o login e uma senha,
e caberia a mim "dar um jeito" de armazenar isso, tornando o cadastro "provisório", haja visto que,
do jeito que o banco de dados foi modelado, o CPF (uma string) era chave primária.
Uma pequena modificação na base de dados foi feita, e fiz o CPF deixar de ser chave primária, criando
uma outra chave primária (desta vez um inteiro).
Assim, eu poderia armazenar o login e a senha do candidato no banco de dados, mesmo que provisoriamente,
como pediu o Shuji, e assim, depois de uma semana, o sistema se encarrega de "limpar" os candidatos sem CPF.
Caso o candidato volte antes de uma semana, pode retornar ao seu cadastro do ponto exato onde parou.
Resolvemos organizar o cadastro do candidato em "passos" para cadastramento, sendo que
ele pode interromper o cadastro em qualquer passo (desde que tenha fornecido um identificador e uma senha).0
Tentando diminuir o número de "passos", chegamos ao mínimo de 6 passos:
Login:
Este pode ser feito diretamente no PeopleDB, ou através de um link em alguma empresa oferecendo
vagas. Em ambos os casos, se o candidato anida não estiver cadastrado no sistema, deverá passar pelo processo de cadastro,
fornecendo um identificador e uma senha.
Dados Pessoais:
Aqui o candidato fornece seus dados básicos, como nome, endereço, telefone e e-mails de contato.
Preenche ainda como ficou sabendo da vaga, para fins estatísticos do setor de RH da empresa.
Objetivo:
Os objetivos profissionais aspirados pelo candidato, incluindo forma de contratação, faixa
salarial, horário, disponibilidades para viagens e de trabalhar em outra cidade ou estado.
Formação Acadêmica:
Em que cursos o candidato é formado e em quais.
Experiência Profissional:
Empregos anteriores, dados sobre as empresas anteriores em que trabalhou e
referências pessoais do candidato.
Conhecimentos:
Aqui o candidato preencherá questionários relativos a vaga a que ele está se candidatando, quando
aplicável, e seu conhecimento em línguas estrangeiras.
Tela Inicial: Resumo
Esta é a página inicial do candidato, e também uma espécie de resumo de tudo. Aqui o candidato
encontra avisos sobre informações que estejam faltando no seu cadastro,
informações sobre como andam os processos seletivos que ele está participando,
e novas vagas que ele ainda não esteja concorrendo, de acordo com seu perfil.
Encontrará ainda um "briefing" da empresa.
Currículo
Basicamente, as informações que ele já preencheu no cadastro, só que ele pode editar e alterar a vontade.
Processos Seletivos
Aqui ele encontra informações sobre como andam os processos seletivos dos quais ele está participando.
Oportunidades
Além de poder se inscrever a eventuais processos seletivos da empresa, o candidato poderá também
realizar uma busca de vagas, conforme faixa salarial, cargo, local, etc. Ele pode, ainda,
se inscrever num cargo ou área específica da empresa, através de uma "árvore" hierárquica de
cargos/áreas onde o candidato vai escolhendo suas aspirações na empresa.
Avaliações
Aqui o candidato preenche eventuais questionários referentes aos processos seletivos a que concorre.
Preferências
Detalhes como se o candidato quer ou não receber e-mails sobre novas vagas, sua visibilidade
para outras empresas associadas ao PeopleDB, se deseja retirar seu currículo do banco de dados, etc.
Sair
E há, enfim, a possibilidade de se deslogar do sistema.
Lado Cliente
A empresa cliente administra tudo via web, através de usuários e senhas, cada um com um nível de permissão.
As funções, a princípio, estavam todas "jogadas" em um menu único, de forma meio caótica.
Após algumas reuniões, foi decidido dividir a parde do cliente em
Vagas, Programas, Currículos, Questionários, Grupos, Estatísticas, Administração.
Vagas:
Aqui a empresa administra suas vagas em aberto, podendo criar uma nova vaga, editar, apagar ou
publicar uma vaga preexistente. Pode ainda ver um
histórico de todas vagas já publicadas pelo cliente utilizando o sistema.
Programas:
Programas são os processos seletivos de uma empresa, que pode, por exemplo, criar simplesmente um
"Programa de Recrutamento 2001", ou então um programa para um setor de desenvolvimento, e outro para
um setor administrativo. As vagas estarão "penduradas" em um ou outro programa.
Currículos:
Aqui a empresa pode fazer uma busca manual pelas vagas a procura de um perfil específico,
rejeitar ou aceitar currículo durante a triagem,
analisar o desempenho dos candidatos, ou então verificar se algum "talento" para uma vaga
foi automaticamente eleito pelo sistema.
A triagem automática considera apenas as respostas dadas as questões dos formulários de um grupo.
Utiliza os valores especificados durante a criação dos formulários para não exibir o candidato
na lista de currículos na triagem por vaga/grupo.
Toda vez que um candidato modifica a resposta de alguma questão ou responde a um novo formulário,
a triagem automática é executada.
As pesquisas realizadas podem ser armazenadas pelo usuário, para futura consulta, caso deseje.
Todas as informações preenchidas pelo candidato podem ser utilizadas na busca,
incluindo cidade, faixa salarial, disponibilidade para viagens, etc.
O usuário tem a possibilidade de gerar uma versão do currículo no formato HTML ou PDF para impressão.
Questionários:
É aqui que a empresa manipula seus questionários, podendo adicionar, editar ou apagar
uma questão, além de poder criar questionários manualmente, pegar de
uma biblioteca de questionários pré-existente ou editar essa biblioteca.
Os conhecimentos do candidato estão distribuídos nos grupos onde o candidato participa.
Nessa visualização é possível passar o candidato de fase, aceitar ou rejeitar o candidato para
aquele grupo.
Grupos:
Grupos são os níveis hierárquicos da empresa, podendo ser dividido por setores ou
por cargos mesmo, dependendo do quanto a empresa quer tornar visível sua hierarquia,
haja visto que essa árvore hierárquica será vista pelos candidatos.
Estatísticas:
Serve apenas para a empresa conferir as estatísticas dos anúncios das vagas
(veículo de comunicação). Conforme os candidatos se cadastram, eles preenchem como ficaram
sabendo das vagas.
Serve ainda para verificar quantos candidatos se inscreveram para determinadas vagas, etc.
Administração:
Na parte de Administração, o cliente pode alterar dados cadastrais da empresa, adicionar, listar e remover usuários
e ainda alterar senha do usuário corrente.
Realizações:
Finalização do projeto:
Completei, juntamente com o outro estagiário, o restante do código que faltava,
implementando as classes que ficaram por fazer, além de algumas novas que foram idealizadas
pelo caminho, juntamente com as alterações (algumas profundas) idealizadas pela consultora, Simone.
Implementação da interface:
Implantei a "cara" nova do PeopleDB, criada pela empresa de design gráfico Ital,
tanto na parte do candidato como na parte da empresa. Para isso foi necessário uma série de "truques"
pra "driblar" as "amarras" dos Servlets, que, da maneira que estavam projetados, mostravam apenas
uma página por Servlet, e simplesmente não foi pensado na possibilidade de se usar "frames", como
a Ital achou necessário.
Melhoramento da Base de Dados
Como a base de dados era uma "meleca" só, com varchars (strings de tamanho variável) como chaves
primárias de tabelas, entre outras "melecas", um grande tempo foi gasto nessa parte, com ajuda
da Simone. Transformei as chaves anteriores em "unique" e criei métodos "FindBy" nas classes respectivas.
A alteração da base de dados pediu que fossem alterados também os Triggers e
Stored Procedures, trabalho chato e tedioso, que eu preferi trocar por uma programação
de scripts em Perl, mesmo que talvez tenha gasto mais tempo programando os scripts do que alterando
"na mão"...
Limpei também várias tabelas que considerei inúteis, como tabelas numerando os países e suas nacionalidades,
nomes de faculdades e universidades, entre outras. Achei muito melhor e mais simples criar arquivos
texto contendo essas informações. Mesmo porque essas tabelas estavam todas em português, e era planejado
que o site fosse "trilingue", com versões em inglês e português.
Melhoramento da Performance
O fato de haver uma classe única (chamada de broker), que realizava todas as transações com a
base de dados, deixava tudo muito lento, e pesavam as classes que precisavam se comunicar com a base,
pois todas tinham que importar o broker, importando junto métodos inúteis.
Assim, quebrei essa classe em vários brokers locais, e cada classe tinha seu próprio broker,
contendo somente os métodos que realmente importavam para ela.
Testes
Paralelamente eram realizados testes em diferentes navegadores, como
Netscape, Explorer, Mozilla e Opera, nos dois sistemas operacionais, Windows e Linux.
Também fiquei de "admin" da rede híbrida local.
Publicação
Em 2 de agosto de 2001, colocamos o projeto PeopleDB no ar.
Infelizmente por pouco tempo, pois além de problemas com o servidor apache da empresa, verificamos
algumas falhas, e ele foi retirado do ar. Até hoje encontra-se em fase de testes.
Relação BCC/Estágio
As matérias que me foram mais úteis no estágio, além das óbvias Laboratório de Programação I e II,
Engenharia de Software , SO e BD, foram também algumas optativas como Administração de Sistemas Unix
e IHC, Interação Homem-Computador.
A transição de Windows para Linux, e também a administração posterior da rede montada foi muito
auxiliada pela matéria de Administração de Sistemas Unix, e IHC foi muito útil quando tive
de pensar como um usuário candidato no sistema, para torná-lo amigável e fácil de usar. Me fez
pensar que muito tempo e trabalho teriam sido poupados se a interface tivesse sido desenhada
primeiro.
Engenharia de Software teria sido uma matéria muito útil aos estagiários anteriores que projetaram
o sistema.
Conclusões
Aprendi muita coisa lá, incluindo a responsabilidade de ter um projeto nas suas mãos,
não é como ser um estagiário pura e simplesmente, mas sim um efetivo, pois o projeto estava
praticamente sob minha responsabilidade, ao menos na implementação, e parte das decisões eram
divididas comigo pela Simone, que na maioria das vezes queria ouvir minha opinião (menos quando
sabia que eu não ia concordar com a opinião dela...).
Percebi como é importante a modelagem dos casos de uso, e a definição clara dos "atores", além
de uma documentação clara e precisa, conforme
as técnicas de Engenharia de Software, além da importância da base de dados, ou seja, de uma cuidadosa
criação e modelagem da base, pensando nas consultas futuras, etc. Realmente, é melhor gastar mais tempo
no planejamento do projeto, do que em refazer código. Um código bem feito num projeto bem implementado
torna fácil, rápida e barata a manutenção e mesmo uma alteração futura.
Pensar no usuário, e na interface, assim como a usabilidade do sistema que se está criando também é muito
importante, como eu aprendi antes em IHC, pois é realmente trabalhoso, em certos casos, alterar a interface
depois que o projeto já está implementado.
Visão Crítica
Como já disse, o projeto já estava iniciado quando eu entrei, e a base de dados já estava modelada e implementada em Oracle, e aproximadamente 60% do código escrito.
Logo que entrei eu percebi, estudando o código escrito, de que os estagiários anteriores, responsáveis pela implementação, não tinham a menor idéia do que fosse um código orientado a objeto, pois o projeto simplesmente não definia
nada disso, e também havia toneladas de código "redundante", que poderiam ter sido herdado de instâncias superiores (se houvesse alguma).
Por exemplo, havia uma classe "Candidate", e outra "Client" e ainda uma "Customer"(SIC), e ambas possuiam métodos absolutamente idênticos (na base do "copy/paste" mesmo).
Seria o caso (básico) de se criar uma classe "User" ou "Person", com os métodos que seriam usados pelas outras duas, que os herdariam.
Além disso, não estudaram ou não quiseram usar Engenharia de Software,
apesar de (ou justamente por) serem ambos do curso de Engenharia da Computação da Poli.
Observei isso por ver que não havia nenhum Caso de Uso decentemente definido ou documentado, somente uma definição dos "Atores" envolvidos, mesmo assim, uma definição vinda "de cima".
Analisando criticamente, com a experiência que possuo hoje, após passar por duas empresas diferentes,
e agregar novas tecnologias, como Beans, JSP, Struts, entre outras, é a de que o projeto foi
realmente mal feito.
A ignorância em Java Beans (e OO) fez com que toda a comunicação com a Base de Dados fosse feita diretamente em SQL puro, quando muito poderia ter sido automatizado via Entity Beans.
A maioria das tabelas SQL utilizava varchars como chaves primárias, por mais absurdo que isso possa parecer. Com isso, qualquer consulta à base demorava décadas.
Além disso, por serem os programadores originais absolutamente ignorantes em JSP, todo o HTML era produzido diretamente pelos Servlets, utilizando alguns "templates" que eram alterados linha por linha (ou tag por tag) pelos Servlets, tornando o sistema, obviamente, muito lento.
Qualquer alteração na interface do sistema era uma tortura, pois era necessário alterar os templates e depois os Servlets. Se um template tivesse uma linha alterada, sem que se alterasse o Servlet, o sistema todo simplesmente "dava pau", pois os Servlets estavam totalmente amarrados às templates.
Analisando hoje, eu teria (me) poupado muito trabalho e irritações se, desde o começo, tivesse
simplesmente apagado tudo e começado do zero, refazendo decentemente a base de dados,
modelando direito casos de uso e interface, e programando decentemente orientado a objeto.
E se pudesse começar o projeto hoje, após ter passado por outras empresas, e tendo aprendido muitas outras tecnologias,
teria as utilizado, e o projeto poderia, acredito, ter sido terminado em 6 meses.
Minha própria superiora na People, a Simone, chegou a essa conclusão, quando da minha saída da empresa.
Por que deixei a Empresa
Com o fim da implementação, restavam poucas coisas a fazer, quase 95% do código já estava finalizado,
e restava apenas a "implantação", que seria na empresa mesmo, e os testes.
Mas todo esse trabalho já estava me irritando, o projeto todo era muito mal escrito,
e eu tinha essa sensação de que ia sempre ser um projeto ruim, por ter começado ruim, e isso me incomodava.
Havia muita coisa que eu ouvia falar ou lia na Internet sobre Java, como Java Beans, JSPs, etc, e eu
tinha vontade de aprender sobre isso, além de trabalhar em outros projetos, eu sabia que se continuasse
na People, seria num projeto semelhante, o PeopleHR, ou então ficar "cuidando" do PeopleDB, ambos
muito desestimulantes na minha opinião.
A esta altura, eu já tinha completado quase 600 horas de trabalho, 200 a mais que o mínimo
exigido por MAC499.
Além disso, havia recebido uma proposta para trabalhar na Spectrum, uma empresa maior,
com mais tradição no desenvolvimento de software, onde vim a aprender outras tecnologias, entre elas,
Java Beans, JSP e o uso ideal de Servlets. Só não sabia que a empresa andava mal das pernas...
Mas isto já é um outro assunto.
Bibliografia utilizada no estágio:
Java:Site da Sun - API do J2EE
Servlets:Java Servlet Programming - 1st Edition
HTML:HTML & XHTML: The Definitive Guide - 4th Edition
Além do manual do Oracle, do JRun, páginas "man" do Linux, incluindo Apache e SAMBA,
e consultas a diversos sites na Internet.
|
