Eu amo o Delphi e quanto ganho por isso?

Olá tudo bem?

É comum e até verdade quando ouvimos e/ou dizermos que trabalhamos por amor, isso é extremamente saudável, afinal o que importa é a qualidade e felicidade e não apenas o quanto ganhamos financeiramente não é mesmo?

Mas… Tudo tem um custo e consequentemente um preço e falando de brasil, muitas vezes o preço é bastante relativo, ou seja, não existe necessariamente um padrão que possa determinar o quanto você irá ser remunerado para realizar seus sonhos e assim manter sua felicidade 🙂

Falando especificamente de valores em nossa área Programação Delphi, quanto o mercado tem nos pago?

Recentemente em um post do amigo André Oliveira no grupo Delphi Brasil Forever onde a pergunta foi: “Qual média salarial para um programador Delphi ?”, surgiram ótimos comentários, onde cada um expõe um pouco de sua realidade e visão sobre o mercado. Isso me despertou a curiosidade (já que estou fora da média do mercado), então fiz uma pesquisa rápida e levantei as seguintes informações:

Pesquisa feita em 04/08/2017

Salário médio de Analista Programador – Delphi

Resultados:

Apinfo 

Obs: Tabela feita com resultados do site

apinfo

 


Catho

Obs: Não existe informações sobre nível profissional ou região

Média Salarial Brasil = R$ 2.467,83


Trainning Education Services

  • Júnior: R$ 2.500,00
  • Pleno: R$ 3.800,00
  • Sênior: R$ 5.500,00

 

Guia da Carreira

  • Júnior: R$ 2.800,00
  • Pleno: R$ 4.256,00
  • Sênior: R$ 6.160,00

Oficina da Net

  • Maior salário: R$ 6.500 – Analista Programador Delphi – São Paulo (SP)
  • Menor Salário: R$ 1.500 – Analista Programador Delphi – Luziânia (SP)
  • Média salarial dos 5 maiores saláriosR$ 5.700
  • Média salarial dos 5 menores salários: R$ 2.100
  • Média Salarial: R$ 3.900

SINE

Obs: Este não é especificamente sobre Delphi, porém os dados são interessantes e se trata genericamente da função/cargo Programador.

SINE


 

Existem outras fontes, porém essas foram as que achei relevante adicionar a este artigo. Caso tenham outras fontes que confiem e quiserem me enviar, eu vou atualizando este material.

E então, o que acham sobre isso? Que tal comentarmos mais sobre o a$$unto 🙂

Compartilhem,  comentem e participem  para formarmos uma base de quanto vale nosso talento 😉

Deus lhe abençoe.

Anúncios

Eu odeio Métodos Ágeis!

Olá,

Diante de muitas polêmicas e discussões acirradas entre profissionais que defendem métodos tradicionais e outros métodos ágeis, ou que simplesmente entendem que métodos ágeis não passam de produtos vendidos por consultorias e gerentes de projetos. Neste artigo tentarei de forma simples e objetiva, levar um pouco de conhecimento para que você possa ao menos não odiar métodos ágeis.

Primeiramente, quero lhes mostrar resumidamente, qual a principal diferença entre método tradicional e método ágil, colocando algumas vantagens e desvantagens:

Método tradicional

Vantagens

  • Maior percepção por parte do cliente referente ao valor total do projeto;
  •  Entrega do produto em sua totalidade;
  • Maior enfoque na etapa de planejamento, com o objetivo de eliminar os riscos;
  • Projetos são realizados de forma mais rápida.

Desvantagens

  • Planejamento rígido, com pouca flexibilidade de trabalho;
  • Não é indicado para clientes que querem sempre inovar e adicionar melhorias no seu produto;
  • Todo o processo é centralizado no gerente de projetos.

Metodologias ágeis

Vantagens

  • Maior liberdade no planejamento do projeto e em cada etapa de trabalho;
  • Projetos são discutidos e flexibilizados em conjunto;
  • Equipe trabalha mais unida e a divisão do trabalho é realizada de acordo com as habilidades de cada membro do time;
  • Existe uma participação mais ativa do cliente em todas as etapas do projeto, através de feedbacks.

Desvantagens

  • O produto é entregue por partes, o que pode não ser vantajoso para o cliente que precisa de um projeto 100% pronto;
  • Planejamento extenso, que exige várias análises em cada etapa do projeto;
  • Pode ter um custo mais alto do que um projeto realizado com metodologias tradicionais.

Embora estas comparações contenham poucas informações, já são o suficiente para que você perceba que não existe um método melhor ou pior, simplesmente existe um método que se aplica e outro não se aplica para cada tipo de projeto.

Para saber se um método se aplica ou não antes de simplesmente odiá-lo, precisamos saber primeiramente, quando usar e quando não usar.

Métodos ágeis não funcionam!

Sim, você pode estar certo! Por exemplo, se um cliente precisa de um projeto entregue 100% não faz sentido utilizar metodologia ágil, isso pode comprometer o cronograma e consequentemente o escopo, além de aumentar custos e inviabilizar o projeto. Sendo assim, é muito melhor utilizar uma metodologia tradicional. Quando um projeto tem escopo definido e totalmente detalhado e requer mais solidez do que aperfeiçoamentos, métodos tradicionais se aplicam sem maiores problemas ou custos extras. Um bom exemplo deste tipo de projeto são softwares feitos por licitações do governo, que devem ser desenvolvidos exatamente como está no edital.

Não é viável utilizar métodos ágeis!

Novamente você pode ter razão, neste caso, se sua empresa não tiver uma cultura ágil, de nada adianta  tentar implantar SCRUM, KANBAN, TDD etc. Isto fatalmente será o fracasso total e prejuízos enormes em seus projetos e até poderá desestruturar sua equipe.

Já vi muitos métodos ágeis darem errado, por isso não acredito que sejam bons!

Por falta de conhecimento e dedicação, muitas vezes, onde os métodos ágeis poderiam ser utilizado, os gestores preferem trabalhar com a metodologia tradicional, apenas por estarem acostumados com essa forma de trabalho.

Ao invés de impor um método ágil, uma forma é tentar utilizar os dois métodos, dependendo do projeto, ajustar a necessidade de acordo com cada cliente. A empresa não precisa seguir 100% um tipo de metodologia, pois cada produto vai exigir um tipo de abordagem distinta, basta analisar e fazer a adaptação ao método mais adequado.
Para isto, a empresa deverá ao menos fazer análises dos pontos positivos e negativos de cada um dos métodos ágeis para a sua organização e assim ver se é mais interessante trabalhar com as metodologias ágeis, com as metodologias tradicionais ou até mesmo avaliar se vale a pena trabalhar com os dois métodos.
Nada impede que os métodos trabalhem juntos. Ambos os métodos são bons, mas não são perfeitos.

Enfim, métodos ágeis devem ser compreendidos para que tornem viáveis em seus projetos, odiá-lo não fará com que o método tradicional seja melhor e vice-versa.

 

 

Os melhores Frameworks BR para Delphi

Olá,

Quando falamos em utilização de um Framework, nos deparamos com os seguintes obstáculos como: Curva de aprendizagem, Requisitos e dependências do sistema, Performance etc.

Ok, ok… Tenho uma boas notícias! 🙂

Graças a Deus, temos amigos como Amarildo Lacerda e Isaque Pinheiro na comunidade Delphi, que por passarem pelos mesmos obstáculos, resolveram dedicar e compartilhar suas fantásticas experiências, criando o que há de melhor em conceito e praticidade para nós desenvolvedores.

Então aproveitem e conheçam os projetos:

 

ORMBr

Mapeamento de Objeto Relacional

e

MVCBr

Um Projeto MVC no Delphi

 

Mesmo que você não for utilizar um desses frameworks, é importantíssimo acompanhar estes projetos que com certeza irá lhe trazer muito conhecimento.

Obrigado a todos, Deus lhes abençoe.

ORMBr – Uma visão aérea

Vejam a estrutura do ORMBr neste artigo feito pelo amigo Isaque Pinheiro.

 

Neste arquivo vou tentar mostrar para você uma visão aérea do ORMBr Framework, ele é separado por camadas, e cada camada são independente uma da outra, proporcionando assim usar qualquer camada em outro projeto que eu queira e haja necessidade.

Nessa imagem mostro o fluxograma, das camadas existentes veja abaixo:

Como citei acima o fluxograma mostra as camadas existentes, cada camada tem suas Units, vou relacionar para que serve cada camada, mas não vou relacionar aqui quais units de cada camada.

Dependency Injection – Essa camada como o nome já diz, traz independência da criação das classe produtos concreto, diretos em nosso projeto, hoje as independências são duas uma para o TClientDataSet e outra para o TFDMenTable.

Driver – Essa camada cuida de tudo que se refere ao banco de dados, nela podemos definir nossa conexão, transações e executar os comando SQL que venham a ser necessários. Essa camada é expansível, podendo existir N drivers, hoje temos para os bancos MSSQL, FireBird, MySQL e SQLite.
Devemos considerar essa camada como unica, pois ela deverá servir para todo o projeto, seu uso foi mostrado no artigo ORMBr – Como criar uma conexão ?

Bind – Essa camada é responsável a nos proporcionar o usar pelo o ORMBr os famosos TDataSet e os componentes dbwares.
Na camada Bind teremos todos os recursos como Insert, Append, Edit, Delete, ApplayUpdates uso dos eventos do DataSet etc…, tudo o que já estamos acostumados, e nos bastidores essa camada trata tudo para se comunicar com a camada que irá fazer o tratamento para persistência das informações no banco.
Devemos ter uma instância do Bind para cada tabela(TDataSet) que precisarmos, no caso de mestre-detalhe por exemplo, vamos ter um Bind Mestre e outro para a Detalhe, passando assim como parâmetro para o Bind Detalhe o Bind Master.

Session – Essa camada é usada pela camada Bind, na verdade é essa camada, que tem o link direto para que o ORMBr faça tudo no banco de dados, ele é quem cuida dos objectos modelos e seus mapeamentos.
Bom ai podemos nos perguntar se é essa a camada que faz gerencia tudo como comandos, persistência etc.. no banco de dados, então para que a camada Bind acima? O motivo é que deixei essa camada para aqueles que não gostam de usar DataSet, com a existência dela, pode-se ter todos os recursos de um ORM, ignorando a camada Bind.

Metadata – Essa camada como o nome já diz, tratará de todos os recursos de gerenciamento do metadata do banco de dados, adicionando, alterando e excluindo, campos, tabelas, FK, PK etc…, a pretensão do ORMBr é ir até onde der para gerenciamento do metadata como exemplo gerenciamento de Views.

Criteria – Essa camada, já veio pronta e foi uma mão na roda para o ORMBr vui. Criteria é uma interface que criei para ser usada como esse nome, mas na verdade quem está por traz é a biblioteca GpSQLBuilder, (o uso do GpSQLBuilder, foi solicitado a autorização ao autor, que autorizou), mais informações em GpSQLBuilder.

Controller – Bom e por final, temos a camada Controller que servirá como base para que voçês possam criar seus controles herdando do TControllerBase, essa class base, já irá disponibilizar para vocês as propriedades que será alimentada após sua criação, o DataSet e o IDBConnection, disponibilizando assim dentro do seu controle o acesso necessários a essas instâncias.

É isso ai, e vamos que vamos, ainda tem muita coisa para eu passar para vocês 🙂

 

Fonte: http://isaquepinheirobr.blogspot.com.br/2016/09/ormbr-uma-visao-aerea.html

ORMBr – Como Conhecer e Testar

Olá, você já conhece o ORMBr? Não??? Então veja como é fácil ter um ORM simples e objetivo para seus projetos. Um dos principais motivos para você utilizar é….

O ORMBr você não precisa instalar nada no seu Delphi: 1) Usar Delphi XE ou superior 2) Baixe os fontes do projeto direto do repositório Download (ORMBr – Framework) 3) Uma outra opção é instalar o Git+TortoiseGit para sempre atualizar seus fontes como o do repositório, veja passo a passo nesse link Guia Git+TortoiseGit passo a passo, se não for suficiente, existem vários posts sobre o assunto. 4) Após baixar todo os fontes, junto irá ter alguns demos, um usando para acesso a dados o DBExpress, outro o FireDAC e outro usando o Zeos, os demos ficam dentro da pasta .\ORMBr\Demo\Data, escolha o de sua preferencia e abra pelo seu Delphi, em seguida basta compilar e estudar os fontes, como já dito não precisa instalar nada. Nota: O ORMBr, pode usar dois componentes conhecidos por nós para fazer baind, com os componentes DBs (TDBEdit, TDBGrid, etc…) são eles : TClientDataSet ou TFDMenTable (esse do engine FireDAC), o componente fica a sua escolha, e ele é independente do engine de conexão que você usará seja ele DBExpress, FireDAC ou Zeos.

 

Fonte: http://isaquepinheirobr.blogspot.com.br/2016/09/ormbr-como-conhecer-e-testar.html

ORMBr – Mapeamento Objeto Relacional

Mapeamento objeto-relacional (ou ORM, do inglês: Object-relational mapping) é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes.

Com esta técnica, o programador não precisa se preocupar com os comandos em linguagem SQL; ele irá usar uma interface de programação simples que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de dados e as classes do programa. A relação entre as tabelas onde originam os dados e o objecto que os disponibiliza é configurada pelo programador, isolando o código do programa das alterações à organização dos dados nas tabelas do banco de dados.
ORM não é uma técnicas tão recentes, pois jé exitem a algum tempo em outras linguagens como Java, e C#, acredito que muitos já ouviram falar sobre Hibernate ORM para a linguagem Java, e Entity Framework para as linguagens .NET da Microsoft.
Já para o Delphi, essa técnica é mais recente, começou a se expandir a partir da versão Delphi 2010, após as enormes melhorias na RTTI e o recurso Generics.
Ultimamente, acredito que a maioria de vocês, tem lido ou ouvido algo sobre ORM, mas a questão é, qual seria as ventagens e quanto isso me custaria para implementar em meus sistemas já existentes, e por fim qual o melhor ORM para eu analisar?
Venho a algum tempo, analisando e estudando as vantagens e funcionalidades de alguns ORMs do mercado, assistindo videos, analisando exemplos etc… e cheguei a conclusão que o ORM seria um grande aliado para nós desenvolvedores, principalmente com a falta de profissionais qualificados no mercado para nos ajudar na continuidade em nossos projetos.
Vou citar aqui um ponto de vantagem, veja se concorda:
Muitos de nós somos desenvolvedores solitários, o qual temos um sistema e a N vezes pensamos em contratar alguém para nos ajudar a mantê-lo, mas nosso tempo é curto e nosso código é tão enraizado em nossos modo de desenvolvimento que ao pensar em ensinar alguém, até desanimamos, pois isso iria nos consumir tempo enorme, então  preferimos nós mesmos pegar e fazer.
Com um ORM, temos ventagens nesse ponto, pois um ORM irá exigir uma linha de aprendizado bem curta a um desenvolvedor que possamos contrata-lo para nos ajudar, isso porque o ORM irá fazer a parte pesada nos bastidores, aliviando e agilizando o aprendizado em um novo profissional.
Poderia ficar aqui citando várias situações das quais, acredito eu que 100% de nós desenvolvedores sofremos no dia dia para conseguirmos ajuda em nosso projetos, mas não vou fazer isso, o exemplo acima já nos mostrar uma visão geral de nossas dificuldades.
Bom, deixa eu mostrar agora para você como que seria simples explicar para um aprendiz, para ele fazer uma tela, o mais simples que seja usando um ORM.
Vou demostrar as imagens para que vocês tenham uma visão da funcionalidade e após vou postar o código usado para chegar a esse resultado.
Acima está a lista de clientes, os componentes usados para que os dados possam ser visualizados são os Dataware, já conhecidos de todos os desenvolvedores Delphi.
Essa tela é a página detalhe do clientes selecionado na lista na primeira imagem, através dessa tela podemos Incluir, Alterar e Excluir registros.
O que usamos para gerar essa tela usando o ORM?
Um TFDConnection ou poderíamos usar no lugar um TSQLConnection ou ZConnection.
Dois TClientDataSet ou poderíamos usar no lugar um TFDMemTable.
Dois TDatasources
TDBGrid, TDBEdits e um TDBNavigator, familiar, não ?
Observe aqui que estou usando componentes já conhecidos nosso, não existe uma componente criado especificamente para atender ao ORM.
Agora vamos ao código para que os dados apareçam na tela grade  e detalhe, e para que as modificações sejam persistidas no banco de dados.
code01
Esse monte de código acima, irá proporcionar os recursos de Incluir, Alterar e Excluir, sem nem mais uma linha.
Cadê o comando “SELECT” ? O ORM irá cria-lo automaticamente.
Cadê o comando “DELETE”, bem esse o Delphi já faz para nós, mas como no ORM se trabalha desconectado quem irá fazer é o próprio ORM.
Cadê o comando “UPDATE”, mesma situações do comando “DELETE”
Mas como ele sabe como gerar o SELECT sabe qual tabela abrir, sabe quais campos mostrar, enfim como o ORM identifica tudo?
Bem o código acima mostra a simplicidade de uso para um desenvolvedor, seja ele um aprendiz, com conhecimento ou um expert, criar algo real.
Por traz disso existe o que chamamos de Modelo, o modelo irá dizer tudo para o ORM, dessa forma desenvolvedores mais experientes podem cuidar dos modelos, enquanto os demais fariam o designer de forma simples e funcional.
Veja como fica o modelo usado para esse exemplo na imagem abaixo:
code02
Como vocês puderam ver, o desenvolvedor não precisou escrever um linha se quer de comando SQL, e convenhamos qual ser humano não teria condição de aprender a criar uma tela de cadastro desse, usando ORM? Se não fosse o ORM teríamos que ensinar ainda sobre tudo comando SQL aumentando assim consideravelmente a linha de aprendizado de um possível novo funcionário contratado, o ORM nos proporciona também criarmos linha de produção, definindo os setores de Tela, de Modelos e de Regras de Negócio separadamente, cada um, responsável por seu setor e código, isso não é um sonho? Confesse para si mesmo.
 Bom, com isso venho apresentar para vocês:
ORMBr, como o nome já diz, e assina Brasil, é um Framework criado por mim, e apesar de ser uma criança ainda, já mostrou um QI acima da média, e a ótima notícia é que ele é OpenSource, podendo ser baixado direto no Bitbucket.
Estamos providenciando um Site e um Fórum para ele, para que possamos juntos, ver essa criança crescer e nos encher de orgulho por suas conquistas.
Fórum Discussão : http://ormbr.forumeiros.com/
Vai lá se cadastre, baixe e teste, conto com todos vocês, e até breve.
Fonte: http://isaquepinheirobr.blogspot.com.br/2016/09/ormbr-mapeamento-objeto-relacional.html

Grupo de Estudos e Compartilhamento

Question-People.jpg

Olá,

Participe das enquetes do grupo para ajudar na criação de conteúdos.

Escolha um tema, marque sua resposta e dê sua opinião nos comentários.

Veja abaixo os assuntos abordados até o momento:

Qual sua primeira versão do Delphi?
http://bit.ly/1NZoWUt

Qual a melhor forma para aprender?
http://bit.ly/26WJ7sr

Você utiliza controle de versões de código? Qual?
http://bit.ly/1TuDdVC

Qual seu estilo ou de sua equipe de programação?
http://bit.ly/1WajErD

Você utiliza TDD?
http://bit.ly/1TLnFzq

Qual a melhor forma de documentação você prefere?
http://bit.ly/1rsR5sM

Acesse também os canais Delphi Clean Code nas redes sociais:

Youtube
Twitter
Googleplus
Facebook
Flipboard
Instagram
Tumblr

Obrigado, conto com sua colaboração para juntos aprendermos e compartilharmos o melhor Emoticon wink

TDD – Desenvolvimento Orientado a Testes com Delphi

TDD – Desenvolvimento Orientado a Testes (Test Driven Development) é uma técnica de desenvolvimento de software relacionado aos conceitos de XP (Programação Extrema). que baseia em um ciclo curto de repetições.

