[Resolvido] 10 dicas profissionais do mundo PHP - Parte 02

[RSS iMasters 5]

Olá, pessoal. No artigo anterior conferimos as dicas de profissionais de Santa Catarina, Distrito Federal, Mato Grosso do Sul, Pará e até de quem nem está mais no país. Agora, seguem as últimas cinco dicas do Rio Grande do Sul, Rio de Janeiro, Tocantins, Minas Gerais e a minha contribuição.

 

6 - Tranparência e conhecimento

Er Galvão (RS) [@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.

 

7 - Abaixo da média

Igor Ferghali (RJ)

 

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, manutenabilidade, 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.

 

8 - Buscando soluções para dar mais fôlego aos seus servidores

Carlos Ferrari (TO) [@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 o 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 maquina (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 media 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?, difícilmente otimização seria um requisito tão importante.

 

9 - Tire a sua certificação e se diferencie no mercado

Sandro J. S. Souza (MG) [@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 no preparamento 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).

 

10 - Não se limite ao óbvio

Este que vos escreve.

 

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 do ultimo ano com alguns de nossos amigos de profissão.

 

Em breve volto com novos artigos.

 

Abraço.

 

 

 

http://imasters.com.br/artigo/22973/php/10-dicas-profissionais-do-mundo-php-parte-02