E aí galera! Virada de ano e de novo volto a ter tempo hábil para as minhas mau traçadas linhas aqui neste blog.

Espero que todos tenham passado as festas muito "de boa" como se diz em São Paulo.

Hoje estarei refletindo sobre como as coisas podem ser feitas para que sejam feitas apenas uma vez na vida, e claro mantidas e somente evoluídas. Durante minha pequena vida corporativa como desenvolvedor de softwares, não raras vezes me deparei com a tarefa de ter que reformular ou reescrever ou "tunnar" funções, métodos, stored procedures, enfim qualquer objeto de software. E muitas vezes diante desta tarefa me perguntei: Será que o cara que fez isso (algumas vezes esse cara era eu mesmo) não pensou enquanto construía esta joça? Pois é isso que penso ainda hoje. Apesar de não gostar muito de testar minhas soluções - na verdade prefiro até que outros testem por que minha capacidade de testes é muito limitada - eu procuro fazer as coisas o melhor possível já da primeira vez, mesmo que voltem de testes umas trocentas vezes.

Se formos seguir os pensadores POG (Programação Orientada a Gambiarras), a primeira lei diz: "Funcionou está certo". Eu discordo veementemente desta tese, pois funcionar é o objetivo de qualquer coisa que se construa (ainda mais no mundo do software), o problema é que via de regra o que funciona hoje um dia precisa ser de alguma forma estendido um bom exemplo para isso é a escalabilidade que qualquer aplicação pode demandar num dado momento de sua vida, ou seja, o sistema nasce com 10 usuários e em menos de um ano já tem mais de 1000 e aí? Como fica? A carga de dados, o número de conexões ao banco de dados ou de requisições ao servidor HTTP aumentam na proporção de 1 pra 100 e num intervalo de tempo muito pequeno. Às vezes o sistema já nasce com a premissa de ser massivamente acessado, mas mesmo assim as soluções que são dadas não são ideais para este cenário.

Seja num sistema pequeno ou grande as boas práticas são sempre as melhores saídas para não se enveredar por este caminho pecaminoso. Muitos de nós meros desenvolvedores, programadores ou analistas-programadores atuamos em ambientes de extrema pressa e de prazos cada vez mais curtos. Porém mesmo nessas horas onde é necessário corrigir um bug em 3 segundos para colocar em produção com o seu chefe ao seu lado. É importante nos portarmos com uma boa dose de sabedoria e gastar mais 3 segundos pensando se aquela solução soluciona completamente o problema, é manutenível no futuro, tem a performance ideal para 10 ou 10000 usuários (ou quantos usuários sua aplicação vá suportar) , o código é claro o bastante para o trouxa que tiver que mexer depois essas coisas todas que a gente sempre escuta falar, mas muitas vezes acaba deixando de lado por conta da agitação da construção do software. Mesmo que estejamos utilizando um framework bem escrito como, por exemplo, um LUMIS da vida (eu trabalhei com ele na versão 3.0 em ASP, mas todos os amigos que ainda vivem dele o elogiam bastante) é importante verificar essas regras básicas do desenvolvimento de software.

E não acho que essa avaliação seja baseada apenas em achismos e no bom e velho feeling profissional. Para tal tarefa existem hoje ferramentas capazes de validar o código, o desempenho, e uma série de outros fatores que podem afirmar: O código escrito está bem escrito.

Sempre ouvi dizer a frase que intitula este post de hoje. E procuro sempre obedecer mesmo que alguma coisa saia errado e os encarregados do teste defiram meu teste. “Faça certa da primeira vez e faça apenas uma vez”. Esta postura pode economizar horas e horas de retrabalho e até mesmo evitar trabalhos em dias não muito auspiciosos como sábados, domingos e feriados.

Mais uma vez agradeço a vocês a paciência e a atenção investidas nestas linhas.

Os galáticos e os meros mortais - Sobre a hierarquia

E ai turma, como andam as coisas?
Por aqui mais um dia comum, tranquilo e calmo ao contrário de tantos outros. Deu até tempo de elaborar mais este post cheio de pensamentos mau formulados e de linhas mal redigidas.

