“Eu sempre me interessei por ciência, tecnologia e (acima de tudo) computadores. Essas são coisas que eu sempre amei, apesar de serem difíceis as vezes. Eu amei matemática e ciências na escola. Eu li histórias de ficção ciêntifica e aventuras fantasiosas durante todo tempo livre que eu tinha. Eu fui o garoto nerd da escola que sofria bullying e era zoado. Teria sido bem mais fácil desistir do meu jeito e ser ‘como qualquer outro’. Eu poderia ter parado de ler. Eu poderia ter praticado mais esportes.
Mas eu não fiz isso. Eu sabia o que eu amava. Eu sabia que o que eu queria era mais importante do que o que eles queriam. Acima de tudo, eu queria mudar o mundo.
Ninguém na história já mudou o mundo sendo o que os outros queriam que fosse. Eles mudaram o mundo pela ousadia de rir do que é senso comum e tentar algo novo. Eles mudaram o mundo ao se manterem de pé e desafiando que “contra a força não há resistência” ou “ser maria vai com as outras” é o caminho certo.
Este é o sentimento que me dirigiu a minha carreira Open Source*. Eu escolhi este caminho em minha vida porque eu vi este como uma forma de fazer alguma diferença real no mundo. Esta foi uma mudança real em minha vida, e continua sendo. E isso vai de encontro a toda a cultura e história dos negócios corporativos.
No seu coração, o movimento Open Source é uma extensão da ciência. O senhor Isaac Newton escreveu: ‘Se vi mais longe foi por estar de pé sobre ombros de gigantes.’. Uma das mais brilhantes mentes da história reconheceu que sua contribuição para a nossa maior compreensão não veio somente de sua mente ou visão, mas sim do fato de que milhares de mentes, maiores e menores, trabalharam juntas para criar um mundo onde sua faísca em particular pudesse inflamar a mudança.
A filosofia do Open Source é a mesma. É um mecanismo para permitir que milhares de pessoas trabalhem juntas por um objetivo comum. O desenvolvimento clássico de software sempre ocorreu em ambientes fechados que sempre protegeram seus segredos a punhos de aço. Essencialmente, este pensamento (fechado) também se refletiu em invenções e na indústria por anos (e ainda reflete). É um hábito difícil de quebrar, especialmente quando parece que você está abrindo mão de algo.
Na minha opinião, este é o ponto central que faz com que as pessoas tem problemas em aprender. Quando você abre mão do controle exclusivo, você está ganhando algo muito mais valioso: você está expandindo o nível base. Você está alimentando esses gigantes para que você, e outros, possam ficar de pé sobre e ver mais além. Onde antes você era um inventor de pé sobre os ombros de um gigante, agora você olha para baixo e pode ver a verdade que isso significa: que este gigante está de pé sobre outros gigantes maiores. E por ai vai, por toda a história.
Uma vez que você se envolve, as coisas começam a ficar mais claras. Quando você ficar mais alto e puder ver mais além, você perceberá que os seus esforços podem ter o impacto maior do que um dia você jamais imaginou. Ao invés de deter um conhecimento irrisório, você pode compartilha-lo com o mundo e ver o que eles irão fazer com este conhecimento também. Isso nem sempre será o bastante e nem sempre irá atender aos seus objetivos originais, mas isso será sempre melhor do que a soma de suas partes. E, de uma forma pequena, você terá mudado o mundo.
Uma coisa que fica bastante esquecida quando as pessoas falam sobre mudar o mundo é que eles falam sobre deslocamentos massivos de direção. Eles falam sobre esses momentos na história em que você pode olhar pra trás e dizer: “Aqui! Foi neste momento que tudo mudou!”. Esses momentos sempre haverão a cada poucos séculos, mas a verdade é que a maioria das mudanças acontece de forma glacial.
Open source é uma dessas mudanças glaciais. Eu não uso este termo para sugerir que esta mudança acontece muito devagar. Pelo contrário, eu escolho este termo para invocar a imensidão, inevitabilidade e o quão incrível é o abalo a que isso leva. Uma geleira pode levar décadas, séculos ou mesmo milênios para se mover pela terra, mas nada pode realmente se manter contra sua maré. Este é o legado do Open Source: a maré do progresso.
Ao longo dos últimos 25 anos de Linux, temos visto um grande número de avanços feitos na marcha do progresso. Quando as pessoas perguntam com o que eu trabalho e eu digo ‘Linux’ ou ‘Open Source’, elas frequentemente me devolvem um olhar vazio. Eu normalmente sigo com a seguinte sequência: ‘Você tem algum dispositivo com um interruptor que não começa com a letra I? É provável que ele esteja rodando Linux ou, ao menos, algum código Open Source’. Toda vez eu digo isso, e me surpreendo com a grandiosidade disso. Todos esses anos de trabalho duro, de tantos indivíduos talentosos, mudou as coisas a tal ponto que agora código open source é padrão, eles estão em todo lugar, é o protagonista ao invés do coadjuvante. Além disso, se tornou tão onipresente, que qualquer um pode usa-los sem sequer saber de sua existência.
De uma maneira bem real, a comunidade Open Source mudou o mundo. E continua mudando dia após dia. Eu comecei a fazer parte disso, e eu não vou mentir que a idéia não me deixa um pouco atordoado.
Eu comecei este blog (https://sgallagh.wordpress.com) com a questão ‘Por que não mudar o mundo?’, mas este foi um pequeno mal entendido. Nós já mudamos o mundo. A questão real deveria ser ‘Como você vai muda-lo depois?’.”
Este texto representa bastante do meu sentimento e carinho pela comunidade Open Source. O post original pode ser encontrado em: https://sgallagh.wordpress.com/2013/08/26/why-not-change-the-world/
]]>Existem muitas formas de adquirir tais habilidades, e é importante ter em mente que sempre haverá algo novo a aprender (e é este desafio constante que me leva a ficar acordado até as 2 da manhã quase diariamente, estudando. Portanto, tenha em mente, para poder se denominar “competente” é preciso desenvolver habilidades e adquirir conhecimento.
Vivemos em pleno século XXI, quase tudo a nossa volta é fonte de informação, e os nossos celulares são fontes de informação praticamente infinita. Isto é ótimo, e ao mesmo tempo muito ruim. Podemos gastar o nosso tempo em conversas levianas no whatsapp, ou vendo fotos no Facebook, ou mesmo rolando infinitamente o scroll do 9gag. Quer se tornar um ótimo programador? Então tome cuidado com isso.
Utilize o seu tempo melhor, forme a sua rede de pessoas, sites e blogs que tenham conteúdos relevantes, e leia-os diariamente. Esta no metrô, ônibus ou na fila de um banco? Este é um ótimo momento para ler um artigo (use seu celular a seu favor). Eu considero a obtenção diária e constante de conhecimento muito mais enriquecedor do que pagar para fazer algum curso (um curso pode ser um ótimo ponto de partida, mas curso nenhum vai te deixar apto ao mercado de trabalho).
Para organizar o que eu vou ler e sempre receber novidades que são do meu interesse, eu uso o Feedly. Um bom leitor de RSS é essencial.
Abaixo, uma lista de alguns dos principais sites e nomes que eu leio diariamente:
Eduardo Pires - Arquiteto de Software e professor, seu Blog tem ótimos artigos sobre arquitetura e engenharia de software, além de ótimos tutoriais gratuitos (e treinamentos pagos).
Troy Hunt (em inglês) - Profissional norte-americano especialista em segurança de software. Seu blog tem uma linguagem super simples e os artigos são sempre muito esclarecedores. Parada obrigatória para qualquer desenvolvedor.
Microsoft Virtual Academy (inglês/português) - A academia da Microsoft possui muito conteúdo e vídeos muito bons. Eu aprendi MVC aqui. Recomendo muito os Jumpstarts (te levam do 0 ao fazendo algo útil em poucas horas). E se você acha que a MVA tem apenas conteúdo sobre tecnologias Microsoft, a cerca de 6 meses atrás foi publicado um Jumpstart de Python Django.
ADT Magazine (em inglês) - Conteúdos diversos, todos relacionados a TI. Segurança, banco de dados, cloud computing, infraestrutura, nova linguagem do Google, e outras coisas.
Allan Kelly (em inglês) - Engenheiro de software britânico. É um dos meus profissionais favoritos. Posta bastante conteúdo sobre agile, engenharia e arquitetura de software. Seu blog é obrigatório para quem quer entender todas as etapas relacionadas ao desenvolvimento de software além da escrita do código.
UX Magazine (em inglês) - Não sou especialista em user experience, mas é sempre bom ver alguma coisa sobre, ter noção de alguns conceitos e ver como o mercado (internacional) está convergindo neste sentido.
André Baltieri - Microposts sobre engenharia e arquitetura de software.
Conheço somente uma forma de desenvolver habilidade: praticando. Então, como se tornar proeficiente com uma linguagem ou tecnologia com a qual não trabalha no dia-a-dia?
Existem inúmeros tutoriais espalhados pela Internet, muitos deles, inclusive, podem ser feitos online.
TryRuby - Ótimo tutorial online para quem quer dar os primeiros passos com Ruby. Este tutorial foi completamente traduzido para o português brasileiro por mim.
Rails Book (em inglês) - Já aprendeu Ruby e agora quer aprender o seu principal framework para desenvolvimento web? O Rails Book é o tutorial em forma de livro mais completo que eu já vi, ele ensina desde comandos básicos de Linux, passando Github, Heroku e, claro, muito Rails. Tutorial muito recomendado, dependendo da sua fome, dá para devora-lo em um final de semana.
Code Combat (em inglês) - Exercite Javascript jogando. É um tipo de RPG no qual a única forma de passar de fase é escrevendo código. Sempre recebe fases e desafios novos.
Robot Game (em inglês) - Jogo multi-player competitivo no qual você possui um robô de combate que deve vencer os robôs de outros jogadores. E onde está a programação? Você não controla o seu robô, você programa sua inteligência artificial em Python.
É fato indiscutível que a todo instante nós estamos utilizando software OpenSource (este blog que você está lendo usa Jekyll, que é OpenSource). Portanto, teve uma ótima idéia que vai ajudar um monte de gente? Nada mais justo do que contribuir um pouquinho com o mundo e participar da comunidade OpenSource. Você também pode contribuir ajudando a melhorar projetos que já existem.
Existe muito conteúdo bom e gratuito na Internet, basta estudar. Você deve ter reparado que a maioria do conteúdo é em inglês, se inglês ainda é o seu fraco, já passou da hora de aprender. Não dá para crescer neste mercado sem saber inglês, portanto, dedique um tempo dos seus estudos a isso.
Na minha opinião, cursos são ótimos pontos de partida mas não irão lhe tornar profissional. O processo de profissionalização acontece a todo instante, a toda hora. É preciso dormir, comer e respirar programação. E, principalmente, gostar de programar.
Gostou deste post? Tem dúvidas ou sugestões? Algum tema específico que gostaria que fosse abordado neste ou em tópicos futuros? Deixe o seu comentário, compartilhe, me ajude a propagar este blog para que eu possa compartilhar meu conhecimento e experiências com cada vez mais gente.
]]>Olhe a sua volta, veja os seus colegas de universidade ou de trabalho, olhe para si mesmo e questione-se: eu estou fazendo da melhor forma possível?
Convido-lhe, a junto comigo, aprender um pouquinho mais e adicionar a sua bagagem intelectual um diferencial de mercado. Vamos aprender algo que não depende de uma linguagem de programação eslecificade REALMENTE programar de forma orientada a objetos. Este é um conhecimento que pode ser levado para qualquer linguagem de programação.
Neste primeiro post eu abordo:
Faça um ótimo proveito e, principalmente, divirta-se !
Orientação a objetos é uma forma de programar que, praticamente, independe de linguagem (uma vez que a maioria das linguagens de programação suportam a orientação a objetos).
Consiste em programar de forma que, cada trecho do seu código tente ser um espelho de algo que existe no mundo real.
A O.O. nos permite reaproveitar o nosso código sem precisar copiar e colar, além de organizar o código de forma que ele seja expansível. Graças a O.O. temos softwares de tal complexidade que, seria praticamente impossível fazer de forma estruturada (programação convencional, linha atrás de linha).
Toda linguagem de programação que suporta a orientação a objetos possuem, elementarmente, suporte a criação de quatro elementos de programação. São eles: Classes, Métodos, Propriedades e Instâncias.
Os métodos são funções, algoritmos, que executam uma determinada ação. O que diferencia um método de uma simples função, é que um método, normalmente, altera o estado (PROPRIEDADES) de um determinado objeto. Métodos SEMPRE, fundamentalmente, são ações. Sempre descreva um método com um verbo de AÇÃO.
Se pensarmos em um carro, ele teria métodos como: acelerar, freiar, ligar, dentre outras.
Outro exemplo, mais voltado a sistemas, um cliente de banco pode sacar dinheiro, depositar, solicitar empréstimo, comprar produtos.
Caso esteja confuso para você, pense em um método como sendo uma função ou um algoritmo qualquer (na prática não há muita diferença). Mas não esqueça, métodos são sempre VERBOS DE AÇÃO.
São características, qualidades, daquilo que estamos tentando representar.
Se pensarmos em um carro, temos propriedades como: material, potência, velocidade máxima, velocidade atual, capacidade de combustivel.
Já utilizando o exemplo do cliente do banco, teremos propriedades como: nome, endereço, saldo bancário, limite de empréstimo, etc.
Uma classe, nada mais é do que um mapeamento de um objeto do mundo real, porém a classe NÃO é o objeto. A classe é como se fosse um molde, uma receita.
Toda classe possui métodos (ações) e propriedades (qualidades).
Toda classe também possui um, ou mais, método especial que é invocado quando criamos uma instância desta classe (não se preocupe, explicarei mais a frente o que é uma instância). Este método especial é chamado de construtor. O construtor é o único método que não é um verbo de ação, mas sim o nome da própria classe.
Ao criarmos uma classe de um carro, nós estamos descrevendo o que um carro TEM (propriedades) e o que um carro pode FAZER (métodos). Vejamos um exemplo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class Carro
{
//Essas são as nossas propriedades
public int VelocidadeAtual;
public int VelocidadeMaxima;
public int TaxaDeAceleracao;
public string Modelo;
public string NomeFabricante;
public Carro()
{
//Podemos definir algumas coisas aqui quando
//cada carro for criado. Este é o nosso construtor.
}
//Este é o nosso método, repare que ele aumenta
//a velocidade atual com a taxa de aceleração.
public void Acelerar()
{
VelocidadeAtual += TaxaDeAceleracao;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Carro
#definimos os atributos
attr_accessor :velocidadeAtual,
:velocidadeMaxima,
:taxaDeAceleracao,
:modelo,
:nomeFabricante
def initialize()
#inicializamos os atributos
@velocidadeAtual = 0
@velocidadeMaxima = 0
@taxaDeAceleracao = 0
@modelo = ""
@nomeFabricante = ""
end
def acelerar()
@velocidadeAtual += @taxaDeAceleracao
end
end
A instância é o objeto propriamente dito. Pegamos a nossa “receita” (classe) do carro, e a partir dela criamos vários carros. Cada carro criado é uma instância.
É importante ressaltar que cada instância possui suas próprias propriedades, com valores independentes.
Por exemplo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
//Este método é o nosso programa principal.
public void main()
{
var carro1 = new Carro(); //criamos uma instância de Carro
var carro2 = new Carro();
carro1.Modelo = "Celta 1.0";
carro1.Fabricante = "Chevrolet";
carro1.VelocidadeMaxima = 120;
carro1.TaxaDeAceleracao = 20;
carro1.VelocidadeAtual = 0;
carro2.Modelo = "Eclipse";
carro2.Fabricante = "Mitsubishi";
carro2.VelocidadeMaxima = 220;
carro2.TaxaDeAceleracao = 40;
carro2.VelocidadeAtual = 0;
carro1.Acelerar();
Console.WriteLine(carro1.VelocidadeAtual); //Será impresso 20
carro2.Acelerar();
Console.WriteLine(carro2.VelocidadeAtual); //Será impresso 40
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#Este é o nosso programa principal.
carro1 = Carro.new #criamos uma instância de Carro
carro2 = Carro.new
carro1.modelo = "Celta 1.0"
carro1.nomeFabricante = "Chevrolet"
carro1.velocidadeMaxima = 120
carro1.taxaDeAceleracao = 20
carro1.velocidadeAtual = 0
carro2.modelo = "Eclipse"
carro2.nomeFabricante = "Mitsubishi"
carro2.velocidadeMaxima = 220
carro2.taxaDeAceleracao = 40
carro2.velocidadeAtual = 0
carro1.acelerar
puts carro1.velocidadeAtual #Será impresso 20
carro2.acelerar();
puts carro2.velocidadeAtual #Será impresso 40
A orientação a objetos tem três pilares básicos: herança, polimorfismo e encapsulamento. Não é correto afirmar que programamos de forma orientada a objetos só porque criamos meia dúzia de classes para separar nossa lógica. É importantiíssimo respeitar esses três pilares.
Não se preocupe se não entende-los agora. O importante é saber que eles existem e ter uma breve noção do que é cada um. Nos próximos posts veremos na prática cada um deles acontecendo.
A herança é a capacidade que uma classe tem de “aprender”, ou “absorver” capacidades de outras classes. A herança nos poupa muita escrita de código. Imagine a seguinte situação, uma pessoa pode ser representada pela seguinte classe:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Pessoa
{
public int Idade;
public string Nome;
public string CPF;
public string RG;
//Este é o nosso construtor.
public Pessoa()
{
//Lógica de inicialização da pessoa aqui.
}
public void Caminhar()
{
//Lógica para fazer a pessoa caminhar.
}
public void Comer()
{
//Lógica para comer.
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class Pessoa
#definimos os atributos
attr_accessor :idade,
:nome,
:CPF,
:RG
#Este é o nosso construtor
def initialize()
@idade = 0
@nome = ""
@CPF = ""
@RG = ""
end
def caminhar()
#Lógica para fazer a pessoa caminhar.
end
def comer()
#Lógica para comer.
end
end
Podemos ver que cada pessoa possui suas propriedades (idade, nome, cpf e rg) e ações (caminhar e comer). Retomando o exemplo do cliente de banco, podemos dizer que todo cliente de banco É uma pessoa. Logo, cliente de banco pode HERDAR de pessoa.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class ClienteDeBanco : Pessoa
{
public string Agencia;
public string ContaCorrente;
public ClienteDeBanco()
{
//Aqui vai nossa lógica de inicialização
}
public int EfetuarSaque()
{
//Lógica para efetuar saque.
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
class ClienteDeBanco < Pessoa
attr_accessor :agencia,
:contaCorrente
def initialize
@agencia = ""
@contaCorrente = ""
end
def efetuarSaque
#Lógica para efetuar saque.
end
end
O que exatamente o código acima significa? Significa que, toda instância de ClienteDeBanco que criarmos, poderá fazer tudo o que uma Pessoa faz (caminhar e comer), terá as mesmas propriedades que uma Pessoa tem (idade, cpf, rg, nome), e além disso ele também terá uma Agência e uma Conta Corrente, além de poder efetuar saques.
Polimorfismo, basicamente falando, é a capacidade que um objeto, de um determinado tipo, tem de se transformar em outro, ou se passar por outro.
É importante saber que é possível o Polimorfismo acontecer, e que toda linguagem O.O. lhe permite fazer isso.
Não se preocupe sobre COMO ou QUANDO você irá usar o polimorfismo. Veremos isso mais a frente.
Encapsulamento é a capacidade do objeto (ou de um sistema) de “esconder” dos outros objetos tudo aquilo que não é relevante a eles.
Você deve ter reparado que nos códigos de exemplo deste post, a palavra public apareceu bastante. Esta palavra é o atributo de visibilidade de uma propriedade ou método.
Dizer que algo, em um sistema O.O. é público, significa dizer que qualquer classe pode acessar aquilo.
Além do public poderíamos usar o private. Mas quando usar o private? Quando vamos escrever algum método (ou propriedade) que “ninguém” mais do seu sistema precisa conhecer.
Voltemos a falar do carro, quando você entra no carro e vira a chave, você está dando para ele o comando de “Ligar”, para ligar, é necessário energizar o motor, dar a partida, injetar gasolina, dentre outras coisas que o carro faz para você. O que o carro faz é encapsular todas essas funções. Você não precisa saber que elas acontecem e muito menos como acontecem (a menos que você seja um apaixonado por mecânica), você só precisa saber que ao virar a chave o carro ligará.
Como isso ficaria em termos de código?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public class Carro
{
//Essas são as nossas propriedades
public int VelocidadeAtual;
public int VelocidadeMaxima;
public int TaxaDeAceleracao;
public string Modelo;
public string NomeFabricante;
public Carro()
{
}
public void Acelerar()
{
VelocidadeAtual += TaxaDeAceleracao;
}
public void Ligar()
{
DarPartida();
LigarOMotor();
LigarPainel();
}
private void DarPartida()
{
//Lógica para dar a partida
}
private void LigarOMotor()
{
//Lógica para ligar o motor
}
private void LigarPainel()
{
//Lógica para liga o painel
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class Carro
attr_accessor :velocidadeAtual,
:velocidadeMaxima,
:taxaDeAceleracao,
:modelo,
:nomeFabricante
def initialize()
@velocidadeAtual = 0
@velocidadeMaxima = 0
@taxaDeAceleracao = 0
@modelo = ""
@nomeFabricante = ""
end
def acelerar()
@velocidadeAtual += @taxaDeAceleracao
end
def ligar()
darPartida
ligarOMotor
ligarPainel
end
def darPartida()
#Lógica para dar a partida
end
def ligarOMotor()
#Lógica para ligar o motor
end
def ligarPainel()
#Lógica para ligar o painel
end
#Aqui tornamos nossos métodos privados
private :darPartida, :ligarOMotor, :ligarPainel
end
Neste artigo eu tentei explicar e exemplificar a base da orientação a objetos. Mas programar de forma realmente orientada a objetos é bem mais do que separar funções em classes e ter alguma estrutura de herança. Nos próximos artigos dessa série eu abordarei os princípios do S.O.L.I.D e ao final, a cereja do nosso bolo serão as metodologias de teste T.D.D. e B.D.D., portanto, não perca!
Dúvidas, sugestões? Deixe o seu comentário.
]]>Todo algoritmo que eu conheço, desenvolvido em qualquer linguagem de programação que eu conheço, são básicamente e fundamentalmente constituidos de:
Operadores Aritméticos
Operadores Lógicos
Controladores de Fluxo
Estruturas de Repetição
Operadores aritméticos são os tão conhecidos operadores matemáticos, que já utilizamos no nosso dia-a-dia e aprendemos desde o primeiro dia em que colocamos os pés na escola.
Os quatro operadores básicos que toda linguagem tem são: + (soma), - (subtração), * (multiplicação), / (divisão).
Além dos operadores básicos, existem outros operadores que são extremamente úteis, por exemplo o operador mod, ou resto de divisão (representado pelo símbolo % na maioria das linguagens). Por exemplo, podemos utilizar este operador para saber se um número é par:
Algumas linguagens possuem operadores matemáticos implementados. Por exemplo, em python podemos utilizar o símbolo ** para representar potência:
a = 2**2
b = 2**3
c = 10**2
print(str(a)) #4
print(str(b)) #8
print(str(c)) #100Minha recomendação é: procure a documentação básica da línguagem que você quer aprender e verifique quais operadores aritméticos eles possuem. A disponibilidade, ou não, de um determinado operador vai impactar diretamente a forma como você irá desenvolver o seu algoritmo.
O que são os controladores de fluxo? Para que servem? Quem são eles?
Como o próprio nome sugere, eles servem para controlar o fluxo de uma aplicação.
É através deles que o seu programa terá a inteligência para tomar decisões. São os controladores de fluxo que permitirão ao seu programa fazer algo, ou não. Os controladores de fluxo são:
if - Sempre que uma determinada condição for verdadeira, ou não falsa (veremos isso nos exemplos), tudo que está especificado dentro do bloco do if será executado.
else - O else é a situação contrária ao if. Um if não precisa de um else para existir, mas o else precisa do if. O else não executa nenhuma verificação lógica, sempre que a condição do if for falsa, o else (se existir) será executado.
Vejamos o seguinte problema:
Um colégio precisa de um programa para verificar se os seus alunos foram aprovados em determinada disciplina. De acordo com as regras desse colégio:
Cada aluno é avaliado semestralmente, ou seja, possui 2 notas.
A média do aluno é a média aritmética das notas. Ou seja, as duas notas somadas e o resultado dividido por dois.
Todas as notas são números inteiros (a fim de simplificar o nosso exemplo)
SE o aluno tiver nota maior ou igual a 6, ele será aprovado, senão será reprovado.
Sempre, eu digo sempre, que você for tentar desenvolver um algoritmo, preste atenção ao problema a ser resolvido. Tente escrever um texto dos requisitos, do cenário, a partir dele já é possível extrair dados importantes ao funcionamento do nosso algoritmo.
Como iremos resolver o problema acima? Recomendo que você, leitor, tente descrever o passo a passo deste algoritmo antes de continuar lendo o passo a passo abaixo:
Definiremos a quantidade de notas como sendo 2
Obteremos a soma entre a nota1 e a nota2
Obteremos a média através da divisão da soma pela quantidade de notas
Se a média for maior ou igual a 6, então o aluno foi aprovado
Senão, o aluno foi reprovado
Esta é a estrutura básica do nosso algoritmo. Como traduzimos isso para linguagens de programação?
1
2
3
4
5
6
7
8
9
10
11
#ruby
def verificar_aluno_aprovado(nota1, nota2)
quantidade_de_notas = 2
soma = nota1 + nota2
media = soma/quantidade_de_notas
if media >= 6
return true
else
return false
end
end
1
2
3
4
5
6
7
8
9
#python
def verificar_aluno_aprovado(nota1, nota2)
quantidade_de_notas = 2
soma = nota1 + nota2
media = soma/quantidade_de_notas
if media >= 6
return true
else
return false
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
//c#
public static bool VerificarAlunoAprovado(int nota1, int nota2)
{
int quantidadeDeNotas = 2
int soma = nota1 + nota2;
int media = soma/quantidadeDeNotas;
if(media >= 6)
{
return true;
}
else
{
return false;
}
}
Continua na parte 2…
]]>“Suponha que você já foi para a montanha da definição de problemas, caminhou uma milha com o homem dos requisitos, lavou suas roupas na fonte da arquitetura, e, por fim, banhou-se nas puras águas da preparação. Então, você soube que, antes de implementar um sistema, você precisa entender o que esse sistema deverá fazer e como irá fazer.”
‘Ponto chave: Parte do seu trabalho como desenvolvedor é educar as pessoas a sua volta que não são desenvolvedoras sobre o processo de desenvolvimento. Este texto o ajudará a lidar com gerentes e chefes que ainda não viram a luz. Este texto é um argumento extendido para fazer o levantamento de requisitos e arquitetura - coletando, de forma correta, os aspectos críticos - antes de você começar a escrevar código, testar e debugar. Aprenda o argumento, então sente-se com o seu chefe e tenha uma conversa, de coração para coração, sobre o processo de desenvolvimento.’
Uma das idéias chave na programação eficiente é que preparação é importante. Faz todo sentido do mundo, antes de você começar a trabalhar em um projeto, você planejar o projeto. Grandes projetos demandam mais planejamento, pequenos projetos demandam menos planejamento (mas demandam algum planejamento). Do ponto de vista de um gerente, planejar significa determinar a quantidade de tempo, numero de pessoas, numero de computadores e outros recursos que o projeto precisa. Do ponto de vista de desenvolvimento, planejar significa entender o que você quer construir, assim você não precisa gastar dinheiro construindo a coisa errada. Muitas vezes (quase sempre) os usuários não tem certeza imediata sobre o que eles querem, outras vezes tem certeza do que querem e não do que precisam. Esses casos demandarão mais esforço do que parece ideal para descobrir o que os usuários do seu sistema realmente precisam. Porém, ainda assim, é mais barato do que construir o software errado, jogar tudo fora, e ter que refazer. Também é importante pensar em como construir o sistema antes de começar a construir o sistema. Você não quer gastar um monte de tempo e dinheiro entrando em becos sem saída, especialmente quando isto eleva os seus custos.
Construir um sistema é como qualquer outro projeto que demanda pessoas e dinheiro. Se você vai construir uma casa, você faz desenhos da arquitetura e da planta antes sair martelando pregos. Você terá sua planta revisada e aprovada antes de começar a misturar e derramar concreto. Ter um plano técnico para o desenvolvimento de software é tão importante quanto para construir uma casa. Você não começa decorando a árvore de natal enquanto você não a tiver montado. Você não começa um churrasco sem ascender a churrasqueira. Você não faz uma viagem longa de tanque vazio. Você não se veste antes de tomar banho, e não coloca as meias após colocar o tênis. Quando se trata de desenvolvimento de software, as coisas devem ser feitas na ordem certa também, não há porque ser diferente. Programadores estão no topo da cadeia alimentar do desenvolvimento de software. O arquiteto consome os requisitos, o designer de software (não o designer de tela) consome a arquitetura, e o desenvolvedor consome o design. Compare a cadeia alimentar do desenvolvimento de software com uma cadeia alimentar real. No mundo real, gaivotas comem salmão fresco. É nutritivo para elas porque salmão come outros peixes menores, e esses comem insetos do mar. O resultado é uma cadeia alimentar saudável. Em programação, se você tiver comida saudável em cada estágio da cadeia, o resultado é código saudável sendo produzido por programadores felizes. Em um ambiente poluido, os insetos do mar nadaram em lixo nuclear, os peixes menores foram contaminados por metais pesados, e os salmões que comeram esses peixes nadaram em águas poulidas por vazamentos de petroleo. As gaivotas são, para o azar delas, o fim da cadeia alimentar, então elas não só comem o petroleo dos salmões. Elas também consomem os metais pesados dos peixes menores e o lixo nuclear dos insetos marinhos. Em programação, se os requisitos estão contaminados, eles contaminam a arquitetura, a arquitetura por sua vez contamina a construção. Isso leva a programadores mal- humorados e desnutridos e um software radioativo crivado com defeitos. Se você está planejando um projeto com requisitos que provavelmente mudarão, você precisará identificar, antes de começar a desenvolver, os requísitos e elementos de arquitetura críticos que influenciarão em cada elemento do software. Um construtor que está desenvolvendo um projeto de casa não precisa saber cada detalhe da casa antes de começar a construir a primeira casa. Mas o construtor irá olhar o terreno, mapear a elétrica e a hidráulica da csa, dentre outras coisas criticas. Se o construtor não se preparar bem, a construção provavelmente atrasará quando o encanamento de esgoto precisar passar por baixo da casa que já foi construida.
Estudiosos, nos ultimos 25 anos, provaran conclusivamente que vale a pena pagar para fazer as coisas da forma certa na primeira vez. Alterações desnecessárias são caras. Pesquisadores da Hewlett-Packard, IBM, Hughes Aircraft, TRW, e outras organizações concluiram que eliminar um erro no inicio da construção permite que o retrabalho seja feito de 10 a 100 vezes mais barato do que quando o problema é encontrado na ultima parte do processo durante os testes ou após a release. Fontes: Fagan 1976; Humphrey, Synder, and Willis 1991; Leffingwell 1997; Willis et al. 1998; Grady 1999; Shull et al. 2002; Boehm and Turner 2004). Em geral, o principio é encontrar o erro o mais próximo possível do momento em que ele foi introduzido. Quanto mais o defeito estiver na cadeia alimentar do software, mais dano ele causará em toda a cadeia. Uma vez que os requisitos são o primeiro elo da cadeia, defeitos de requisitos tem potencial para estar por mais tempo no sistema e para serem mais caros. Quanto mais no inicio da cadeia o problema for inserido, mais este defeito tende a se propagar pelo restante da cadeia. Isso também torna defeitos inseridos antes mais caros. A maioria dos projetos tentam fazer a detecção de problemas somente no final do projeto, isso significa que debugar, identificar e fazer retrabalho para corrigir tomam mais de 50% do tempo gasto em um projeto saudável de desenvolvimento de software. Fontes: (Mills 1983; Boehm 1987; Cooper and Mullen 1993; Fishman 1996; Haley 1996; Wheeler, Brykczynski, e Meeson 1996; Jones 1998; Shull et al. 2002; Wiegers 2002). Várias empresas concluiram que simplesmente focar na correção de defeitos mais cedo, e de forma continua no decorrer do projeto, ao invés de apenas efetuar testes ao fim pode cortar os custos de desenvolvimento e reuniões pela metade ou mais (fonte: McConnell 2004). Isto é um incentivo saudável para encontrar e consertar os problemas o mais cedo que você puder.
Quando você pensar que seu chefe entende a importância de trabalhar com pré- requisitos antes de ir para a etapa de desenvolvimento, tente o teste abaixo para ter certeza. Quais desses pontos são profecias auto realizáveis?
É melhor começarmos a escrever o código imediatamente porque nós teremos um monte de debug e correções a fazer.
Nós não planejamos muito tempo para testar porque não iremos encontrar muitos defeitos.
Nós investigamos os requisitos e o design tão exaustivamente que eu não consigo pensar em maiores problemas que teremos durante a escrita de código ou debug.