egomesbrandao, blog

Eu tomo café da manhã na padaria: um suco de laranja e um croissant. Como vou sempre na mesma,  o atendente já me conhece, mas quando ele começou lá foi a mesma coisa do anterior, ele me servia o croissant, servia o suco e ia pegar um canudo, que eu sempre recusava (questões ambientais)… Se você pede um suco sempre colocam um canudo, mas se você pede um refrigerante, um chocolate quente, uma água com gás, uma cerveja… não colocam! Por quê? O copo é o mesmo. Acho que quando inventaram o canudo era para você conseguir beber um líquido de um lugar do tipo uma garrafa, ou até mesmo acho que era para crianças. Não tem  sentido servir um suco com canudo e um refrigerante sem!
No desenvolvimento de software é a mesma coisa. Não usamos canudo, mas já perceberam como fazemos coisa que não sabemos por quê? Alguém fez a primeira vez, talvez para resolver um problema específico, e outro copiou, depois outro… E de repente está todo mundo fazendo, e ninguém sabe por quê.
Por quê se usa Dataset’s? Além do fato de vários livros de .Net básicos ensinarem e o pessoal parar de estudar no básico ou intermediário, se você perguntar para algum desenvolvedor o motivo que o levou a usar Dataset ele não vai saber explicar. Teve alguma vantagem? Ele não vai saber. É mais rápido? Ele não vai saber.
Por quê usamos Try…Catch? Muitos desenvolvedores não vão saber explicar! Aliás, muitos não sabem nem mesmo usar! Ou alguém nunca viu um método FazTudo com um Try…Catch abrangendo um código gigantesco?
Por quê ainda usamos ADO.Net puro quando temos outras maneiras melhores de acessar um banco de dados? Por quê programamos estruturado em uma linguagem orientada a objetos?
Meu pai fala uma frase: “O ser humano é um animal acostumado a hábitos”.
Nós simplesmente acostumamos a fazer alguma coisa e isso vira um processo, sempre se repetindo, sem espaço para inovação, criatividade, pensar fora da caixa. E a sociedade, a vida cotidiana, força-nos mais ainda a manter esse hábito de repetição (olha a recurividade aí, hábitos já são repetitivos).
Os estudantes não são ensinados a pensar e sim a repetir, a decorar, desde os primeiros anos. Não são forçados a questionar, a verificar, a pesquisar, a tentar entender e quem sabe no futuro entender esse conhecimento sozinho. Anos atrás por conta da pobreza dos editores das linguagens de programação e também por causa da fraca tipagem era uma questão de bom senso usar um prefixo com o tipo da variável.

<br />
float fValorTotal;<br />
int iQuantidade;<br />

Mas era algo totalmente justificável, pois você não tinha algo como o Intellisense do VS.Net, você podia atribuir um valor decimal para uma variável declarada como inteira, e por aí vai. Mas e hoje, por quê ainda se usa esse prefixo? E por quê ele é ensinado em muitos lugares? Não tem o menor sentido. E os alunos habituados a anos a decorar sem questionar não conseguem perceber que sem o prefixo o código compila da mesma maneira.
Por quê ao ensinar o paradigma de orientação a objetos não deixamos de codar estruturado? Temos ainda o paradigma funcional, dinâmico, … Mas essa distinção não é clara para recém formados ou participantes de cursos de programação. Por que até hoje se ensina OO como se fosse uma evolução do estruturado, o que nunca foi uma verdade.
Hoje os bancos usam programação estruturada, indústrias com seus softwares MRP também, esse tipo de linguagem não vai sumir, ela tem o seu uso, e o OO não é o futuro dela.
Manter a mente aberta para o aprendizado é algo extremamente difícil, questionar processos, discutir teorias, é complicado, pois somos avessos a mudanças. Albert Einstein, disse: “A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original”. E é assim que deveríamos agir em todos os momentos da nossa vida, e precisamos de pessoas que queiram experimentar, criar, aprender e evoluir principalmente na área de software. Quem sabe assim termos mais qualidade, seremos mais econômicos, mais rápidos e assertivos. Só depende de quem faz.

Outro dia saiu uma pergunta numa lista de discussão, sobre o que era melhor usar, For, foreach ou ainda ForEach?

Histórinha do ForEach: Depois dos Generics, disponibilizado no framework 2.0, se tornou comum o uso de listas tipadas, muito melhores que o uso de Arrays de Objects! Também foi introduzido os tipos anônimos, expressões Lambda. Em seguida na versão 3.5 do framework foi introduzido o Linq, mudando a forma como são manipuladas coleções de objetos.

Se é necessário somar o valor dos itens de uma nota fiscal o modo “old school” é:

List<Item> itens = new List<Item>();

itens.Add(new Item() { Valor = 10.3M });
itens.Add(new Item() { Valor = 11.7M });
itens.Add(new Item() { Valor = 15.8M });

decimal valorTotal = 0;

foreach (Item item in itens)
{
 valorTotal += item.Valor;
}

Ou você pode fazer:

List<Item> itens = new List<Item>();

itens.Add(new Item() { Valor = 10.3M });
itens.Add(new Item() { Valor = 11.7M });
itens.Add(new Item() { Valor = 15.8M });

decimal valorTotal = 0;

itens.ForEach(item => valorTotal += item.Valor);

Mas fora a diferença de sintaxe, existe alguma outra? Performance? E o que é esse método ForEach?

ForEach é um método que recebe como parâmetro um delegate Action<T>, ou seja ele recebe uma função a ser executada, nesse caso será executado um foreach!! Sem emoção aqui, mas o legal é que percorrer uma coleção fazendo alguma alteração em seus itens agora requer apenas uma linha.

Mas não é só isso! Voltando a nossa questão de performance o ForEach é mais otimizado sim, eu ia fazer um pequeno projeto de teste mas… achei um post falando justamente sobre isso, então para reaproveitar código quem quiser testar é só usar o projeto que foi disponibilizado pelo Dustin Russell Campbell aqui neste post. A comparação é bem completa, usando vários tipos de interação (For, foreach, ForEach), e o ForEach ganha! Somente quando o código esta usando otimização na compilação com uma coleção pequena a velocidade se equipara, mas a medida que a quantidade de itens aumenta ele é mais rápido que outros métodos.

A quem não goste

Encontrei também comentários de pessoas que não gostam dessa abordagem, dizendo que ela não adiciona poder representativo a linguagem, o exemplo dado no link é bem simples então o autor tem razão. Porém minha opinião é que o código fica muito mais legível, tornando a leitura mais fluída.

Anos atrás uma onda de terceirização foi iniciada em vários segmentos da economia, indústria, serviços; delegando para terceiros a fabricação de partes de  componentes , a montagem de um equipamento, até mesmo sua completa fabricação. No setor de serviços sub-contratando mão de obra, ou empresas inteiras para prestação de algum serviço, limpeza e segurança são os exemplos clássicos, além do telemarketing e  serviço de atendimento ao consumidor, que foi chamado de chão de fábrica do século XX. O objetivo principal: redução de custos! Enquanto a inteligência do negócio, criação, comercialização, continuava com a empresa, atividades de menor valor eram terceirizadas. Em nenhum outro segmento como na TI foi e é tão visível, e isso não funciona. Nunca funcionará.

Surgiram então as fábricas de software, muito bem descrito no artigo do Akita, Fábrica de Software é uma Besteira , como: “O maior desserviço à área de Desenvolvimento de Software já criado na nossa história recente foi o termo ‘Fábrica de Software’”. No qual existe até uma concordância com outro texto meu, Arquitetos não existem, em que eu coloco que a construção do software é trabalho do compilador, o desenvolvedor faz o projeto dele. Engraçado que,  apesar de saber da existência deste texto do Akita, eu ainda não havia lido.

Já que a  questão da fábrica de software já foi discutida, quero colocar outro problema em evidência:  o body shop, outsourcing; que é feito por várias empresas que alocam profissionais para trabalhar nos seus clientes. O objetivo é sempre o mesmo, redução da carga tributária; a falta da necessidade de manter indefinidamente a estrutura com esses profissionais, enxugando assim a quantidade de funcionários propriamente dita. Mas chega um determinado ponto que esse modelo falha.  Acontece que esses profissionais não estão comprometidos com a empresa em que estão alocados, ou seja, não vão se comprometer com o seu trabalho, com o projeto ou com o produto. Ele não está comprometido com a continuidade. No primeiro sinal de perigo ele pula fora. Afinal quando uma empresa decide fazer cortes ela começa por aí, já que não terá o ônus trabalhista,  só precisando  cancelar um contrato. Uma proposta um pouco maior também faz esse profissional sair e, uma vez que  a visibilidade dele para a empresa em que está alocada e para a sua empresa as vezes é pequena, será difícil ele conseguir uma valorização financeira maior sobre o trabalho que está executando.

Esse profissional está por conta própria. Com perspectivas de crescimento pequenas, de valorização ainda menores, ele se encontra em uma posição desfavorável e ninguém gosta de estar assim. Por conta disso,  diversos profissionais encontram-se estagnados, já que não tem motivação para ir além de sua capacidade. Dessa forma, executam um trabalho diário braçal e mecânico, sem melhorar sua técnica, trazer mais valor para o seu trabalho. Muitas vezes ele é hostilizado por funcionários da empresa em que se encontra alocado, tratam-no apenas como recurso no processo, proveniente de um contrato de prestação de serviço. Com certeza algum leitor está pensando que não é verdade que todo profissional não contribua, que não invista, que não melhore seu trabalho. Sim vários se importam, por que eles entendem que não são só as empresas envolvidas em um projeto mal feito que serão penalizadas, seu nome também esta em jogo. Mas mesmo esses profissionais são desestimulados com o passar do tempo.

Pessoas não são recursos. Elas determinam o sucesso e o fracasso de um projeto, e não as máquinas usadas, a linguagem, a internet. A desvalorização e, consequente, a  desmotivação de uma pessoa afeta diretamente o sucesso de um projeto no qual são horas perdidas de conhecimento, pesquisa, e por aí vai.

Mas então,  qual seria a solução? Empresas fortes em desenvolver sistemas para os seus clientes e não apenas em fornecer mão de obra. Empresas que pesquisem, armazenem esse conhecimento, mantenham profissionais e vendam soluções,  e não horas. Empresas de TI que sejam do negócio de TI e não apenas RH especializados em TI. Empresas assim,  ganham mais, pagam mais e contribuem com a economia do país. Essa empresas teriam foco, da mesma maneira que os clientes que ela atenderia  têm foco, que não é a TI.