Programação

S.O.L.I.D – Coisas que todo programador deveria saber

Thiago Burgos Agilidade, Programação, Tudo , , , ,

Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

  • S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

    Arquitetando…
  • O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
  • L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
  • I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
  • D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Thiago Burgos #TGIF, Agilidade, BdB Recomenda, Embedded, Empreendedorismo, Programação, Testes de Sw, Tudo, UX, Vagas

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Vídeos – Google Test Automation Conference 2013

José Carréra Programação, Testes de Sw , , , , , ,

Nos dias 23 e 24 de Abril aconteceu mais uma edição do GTAC – Google Test Automation Conference. Dessa vez também acessível via streaming. Os vídeos das 16 horas de palestras também já estão disponíveis no YouTube, os quais compartilho com vocês no decorrer do post. Ainda não tive tempo de assistir a todas as palestras, mas tenho certeza que o nível do conteúdo é excelente, pois já assisti a vários vídeos dos anos anteriores.

As palestras estão divididas em dois vídeos, referentes a cada um dos dias do evento, porém a partir da agenda você pode saltar para a palestra que mais lhe interessar. Já assisti as 4 primeiras palestras do dia 1 e gostei bastante das duas primeiras.

Segue a lista das palestras e os vídeos.

Dia 1:

Duração Palestrante Empresa Tema
00:15:00 Tony Voellm Google Opening
00:45:00 Ari Shamash Google Evolution from Quality Assurance to Test Engineering
00:45:00 James Waldrop Twitter Testing Systems at Scale @Twitter
00:30:00 Break
00:45:00 David Burns and Malini Das Mozilla How Do You Test a Mobile OS?
01:00:00 Lunch
00:45:00 Igor Dorovskikh and Kaustubh Gawande Expedia Mobile Automation in Continuous Delivery Pipeline
00:15:00 David Röthlisberger YouView Automated Set-Top Box Testing with GStreamer and OpenCV
00:15:00 Ken Kania Google Webdriver for Chrome
00:15:00 Vojta Jina Google Karma – Test Runner for JavaScript
00:15:00 Patrik Höglund Google Automated Video Quality Measurements
00:15:00 Minal Mishra Netflix When Bad Things Happen to Good Applications…
00:30:00 Break
00:45:00 Tao Xie North Carolina State University Testing for Educational Gaming and Educational Gaming for Testing
00:45:00 Simon Stewart Facebook How Facebook Tests Facebook on Android
00:15:00

Dia 2:

Duração Palestrante Empresa Tema
00:15:00 Opening
00:45:00 Mark Trostler Google Testable JavaScript – Architecting Your Application for Testability
00:45:00 Thomas Knych, Stefan Ramsauer, Valera Zakharov Google Breaking the Matrix – Android Testing at Scale
00:30:00 Break
00:45:00 Guang Zhu (朱光) and Adam Momtaz Google Android UI Automation
01:00:00 Lunch
00:45:00 Jonathan Lipps Sauce Labs Appium: Automation for Mobile Apps
00:15:00 Eduardo Bravo Google Building Scalable Mobile Test Infrastructure for Google+ Mobile
00:15:00 Valera Zakharov Google Espresso: Fresh Start to Android UI Testing
00:15:00 Michael Klepikov Google Web Performance Testing with WebDriver
00:15:00 Yvette Nameth, Brendan Dhein Google Continuous Maps Data Testing
00:15:00 Celal Ziftci, Vivek Ramavajjala University of California, San Diego Finding Culprits Automatically in Failing Builds – i.e. Who Broke the Build?
00:30:00 Break
00:45:00 Katerina Goseva-Popstojanova West Virginia University Empirical Investigation of Software Product Line Quality
00:30:00 Kostya Serebryany Google AddressSanitizer, ThreadSanitizer and MemorySanitizer — Dynamic Testing Tools for C++.
00:30:00 Claudio Criscione Google Drinking the Ocean – Finding XSS at Google Scale
00:05:00

Agilidade é Ritmo!

