Tive a excelente oportunidade de conhecê-lo em minha pós-graduação onde ele na condição de professor ministrou aulas de Java, padrões de projeto e algumas coisas a mais que ele trazia – WebServices, Sistemas distribuídos, … – para agregar ainda mais as aulas.

Recentemente, mandei-lhe um e-mail convidando-o à participar daquelas renomadas 9 perguntas que faço com algumas pessoas no blog. As respostas – e perguntas, claro – seguem:

1. Tudo começou…
Tudo começou quando minha mãe disse pra mim: “Meu filho, vou comprar um consórcio (olha como era difícil) de um computador”. “Legal mãe”, eu disse. “Pra que serve isso?”. Tinha eu 12 anos, numa era pré-internet. Quando chegou minha então 8a. série eu já havia decidido que ia trabalhar com computador. O quê exatamente ainda era incógnita.

2. Formado em Engenharia da Computação pelo ITA. Como foi o processo “pré-universidade” e sua relação com o mundo exterior após ingressar ?
No meu ano de vestibular (3o. ano) descobri o ITA. Vi (já pela internet, numa era pré-google) que era um lugar onde eu poderia ir para São Paulo, numa faculdade renomada, e que teria um apoio de moradia e alimentação. Coisa que uma USP não me daria. Sou do Norte, de Belém do Pará. Era preciso um apoio pra que eu conseguisse isso.
Passei, e quando cheguei aqui percebi o tamanho da briga que eu tinha saído (não tinha noção da briga que era o vestibular do ITA) e da briga que eu tinha entrado (o ITA mesmo). Muito mudou minha forma de ver o mundo, muito estudo mas principalmente as amizades que o clima do alojamento do ITA traz. E, aos retornos pra casa durante as férias, a saudade e o carinho de quem fica longe.

3. O ITA é uma instituição de renome no país. Como um ex-aluno, de que forma você avalia o ensino, ambiente e convivência na universidade e, na sua opinião, qual o diferencial do ITA em relação as demais ?
O diferencial do ITA são os alunos. Mas, se não fosse a cobrança severa dos professores com as provas, faltas, as regras do ITA (como não poder repetir mais de uma vez o ano, de ser reprovado em no máximo 5 matérias durante o curso inteiro) e a disciplina consciente (nós no ITA abominamos cola. Quem cola é expulso de lá pelos próprios alunos com aval dos professores. Assim conseguimos fazer prova em casa, por exemplo. E sem consulta!) forçam os alunos a se organizarem, se unirem, tornarem-se companheiros. Sempre se diz por lá que quem se isola não termina o curso.

4. Durante as aulas que ministrou em meu curso de pós, ficou bem claro que é um Javeiro nato, porém, diferente de muitos que já conheci, mente aberta para outras tecnologias – PHP, oi ?. Qual tecnologia você investiria tempo hoje e por quê ?
Java foi minha área de expertise e continua sendo. Uma tecnologia altamente abrangente e sólida. Mas não sou fanático como alguns. Reconheço os prós e contras da tecnologia e da linguagem. Por isso mantenho minha mente aberta para estudar outras tecnologias. Algumas, como o PHP, são muito presentes no dia-a-dia da internet e é preciso conhecê-las. PHP eu admiro pela abrangência, o que me impele a conhecê-la, mas vejo nela muitos revezes. As tecnologias da Microsoft são excelentes, mas possuem uma filosofia que não concordo. Tenho a mentalidade livre e por isso o Software Livre me seduz. O Java hoje consegue ser bem mais livre, com suas JSRs e JCPs e implementações de VM diversas.

As tecnologias que eu invisto tempo hoje são o próprio PHP, por necessidade; a linguagem Scala, pra mim a linguagem mais completa que temos hoje. Scala melhora minha modelagem orientação a objetos, entendimento de programação funcional, capacidade de criação de scripts simples e sistemas altamente escaláveis (twitter) e complexos. E integra com Java, que possui uma base sólida de frameworks para uso. Ainda gostaria de estudar Python, pela programação linux e sua capacidade de utilizar bibliotecas C e C++ sem ter que utilizar essas linguagens, mas o tempo não permite… Ah, ainda pesquiso ferramental que permita um desenvolvimento mais rápido sem perder a beleza de um código bem modelado.

