Performance com Strings e StringBuilder em Java

Semana passada, estava trabalhando em uma ferramenta em java, que coletava algumas informações e gerava uma saída para um arquivo txt.

Ao testar a ferramenta com um grande volume de dados, me surpreendi que ela gastava mais tempo de execução na concatenação de String do que na escrita do arquivo.

Não podia deixar a ferramenta assim e como um bom programador resolvi melhorar o meu código. E olha como ficou o resultado.

Na primeira versão concatenava usando apenas Uma String (output), código abaixo:

long prev_time = System.currentTimeMillis();
long time;
String output = "";

for (Device device : this.devices) {
 output += "\"deviceid\": \"" + device.deviceid + "\", ";
....
}
time = System.currentTimeMillis() - prev_time;
System.out.println("Time after for loop " + time);

O resultado foi “Time after for loop 233117 ms“, a ferramenta gastava aproximadamente 4 minutos para executar.

Na segunda versão, usei Duas Strings (output e output2) para fazer a concatenação, código abaixo:

long prev_time = System.currentTimeMillis();
long time;
String output = "";

for (Device device : this.devices) {
 String output2 = "";
 output2 += "\"deviceid\": \"" + device.deviceid + "\", ";
....
 output += output2;
}
time = System.currentTimeMillis() - prev_time;
System.out.println("Time after for loop " + time);

O resultado foi “Time after for loop 22929 ms“, a ferramenta agora gastava apenas 22 segundos para processar. Muito bom!!!

Achei que não deveria parar nesse valor e procurei qual outro tipo de classe Java, que poderia utilizar, e num pesquisa rápida encontrei o StringBuilder.

Na terceira versão usei o StringBuilder, veja código abaixo:

long prev_time = System.currentTimeMillis();
long time;
StringBuilder sb = new StringBuilder();

for (Device device : this.devices) {
 String output2 = "";
 output2 += "\"deviceid\": \"" + device.deviceid + "\", ";
....
 sb.append(output2);
}
time = System.currentTimeMillis() - prev_time;
System.out.println("Time after for loop " + time);
String output3 = sb.toString();

O resultado foi  “Time after for loop 137 ms“, impressionantes 137 milissegundos.

Performance é sempre um desafio, mas melhor ainda é compartilhar. #FicaADica

Leia também:

Engenharia de Software: Métodos Ágeis – SCRUM

Artigo da Série Engenharia de Software.

O tema de hoje: SCRUM.

Scrum é uma metodologia ágil para Gerenciamento de Projetos. Ela é baseada em ciclos de 2 a 4 semanas chamados Sprints.

Nos Sprints, se trabalha para alcançar objetivos bem definidos. Estes objetivos (requisitos do sistema) estão no Product Backlog, e são constantemente atualizados e re-priorizados.

No Scrum, as pessoas tem seus papéis:

  • Product Owner

É o ponto focal do projeto, pois tem a visão do negócio. É quem prioriza o Product Backlog.

  • Scrum Master

É um lider/facilitador. Ajuda a equipe a resolver problemas e assegura a prática do Scrum. Não tem autoridade sobre a equipe.

  • Time Scrum

É a equipe de Desenvolvimento. No Scrum, a equipe se auto-organiza e tem poder para definir, inclusive com possibilidade de remove membros da equipe.

Como funciona?

Pega-se os itens do topo da lista no Product Backlog, e define-se um Sprint. Na Execução do Sprint, estes itens são chamados de Sprint Backlog, e são distribuídos no time Scrum.

O Scrum Master faz reuniões diárias de 15 minutos (Daily Scrum) para saber o andamento. Nesta reuniões cada membro deve responder as seguintes questões:

  • O que foi feito?
  • O que tem pra hoje?
  • Tá com algum problema?

No final do Sprint, temos como entrega o produto de Sprint e o Document-of-Done (DoD). Deve ser feita uma revisão pela equipe do produto entregue (Sprint Review) e do  processo (Sprint Retrospective), afim de melhorar ambos.

Leia também:

Engenharia de Software: Modelo de Ciclo de Vida

Artigo da Série Engenharia de Software.

O tema de hoje: Modelo de Ciclo de Vida.

Em Engenharia de Software, o Modelo de Ciclo de Vida é o processo de planejar, criar, testar e colocar em produção um Sistema da Informação.

Categorias:

  • Sequenciais
    • Modelo em Cascata (Clássico) : Segue uma sequência linear.
  • Incrementais
    • Modelo Incremental: Combinação do modelo Linear e Prototipação.
  • Evolutivos
    • Prototipação (Prototipagem): Facilita o entendimento pelo usuário
    • Espiral: Ciclos de desenvolvimento que melhoram a cada iteração. Focado em Risco.
  • Agéis
    • Incremental + Evolutivo

Leia também:

Engenharia de Software: Engenharia de Requisitos

Artigo da Série Engenharia de Software.

O tema de hoje: Engenharia de Requisitos.

Engenharia de Requisitos é o processo de definir, documentar e manter os requisitos em Engenharia de Software.

Quais as principais atividades?

Antes de mostrar quais as atividades estão envolvidas na Engenharia de Requisitos, é importante fazer um Estudo de Viabilidade com as partes interessadas, para saber se a solução a ser implementada agrega valor ao negócio, se tem orçamento, se tem integração e se já não existe uma solução pronta de mercado.