Thiago Burgos Agilidade, Programação, Tudo ,

Assitir palestras de alguns gurus é sempre interessante! Mesmo quando a palestra não está legal, em algum momento você pode escutar alguma frase ou alguma explicação que pode mudar sua vida. Eu diria que é mais ou menos como um atacante de futebol que é artilheiro, mas está jogando uma péssima partida, mas o técnico o deixa em campo pois a qualquer momento ele pode fazer um gol!

Dito isto, eu estava em uma longa palestra com um artilheiro, mas a palestra não estava tão interessante. Mas em determinado momento, falando sobre agilidade,  ele disse: “Agile is about rhythm!” Essa frase então chamou minha atenção e fiquei atento a explicação do que isso significava, e fez sentido pra mim.

Se você participa de um projeto que tem um determinado ritmo como por exemplo entregar um release do software a cada 6 meses, você tem “muito tempo” para pensar/fazer/detalhar requisitos, “muito tempo” pra implementar e por aí vai. É óbvio que você vai terminar fazendo mais do que o necessário para o momento e talvez não consiga finalizar tudo, além de colher o feedback muito tarde (em 6 meses tudo pode mudar).

No entanto, se você tem um ritmo de fazer um release por mês, você tem menos tempo pra focar em vários requisitos, por isso você só seleciona alguns deles (os mais importantes do ponto de visto do cliente), você nao tem tanto tempo pra discutir requisitos em um nível de detalhes muito aprofundado (a  não ser que realmente seja preciso) e você não tem tempo para perder tempo com reuniões sem sentido e etc, então você foca em desenvolver aquilo que tem pra ser desenvolvido de forma a receber feedback o mais rápido possível e mudar o mais rápido possível (antes que o custo da mudança seja muito caro ou inviável).

Ah, acho que tem um cenário pior do que os dois que apresentei, que é o caso de você não ter ritmo nenhum!

E você o que acha? Qual o ritmo que faz mais sentido para você ou para sua empresa?

BdB Recomenda – Aprenda a programar online e sem custos parte II

José Carréra BdB Recomenda, Programação , , , , , , ,

Algum tempo atrás, trouxemos no BdB Recomenda o projeto chamado Codeacademy – Learn to Code, uma maneira extremamente interativa de aprender a programar, através da prática direta da programação.

O post de hoje, faz uma nova indicação, que parece ser uma alternativa ainda melhor para o aprendizado online e sem custos, graças a excelente qualidade do material didático auxiliado pela boa organização das lições no site.

OUdacity foi fundado por três especialistas em robótica, que acreditavam que muito do valor de suas aulas na universidade poderiam ser disponibilizados online e a um custo muito baixo.

Os fundadores acreditam que o ensino universitário pode ser de alta qualidade e de baixo custo. Usando a economia da Internet, eles conectam professores de altíssimo nível a milhares de estudantes em quase todos os países da Terra.

O custo para começar o aprendizado é ZERO. A quantidade de cursos oferecidos já é considerável, entre eles estão disponíveis:

– Introdução a programação com Python

– Software Debugging

– Desenvolvimento Web – Construindo um Blog

– Introdução ao Teste de Software

E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!

O fator ônibus *

Thiago Burgos Agilidade, Programação, Testes de Sw, Tudo ,

O post de hoje é simples e curto mas apresenta um conceito que é muito importante no dia-a-dia das empresas e dos projetos (principalmente de software, mas não necessariamente se limita a software).

Já participou de algum projeto onde uma ou talvez duas pessoas possuiam todo o conhecimento sobre o projeto? Acho que não é muito difícil isso acontecer, eu mesmo já participei de alguns. Alguns onde outra pessoa tinha todo o conhecimento acerca de um projeto, e outros onde eu mesmo tinha o conhecimento “concentrado” em mim (não porque eu queria, mas por conta das circunstâncias).