Vim para o trabalho hoje pensando a respeito da hierarquia nas equipes de desenvolvimento. Nos lugares onde trabalhei geralmente vivi em um cenário onde existiam os gerente, os líderes, os analistas, os programadores ou dbas ou operadores. E esse cenário era de forma vertical onde: os programadores (ou dbas ou operadores) se reportavam aos analistas, os analistas aos líderes e os líderes aos gerentes. Somente em uma experiência houve o caso onde analistas, programadores e dbas estavam no mesmo nível, mas basicamente é isso. Claro que os gerentes estão no topo da cadeia, porém se estamos falando de pessoas, em geral, com qualificação igual por que existe esta distinção hierárquica? Acredito, fortemente que dentro das equipes de desenvolvimento não existe hierarquia, claro que em toda equipe existem atores que se destacam por ter mais experiência, vivência com a tecnologia ou o negócio abordados, porém estão todos atuando em papéis em linhas gerais que se complementam.
Cada um especializado em seu papel, seja o analista de negócio, o analista técnico (ou arquiteto), o desenvolvedor, o webdesigner e o pessoal de comunicação (para aplicações web) todos estão envolvidos no projeto com a intenção de transformar uma coleção de requisitos em um produto de software.
Pensando em uma linha de produção de automóveis: não existe o caso do cara que monta a porta delegar tarefas ao fulano que é responsável pela montagem do painel, afinal de contas todos estão embuidos da intenção de dar forma a um automóvel. Deveria ser assim também com o software. Claro que as tarefas são interdependentes, se o cara que coloca a porta não colocá-la em tempo hábil para a colocação da fechadura, ou para a pintura todas as atividades da cadeia acabam se atrasando, mas é para isso que serve o gerente do projeto, além de outras atividades, controlar este fluxo e não tão simplesmente cobrar.
Concluindo, a pergunta que me faço é: Qual o diferencial do papel "A" que dá a ele o direito de ser superior hierárquico do papel "B"? Deixo aberto os comentários para as conjecturas.

Por que pensar se é mais fácil copiar?

E ai pessoal como estão indo as coisas,
Tenho percebido ultimamente que com o advento da tecnologia, as pessoas não se dão mais ao trabalho de raciocionar, que segundo os cientistas é o que nos diferencia dos animais irracionais. Estamos passando por um processo de emburrecimento total, e este processo já se iniciou a algum tempo, não é de hoje, alguém se lembra por que não podíamos utilizar as famigeradas calculadoras no ensino fundamental, quando estávamos aprendendo a raciocionar com a matemática?
Desde a calculadora, nos condicionamos a não ter mais que pensar, daí em diante a tecnologia evoluiu e quanto mais evoluiu menos pensamos, da calculadora veio a popularização do computador e suas feramentas mágicas: Calculadora Científica, Planilha Excel e mais contemporâneo ainda o Google. Não que eu não faça uso destas ferramentas, também faço sim e as acho fantásticas. Mas como desenvolvedor, me deparo com a missão de ter que pensar pelo outro, pois sempre aparecem pedidos do tipo: "Não dá para colocar um botão para abrir a calculadora?" ou então: "Esse somatório não podia ser feito automaticamente pelo sistema, para facilitar a conferência do usuário?" ou pior ainda: "Para o usuário tem que ser simples, pois ele não sabe nada de informática."
Como não sou um monstro e nem quero parecer com um, muitas vezes abro concessões para tais solicitações, mas olhando pelo ponto de vista de um desenvolvedor, muitas horas de trabalho são gastas com essas questões, quando poderiam ser utilizadas de forma mais útil, investidas em otimizações de funcionalidades, ou em melhorias do framework por exemplo. Porque na minha opinião, a atividade onde estas horas deveriam ser gastas não é na construção do sistema, mas sim no treinamento de seus usuários, então você aumenta o tempo de construção construindo uma ferramenta altamente inteligível ao usuário e não investe nada - ou quase nada- treinando os usuários, ou seja, ensinando-os a pensar sobre o que eles estão utilizando.
Também não sou contra as técnicas de usabilidade ou de interface homem-máquina, que têm como principal missão facilitar a vida do usuário, mostrando a ele as coisas que ele está procurando. Volto a dizer sou contra a anulação do ser que se imputa ao usuário, fazendo com que ele não seja capaz de tomar uma decisão durante a utilização da ferramenta que é o sistema informatizado, tornando ele um robô refém e não um manuseador desta ferramenta.
Percebo que inclusive em atribuições ditas intelectuais estão se adotando práticas cada vez mais mecânicas, por exemplo no próprio processo de construção de um sistema informatizado, pra quê perder horas escrevendo linhas e linhas de código se podemos simplesmente googar algo que faça o que queremos, afinal de contas: "Outra pessoa já deve ter escrito isso em algum lugar do mundo". E ai que encontramos o código no Google, basta copiar e colar na IDE e partir pro abraço. O problema desta prática, não é o fato de copiar e colar. Mas sim as perguntas que vêm ao redor: Será que a performance deste código está dentro das expectativas do sistema? E a legibilidade? E a manutenabilidade? E o acoplamento (que segundo o manelzinho do Diario do Babaca é sexo)? O cabra que se utiliza desta técnica religiosa (por que é copiar, colar e rezar pra dar certo) não se preocupa com nada disso ele quer é dizer pro chefe que tá pronto e ponto final. Aí ao primeiro problema que isto gera, poe-se a culpa no estagiário (quando tem) ou no Junior da equipe ou então em quem der pra colocar a culpa e mandar corrigir.
Tenho a esperança em que um dia ainda voltaremos a pensar e interagir de forma racional com o meio ai sim seremos tecnologicamente avançados e realmente racionais e daremos a oportunidade a todos de serem usuários.

