Olá, pessoal! Este é meu primeiro artigo para o iMasters. Bom, isso não é 100% verdade, pois eu 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:

1. Estude e pratique

Elton Luís Minetto (SC) [@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 independente 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”.

2. Repasse seu conhecimento

Adler Medrado (DF) [@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 agrádavel 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!

3. Não espere o futuro, faça agora!

Bruno PorKaria (MS) [@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.

4. Não seja tradicional

Marcelio Leal (PA) [@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 possíbilidades do PHP.

5. Organize e programe seu código de forma coerente

Guilherme Blanco (Toronto – Canadá) [@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 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 idéia 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 seguí-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.

Acho que por hoje é só. Em breve vou trazer pra vocês outro artigo com as cinco dicas finais. Até a próxima!