O fator ônibus * (do inglês bus factor), significa a quantidade de pessoas, que se forem atropeladas por um ônibus, farão o projeto desandar, ou até mesmo inviabilizar a continuidade do projeto. É óbvio que quanto maior essa medida melhor, pois dificilmente 10 pessoas são atropeladas por um ônibus no mesmo momento.

Moral da história: Se o seu projeto tem o fator ônibus igual a 1 ou 2, você corre sérios perigos! Então corra atrás, compartilhe o conhecimento, treine as pessoas, sugue o que puder sugar dos que tem mais conhecimentos, pergunte, leia, converse e se informe para o bem do seu projeto e da sua equipe!

* Observação: Vale a pena lembrar que o fator ônibus não significa ser literalmente atropelado por um ônibus. Ser atropelado por um ônibus pode significar: Algum membro da equipe conseguir um outro emprego, alguém sair de licença maternidade, alguém decide mudar o estilo de vida, alguém pedir demissão, alguém simplesmente sair de férias por 1 mês (parece absurdo né?), ou realmente alguém for atropelado mesmo por um ônibus 😛

Já conhece o eXtreme Go Horse Programming?

Marília Balbé Agilidade, Programação, Testes de Sw, Tudo

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH.

XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes.

Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script maluco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro.

O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe

É melhor focar no problema? ou na solução?

Thiago Burgos Agilidade, Programação, Tudo
Cabra-cega – Imagem Retirada de http://fadadacaixinhademusica.blogspot.de/

Cabra-cega é uma brincadeira de criança onde alguém coloca uma venda nos olhos e fica com uma vara na mão para tentar acertar um vaso de barro (cheio de doces e gostosuras) e quebrá-lo, dessa forma não só você ganha os doces, quanto todos ao seu redor tb correm para os doces e assim todos saem ganhando! Não sei no restante do Brasil, mas pelo menos em Recife essa é uma brincadeira bem comum. O detalhe dessa brincadeira é que todos os outros ao seu redor ficam dando dicas apra vocês chegar mais perto, e eventualmente acertar o vaso.

Trazendo isso para nossa realidade de TI, um ponto que venho percebendo com uma certa frequência  é que geralmente estamos fechando projetos e contratos onde nosso cliente chega até nós com uma “solução” para o problema dele, e nós geralmente vamos direto atacar essa pseudo-solução! Isso acontece mais frequentemente em casos onde o cliente tem um certo conhecimento de TI, de desenvolvimento de software, então ele já chega com a solução bolada na sua cabeça! E como cada vez mais temos gente que entende [um pouco que seja] de TI, temos essa situação acontecendo cada vez mais.

Me sinto um pouco jogando cabra-cega. Estamos lá, escutando as dicas e as direções dos outros, mas não sabemos exatamente ONDE está o problema! Estamos com uma venda nos olhos tentando caminhar na direção que os outros estão gritando! E eis que chega o grande conselho desse post (que até parece um pouco óbvio):

Tire a venda dos olhos!!

Faça isso, por favor! Procure entender sempre o problema que está por trás de uma solução proposta, entenda o porquê por trás daquilo e procure identificar outras possíveis saídas para aquele problema. Talvez a solução proposta inicialmente pelo cliente seja realmente a melhor, mas talvez seja a pior também. E você só vai saber se tirar a venda dos olhos! TI é pensar! Muitas vezes somos pagos não para implementar algo para o cliente, mas para PENSAR na situação dele e identificar saídas viáveis!

Vale salientar que isso se aplica a diversos contextos dentro do desenvolvimento de projetos, e ainda mais, se aplica a diversas outras áres além de TI!

Cargo cult, eXtreme go horse e afins

Renato Molina Agilidade, Programação, Tudo , , ,

Depois de alguns anos escrevendo código, e também, observando códigos de outras pessoas, meus códigos antigos e código legado percebi alguns comportamentos e padrões entre o aptidão e/ou tempo de experiência X design do código das pessoas.

Investigando esses padrões, consegui entender melhor os “porquês” da incidência, em projetos grandes e bem financiados, de fenômenos como Cargo cult, eXtreme go horse, programação orientada a gambiarra e afins.

