BT

Melhores da InfoQ 07: Críticas surpreendentes do líder de desenvolvimento da Microsoft em sua saída

por Niclas Nilsson , traduzido por Gabriel Bogéa em 30 Out 2008 |

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.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Falando com pedras by Luiz Sanches

Alguns desenvolvedores ainda vivem em mundo que não querem que mudem, tem medo da mudança, se sentem "estáveis". São pedras.

Posse Coletiva do Código by yuri negocio

Estas últimas questões remetem a posse coletiva do código e reponsabilidade. A idéia de melhoria contínua é excelente mas muito difícil na prática, principalmente em um cenário desmotivante com pesados processos burocráticos, interessante seria se ele mostrasse como atingiu tais objetivos.

Vale para todos nós by André Faria

Muito bom! Isso vale para todos nós desenvolvedores de software e nem de longe são problemas que só acontecem na Microsoft, eu diria que todo desenvolvedor deveria se questionar a respeitos dos pontos que Niclas levantou antes de escrever uma nova linha de código.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT