A poesia do codificador

Quando comecei com programação profissionalmente, a única coisa que  eu queria era que o sistema funcionasse, não importasse como. O tempo era gasto com esse único objetivo, porque eu ainda estava em uma época de confirmação das minhas capacidades como desenvolvedor. Era uma época de provar para mim mesmo o que eu podia ou não podia fazer.

Hoje, olhando para os novos programadores que sou responsável, vejo muito disso. Existe uma insegurança em quem começa a desenvolver e tem a responsabilidade de entregar um produto. Essa dúvida está alicerçada na crença de que não possuem conhecimento suficiente para fazerem o que estão fazendo. Questionamentos simplistas como “melhor adicionar isso na esquerda ou na direita” surgem porque possuem a necessidade de criar os limites mentais para terem aprovação daquilo que estão fazendo, e assim medirem seu próprio desempenho, e construírem uma base sólida para sua formação. É o período da infância em todo novo aprendizado, no eterno ciclo de evolução.

Mas o conhecimento é conseguido pouco-a-pouco, a confiança instaurada em sua personalidade, e eis que o amadurecimento surge suavemente como o nascer do sol em uma noite escura, acalentando as mente para as novas possibilidades. As dificuldades de outrora tampouco são lembradas, porque o profissional já atingiu o patamar necessário para sua estabilização. Agora não existe mais insegurança. Existe apenas a continuação do caminho do aprendizado.

Esse é um ponto muito interessante. Nesse momento, o desenvolvedor já não se preocupa se vai conseguir ou não. Ele sabe que vai, porque sua fé é baseada em experiências passadas. A questão é apenas “como” ele vai fazer, e nesse momento algo muito legal acontece: ele passa a ser crítico. Passa a pensar em tudo o que faz, com olhar analítico, para fazer tudo da melhor forma.

O desenvolvimento de sistema já não é mais preocupação. Torna-se um passa-tempo, um jogo mental. O desafio é superar a sí mesmo, tornando tudo mais simples, flexível e performático, e o desenvolvedor para de escrever programas e passa a criar uma obra, como um pintor em uma tela. É possível ver beleza no código-fonte, e quem desenvolve a muito tempo sabe disso. Os recursos bem empregados, o algorítmo otimizado, as abstrações de forma coerentes, a teoria da orientação à objetos (para aquele que não concordam com essa afirmação, veja isso) tornando-se viva na implementação, tudo isso contribui para um código bonito.

Espero muito que você tenha essa experiência, de desenvolver sistemas de forma otimizada. É muito gratificante sair da “obrigação” do desenvolvimento funcionar e atingir a esfera da criatividade.

 

 

Paradigma da Programação Orientada à Objetos (POO)

Quando comecei com programação, lá no anos 90, o paradigma da orientação à objetos já era algo muito discutido. Ele foi criado na década de 60 (para saber um pouco da história, acesse http://www.webgoal.com.br/origem-da-orientacao-a-objetos) , mas vejo que até hoje as pessoas tem dúvidas, se questionam a respeito e algumas vezes vão contra ele. Existe a legião de pessoas que idolatram a orientação à objetos, e vejo recentemente uma grande tendência contra ela, que vem crescendo à cada dia. Não sei o que o futuro nos aguarda, mas pode ser que venhamos à condená-la. Assim são as coisas com a evolução. O que posso dizer, humildemente, é que eu a adoro.

A orientação à objetos tem uma característica que considero fantástica: a forma que ela consegue organizar as coisas.

Durante anos estudei programação e análise de sistemas e, no início, mas durante um período que durou alguns anos, me questionava muito se eu realmente entendia sobre orientação à objetos. Entendia de classes, de herança, de polimorfismo, de sobrecarga de métodos e todas as outras coisas relacionadas, mas não era capaz de responder à simples questão: porque as pessoas precisam disso se conseguem desenvolver sistemas sem seguir a orientação à objetos? Não pode ser simplesmente pela reutilização do código, porque uma função também pode ser reutilizada. Porque criar uma estrutura se posso ir diretamente ao ponto e resolver o problema? Felizmente, a resposta para essa pergunta me apareceu futuramente.

Somente quando comecei a trabalhar com grandes projetos, o que aconteceu depois que entrei na faculdade (sim, comecei a desenvolver muito antes disso) é que fui entender a importância da facilidade de manutenção e de comunicação com outras pessoas da equipe, referente ao código-fonte.

A grande maravilha da orientação à objetos para mim não é relacionado aos seus pilares: abstração, encapsulamento, polimorfismo e herança (não despreso esses recursos!). É a forma como ela organiza as informações que é mágico. Você pode ter milhões de arquivos no seu computador, e todos vão funcionar e você eventualmente vai encontrar todos sempre que possível, mas mesmo assim, você os organiza em pastas, não é? Por que? Porque dessa forma, fica muita mais fácil trabalhar com eles. É a mesma coisa! Ah, mas eu poderia utilizar namespaces para organizar meu código… sim, você poderia! Eu utilizo os dois (classes e namespaces), e sou feliz assim! Quer utilizar namespaces apenas, e classificar suas funções? Vai em frente! Porque não importa o que você faça, o importante é que dê certo! Não existe certo ou errado em informática, desde que  as pessoas consigam aquilo que elas busquem.

Muitos argumentam que OO não é performático. Comparado a que? Procedural? Sim, pode ser verdade. E daí? Ah, então não devemos utilizar OO para nenhum projeto? Responda-me uma coisa: quando as pessoas vão para o fundo do mar, elas vão de submarino ou de avião? Mas o avião não é mais veloz (é, forcei um pouco no exemplo!)?  O que quero dizer é que não existe uma tecnologia que resolve todos os problemas. Cada coisa tem seu papel. Se vou realizar um processamento em lote, provavelmente farei sem utilizar OO, para que tenha o máximo de performance. Provavelmente farei tudo da forma mais direta possível, porque o problema exige isso. Mas, se ao mesmo tempo, tiver um deadline muito curto e já exista uma classe preparada para o serviço, só que utiliza ORM, etc, etc, etc, talvez utilize a OO simplesmente porque tenho que entregar o projeto, e sem isso, não conseguiria atingir o prazo. É melhor meia vitória do que nenhuma. Por outro lado, prefiro utilizar OO sempre que possível, porque isso me dá um egrenciamento do código que eu preciso nas manutenções, que é essencial para o desenvolvedor. Outras formas de desenvolver sistemas podem gerar uma melhor performance do programa, mas e quanto à performance da equipe? Isso também importa.

As dificuldades em desenvolvimento de sistemas são relacionadas à prazos, regras de negócios, relacionamento com os clientes, processos internos dentro da fábrica de software. A tecnologia é só a forma de chegar lá, é o veículo para atingir os objetivos. É como ter que ir para outra cidade, podendo escolher ir de carro, ônibus ou avião. Mas o problema real ainda é ir para outra cidade. O que geralmente vejo são as pessoas discutindo que é melhor ir de carro, outros de avião. Poucos discutem sobre: por que preciso ir para outra cidade? O que vou fazer lá? Essas são as questões, porque sem isso, nada adianta qual veículo você vai usar.

Costumo falar que informática é igual time de futebol. Fulano torce para aquela tecnologia, siclano para aquela linguagem de programação específica. Isso só demonstra imaturidade profissional. O bom profissional sabe que essas coisas são passageiras e que o importante é resolver o problema, seja como for. É a satisfação do cliente que importa, e ele não está preocupado com isso. Os envolvidos nos projetos geralmente não se preocupam com a tecnologia. Os pedidos estão caindo? Minha empresa está faturando? Como estão as vendas? Está formando filas nos caixas? Nada disso tem a ver com tecnologia. Isso tem a ver com pessoas. Foco nas pessoas. A tecnologia é o veículo para a resolução dos problemas. Se o faturamento está ótimo, importa se foi feito utilizando POO ou da forma procedural? Claro que não! Importa que funciona. E pode ter certeza que dá para se fazer bem feito das duas maneiras, ou de qualquer outra.

Outra vantagem de se utilizar OO que me ajuda muito, é algo que obtenho também dos padrões de projeto. Facilidade de comunicação com a equipe. Quando as pessoas estão integradas com o código, é fácil simplesmente dizer: utilize esse ou aquele objeto para resolver isso. Faça tal sobrecarga, etc, etc. É simplesmente fácil de se comunicar, porque os objetos são abstrações das estruturas e dos comportamentos, e quando falamos de comportamento, estamos utilizando uma linguagem comum a todos.

Se sua equipe está acostumado com a forma procedural, não mude! Não tire o know-how de como ter sucesso (a não ser que você não esteja tendo)! Se sua equipe está acostumada à OO, não mude! Não tire o know-how dela. Mudar os processos internos é traumatico e retira o conhecimento daqueles que já o detém. Cade equipe precisa encontrar a própria forma de trabalhar. Eu encontrei a minha. Espero que você também encontre a sua.

Solucionando o problema do armazenamento da senha de proxy do Chrome

Se assim como eu, sempre que você abria o Chrome utilizando uma conexão através de um proxy, você ficava com raiva de ter que redigitar o usuário e a senha, saiba que a culpa provavelmente é sua! Isso mesmo. A não ser que você não tenha a última versão do browser instalada – e não posso imaginar o motivo de não tê-la – aposto que se você passa por esse problema é porque na primeira vez que entrou através do proxy, você disse ao Chrome que não gostaria que ele salvasse a senha. Não lembra? Dúvida? Novamente, se assim como eu, você estava acostumado com o Internet Explorer, onde havia um campo com a opção “Lembrar a senha”, ou “Lembrar minhas credenciais”, ao não encontrar algo semelhante, logo culpou a Google pela “Grave Falha”. É, mais uma vez fica provado que se a grama mudar de cor, o boi morre de fome. Vale lembrar que a Google não precisa imitar a Microsoft, e via de regra, o pessoal lá sempre tenta inovar. Eu, pessoalmente, colocaria a opção aí, por achar mais intuitivo, mas isso não é uma regra a ser seguida, a qual de fato não foi.

Para resolvermos essa situação, é muito fácil (dependendo da versão do browser, as telas e os passos podem ser diferentes, mas nada que fuja muito do conceito geral). Entre nas opções do browser (chave de fenda no canto superior direito e depois em opções). A tela a seguir será apresentada:

Entre na opção “Mostrar senhas salvas”. A seguinte tela será apresentada:

Provavelmente o seu endereço de proxy vai estar nesta lista. Selecione-o e click em remover. Isso fará com que o Google Chrome passe a buscar senhas salvas para o endereço do proxy. Basta fechar todas as janelas e sair do navegador. Ao abrí-lo novamente, você deverá informar o usuário e a senha normalmente. Perceba que assim que o navegador for aberto (pode ser necessário acessar alguma página, como o http://www.google.com.br, por exemplo), aparecerá uma tarja, perguntando se você gostaria de salvar sua senha.

 Diga que sim, e seus problemas estarão resolvidos. Assim que abrir o navegador novamente, o usuário e a senha estarão preenchidos.