Salve pessoal!

Este foi meu primeiro artigo para o iMasters. Bom, isso não é 100% verdade, pois o escrevi com a ajuda de nove amigos meus. Todos profissionais conhecidos do mundo PHP e de diversos estados do país. Apesar do título, a maioria das dicas aplicam-se a qualquer linguagem e/ ou tecnologia.

A idéia partiu em uma conversa, como sempre bem descontraída, com o Elton Minetto, que é quem nos proporciona a primeira dica:

Estude e pratique, por Elton Minetto

[@eminetto]

Fazer uma universidade, ou não, é uma discussão enorme. Eu fiz e recomendo. Aprendi diversos assuntos interessantes e importantes que uso até hoje. Mas independentemente de você fazer, ou não, um curso universitário, estudar é obrigatório. Leia livros técnicos, participe de cursos, seminários etc. Tecnologias surgem todos os dias, se você não prestar atenção ficará ultrapassado.

Um esportista pratica diariamente seu esporte. Nós podemos fazer o mesmo. Programe e teste sempre que puder. Pequenos trechos de códigos, pequenos exemplos e problemas de lógica. Além de ser divertido, mantém a sua mente “afiada”.

Repasse seu conhecimento, por Adler Medrado

[@adlermedrado]

Como foi que você aprendeu a fazer seu primeiro Hello World? Provavelmente por meio de um livro, um texto em um site/ blog, ou alguém direta e pessoalmente te ensinou. Raramente nós aprendemos sem a ajuda direta, ou indireta, de alguma pessoa que usou seu tempo para compartilhar o conhecimento dela. Então, que tal começar a compartilhar também?

Crie um blog (e escreva nele, claro!), ministre palestras e/ ou minicursos em eventos, participe de dojos, ou escreva um artigo para alguma revista. É válido também mandar e-mail com dicas para seus colegas de trabalho e dar aula em escolas de informática. Estas são apenas algumas sugestões, e certamente existem outras maneiras de colaborar.

Após decidir como repassar seu conhecimento, você pode perguntar a si mesmo: “Mas em que eu posso ajudar? A Internet já possui muito material disponível”. Esta questão certamente passa pela cabeça de muitos de, mas você terá a agradável experiência de saber que, um dia, aquele simples post seu ajudou alguma pessoa, de alguma maneira e em algum momento. E eu te digo: você ficará sabendo disso!

Não espere o futuro, faça agora! por Bruno PorKaria

[@porkaria]

Todo mundo tem uma ideia, mas nem todos tem a coragem de tirá-la do papel. Coragem não é talento, muito menos “dom divino”. É, simplesmente, algo que precisa ser constantemente treinado. Você não é o melhor programador do mundo, o seu código quase sempre não vai ser a melhor maneira de resolver aquele problema, mas você não precisa esperar que alguém resolva o seu problema.

Crie agora a sua conta na PEAR, no github, ou sourceforge, dentre tantos outros e compartilhe seu código. Tenha coragem de aprender, não tenha medo de errar e faça agora o que você espera para o seu futuro.

Não seja tradicional, por Marcelio Leal

[@marcelioleal]

Os conceitos e a arquitetura são mais importantes do que os padrões de projeto, os recursos de linguagem e os frameworks. Utilize ao máximo a flexibilidade e todo o potencial que o PHP proporciona. Quando você for utilizar PHP, avalie o custo do uso de padrões de outras linguagens, padrões de projeto, e outros tipos de padrões. A utilização indiscriminada pode proporcionar perda de flexibilidade, extensibilidade e outras características boas do PHP.

Por exemplo, na implementação do Zend Framework 1.0 (famoso framework PHP) foram utilizados alguns padrões de projeto que na sua versão 2.0 estão sendo retirados, por não proporcionarem as melhorias que, em teoria, os padrões proporcionariam.

Adicionalmente, escolha soluções que te proporcionem a flexibilidade e o uso das principais características do PHP. O Zend Framework e o Doctrine são dois bons exemplos disso, já que te permitem utilizar parte dos seus componentes e, ainda assim, te subsidiam para uma boa solução.

Outro ponto importante, é que você deve conhecer pontos que o PHP proporciona para soluções mais simples, como os métodos mágicos, reflection, reescrita de funções padrão (como a de erros) e o próprio PHP embeded HTML. Isto significa que vai se tornar um desenvolvedor que sabe tomar decisões apropriadas em PHP.

Nunca esqueça que a sua arquitetura é mais importante do que o Framework que você vai usar. Você tem o direito de adequar a sua arquitetura e escolher os componentes e frameworks que precisar para resolver o seu problema da melhor forma possível. Assim, foque na simplicidade, e conheças as possibilidades do PHP.

Organize e programe seu código de forma coerente, por Guilherme Blanco

[@guilhermeblanco]

Tomei por base a dica do Marcelio, que pode ser expandida dedilhando um pouco mais o assunto. Diariamente sofremos com códigos bizarros, que nos fazem questionar o conhecimento das pessoas. Por mais que haja conhecimento, também é necessário planejamento e organização quando se programa. Felizmente, a área de programação é uma das poucas onde perfeccionismo não é prejudicial à saúde do projeto, pelo contrário, na maioria das vezes não só é benéfico, como também possibilita ter uma maior visibilidade sobre o escopo da aplicação.

Antes mesmo de sentar-se e sair programando, pense na sua estrutura, faça o mínimo de planejamento. Até futebol precisa de planejamento e estratégia de jogo. Na programação, a estratégia fica à critério do scrum master e project leader. Mas o planejamento fica a critério do arquiteto e dos desenvolvedores. Olhe ao seu redor: seu time tem um arquiteto? Na maioria dos casos, o “dito” arquiteto trabalha ao seu lado, mas trabalha da mesma forma que você e o seu cargo é apenas para justificar um salário melhor que o seu.

A responsabilidade dele deveria ser de auxiliá-lo no planejamento do seu código. De qualquer forma, para não importunar o arquiteto, você também precisa ter o mínimo de organização. O UML, nesse caso, ajuda muito. O diagrama de pacotes é um bom começo, pois ilustra a dependência entre eles. Dependências cíclicas (A depende de B e B depende de A) devem ser evitadas ao máximo, bem como a dependência de classes de pacotes mais intrínsecos à uma classe de um pacote mais externo. Sempre que possível, pare para pensar sobre nomenclatura de classes e métodos. Evite nomeá-los de forma aleatória; siga um padrão. Vamos usar um exemplo na prática:

Uma classe TokenService contendo os métodos generateToken(Credential $credential) e getCredentialByToken(Token $token). Apesar de inofensivos, os métodos esboçam claramente os seus respectivos propósitos. Mas ao mesmo tempo, ferem a semântica da classe no quesito da correlação entre eles. Isso porque a semântica cíclica dos métodos A -> B e B -> A não foi mantida. Se o desenvolvedor tivesse pensado trinta segundos a respeito disso, a nomenclatura poderia ser outra. Expor um ciclo é simples, mas, especialmente nesta situação, é necessário também expor o retorno esperado. Uma ideia seria nomeá-los convertCredentialToToken(Credential $credential) e convertTokenToCredential(Token $token). Não doeu nada e ficou bem mais interessante, né?

Outro ponto bastante interessante na nomenclatura de classes é a insistente presença de sufixos ou prefixos que caracterizam o objeto, exemplo: AbstractDriver, EncoderInterface, etc. Saliento que exceto justificativas extremamente plausíveis (algumas demoram até horas para serem quebradas ou afirmadas), estes modificadores não deveriam existir. Talvez o argumento mais difícil a ser quebrado é o fato de que mudando a responsabilidade de uma classe/ interface, por exemplo de “interface DriverInterface” para uma classe abstrata “abstract class AbstractDriver”, o esforço de refatoração deveria ser o mínimo possível.

Como é possível ver, o esforço não foi simplificado com a mudança, e inclusive pode quebrar o código estável (exemplo: instanceof). Baseado nisso, confie sempre em um nome estável e siga em frente. Os nossos exemplos iniciais, Driver e Encoder, seriam bons candidatos à nomes de interfaces.

Uma proposta recente que se mostrou muito interessante na codificação de classes foi o Object Calisthenics. O conceito está disponível no livro The ThoughtWorks Anthology. Para ser mais exato, está no capítulo 6, onde Jeff Bay menciona alguns passos simples, mas que mudam completamente a sua forma de programar, se segui-los à risca:

  1. Não abrevie palavras e/ ou variáveis;
  2. Um nível de indentação por método;
  3. Não utilize a palavra-chave ELSE;
  4. Sem métodos estáticos que não façam parte de métodos fábrica (Factory methods);
  5. Mantenha suas entidades/ classes o menor possível;
  6. Nenhuma classe com mais de duas instâncias de objetos.

Nesse artigo é possível ler mais regras – são onze no total, mas algumas não são aplicáveis ao mundo PHP (tais como encapsular tipos abstratos, coleções de primeira classe), mas seguindo apenas estas 6 regras, já é possível ter uma melhora significativa no seu código. Eu, particularmente, ainda incluo mais duas, não obrigatórias sob argumentos válidos (obrigatórias caso não tenham), que também auxiliam:

  1. Classes com no máximo 500 linhas e apenas 1 responsabilidade;
  2. Métodos com no máximo 50 linhas e apenas 1 responsabilidade.

É interessante ressaltar que adotando as seis regras de Jeff Bay, as duas que proponho se tornam bem naturais.

Transparência e conhecimento, por Er Galvão

[@galvao]

Admita o erro, procure soluções. Frases como “admitir o problema é 50% da solução” foram criadas por um motivo. Se o problema existe, admita, compartilhe com seus colegas, com seu gerente. Fingir que o problema não existe apenas aumenta a probabilidade de ele ser descoberto por pessoas de fora da empresa, arriscando o produto, a própria empresa e a sua reputação.

Além disso, não se contente com encontrar a solução. Bons profissionais não apenas solucionam problemas, mas entendem como solucioná-lo. Quanto mais difícil é o problema, mais conhecimento você obterá depois de solucioná-lo.

Abaixo da média, por Igor Ferghali

Pessoalmente, sou extremamente detalhista no quesito otimização. Não consigo me conformar em ter que circular uma montanha para chegar ao outro lado. Para economizar no túnel uma única vez (em tempo de construção), todos os usuários da estrada são forçados a gastar mais combustível (em tempo de execução). Dessa forma, quando eu estou escrevendo código, busco não sacrificar sequer um byte de memória, ou um ciclo de processamento, em prol do meu conforto como programador. É por isso que resisti às práticas modernas de programação, que adicionam camadas e mais camadas no produto final, com meus grandes blocos monolíticos de código.

Entretanto, essa busca desenfreada por performance não se sustenta, exceto talvez para um nicho restrito de aplicações como o kernel, sistemas embarcados de tempo real e outros. Para todos os outros casos, é preciso um bom trabalho de engenharia para balancear performance, manutenibilidade, legibilidade e todos os outros ades (não o suco) que nos perseguem.

Além disso, por muito tempo me senti bem servido com o meu conjunto próprio de bibliotecas (conhece mais alguém assim?). O fato é que eu descobri tarde demais que alguém já fazia o que eu fazia, e, diga-se de passagem, com mais elegância, e tinha chamado isso de framework.

Então, além de me render à orientação a objetos e aos padrões de projeto – relaxando a minha sede por performance -, eu também tinha que passar a observar, a aprender e a aproveitar o ecossistema à minha volta – evitando reinventar a roda. Para tanto, eu haveria de enfrentar um pequeno detalhe antes…

Recentemente, li um texto sobre a superioridade ilusória, de Derek Sivers, que me causou um certo efeito inception. Ele pontuou que, em determinados grupos de pessoas, a grande maioria se sente superior à média, o que eu diria que é no mínimo matematicamente incoerente. Porém, a grande questão não é resolver a inequação na qual os egos não são incógnitas, mas enxergar como esse comportamento se curva em um paradoxo de Escher – assim como as ruas nos sonhos de Ariadne.

Se eu assumo que sou acima da média, é porque tenho algo a mais que a maioria não tem. À medida em que se observa que isso também é verdade para o resto dos indivíduos, todos passam a se aproximar da média, o que acaba por contradizer nossa premissa inicial. Foi nesse ponto paradoxal que eu me lembrei do filme – e de como ele me deixou confuso por alguns instantes.

Foi então que, assim como Sivers, eu passei a assumir que sou abaixo da média. Isso significa que estou assumindo que as minhas palestras são ruins, que sempre há uma solução melhor do que a minha, que o JavaScript tem muito a me ensinar (como esse do while false – que a princípio pode equivocadamente parecer uma estupidez) e que a engenharia de software e o gerenciamento de projetos têm as suas vantagens (quem diria). E, por que não, também a governança de TI (por favor, me perdoem).

Contudo, ser abaixo da média não significa entregar soluções abaixo da média. Ao contrário, significa enxergar o mundo com a inocência de um aprendiz. Significa reconhecer grande potencial nas coisas simples ou aparentemente inúteis. Significa reconhecer que todos aspectos do seu projeto são igualmente importantes: código, algoritmo, funcionalidades e documentação, apenas para citar alguns. E, por fim, significa reconhecer que há sempre algo a se melhorar – mantra que os japoneses enfeitaram e apelidaram de processo de melhoria contínua.

Ser abaixo da média era a resposta que eu precisava para mudar meus paradigmas e minha carreira.

Buscando soluções para dar mais fôlego aos seus servidores, por Carlos Ferrari

[@caferrari]

Nos últimos sete anos, estou trabalhando com contrato para o Governo do Tocantins e nesse tempo aprendi algumas coisas básicas sobre o funcionalismo público:

  1. Os gestores preferem gastar 10 milhões em publicidade do que 100 mil em infraestrutura de TI;
  2. Contratar gente? Sem chance. Provavelmente você vai assumir uns cinco cargos e vai ter que estudar e aprender o que for necessário para manter tudo funcionando. Bom para você!
  3. Enquanto o sistema está rodando, o povo está feliz, se sai do ar, a culpa é sua, independentemente se os seus sites tiveram 10.000% de aumento de tráfego nos últimos anos e aquele Pentium 4 com 1GiB de RAM tiver que servir mais de 1 milhão de pageviews por dia.

Com todos esses detalhes, nos últimos anos, boa parte do meu trabalho foi voltado para performance. Tínhamos que manter nossos sites rodando nesse Pentium 4 (nosso departamento é responsável por desenvolver e hospedar sites e hotsites para órgãos que não têm estrutura para desenvolver por conta própria), com isso, passamos por várias melhorias na infraestrutura dos sites no decorrer do tempo.

Em 2008, começamos a ter problemas de performance. Nossa base de dados não estava aguentando a quantidade de acessos, por isso, começamos a estudar sobre caching de dados e sobre uma forma eficiente de controlar isso. Decidimos então criar um webservice rest que ficasse responsável por servir os dados para os sites. Foi desenvolvida uma classe para ser o cliente desse webservice, e essa classe ainda fazia cache dos dados em disco. Nosso problema com a base de dados foi resolvido e, com isso, também aumentamos a segurança, pois todas as consultas passariam por ali.

Lá pelo final de 2009, os acessos cresceram mais e começamos a ter problemas. Dessa vez, era o apache que não estava dando conta do recado. Depois de pesquisar um pouco, achei um webserver que estava começando a dar as caras, o Nginx. Enquanto o apache começava a dar problema com 300 pessoas conectadas, o Nginx com o PHP via fastcgi não sofria degradação nenhuma. Ele funcionou tão bem que aumentamos o keep-alive do servidor para 70 segundos, e a experiência de navegação dos nossos sites melhorou consideravelmente.

Em 2010, tivemos que construir uma nova versão do nosso CMS, de modo que os dados ficassem centralizados. Nesse estágio, decidimos dedicar bastante tempo e modelar uma base de dados o mais otimizada possível e mudamos nosso sistema de cache para o memcached. Logo em seguida, conhecemos duas coisas que estavam surgindo para o PHP: a extensão PHP-APC e o modulo PHP-FPM de fastcgi. Com isso, além de melhorar ainda mais a velocidade dos sites, reduzimos muito o uso de processamento.

Em paralelo a tudo isso, em 2008, após ver algumas opções de frameworks do mercado, decidimos criar um framework nosso. Um que seguisse os princípios KISS e DRY, consumisse poucos recursos, fosse extremamente veloz e melhorasse nossa produtividade.

Com tudo isso, tiramos todo dia mais um pouco de água da pedra por ter que suportar o crescimento de visitas e sites hospedados, temos 49 sites hoje rodando em uma máquina (emprestada!) um pouco melhor: uma VM dual core Xeon de 2Ghz com 1GiB de RAM. Nosso consumo de processamento em horários de pico gira em torno de 15%, com uma média de 1.2 milhão de pageviews por dia. Apesar das dificuldades, os problemas encontrados aqui me permitiram aprender muito. Se eu estivesse em uma empresa com mais “recursos”, dificilmente otimização seria um requisito tão importante.

Tire a sua certificação e se diferencie no mercado, por Sandro Souza

[@xkurts]

O Elton Luís Minetto já falou sobre como pode ser interessante se cursar uma faculdade, você vai poder agregar uma série de conhecimentos importantes para sua carreira, porém uma certificação específica (seja de PHP, frameworks, gerenciamento de projetos etc) pode ser tão importante quanto um diploma de ensino superior e irá te garantir uma diferenciação ainda maior de outros profissionais no mercado de TI.

Já não é mais tão incomum hoje em dia vermos divulgações de vagas para programadores em que as empresas exigem uma determinada certificação, e em PHP temos a certificação da Zend Certified Engineer (ZCE). Mais informações: http://www.zend.com/en/services/certification.

Na Internet, você ainda encontra testes preparatórios e em diversas cidades há empresas especializadas na preparação para a certificação (procure na Internet ou se informe no de grupo de usuários PHP do seu estado). Há ainda livros específicos para quem quer se preparar para tirar a certificação PHP, como por exemplo: “php|architect’s Zend PHP 5 Certification Study Guide” (Davey Shafik e Ben Ramsey); “The Zend PHP Certification Practice Test Book – Practice Questions for the Zend Certified Engineer Exam” (John Coggeshall e Marco Tabini).

Não se limite ao óbvio, por eu mesmo :P

Ao desenvolver, sempre nos deparamos com tomadas de decisão que podem ser cruciais ao projeto. Geralmente, pendemos ao famoso “vamos fazer desse jeito porque é o que todo mundo faz”, em outras palavras, vamos pelo caminho mais óbvio, mais comum. E isso é ruim? Em termos gerais, não, você provavelmente vai ao encontro da decisão tomada por outros na mesma situação, que deu muito certo e não precisa ser mudada.

Mas pense de outra maneira: você perdeu uma oportunidade única de evoluir um conceito.

Vamos a um exemplo de uma realidade recente: você provavelmente já se viu na decisão de como fazer uma simples validação de formulário; a maioria dos frameworks e bibliotecas já implementa um validador, e quase sempre são implementados do mesmo jeito; provavelmente você penderia por usar algo já existente, ou desenvolver o seu baseado em algum já bem consolidado. Um amigo pensou: “acho que isso poderia ser feito de uma forma mais reutilizável…” – E assim nasceu o projeto Respect\Validation. Realiza basicamente a mesma função dos validadores de mercado, porém numa visão completamente diferente, e mais fácil, que as implementações já existentes.

Antes que alguém pense: “Você está incentivando todos a reinventar a roda, então?” – Não! Assim como a própria roda evoluiu, nossos conceitos também podem, assim como nossos validadores, camadas de abstração, componentes de configuração etc… O princípio de “Não reinventar a roda” se aplica sempre; o problema é quando a roda que estamos usando não nos atende mais. Ou até atende, mas, com uma roda melhor, podemos ganhar em performance, consumo, durabilidade e o principal: satisfação.

Bom, pessoal, espero que vocês tenham aproveitado essas dicas que eu e o Elton reunimos ao longo de 2011 com alguns de nossos amigos de profissão.