Após o estudo teremos:

  • Levantamento (Elicitação)

Analistas e Stakeholders se reunem para levantar necessidades. Aqui podemos fazer uso de técnicas como: Entrevistas, Questionários, Workshops de Requisitos, Cenários, Prototipagem e Etnografias (vivenciar na prática a situação, semelhante aos Laboratórios que atores realizam pra montar uma personagem).

  • Análise/Negociação de Requisitos

Aqui classificamos, resolvemos conflitos ( inclusive políticos), priorizamos e confirmamos os requisitos.

  • Especificação

Esta é a atividade de documentação e modelagem. Definimos requisitos para os usuários, requisitos de sistema, o design da aplicação. Estes requisitos classificamos como requisitos funcionas (RF) e requisitos não funcionais (RNF). Criamos Casos de Usos, e outros diagramas presentes na UML.

  • Validação

Com a documentação em mãos, o analista de requisitos verifica e valida se o sistema atende ao clientes. Algumas técnicas usadas são Revisão, Prototipação, Criação de Casos de Testes.

  • Gestão de Requisitos

A gestão de requisitos faz o controle de mudanças para atender à dinâmica dos negócios, visão do usuário, ….

Leia também:

Engenharia de Software: Teste de Software

Artigo da Série Engenharia de Software.

O tema de hoje: Teste de Software.

Teste de Software é o processo de investigar o Software em busca de defeitos críticos e para a validação de requisitos. E tem por finalidade aumentar a qualidade do mesmo e evitar transtornos ou prejuízos para as pessoas e/ou empresas envolvidas.

Quais são as fases:

  • Teste Unitário

    Nesta fase quem participa é o desenvolvedor. Ele será responsável por criar os testes unitários, e verificar a funcionalidade de classes e metódos.

  • Teste de Integração

    Nesta fase os desenvolvedores de diferentes partes do sistema, testa como cada parte interage entre si.

  • Teste de Sistema

    Nesta fase o desenvolvedor e usuário testam o sistema.

  • Teste de Aceitação

    Os usuários que vão utilizar o Sistema vão dar o OK, para colocar o sistema em produção.

  • Teste de Operação

    O Administrador do Sistema faz a validação da Administração do Sistema

Algumas técnicas:

  • Caixa Preta (Teste Funcional)

Verifica a entrada e saída, não olha o código. Não é preciso conhecer a arquitetura ou tecnologia.

  • Caixa Branca

Aqui olhamos o código, é um teste voltado a lógica de programa. Fazemos o uso de ferramentas como o junit.

  • Teste baseado em Erros

Testa-se erros conhecidos em Computação. Por exemplo: Divisão por Zero.

  • Teste de Regressão

Aplica-se a cada nova versão do Software, os testes que forma aplicados na versão anterior, afim de verificar a nova versão não comprometeu os requisitos inalterados.

  • Teste de Estresse

Verifica a carga suportada pelo software. A quantidade de usuários que serão atendidos, ….

Quais são os ciclos:

  • Planejamento
  • Preparação
  • Especificação
  • Execução
  • Entrega

O que é critério de teste?

Estabelece uma exigência ou nível para a aceitação do programa, isto é:

Se o software não atender a 80% das nossas necessidades então abortamos o projeto.  🙁

Leia também:

Engenharia de Software: Gerência de Configuração de Software

Artigo da Série Engenharia de Software.

O tema de hoje: Gerência de Configuração de Software.

O desenvolvimento de Software é uma atividade dinâmica. Mudanças são inevitáveis. Mudam as regras de negócio, muda a visão do usuário sobre o sistema.

A Gerência de Configuração de Software (GCS) é uma área da Engenhar de Software, que atua sobre essas mudanças/modificações afim de manter a consistência e a integridade do Software com as especificações, minimizando problemas durante o desenvolvimento e controlando sistematicamente essas modificações.

As atividades e ferramentas da GCS são:

  • Controlar e acompanhar mudanças (Controle de Mudança)
    • Ferramentas: GitHub, Jira, BugZilla
  • Registrar a evolução do projeto (Controle de Versão)
    • Ferramentas: Git, SubVersion
  • Estabelecer a integridade do Sistema (Integração Contínua)
    • Ferramentas: Jenkins, IBM Urban Code

Vale lembrar, que em cada fase do ciclo de desenvolvimento um conjunto bem definido de itens de configuração é definido, este conjunto é chamado de Baseline.

Leia também:

Projetos em Node.js com boas práticas

Como o Node.js é uma plataforma e não um framework, as boas práticas ficam dependentes do projeto e dos desenvolvedores envolvidos.

Os padrões de design e as melhores práticas existem para evitar armadilhas comuns e construir aplicativos mais estáveis, mas esses princípios orientadores na maioria das vezes não são bem documentados.

Mas existem bons guias e filosofias disponíveis, recomendo visitar o The Node Way. Lá descrevem práticas recomendadas e princípios orientadores para a escrita de módulos de manutenção, aplicações escaláveis e códigos que são realmente agradáveis de ler.

 

Uma sugestão que ajuda bastante é utilizar um linter desde o início.

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs in C language source code. Wikipedia

No caso de Javascript, o mais bem availado é o ESLint, veja a comparação com outros neste link.

Como dica de uma boa leitura utilize JavaScript Standard Style, que exemplifica e evita de você criar as suas próprias regras.

Leia também: