Esta notícia foi originalmente publicada em 23 de novembro e faz parte da coleção das melhores notícias de 2007 publicadas na InfoQ
Jay Bazuzi,ex líder de desenvolvimento do editor do C#, está saindo da Microsoft, e escreveu algumas palavras surpreendentemente duras para seus colegas antes da sua partida: "OO não é uma moda passageira" e "Não há problema em utilizar o código de outra pessoa".
Jay começa dizendo:
Eu tenho algumas opiniões sobre o desenvolvimento de software da Microsoft antes da minha partida.
Seu post é focado em cinco pontos nos quais ele acredita que o potencial de melhoria é grande:
- O código mais claro vence.
- OO não é uma moda passageira
- Não há problema em utilizar o código de outra pessoa
- Espante seus problemas com projetos
- E mais importante: nós podemos melhorar.
Apesar da franqueza de Jay, não houve muitos comentários sobre seu post. Alex Barnett acredita que ele deveria ter sido divulgado apenas internamente, mas, fora isso, o post produziu produziu uma repercussão muito menor que a esperada.
Mas a triste verdade é que os argumentos de Jay não se aplicam apenas à Microsoft. Muitas companhias poderiam ter achado que o post era sobre elas e suas bases de código se essas descrições fossem anônimas. Sobre a questão docódigo claro, por exemplo, Jay escreve:
A maioria dos desenvolvedores na Microsoft ainda não aprendeu o incrível valor de se escrever código o mais claro possível. Uma vez eu vi alguém fazer um checkin que adicionou 200 linhas no meio de uma função de 600 linhas. Eu achei que ela já tinha aproximadamente 597 linhas a mais que o necessário. Use o Extract Method para dividi-las em pedaços menores. Use o Extract Class para gerenciar a quantidade de métodos que você subitamente produziu. Não pare por aí.
Quando se trata da falta de pensamento orientado a objetos, Jay dá um exemplo de como o problema de buffer overruns foi tratado durante os últimos anos de foco em segurança. Ferramentas foram escritas para verificar que um tamanho apropriado sempre fosse passado como um argumento separado quando manipulando buffers, uma solução com a qual Jay não estava satisfeito:
Ei, quando você encontrar dois ou mais valores sendo passados juntos, por que não colocá-los em uma classe? Comece por aí. Polimorfismo, herança e encapsulamento podem vir depois.
Trabalhar com objetos pode ser difícil e reutilizar objetos pode ser ainda mais difícil. A Microsoft parece sofrer da boa e velha síndrome do "Não inventado aqui", não apenas quando se trata de código externo.
Em certo ponto, a base de código do Visual Studio tinha cerca de uma dúzia de implementações da classe String do C++, a maior parte delas hakeadas da MFC. Isto é uma grande melhoria em relação a passar os buffers de um lado para o outro, mas veja... estes desenvolvedores de bibliotecas são pagos para trabalhar nessas coisas em tempo integral! Por que vocês ainda não estão usando STL ou ATL?
Isto não acontece apenas no C++… Nas implementações originais do Framework .Net, havia incontáveis implementações de hash tables. Alto lá galera! Vamos criar umas bibliotecas!
Mas a lição mais importante para os desenvolvedores ao redor do mundo é a discussão de Jay sobre como melhorar de forma contínua. Jay descreve que certa vez ele era o gerente de uma equipe muito inexperiente; uma quipe que, depois de um ano, era mais produtiva e escrevia mais código com qualidade mais alta do que equipes experientes trabalhando em bases de código com as quais eram bem familiares. E eles sempre o faziam dentro do prazo.
Jay atribui este fato à habilidade da equipe de melhorar continuamente, e mostra uma série de questões que colocam o desenvolvedor na direção certa, perguntas que ele acha que seus ex-colegas deveriam se perguntar. Na verdade, estas são questões que todo desenvolvedor em todas as empresas deveria se perguntar mais freqüentemente:
- “Como eu posso ter certeza que este problema vai embora para sempre?”
- “Como eu posso produzir menos bugs?”
- “Como eu posso tornar mais fácil a correção dos meus bugs?”
- “Como eu posso tornar mais fácil responder a mudanças rapidamente?”
- “Como eu posso tornar mais fácil fazer com que meu software seja rápido o suficiente?”
Questões verdadeiramente poderosas que muitas, senão, a maioria das equipes poderiam se beneficiar ao fazê-las periodicamente.