Escrever errado… #atequando?

Nos comunicamos através de códigos e esses códigos são as línguas, que tornam possível interagirmos com outras pessoas. Primeiro,  aprendemos a falar e aos poucos vão nos ensinando algumas regras. E existem regras básicas, por exemplo o pronome oblíquo tônico “mim”, que  não deve ser usado na conjugação de um verbo, mim não leva, mim não faz, … Mas muitos cometem esse deslize. Depois aprendemos a escrever e várias outras regras que formam a gramática da língua. Com isso temos a possibilidade de espalhar nosso pensamento estando presente ou não. A escrita possibilita e-mails, slides em uma apresentação, comunicar procedimentos, ações ou proibições em placas de trânsito; artigos em jornais, revistas, livros, blogs, … Uma infinidade de possibilidades, até mesmo nos tornarmos imortais.

Uma frase muito comum dita por vários desenvolvedores de software em listas de discussão ou no cafezinho na empresa é: “Não preciso saber escrever,  o meu negócio é escrever código”. Isso é uma verdade? Nós desenvolvedores não precisamos saber nos expressar na língua portuguesa escrita? Um desenvolvedor escreve e-mail? Escreve um documento no Word? Ou abre uma thread em alguma lista de discussão? É lógico que sim! Um desenvolvedor de software precisa muitas vezes saber se comunicar por escrito. E precisa fazer isso de maneira extremamente correta para se fazer entender e para isso deve fazer uso das regras gramaticais, ortográficas [tem mais alguma?]. Ou não se vai  entender mesmo! Escrever errado só mostra o seguinte: Você já era incompetente no primário ou ficou preguiçosamente vagabundo depois de adulto.

Quem acha que não precisa escrever direito muitas vezes também não gosta de ler. Pergunta para alguém que disse que não precisa escrever direito qual o último livro que ela já leu. Pergunte qual o livro que ela está lendo ou qual livro na área de desenvolvimento ela leu ultimamente e que a ajudou ou que foi interessante. Você vai ficar sem resposta provavelmente. Ler é essencial e, para escrever bem é preciso ler também. A leitura no mínimo serve como a manutenção do nosso aprendizado da língua.

Se você acha que não precisa escrever português direito… como é o seu código?

A maior parte do tempo um desenvolvedor vai escrever, ou pelo menos deveria! Ele não vai escrever a maior parte do tempo e-mails, artigos, posts ou threads de discussão, ele vai escrever código em um língua que o compilador vá entender e depois transformar em uma língua que a máquina vai entender. As linguagens de programação de sua própria sintaxe, regras. Existem palavras reservadas, regras de sintaxe que, se não obedecidas, seu código simplesmente não vai funcionar. As vezes nem irá compilar! Para a sorte de muitos, erros básicos (o “dá pra mim fazer”), da linguagem de programação são pegos pelo compilador, algumas linguagens funcionam diferente.

Indo além, como é a legibilidade do seu código? Não basta só saber usar as palavras reservadas em uma ordem que funcione, é preciso também escrever bem o seu código. Chovendo no molhado,  é preciso descrever bem o que você quer dizer com aquele código, o @vquaiato já blogou sobre o assuntou quando estava comentando o Clean Code (aliás: você já leu o livro? 😀 ).

Quando estiver escrevendo um código assim você poderá aplicar Command and Query Separation! O Uncle Bob escreveu apenas uma página no livro, mas acho um assunto bem interessante e tenho procurado colocar isso no meu código. A ideia aplicada em funções é que elas façam alguma coisa ou respondam alguma coisa, nunca as duas ações juntas. Exemplo:

[code lang=”csharp”]
namespace CQS
{
class Program
{
static void Main(string[] args)
{
CalculoAumentoDeSalario calculo = new CalculoAumentoDeSalario();

decimal SalarioComAumento = calculo.CalculaAumentoERetornaSalario(10);
Console.WriteLine("Salário com aumento: {0}", SalarioComAumento);
Console.ReadKey();
}
}
public class CalculoAumentoDeSalario
{
private decimal Salario = 1000;
//…
public decimal CalculaAumentoERetornaSalario(decimal percentualAumento)
{
//…
Salario = Salario + (Salario * percentualAumento / 100);
//…
return Salario;
}
}
}
[/code]

Repare no código acima que nem tudo o que o método CalculaAumentoERetornaValor vai fazer está explicito no seu nome, para quem lê só a chamada da função vai entender que irá ser calculado o aumento e retornado e não que já irá alterar o valor do salário. Se essa classe que estiver sendo persistida uma conferência de valor, já que para aumentar o cálculo real compreende vários impostos e realmente é preciso uma conferência; o sistema seria comprometido!

Fazendo um refactoring, melhorando nomes, aplicando CQS:]

[code lang=”csharp”]
namespace CQS
{
class Program
{
static void Main(string[] args)
{
Salario salarioFuncionario = new Salario();
salarioFuncionario.AplicaAumento(10);
Console.WriteLine("Salário com aumento: {0}", salarioFuncionario.Valor);
Console.ReadKey();
}
}
public class Salario
{
public decimal Valor { get; set; }
public Salario()
{
Valor = 1000;
}
//…
public void AplicaAumento(decimal percentualAumento)
{
//…
Valor = Valor + (Valor * percentualAumento / 100);
//…
}
}
}
[/code]

O código ficou mais legível, os nomes refletem melhor o que as funções fazem. Esse é um código de exemplo, alguns nomes ficariam ainda melhores em um código funcional. A função agora realmente só tem uma única função. Faça o teste no seu código!

Obs.: Encontrando algum erro de português nesse post se atenha ao conhecimento, ou seja, faça o que eu digo e não faça o que eu faço. #Bazinga

UPDATE, links úteis:

CommandQuerySeparation, por Martin Fowler

CQRS, por Martin Fowler

CQRS, por Udi Dahan

Arquitetos não existem… só desenvolvedores!

Ou o contrário… eu explico.

Anos atrás,  quando comecei a me envolver mais com arquitetura de sistemas, quando procurei por “coisas que me ajudassem a desenvolver melhor o meu trabalho (tudo começou por que eu achava que deveria existir uma maneira melhor de fazer acesso a dados do que com Dataset’s, mas isso é outra história), eu me deparei com Padrões de design, DDD, e por aí vai; Nessa época o Giovanni Bassi também estava procurando pessoas para discutir arquitetura, e assim que me deparei com o .Net Architects. Passei por uma grande empresa de software no Brasil e lá existia cargo de arquiteto, de arquiteto corporativo, este último trabalhando com a diretoria. Mas conhecendo mais sobre arquitetura, com as discussões no #DNA comecei a pensar que, na verdade, o arquiteto era um papel exercido por um desenvolvedor dentro do processo de desenvolvimento de software, e não um cargo ocupado por alguém pensando somente em arquitetura conceitualmente, mas  sim “codando” junto com o time de desenvolvimento, pelo menos em uma parte significativa do tempo e em PoC’s, ou em partes específicas. Afinal, se o arquiteto não vive a codificação, como ele garante que a arquitetura que ele pensou inicialmente está aderente ou ainda,  que está mais ajudando do que atrapalhando? Sim, por que se a arquitetura é a estrutura na qual será construído um software ela tem que ajudar a codificar, se está atrapalhando, é melhor fazer sem. Ou seja, ninguém deveria ser contratado para ser arquiteto e sim, deveria exercer o papel de arquiteto durante um projeto, ou em uma equipe de um produto específico. Da mesma maneira que podemos estar no papel de tester, ou focado em desenvolvimento de interface (papel de dev de UX), etc…

Para que o arquiteto consiga desenvolver uma arquitetura, o que ele precisa? Conhecimento, experiência; ou não, se o cara é inteligente e cresce com PBL, qual o problema? Existem os skills que não são técnicos, comunicação, habilidade social (afinal ele precisa conviver com o time e não achar que esta acima de tudo isso). E ninguém tem dúvida que ele deve conhecer Design Patterns, frameworks, build, Testes e por aí vai. Mas espera, isso não seria tudo o que um desenvolvedor deveria conhecer? Design Patterns, codificação, framework’s, melhores soluções, tendências, Testes, Build, sem isso um dev não vai desenvolver.

– “Ah! Um dev desenvolve software, ele constrói software, já um arquiteto cria arquitetura, a base, ou um projeto… Não é a mesma coisa.” Será? Um dev realmente constrói software? Vamos fazer um paralelo? Vamos pegar outro segmento de mercado, uma indústria, uma construtora civil… Para se produzir um carro, para se construir uma ponte, é necessário um projeto, existem pessoas com diferentes habilidades lá, nem todas conseguem imaginar um carro ou os detalhes de uma ponte e nem todas conseguem instalar vidros nas portas ou pilares. Então os que não conseguem imaginar os detalhes de construção são dirigidos por um plano, ou um projeto, que é elaborado por pessoas que conseguem visualizar todos esses detalhes. Então arquitetos, engenheiros mecânicos produzem um projeto que serve de guia para operários construirem a ponte ou o carro. Os arquitetos e engenheiros tem uma visão abrangente, mesmo se só desenvolverem um pedaço desse projeto, esse pedaço é abrangente, pois é composto por diversos detalhes. O operário tem uma visão de processo de construção, seguindo o plano. Às vezes dentro desse processo ele consegue sugerir melhorias, novas idéias, mas dentro desse processo.

Voltando ao desenvolvimento de software… O desenvolvedor constrói software? Ele empilha os bits em código de máquina? Ele “builda” o código de máquina? Não! Um desenvolvedor de software constrói um projeto do que ele quer que seja o software, daí ele aperta F5 e envia uma mensagem para o Compilador dizendo “construa um código de máquina baseado nesse projeto aqui, nesse código”. Se o desenvolvedor é quem projeta ele é um arquiteto/engenheiro de software, pois ele exerce as características que definimos como a de um arquiteto. Ele não é simplesmente um operário que segue um projeto, que segue um plano, um processo. Ele pensa, elabora, planeja e PRECISA conhecer tudo aquilo escrito lá em cima: Design Patterns, ORM, Banco de dados, SOA, linguagens de programação, código, frameworks, protocolos, API’s, UX, etc… etc… Um desenvolvedor que apenas sabe usar IF…ELSE, FOR…EACH, SWITCH, simplemente não estudou o suficiente, é iniciante, ou esta enganando alguém. E ainda não leu “Clean Code”.

Se todos os dev’s se comportarem com o que esperamos hoje de um arquiteto eles serão realmente responsáveis pelo código que estão gerando, já que a arquitetura será dele também, já que ele vai ter que estudar, e muito, para aprender tudo isso. Ele também vai aumentar a visão que tem do projeto, poderá ver coisas que não estava entendendo e que contribuíram para um desenvolvimento mais pobre que ele tenha feito. É óbvio que um desenvolvedor que acabou de iniciar na profissão não terá conhecimento e experiência suficiente para codar sozinho definindo frameworks, arquitetura, mas com o auxílio de um outro dev mais experiente ele irá adquirir essa bagagem.

Então desenvolvedor,  pense como um arquiteto, seja um arquiteto! O projeto/código é seu!