Contextualizando – Cargo Cult, descrito por Steven C. McConnell no livro Code Complete, é o fenômeno cultural observado em tribos indígenas/aborígenes, durante a segunda guerra mundial, que envolviam impactos entre duas civilizações, sendo uma moderna em aspectos tecnológicos e outra primitiva. Durante a guerra, soldados americanos necessitavam pousar em ilhas desertas para recarregar combustíveis ou armar mísseis, entretanto muitas dessas ilhas visitadas eram habitadas por esses povos. Ao ocorrer o choque das civilizações, os primitivos imaginavam que os soldados, com todo seu aparato, fossem deuses. Depois da partida da civilização moderna, os indígenas costumavam fazer rituais em determinados períodos do ano com o intuito de invocar os supostos deuses soldados, mudando assim o comportamento cultural/religioso do local.

Ao trazemos esse conceito para computação temos situações clássicas que vivemos no nosso dia a dia, talvez a mais popular seja : Ao perguntar a um desenvolvedor/gerente/engenheiro: – Para que serve esse pedaço de código? Ele te responde: – Não sei, mas não mexe aí! Pode parar de funcionar! Em outras palavras o desenvolvedor possui um tipo de ritual para realizar determinadas tarefas, como inserir código legado, bibliotecas, classes que não necessariamente são úteis para a implementação do mesmo, acarretando a incompreensão sobre o sistema de forma geral.

Para falar de eXtreme go horse temos que esquecer de qualquer boa prática, Scrum, Kanbam, Pair Programming ou qualquer coisa que lembre engenharia de software, isto é, se focar em escrever código e vencer o prazo. Infelizmente é uma realidade triste do mercado, que muitas vezes pode indicar falta de comprometimento do time e falta de alinhamento de interesses entre equipe/empresa ou má gestão do líder.

A verdade é que o caminho para esses cenários(caóticos) são convergentes podendo ser resumidos em falta de maturidade da parte do líder ou desenvolvedor, insegurança, pressão, contratos com prazos irreais, falta de comprometimento da equipe, etc. Muitas vezes esses motivos também podem acarretar um efeito dominó, piorando a situação exponencialmente.

Claro, podemos determinar inúmeras hipóteses para a solução do problema de desenvolvimento de software, entretanto, é fato que a solução está bem longe de determinar metologias rígidas ou mudar conceitos das mesmas. Temos que ir além, precisamos mudar conceitos, quebrar paradigmas, criar um time com determinação e com aptidão, mensurar e explorar potenciais, trabalhar com dificuldades, amadurecer a equipe e acima de tudo cair na real.

BdB Recomenda – Aprenda a programar online e sem custos

José Carréra BdB Recomenda, Programação , , , , , , , , , ,

O BdB Recomenda de hoje apresenta um projeto muito interessante, chamado Codeacademy – Learn to Code. O projeto criado a partir das frustrantes experiências enfrentadas por Zach Sims e Ryan Bubinski. Cansados de vídeos e tutorias pouco eficientes, eles criaram o Codeacademy, como uma maneira extremamente interativa de aprender a programar, através da prática direta da programação.

Codeacademy

Para começar o aprendizado basta se cadastrar no site (pode utilizar a própria conta do facebook) e começar a realizar os exercícios. Os exercícios são conduzidos de maneira gradual, apresentando os conceitos fundamentais para aprender a programar de maneira prática, além disso, o ambiente possui um fórum de ajuda bastante participativo e dicas para ajudar na resolução dos problemas.

Code Year - 2012

O projeto é audacioso e deseja ensinar programação a pessoas de diferentes áreas de atuação. Segundo o próprio Zach “As pessoas têm um desejo genuíno de compreender o mundo que vivemos. Eles não querem apenas usar a Web; Eles querem entender como ela funciona.”

O custo para começar o aprendizado é ZERO. Atualmente estão disponíveis cursos de JavaScript e HTML.

E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!