5. Certificações. Você tem uma porção delas, inclusive a SCEA que é um sonho ainda para mim. Elas agregaram alguma coisa na sua vida profissional ou foi mais para satisfazer seu lado pessoal – pendurar na parede ?
Eu ainda não terminei o SCEA. Passei na primeira parte e ainda falta terminar o projeto. Ainda quero fazer isso esse ano. Mas tenho outras cinco, desde a de Associates até a de Java Web Services. Elas começaram a me abrir portas em outros lados profissionais, em particular as aulas pois precisava de algo que comprovasse meus conhecimentos em Java sem ser por uma prova. Mas as portas foram mais abertas pelo Networking do que pelas certificações.
Elas começaram para satisfazer um lado pessoal. Eu trabalhava e me considerava bom naquilo e era uma forma de me forçar a estudar mais e ter um comprovante disso, além do trabalho. Fazer certificações obrigam você a se aprofundar mais nos detalhes, coisa que não se faz no dia-a-dia. E a minha empresa me incentivava a esse crescimento, sem me obrigar. Isso ajuda muito.
Eu indico as certificações. Mas não as considero como única credencial. Dá para tirar o SCJP e não saber nada de Web. Isso ser pré-requisito para um trabalho com Web não é muito lógico. Elas devem ser um meio, não um fim a ser perseguido.

6. Java e Oracle. Como um Javeiro, você teme alguma ação que venha a prejudicar a comunidade ?
Sim, temo. James Gosling saiu de lá. Vários outros saíram. Houve muitas demissões. Mas as atitudes até então tem nos tranquilizado. O Netbeans não acabou, o MySQL também não, apesar do futuro ainda incerto. A JVM continua free embora tenha tido algumas mudanças na licença, que geraram algumas repercurssões.
A Sun antes de ser vendida parece que se organizou para que isso não ocorresse. A OpenJDK foi uma jogada de mestre. Esperamos que a Oracle continue nesse caminho.

7. Hoje muito se fala sobre boas práticas, padrões de projeto, modelagem rica, desenvolvimento orientado à testes e arquitetura em camadas. Qual a dica que você, um arquiteto de software, deixaria para aqueles que tem a arquitetura/engenharia de software como objetivo ? Quais passos indicaria para aqueles que pretendem lá chegar ?
Comecem do começo. Desenvolvam com alguém mais senior, aprendam como escrever um bom código. Façam modelagem de problemas, depois estudem o Gof. O Gof deve ser entendido e não usado simplesmente para dizer que seu projeto usa padrões de projeto. E ele é melhor entendido depois que você teve o problema. Ao arquitetar, lute pelas bases, alta coesão, baixo acoplamento. É isso que todas as grandes arquiteturas buscam fazer. O Spring nasceu com esse propósito. As arquiteturas padrão sempre lutaram por isso, apesar das dificuldades iniciais.
Com essas bases, generalize. Estude tudo o que puder. Cada coisa nova é uma visão nova que se abre. Tudo tem seus prós e contras, e esses dependem do contexto que seu problema está. A arquitetura por melhor que seja não é a adequada para todos os casos. Saber analisar o contexto e saber colocar a arquitetura mais adequada em cada caso é o trabalho do arquiteto. Tem que gostar não é?

8. Nas suas atuais responsabilidades, o gerenciamento, seja de pessoas ou projetos, provavelmente está incluso. Como você costuma gerenciar seu time, cronograma, divisão de atividades e até, relacionamento entre todos ?
Eu fiz minha pós-graduação em Gerência de Projetos. Interessante quando você estuda o PMBOK é que parece que sua tarefa termina quando o Plano do Projeto está pronto. Mas na realidade é quando ele começa. Eu trabalho um pouco na gerência do projeto, com os cronogramas e atividades e principalmente com a liderança técnica da equipe do projeto, organizando e mantendo as atividades integradas.
A parte mais difícil é o gerenciamento das pessoas. Como manter a equipe coesa, motivada e com a produção no seu melhor? Eu gosto da máxima do Manifesto Ágil, “Indivíduos e interações mais do que processos e ferramentas.”. Conheça sua equipe, conheça os potenciais, seja transparente e confie. Mostrar que você confia na equipe é muito importante.

8++. Javeiro, Arquiteto de Software e professor. Quais os possíveis próximos passos em sua carreira ? Imaginou-se assim algum dia ou tudo aconteceu como um “acaso” ?
As coisas tem acontecido naturalmente, sem muito planejamento. O esforço no estudo e na relação interpessoal tem me impulsionado nessa direção. Tenho pensado em investir mais em dar aulas mas sem parar de desenvolver como principal atividade. Para ensinar é preciso ter experiência, é isso que dá mais crédito àquele que fala.
Espero mais para frente ter outras oportunidades, investir um pouco mais no estudo dos processos ágeis ou na melhoria dos tradicionais. Mas, acima de tudo, gosto de ver pessoas vindo trabalhar ou estudar comigo e saindo profissionais melhores, de saber que pude contribuir com algo de útil. Conseguir fazer isso e ainda gerar resultados, é uma experiência de vida muito gratificante.

Salvador Dali, 1931 - The Persistence of Memory

Já conversei com pessoas que batem o martelo facilmente dizendo:

- É por tempo.  Eu programo em brainfuck há seis anos, logo sou sênior.

Será mesmo ?

Em tempos modernos, fica ainda mais complexo fazer uma avaliação deste tipo para programadores, arquitetos ou engenheiros de software, pois, não é somente uma linguagem de programação que está em análise. É todo um contexto que abrange desde a escolha do ambiente de desenvolvimento até relacionamento com stakeholders e domínio em metodologias e paradigmas de desenvolvimento.

Se temos a análise temporal como inválida, então o que espera-se de um dito sênior ?

Para tal, conversei com três pessoas que estão diretamente envolvidas com estes aspectos.

Creio que sim. Existem os profissionais seniores, porém muitas pessoas, e empresas, acabam confundindo o nível do profissional com o seu tempo de experiência.

Em minha visão, o tempo de experiência é importante, porém, não determinante para rotular um profissional, ou seja, é perfeitamente possível existirem seniores com 3 anos de experiência e juniores com 15 anos.

O profissional Júnior, é aquele que já desempenha as tarefas com certa autonômia, porém, necessita de um maior tempo de pesquisa e em alguns casos de orientação.

Por sua vez, o pleno já demora um tempo menor para realizar as mesmas tarefas além de não necessitar de orientações referente aquela tarefa. O que difere o pleno de um sênior é a visão holistica, ou seja, para ser um profissional sênior é preciso possuir habilidades complementares as necessárias para o desenvolvimento daquela tarefa, isso ajuda acima de tudo no desenho de uma melhor solução além de maior facilidade no tratamento de problemas.

Outro ponto que vale ser observado, é que muitas vezes o sênior é destacado para tarefas simples, que não exige um conhecimento avançado, como seguir um procedimento de criação de usuário. Esse fato, além de desmotivar o profissional, gasta recursos de forma imprudente, já que são os seniores que deveriam criar os procedimentos a serem seguidos, além de desenhar soluções para problemas e corrigir falhas críticas ou em serviços críticos.

Vinícius Bufoni, coordenador de engenharia web na Vex

Este é um assunto interessante. Na maioria dos lugares as pessoas usam “anos de experiência” como medida para classificar. Esta é, na minha experiência, uma das piores maneiras de se fazer este tipo de classificação. Uma pessoa que desenvolve em, digamos, JSP e Servlets Java por 10 anos não necessariamente tem 10 anos de experiência desenvolvendo software, ele tem experiência desenvolvendo JSP e Servlets! E mesmo assim, tempo gasto em uma tecnologia não está diretamente relacionado com proficiência nesta. Enfim, utilizar tempo para medir experiência é, normalmente, uma besteira.

A forma com que eu tenho lidado com esta relação entre níveis de desenvolvedores, atualmente, é usando algo chamado modelo Dreyfus de aquisição de conhecimento: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition .

Normalmente eu tenho as áreas em que eu considero que meu time deve ser competente (este post: http://fragmental.tw/2009/11/24/i-wish-i-knew-that-before-getting-this-job-–-slides-and-long-notes da uma idéia sobre quais seriam estas áreas) e uso o Dreyfus para tentar entender onde cada um está nestas competências. Tem funcionado relativamente bem para mim mas ainda é, como sempre será, problemático e, por muitas vezes, injusto.

Phillip Calçado, consultor na ThoughtWorks

Do meu ponto de vista um profissional sênior é acima de tudo auto suficiente, é o tipo de profissional em que você não precisa passar o que deve ser feito, ele geralmente entende seu papel em uma equipe e como pode contribuir.

Um profissional Sênior consegue tomar decisões e assumir responsabilidades, ele não depende de alocações e precisa de muito pouca supervisão gerencial e técnica.

Geralmente um profissional Sênior também, está sempre atualizado e esta sempre ligado em tendências do mercado e em como adaptar estas novidades a sua realidade nos projetos em que esta envolvido.

“Tempo” de experiência na verdade não é tão importante, mas a diversidade e intensidade da experiência da pessoa é extremamente importante, se ele esteve envolvido uma grande diversidade de projetos e atuou em papeis dos mais diversos, um profissional sênior geralmente consegue se adaptar pois já trabalhou em diversos papéis e com diversos times.

No caso de grandes empresas de Internet, como o Yahoo!, é vital que o profissional sênior entenda de e tenha tido vivência com projetos de grande escala, e que entenda de Sistemas, arquiteturas e plataformas que funcionem com grandes volumes de acesso e demandam muita performance.

Não gosto muito destes rótulos, mas um profissional Pleno depende de um nível de supervisão/apoio maior. Um Pleno também tende a ser mais inseguro na tomada de decisões e definições mais complexas.

Mas a principal diferença é a experiência, bagagem de conhecimento. Em entrevistas sempre pergunto qual foi o maior desastre da carreira da pessoa, espero que ele me diga quais foram os erros e o que ele aprendeu com isso. Isso mostra maturidade em relação a tentativa/erro, onde não se deve temer cometer erros e que sempre devemos aprender com eles e continuar tentando. Isso é chave para ser inovador.

Antônio Carlos Silveira, diretor de Produto e Engenharia, Yahoo! América Latina

Cada um tem seus métodos de análise, mas ficou evidente que contar os dias no calendário já não é mais tão convincente como parecia

"Java printout por Ngọc Hà @ flickr"

Naquela época era claro para mim que programação era algo relacionado à área de exatas, pois criar uma aplicação é algo lógico tendo envolvimento direto com matemática e tudo mais.
Em coisa de um mês e pouco já conseguia fazer até uns “SQLs” e montava sites no estilo macarrônico de desenvolver. Aquilo para mim era fantástico! Tinha como objetivo aprender bem a linguagem para assim conseguir minha certificação da Zend, tornando-me assim um programador profissional.

Aconteceu porém, algo inesperado: comecei a “seguir” – não era no Twitter, até porque ele ainda era um protótipo de projeto na época – pessoas realmente profissionais em desenvolvimento de software e eu percebi assim que o buraco era mais embaixo e que eu ser excelente em uma linguagem era apenas um dos passos para tornar-me um programador profissional.

Abrindo um parênteses, eu li através do @sergioprado, não lembro onde agora, uma frase interessante e que tem como tradução algo como:

"O caminho para tornar-se mestre: siga o mestre; ande com o mestre;
torne-se o mestre."

Após começar eu a seguir os mestres, pude perceber que programação vai muito além da leitura de um requisito funcional de software e fazer daquilo algo sistêmico. Hoje, arrisco-me a dizer que programação não é algo somente relacionado à exatas. Possuí também, questões éticas – humanas – e artísticas.

A programação é relacionada a área de exatas

Isso é bem claro aos envolvidos em desenvolvimento de software. Você lê um problema descritivo, vulgo especificação funcional, ou visual (UML, rabisco na Moleskine, whatever) e faz daquilo algo sistêmico e que agregue valor ao negócio de seu cliente.

Como premissa você precisa aprender uma linguagem. Conhecer uma linguagem bem não é nada fácil. Você precisa empenhar-se para conhecer as intrínsecas e peculiaridades para aproveitar o melhor dela, tornando-se um especialista na linguagem. Eu valorizo mais um programador excelente em uma linguagem a um que já “trabalhou” com várias. Não é impossível uma pessoa ser excelente em mais de uma linguagem, mas isto, porém, demandaria muito tempo de dedicação para atingir tal nível.

A programação é relacionada a ética

Toda área tem suas condutas éticas e humanas, óbvio. Em programação, porém, vejo muitos ditos programadores ignorando isto. Quando você troca qualidade por falso ganho de tempo, você está sendo antiético. Quando não analisa corretamente as decisões que irá tomar em cima de algum problema, falta-lhe ética. Quando deixa de atentar seu cliente, o que inclui seu chefe, sobre a ausência de segurança, qualidade ou algum problema em cascata que venha a aparecer em decorrência de uma atitude, você está sendo antiético.

E isso acontece em demasia em nossa área! Seja por falta de interesse por parte do dito programador ou mesmo por medo de perder o emprego/projeto por “afronto” ao seu chefe ou cliente.

Para conhecer as técnicas, metodologias e artimanhas no desenvolvimento de software é necessário antes, ter uma boa noção de análise e projeto de software; arquitetura de aplicações; padrões e melhores práticas, para, após criticar uma atitude antiética de seu chefe/cliente, você ter total embasamento para propor a solução sem comprometer o projeto nem a aplicação. Isto será necessário também, para você ter um vocabulário comum para quando estiver numa roda de conversa entre os “mestres” da área.

Importante ressalvar que seu cliente ou chefe pode estar tomando uma atitude antiética, no ponto de vista de programação, inconscientemente. Afinal ele é especialista no negócio, o programador profissional é você!

A programação é também relacionada a artes

Há uma enorme diferença entre criar algo que funcione e criar algo que além de funcionar, transparece o domínio (regra de negócio).

Eu posso saber ler e escrever em português, mas há uma diferença gritante entre um poeta português e eu. Ele, diferentemente de mim, sabe utilizar muito bem as palavras e com elas, faz transparecer sentimentos, idéias e pensamentos sobre determinado tema, trazendo um enredo ao assunto abordado, envolvendo-nos em sua história.

Posso saber desenhar, mas isso não me torna um artista que emociona as pessoas com minhas obras.

Como programadores profissionais é fundamental conseguirmos fazer o mesmo ! É de nossa responsabilidade criar um código simples, legível e que conte toda a história da aplicação através de seus pacotes, classes, métodos, parâmetros, atributos e variáveis. Qualquer coisa diferente disso, não pode ser aceito como código profissional.

Pouco importa se a linguagem X é tachada como mais poluída que a Y. Você como profissional, tem que quebrar essa barreira e torná-la tão legível quanto qualquer outra, afinal, você é especialista na linguagem, lembra ?

Além de criar, é nossa responsabilidade cuidar para que o código continue sempre otimizado por tantas quantas forem as mudanças que nele ocorrer. Criar algo legível recai diretamente sobre isto, pois, no futuro outro profissional em programação poderá continuar seu trabalho sem danificar ou abandonar as premissas cruciais para um bom código. Andrew Hunt aborda o título: “Don’t live with broken windows”, onde resumidamente ele alerta para não descuidarmos da qualidade, pois, basta uma janela quebrada em uma casa para que ela transpareça o estado de abandono, fazendo assim, com que outras pessoas destruam mais janelas.

E como toda arte, não há uma receita para criar bons softwares. É necessário muito empenho, ler muitos códigos, revisar muitos paradigmas ao longo do tempo e claro, programar bastante. Não é possível tornar-se um programador profissional sem conhecimento teórico, tão pouco, sem vivência com erros e acertos.

Ao desenvolver a aplicação, não aceite nada menos do que seu melhor naquilo e atente-se para não cair na armadilha de criar softwares de forma sistematizada. Tenha autocrítica para fazer avaliações em seus próprios códigos e evitar assim, programar por coincidência.

Lembre-se de que será seu nome no @author.

Resumidamente é um projeto criado pelo Fabien Potencier - para quem não o conhece é o criador do symfony framework – e salvo engano há rumores de que ele pretende integrar o Twig à versão 2.x do symfony removendo o PHP super verboso que rola nos templates do symfony desde seu lançamento. * carece fontes concretas

Recursos bacanas e uma sintaxe à lá Django nos templates me chamou muita atenção para não só mais olhar, mas sim, testar para ver melhor a ferramenta.

Não demorou para eu testar como ele se portaria diante de objetos no template e para minha tristeza, para ele ler um atributo, depende nada mais, nada menos do que __get() e __isset(). É possível também, assim como na JSTL ler um atributo iniciado por get. No template você deveria chamá-lo sem esse get. i.e: getFoo() no template seria apenas foo.

Imediatamente, o que vem a mente de quem trabalha com OO ? Quebra brutal de encapsulamento. Sim, __get() por mais fácil que possa parecer, quebra totalmente a segurança de uma variável membro, uma vez que os atributos da mesma tornam-se públicos.

Tentei entrar em contato com o Fabien para ver o motivo que o levou a implementar assim. Ele, bem receptivo - ironia mode on - disse-me: se tiver um patch mande-o, do contrário, peço que seja paciente.

Fiz o patch, revi algumas coisas e mantive compatibilidade com o __get() __isset() que o Twig originalmente aceita e criei um Fork do projeto no GitHub.

Features default

• Suporte a plugins
• Variáveis
• Leitura de arrays por índices int ou string
• Arrays multidimensionais
• Objetos (via __get() __isset() apenas)
• Objetos alinhados (Nested Objects) com __get() __isset() também
• Blocos de controle, loops, etc.

Mudanças

Métodos públicos começados por:

• get
• is
• has
• match
• contain

Podem ser chamados no template sem qualquer problema sem a necessidade dos métodos mágicos.
Abaixo exemplos funcionais:

//...
/**
 * SomeVar
 * @var string
 */
 private $baz;
 /**
 * Bar Object
 * @var Bar
 */
 private $bar;
 /**
 * Magic String with __get
 * @var string
 */
 public $magic;

 public function __construct() {
    $this->baz = "Value of Foobar::\$baz";
    $this->bar = new Bar();
    $this->magic = 'Magic methods still working !';
 }

 /**
 * @return string
 */
 public function getBaz() {
     return $this->baz;
 }

 /**
 * @return boolean
 */
 public function hasBaz() {
     return (!empty($this->baz)) ? true : false;
 }

 private function hasIamNull() {
     return false;
 }

 public function fakehasFoo() {
     return 'I will not be displayed !';
 }

 public function matchesWith($otherString) {
     return ('foo' === $otherString);
 }

 public function getBar() {
     return $this->bar;
 } // ....

No template teriamos:

<body>
 <h1>Meu título</h1>
 <p>Bar foo</p>

 {% if foo.hasBaz %}
 <p>{{ foo.getBaz }}</p>
 {% endif %}

 {% if foo.hasIamNull %}
 <p>{{ foo.getBaz }}</p>
 {% endif %}

 <p>{{ foo.getAbstractBaz }}</p>

 <p>{{ foo.getIamPublic }}</p>

 <p>{{ foo.fakehasFoo }}</p>

 <p>{{ foo.getBar.getHlegius }}</p>

 <p>{{ foo.getBar.getBarFoo.getTwig }}</p>
 <p>{{ foo.getBar.getBarFoo.tryToCallMe }}</p> <!-- private function, fails. -->

 <p>{{ foo.methodThatIsnotExists }}</p> <!-- without error -->

 {% if foo.matchesWith('foo') %}
 <p>Yeah, it's matches !</p> <!-- will matches -->
 {% endif %}

 {% if foo.matchesWith('baz') %}
 <p>Yeah, it's matches again :S !</p> <!-- will NOT matches -->
 {% endif %}

Métodos não permitidos, índices não existentes e outros tipos de erros são omitidos por default.

Ainda penso em melhorar e implementar mais coisas ao projeto. Minha ideia inicial é ir sempre atualizando do projeto oficial para não distanciar-se muito. O patch eu também encaminhei ao próprio Fabien, mas ainda ele sequer respondeu ao meu e-mail.

Quem já utiliza o Twig e quiser testar essa nova versão mais “Object-oriented friendly” farei questão de dar total suporte e apoio para mantê-la up to date
Há ainda, exemplos de uso e do que você pode fazer com o Twig que eu modifiquei. Detalhes você encontra no diretório examples do projeto.

Vejamos um exemplo nada científico que fiz:

Criei os seguintes exemplos:

<?php
class Estatico {

    public static function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
           echo Estatico::outraCoisa();
           $i++;
        }
    }

    public static function outraCoisa() {
        return "Conteúdo";
    }
}

Estatico::fazAlgumaCoisa();

<?php
class Instancia {

    public function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
            echo $this->outraCoisa();
            $i++;
        }
    }

    public function outraCoisa() {
        return "Conteúdo";
    }
}
$objInstancia = new Instancia();
$objInstancia->fazAlgumaCoisa();

Os resultados após rodar quatro vezes cada foram:

Ou seja: 91.09 ms para o estático contra 90.07 para a versão non-static. Obviamente foi apenas um teste sem qualquer relevância, pois rodei em minha máquina pessoal com várias outras aplicações rodando em background. É perceptível porém, que a diferença não é absurda que compense o uso de estático por este motivo.

Deixando a questão de “performance” de lado, partimos para questões arquitetônicas:

• Identidade
• SoC – Separation of Concerns (Principio de Separação das Responsabilidades)
• Encapsulamento
• Estado
• DRY – Don’t Repeat Yourself
• Associações – sejam elas composições ou agregações

Ao perder Identidade e Estado as possibilidades daquele método – ou da classe inteira, caso use estático em tudo – tem o leque de utilidade reduzido para:

• Service
• Facade
• Factory
• Helpers – no âmbito de serem apenas funções que realizam determinada tarefa na aplicação sem qualquer valor ao Domínio

Com isso, perdemos também o Princípio de Separação das Responsabilidades, ou seja, a classe perde o controle sobre a integridade dos dados que ela deveria controlar e proteger contra acesso ou alteração indevidos.

Listei o DRY também por um motivo simples: com métodos estáticos, perdemos a grande chance de usar as variáveis de instância da classe à favor da mesma. Exemplo:

class UsuarioEstatico {

    public static function login($usuario, $senha) {
        // valida o usuário e zaz
        $autenticador = new Autenticador();
        $autenticador->autentica($usuario, $senha);
    }

    public static function logout($usuario) {
        // verifica se a sessao está aberta
        $autenticador = new Autenticador();
        $autenticador->fechaSessaoPara($usuario);
    }
}

class Usuario implements Autenticavel {
    private $autenticador;

    public function __construct($usuario, $senha) {
        // manipula os dados de entrada
        $this->autenticador = new Autenticador($this);
    }

    public function login() {
        return $this->autenticador->autentica();
    }

    public function logout() {
        return $this->autenticador->fechaSessao();
    }
}

Repare no modelo estático: foi necessário instanciar o antenticador por duas vezes em pontos diferentes. Opa, repetiu ! Mesmo que o autenticador fosse estático, teriamos duplicação, pois teriamos que certificar que o usuário existe e tudo mais. Isso porque não comentei como ficaria o lado cliente dessa implementação estática. O cliente – seja Controller, WebService ou qualquer classe em outra camada no domínio – teria que conhecer muita coisa sobre implementação dessa classe para poder manipulá-la.

Como bônus, repare que perdemos neste caso também o Polimorfismo, uma vez que eu poderia ter esse Autenticador() como base de autenticação para qualquer tipo (Usuário, Funcionário, Gerência, Administradores…)

O uso de métodos ou funções – sim, há diferença – estáticas pode ser bem-vindo nos itens já enumerados. Alguns developers porém, ainda que nestes casos são contra o uso por achar a ideia estática demasiadamente anti-oo.

Você deve estar se perguntando: aonde você quer chegar ?
Simples: se tudo isso que citei é muito óbvio para você, meus parabéns ! Você deve ser um profissional preocupado com a documentação !

Sim, da mesma forma que você precisou ler para entender como funciona a API de reflexão nativa do PHP, o seu colega de projeto precisará ler a documentação daquele Webservice que você fez para o projeto.
Partindo da minha analogia, seu amigo precisa ter como pré-requisito: saber ler e conhecimentos em PHP para poder implementar x)

Pensamento óbvio o meu, claro, claro que sim ! Mas pensa aí rapidinho: quantos códigos nos últimos tempos você pegou totalmente sem documentação, isso sem falar em outros aspectos, como qualidade interna e blablablá [no bom sentido] que profissionais aptos a escrever grandes softwares fazem [Se essa última palavra não faz sentido para você, recomendo ler este livro para entender o que é um grande software]

Aquela velha estória de que quem manja mesmo lê o código e já era caiu por terra. Para um formmail até que pode ser, mas aplicações modularizadas com um modelo bem definido e aplicado e uma chuva de classes trabalhando neste modelo precisa muito mais do que uma simples leitura de código. O mínimo necessário são os comentários do tipo DocBlock além dos comentários inline e por fim e não menos importante Classes, atributos, comportamentos, variáveis locais e constantes com nomes reais do que fazem, recebem ou são.

Isto é um DocBlock retirado daqui !

Para fechar, eu recomendo fortemente que você caso não conheça, dê uma boa olhada e claro, passe lá e pegue sua cópia gratuitamente dele, o PHPDoc em PHPdoc.org. Não vou me prolongar em explicar o que ele tem ou o que faz. O site está lá completinho.

Veja você mesmo neste exemplo online onde foi gerado o manual do Smarty Template. Ele por si só já diz tudo. Agora é com você

Pensando rapidamente parece um absurdo tratar sobre isto, mas acredite, assim como temos os Freetards - pessoas que têm amor ao Software Livre e critica todo o resto - Mactards, Wintards temos os programadores que descutem sobre indentação do código ! E acredite, tem "grupos" de programadores, cada qual defendendo um lado ! Loucura ? Continue lendo !

Nosso ponto de partida..
Como eu não sei exatamente onde que teve inicio isto, tomaremos como ponto de partida a publicação do livro The C Programming Language, escrito por Brian Kernighan e Dennis Ritchie. No livro você percebe que eles indentam o código da seguinte forma:

Porém, há uma exclusão aí ! Quando temos funções, a indentação desta é diferenciada, veja:

Repare que nestes casos, a abertura de chaves fica abaixo da linha que indentifica a função. Em todo o resto, a chave de abertura ficará na mesma linha.

Nota: vale lembrar que a mesma dupla que definiu que "Os nomes de variáveis e funções tem que expressar o significado do que ela armazena/executa, entretando o nome não pode ser extenso demais."

Em desacordo, nascem outras formas...

1. Eric Paul Allman - "Allman Style"
Vejamos a forma que ele usa e defende(defendia) :

A explicação é clara, assim como o código: isso evita que tenhamos linhas cheia de "tabs" apenas com chaves lá no final. Uma vez que as chaves sempre ficariam antes do conteúdo do bloco de código. É, até que tem sentido...

2. Whitesmiths Style
Esse estilo é usado pela Symbian ao desenvolver as aplicações em C++ para seus dispositivos móveis.

As chaves do bloco ficam abaixo da última letra do nome do método/construtor da linguagem. Ao que me parece, era usado nos primórdios do Windows também. (Carece de fontes confiáveis)

3. GNU Emacs
Sim, o guru do Software Livre também entrou nessa e criou seu estilo. Ele nada mais é do que a mistura do Allman com a Whitesmiths.

O código é indentado da seguinte forma: após o *if* você vai para linha debaixo e dá 2 espaços, e então coloca a abertura da chave do bloco. Vai para a linha debaixo novamente, e dê mais 2 espaços avançando dentro dos dois anteriores. Aí agora pode colocar seu código

Analisando alguns códigos...
Vejamos alguns códigos por aí a fora para ver o que a galera acha "pop".

- Código fonte Kernel do Linux (arquivo proc.c)

- Código fonte Mozilla Firefox (GranParadiso Alpha8) (arquivo nsBrowserApp.cpp)

- Código fonte The Vim Editor (arquivo edit.c)

- Código fonte Zend Framework 1.5 (arquivo Action.php)

- E claro, a "minha" forma de indentação

Resumindo....
Pegando emprestado o resumo do EmacsWiki.org, temos:

“gnu”
The default style for GNU projects
“k&r”
What Kernighan and Ritchie, the authors of C used in their book
“bsd”
What BSD developers use, aka “Allman style” after Eric Allman.
“stroustrup”
What Stroustrup, the author of C++ used in his book
“linux”
What the Linux developers use for kernel development
“python”
What Python developers use for extension modules
“java”
The default style for java-mode (see below)
“user”
When you want to define your own style

Para fechar o post, deixo aqui uma frase que encontra-se no livro The Programming C Language:

The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently.

Veja também: (Links em inglês)
http://www.emacswiki.org/cgi-bin/wiki/IndentingC
http://en.wikipedia.org/wiki/Symbian_OS
http://en.wikipedia.org/wiki/Indent_style
http://www.gamedev.net/community/forums/topic.asp?topic_id=446444

A aplica��o dos standards da web permite que os sites da web funcionem e se vejam correctamente em quase todos os navegadores (browsers). Tristemente, o Internet Explorer, o navegador com maior predomin�ncia no mercado, apresenta as mais fortes e s�rias defici�ncias na implementa��o dos standards da web. Como consequ�ncia destas defici�ncias, os programadores (developers) da web t�m que desenvolver trabalho extra para garantir uma boa viv�ncia dos utilizadores deste navegador (browser). E isto custa dinheiro. E cabelo, muito cabelo.

Mais informa��es voc� poder� encontrar diretamente no site do "projeto"

http://403day.org/pt/