Um abraço a todos do Pachecas.

Começando agora.

Oi pra você,
Estou enveredando por um mundo novo, apesar de existirem blogs e bloggers já a muito tempo, decidi começar hoje. Quando pensei em escrever um blog de desenvolvimento de sistemas, não me propuz a escrever um blog de tecnologia, com coisas de geeks e tecnocratas em geral, mas gostaria de falar sobre o mundo coroporativo em volta do desenvolvimento de sistemas. Um mundo onde nem tudo são flores e onde as flores geralmente não falam (parafraseando Cartola). Pra começar vou falar um pouco de mim e de minha experiência em desenvolvimento de sistemas corporativos, graças a Deus só falarei de sistemas de informação corporativos, nunca desenvolvi para locadora, ou açougues ou algo que tenha um orçamento tão diminuto e não é que esteja me gabando, mas quem quiser discutir o uso do MS Access na padaria do Sr. Manel, por favor procure outro blog. Bom vamos começar com minha apresentação:
Meu Nome e Adolfo Pacheco, sou desenvolvedor .Net ja a 3 anos, apesar de ser um profissional de nível técnico, tendo por motivos de força maior trancado a facu, tenho cursos na PUC-Rio, Microsoft e na vida em geral. Sou um fanático pelo MSDN® da microsoft e alguns outros poucos sites, sou adepto de fazer as coisas sob medida ou seja, por que utilizar uma biblioteca de AJAX extensíssima se a gente pode criar uma que se adeque as nossas necessidades? Já fui a palestras sobre coisas chatas e interessantes e participei de alguns projetos bastante interessantes dos quais estarei lembrando histórias e contando causos aqui. Lugares onde aprendi o que fazer e o que não fazer, como proceder e como não proceder e porque e legal usar uma metodologia ou outra. Falarei um pouco de boas práticas - o que é bem minha praia, vamos abrir discussões sobre performance de rotinas e outras coisas mais.
Espero aprender bem mais do que ensinar e assim conhecer gente, fazer amigos, ouvir opiniões e o mais importante: abrir um canal para debates. Fiquem a vontade para fazer suas considerações, prometo que me esforçarei ao máximo para responder ou ao menos avaliar todos os comentários e assim vamos ver onde este blog chega.

Atenciosamente
Pachecas