Trabalho em paralelo

Engraçado, não sei o que passa na cabeça do pessoal de TI às vezes.

Quantos de vocês trabalham eme paralelo? Quero dizer, fazem duas ou três coisas "ao mesmo tempo" ou trabalham em mais de um projeto ao mesmo tempo?

Acho que a gente acostuma tanto que o computador consegue lidar com várias coisas ao mesmo tempo que a gente acha que consegue fazer o mesmo. Só que enquanto o processador de um micro fica a maior parte do tempo ocioso, não é nosso caso. Se vc pegar um computador que está trabalhando a 100% de CPU e colocar outra coisa pra rodar junto, ambos os serviços vão demorar o dobro do tempo (ou mais) para serem concluídos. O mesmo ocorre conosco porque, via de regra, não temos tempo "ocioso".

Me lembra um caso que eu gosto de contar: Um antigo chefe meu me chamou na sala dele, me deu um escopo e disse:
"Por alto, quanto tempo você acha que dá pra fazer isso?"...

Perdi uns 15 minutos olhando e falei:
"De um a dois meses".

Ele:
"E esse?"

Gastei mais um tempo olhando e disse:
"É parecido com o primeiro, deve levar mais ou menos o mesmo tempo".

O olho dele brilhou:
"Ótimo! Isso significa que no próximo mês temos tudo pronto, certo?"

Eu:
"???... Não... se cada projeto leva 1 a 2 meses, daqui 2 meses temos um pronto e daqui a 4 meses temos o segundo pronto!"

Ele:
"Mas e se você trabalhar nos dois ao mesmo tempo?"

...

Não sei o que passa na cabeça das pessoas pra conseguir formular uma lógica dessas.

Rules to live by

"Complaining don't fix things,
Blaming just causes more trouble,
We are trying to get things done here,
If you can't help, at least get out of the way."

"You're not able to tell me if that's easy or not,
you're not able to tell me if that's fast to make of not.
Unless you are the one who will do it."

"I don't care about the best way. I need a good way that works."

"Double things to do, double time. Triple things, triple time. That's basic arithmetic, right?"

"If you can't put it in numbers, you don't really know about it"

And the basic principles for any developer: K.I.S.S. and D.R.Y. (I would also add "C.O.C." - Conventions over Configurations, but that's a nice thing to have, not a must one)

As partes que precisam ser especificadas em um sistema web

A aparente simplicidade de sistemas web (tela -> banco, banco -> tela) faz com que a gente subestimar coisas e NÃO especificar nem pensar muito em algumas delas que são simplesmente essenciais.

Aproveitando o tema da aula de hoje (teste de especificação), comecei a bolar um check list de coisas que deveriam ser especificadas para cada TELA em um sistem web.

A lista é só um rascunho, mas acho que já é um bom começo.

• Quais entidades e campos precisa para carregar a página?
• Quais entidades e campos precisa pra gravar? São os mesmos para carregar a página?
• Quais validações cada campo precisa, estão todas especificadas individualmente?
• Para poder gravar, alguma entidade tem que estar em algum estado específico? Tem que existir alguma outra entidade que não as que foram listadas nos dois primeiros itens?
• O que acontece quando não é possível gravar?
• A tela tem espaço para exibir os erros? Lembrando que ficar exibindo um erro de cada vez na gravação é muito chato para o usuário.
• Se a tela grava em mais de uma entidade, é possível que ela seja um processo, não simplesmente um caso de tela -> banco, banco -> tela. Esse processo está descrito como tal? Possui validações? Você consegue buscar todas as entidades envolvidas com as campos que tem na tela? Os campos que tem na tela são suficientes para você alterar os estados das entidades de acordo?

Bom, acho que tem mais coisas na lista, mas vou melhorando aos poucos.

Deixei passar algo óbvio?

Tela, banco - banco, tela.

Tava pensando nas aplicações de hoje em dia. Todo mundo quer fazer elas pra web (quando não pr rodar em celular). Isso facilita muito as coisas.

Dada a natureza "em lote" da web, as aplicações acabam ficando muito mais simples e desconectadas. Já que uma página não consegue se conectar com outra direito, e quando consegue é obrigada a passar um "pacote" de dados ao invés deles individualmente, você acaba criando (inadvertidamente) vário protocolos de comunicação entre elas :)

No final das contas, as aplicações web viram um monte de páginas com a seguinte estrutura: "Da tela pro banco" ou "do banco pra tela", com algumas transformações no meio que o pessoal chama de lógica de negócio (e validações).

Migrar uma aplicação dessas é bem mais simples. Alterar ela é BEEEEM mais simples. No final das contas, as limitações acabaram formando um ambiente mais saudável.

Tá certo que tem uns Zé Ruelas que conseguem fazer a coisa tão complicada que os dados de um lado pro outro são passados meio por Session, meio por Request, e um pouco por banco. Fazer isso em partes diferentes da aplicação é normal, duro é quando de uma simples página pra outra vc recebe as coisas por mais de um lado :| tipo "bombardeio de dados"

Agora, com AJAX (legal!!!) as aplicações estão ficando muito mais inteligente (finalmente!). Mas está abrindo brecha pra cada barbaridade :p

Vai ser interessante, aguardemos e observemos.