O ciclo de desenvolvimento com TDD se resume em:

1 – Primeiro crie os testes unitários. 

2 – Crie o código até que os testes funcionem.

3 – Refatore o código. 

TDD é uma das formas de manter seu código funcionando seguramente mesmo que sejam feitas mudanças radicais no projeto. O primeiro passo, onde é requisito escrever um teste antes de ter o código final desenvolvido no projeto, certamente é o ponto mais difícil de entendimento entre profissionais e equipes que ainda não conhecem esta técnica.

O fato é que nesta primeira etapa é justamente onde você vai entender dentre muitas outras coisas, que terá uma regra seguramente funcionando antes de partir para o desenvolvimento do código.

Como assim? Você está me dizendo que “do nada” eu tenho que codificar uma regra?

Você ainda pode estar se perguntando: “Se eu ainda não tenho o código que funciona, como terei um teste para ele?”

Eu lhe digo, justamente! A regra no caso do TDD é justamente ter um teste que ainda não funcione, para que você passe para a segunda etapa que é “Criar um código que faça seu teste funcionar”, certo?

Para que isto se torne possível, neste texto irei falar do uso do framework DUnitX.

DUnitX é um framework open-source que pode ser utilizado no Delphi a partir da versão 2010. Ele é baseado em frameworks como NUnit e xUnit, contendo inúmeros métodos para implementação de testes unitários de suas classes e métodos. DUnitX utiliza métodos anônimos e generics. Existem muitos artigos e videos com exemplos práticos a serem explorados, a princípio você pode conhecer um pouco mais sobre este framework, conceitos e métodos a serem utilizados em: http://docwiki.embarcadero.com/RADStud…/…/en/DUnitX_Overview

Ok, mas voltando ao texto,  isso pode não está bem claro ainda, então vamos ao tal código do teste.

Antes quero lhe dizer que cada teste, deve ser baseado em uma regra compreendida pela análise do problema a ser resolvido, então vamos ver um exemplo comum para iniciar.

Caso do teste:

Ao iniciar uma venda, em seguida finalizar a mesma venda sem itens lançados,  o sistema deverá informar o usuário por diálogo de exceção, com a seguinte mensagem “É necessário pelo menos um item lançado para finalizar a venda”.

Observe a estrutura das classes de Venda. Note que não existem implementações desta regra de negócio na classe TVenda.

ClasseBase

Mas isto não impede a criação dos métodos de teste, pois é justamente o que deve ser feito quando se trabalha com TDD, Desenvolvimento Orientado a Testes!

Agora vamos ver como é feito o Teste:

VendaTest

E o que este teste quer dizer mesmo?

Simples! Vamos ver cada parte demonstrada por cores.

Verde: Este método Setup serve para que seja executado algo para cada método de teste, isto ajuda para que você separe a parte de inicialização de variáveis e instancias de objetos e deixe seu código somente com a regra a ser testada.

Vermelho: É outro método a ser executado, desta vez após todo método de teste que for implementado. Assim como o Setup, neste método, você pode liberar possíveis objetos da memória e até executar outros procedimentos como finalizar uma conexão por exemplo.

Amarelo: Este é o primeiro método de teste conforme nosso caso relatado acima!

E como foi implementado este teste?

No framework de testes DUnitX,  existe a classe Assert que contém inúmeros métodos para que possa ser feito várias condições, para nosso caso, foi utilizado o método  WillRaiseWithMessage (a grosso modo quer dizer: Irá(deverá) levantar uma exceção contendo a seguinte mensagem). Para este método, podem ser passados os seguintes parâmetros:

1 – Um procedimento anônimo com uma implementação que deverá ser a mesma utilizada no sistema, ou seja, Inicia uma venda e Finaliza uma venda, neste caso sem lançar nenhum item, assim como previsto no Caso de teste.

2 – Uma classe de exceção, pode ser nil caso não tiver nenhuma específica.

3 – A mensagem que será esperada pelo sistema ao ocorrer o caso  do teste. Esta mensagem tem que ser exatamente a mesma, caso contrário o teste irá falhar.

Pronto! Assim concluímos a primeira etapa do teste, este teste já pode ser executado e deverá dar errado, é isso que precisamos fazer até o momento.

Olhe o resultado ao executar o teste:

ErroTeste

Pode comemorar, o teste falhou!

Veja só o que temos, o retorno de que o teste FinalizarVendaSemItensLancados não retornou um exceção como esperado!

Agora sim já podemos partir para o segundo passo que é justamente fazer isto acontecer em nossa classe, consequentemente na aplicação onde ela será utilizada.

O que precisamos fazer é simplesmente codificar nossa classe para que dispare uma exceção com a mensagem esperada pelo teste, então observe um exemplo de como isto pode ser feito na classe TVenda:

ImplementacaoTeste

Assim, ao chamar o método Finalizar, será verificado se existem itens lançados, caso não existam é disparado a exceção com a mensagem correspondente.

Então ao executar novamente a aplicação de testes, devemos receber o seguinte resultado.

TestePassou

A partir deste modelo, você já pode criar outros testes unitários para sua classe, não há limites para isto, o ideal é que sejam atendidos 100% dos possíveis casos de sua aplicação, quanto mais casos forem atendidos melhor!

Bom, isto está longe de ser um material completo sobre testes unitários, porém já é o suficiente para que você conheça como irá finalmente garantir que sua aplicação se torne segura independente da mudança sofrida durante a vida do projeto

Para finalizar quero ressaltar alguns benefícios ao adotar TDD:

  • Certeza de que se algum outro desenvolvedor acidentalmente mudar a regra de negócio na aplicação, o teste irá falhar antes que chegue ao cliente.
  • Conhecimento de todas as regras de negócio ao ler os casos de testes.
  • Identificar rapidamente regras incorretas ou obsoletas.
  • Facilidade de alocação de um novo profissional para o projeto sem maiores riscos de mexer em código que já estava funcionando.
  • Identificar quais são os mínimos e máximos argumentos para que regras de negócio sejam atendidas (eliminando redundância e métodos desnecessários).
  • Documentação de regras de negócio, baseada nos casos de testes.
  • Confiança!

É isso ai, muito obrigado por ler este artigo e não para por aqui, estou editando alguns videos onde certamente falarei mais sobre testes :d

Obrigado.

Carlos Eduardo – Delphi Clean Code

 

Técnicas de Refatoração com Delphi

casa

Imagem retirada de: http://www.desenvolvimentoagil.com.br/xp/praticas/refatoracao

Olá

Uma das técnicas que quando utilizadas fazem muita diferença  na vida de um projeto é a Refatoração.

O que é refatorar?

Refatorar é alterar a estrutura do código sem alterar o seu comportamento.

Um dos grandes nomes da técnica de refactoring – refatoração –  é Martin Fowler. Seu livro mais importante sobre refatoração é Refactoring: Improving the Design of Existing Code (ISBN 0-201-48567-2), onde são explicados os conceitos, motivações e uma série de refatorações descritas passo a passo.

Neste você verá um pouco sobre algumas técnicas que podem ser utilizadas para ter bons resultados com a refatoração de código.

Continuar lendo “Técnicas de Refatoração com Delphi”

Qual seu controle de versão?

 

ArtigoControleVersao

 

Assim como a maioria das tecnologias, linguagens, IDE’s etc. Utilizar controle de versão exige muito estudo, análise e testes para uma boa escolha, isto é, adequar a estrutura, os projetos e capacitar equipes para trabalhar com segurança, desempenho, funcionalidades e o mínimo de complexidade.

Então, sugiro mais um questionário para compartilharmos qual ferramenta utilizamos no dia a dia e ainda comentarmos um pouco de nossas experiências boas ou ruins sobre as seguintes opções Git – SVN – Mercurial.

Responda em: Facebook Grupo Delphi Clean Code

Lembrando que o Delphi já possui integraçã
o com os 3 sistemas, sendo:

SVN desde a versão XE,

Git desde a versão XE7,

Mercurial desde a versão XE8.

Participe!

Obrigado,

Carlos – Delphi Clean Code.