Estas leis são muito importantes e são para o mundo da criação do software o que as leis de Newton são para a física ou as leis de Asimov para  a robótica.  As leis de regem o desenvolvimento devem ser a base para novos trabalhos, inovações e progresso da forma como fazemos software. É preciso entender que estas leis não dependem da tecnologia utilizada e por isso são válidas em qualquer tempo.

1. Lei Fundamental Do Desenvolvimento de Software

“O tempo necessário para criar um software completo é infinito“

Esta lei é simples, mas tem consequências muito complexas. Significa que nunca você poderá alcançar o software completo. Isto pode parecer castrador, mas significa realmente que temos que aproveitar melhor o tempo e tentar não criar o software completo, mas o software “completo o suficiente”. O conceito de “suficiente” leva a considerações de necessidade, disponibilidade de recursos e outros constrangimentos. Por outro lado, deixar o tempo ser uma variável em vez de uma constante levará um resultado absurdo. Ou seja, se você tem um software suficiente você deve estipular um período para o seu desenvolvimento.Concluímos , portanto, que o prazo do desenvolvimento nunca é uma variável. É a condição de “suficiente” que é a variável. Dito de outra forma, o prazo sempre é fixo e o conjunto de funcionalidades sempre é variável.

2.Leis de Parkinson’s

“O trabalho se expande pelo tempo disponível”

Isto significa que em qualquer tarefa, projeto, atividade aquilo que houver para fazer será diluído no tempo que for estabelecido para a realização desse trabalho. Ou seja, em outras palavras dado um certo trabalho e um certo periodo de tempo, nunca a atividade será realizada no inicio do perido, deixando o final do periodo sem nada para fazer. Isto é outra forma de dizer que : o trabalho nunca estará pronto antes da data final do prazo.

Sindrome do Estudante

“O inicio do trabalho acontece no ultimo momento possível antes do final do prazo”

Isto significa que você designar alguém para uma tarefa e lhe der um prazo, a pessoa irá protelar o inicio da atividade até o ultimo momento possível. Este limite é imposto pela própria pessoa que irá realizar a tarefa. A pessoas faz isto para poder aproveitar o principio do prazo que lhe deram para fazer outras coisas. Se chama “do estudante’ por é exatamente assim que um estudantes se comporta com o estudo ou deve de casa. Sempre é feito na ultima hora. Mas sabemos que nem todos os estudantes fazem isto. Logo, o síndrome do estudante, como outros síndrome pode ser controlar através de treinamento. O síndrome do Estudantes aliado à lei de Parkinson torna um problema em um risco e um potencial desastre. A Lei de Parkinson não pode ser alterada, mas outros fatores devem ser minimizados.

3.Lei de Pareto

“80% das consequências se devem a 20% das causas”

Este principio tem várias aplicações práticas. A primeira é que 80% dos bugs resultaram de 20% do código. A segunda é que 80% do trabalho será feito por 20% da equipe.  O problema do principio é que você não sabe à partida quais 20% causarão quais 80%.  É por isto que sempre ha que vigiar por um bom design e uma boa codificação porque você sabe que irá alterar pelo menos 20% do software porque irá causar 80% dos problemas. É também por isto que é tão importante a disseminação de informação e cultura na equipe , pois se acontece alguma fatalidade com os 20% que realizaram 80% do trabalho, a empresa terá um problema muito grave, sendo possível até que não consiga acabar o software.

4. Navalha de Occam

 ”A explicação de um fenômeno deve ser baseada no minimo possível de premissas, eliminando aqueles que não fazem diferença para as predições observáveis”

A Navalha de Occam ( também conhecido como Principio de Parcimônia)  é uma ferramenta de raciocínio muito aplicada em ciências naturais. Ela pode ser aplicada no mundo do software de várias formas. Duas são realmente importantes. Durante o levantamento de requisitos aprenda o máximo possível sobre as regras de negocio. Esta fase é chamada Coleta.  Depois analise como essas regras de relacionam. Esta fase se chama Analise. Por fim, simplifique e remova as regras que não são necessárias e/ou que derivam de outras regras. Esta terceira parte é chamada Síntese.  Hoje em dia as pessoas falam muito em analise. Temos até os Analistas. Mas o que realmente é importante é a sintese. É a sintese que cria um software mais simples porque em vez de implementar 100 regras você implementa 10 que produzem o mesmo resultado. Por outro lado, ao escrever código, o código deve envolver o menor numero possível de parâmetros. Sempre que um parâmetro poder ser inferido de um conjunto de outros, esse parâmetro é desnecessário

A redação desta lei pode ser escrita então em temos mais adequados ao desenvolvimento de software :

 ”A especificação de uma regra do sistema deve ser baseada no minimo possível de premissas e parametros, eliminando aqueles que podem ser derivadas das outras.”

Esta lei é conhecida na cena de desenvolvimento pelo acrónimo KISS (Keep it simple, stupid. Particularmente eu acho acrônimo ofensivo. Realizar a síntese não é trivial e a pessoas não conseguir fazê-lo não a torna estupida. O principio KISS realmente utiliza a palavra estupido no sentido contrário. O principio KISS parte do principio que a pessoa irá se esquecer de detalhes e do por quê de certas decisões. Ou seja, assuma que você é estupido, e por isso mantenha as coisas simples. Eu acho que a Navalha de Occam é muito mais elegante, e aplicando a Navalha de Occam ao principio KISS podemo facilmente concluir que a premissa que a pessoa é estupida é irrelevante.

5. Lei de Brook

“Adicionar pessoas a um projeto não diminui o seu tempo de execução, só o aumenta”

Esta lei é bem conhecida e tem várias outras redações possíveis. A redação mais simples e conhecida de todos nós é :

“A tarefa de gestação de uma criança  demorará 9 meses. Não importa quantas mães forem designadas à tarefa”

Basicamente esta lei representa que as tarefas têm um tempo que lhes é inerente e que mesmo com todas as ferramentas do mundo e a melhor inteligencia não dá para realizá-las mais cedo que um certo limite. Por outro lado, adicionar pessoas a um projeto multiplica a rede de canais de comunicação. Se você tem 2 pessoas em uma sala, A e B,  você tem 1 canal de comunicação (A-B). Com 3 pessoas você tem 3 canais (A-B, B-C, C-A). Com 4 pessoas você tem12 canais … em geral com N pessoas você tem N*(N-1)  canais de comunicação. A cada pessoas adicionada você gera 2(N-1) canais. Para resolver estre problema as empresas tendem a usar um modelo de hirarquia como no exercito. Isto funciona se um dado grande grupo de pessoas faz a mesma atividade. No exercito quando a cavalaria ou a infantaria são mandadas “atacar” cada individuo sabe o que tem que fazer, e o que ele tem que fazer é igual ao que o outro está fazendo. Não ha instruções especiais para cada individuo. Contudo, mesmo no exercito, o grupos de operações especiais não funcionam neste modelo. O modelo usado em comandos especias é um modelo em estrela. O grupo é pequeno, e cada pessoa tem comunicação apenas com um individuo que lhe passa instruções com pormenor. Ou seja, quanto mais especifico são as instruções ao individuo, menos um modelo hierárquico é adequado. No modelo em estrela adicionar uma pessoa cria apenas 1 canal, e não 2(n-1) canais.

6. Revelação de Sturgeon

“90% de tudo é CRUD”

Esta revelação é chocante. Se você não se sentiu chocado por ela, você não entendeu direito.Lei de novo. Ah! claro, CRUD significa “Create, Retrive, Update, Delete” as 4 operações básicas em um sistema de dados. Várias implicações saem desta revelação. A primeira é que se você não tem um mecanismo de persistência robusto, fácil de usar, você está indo para um buraco negro e profundo. A outra é que, mesmo mecanismos que não parecem CRUD são de fato CRUD. Repare que a revelação não diz que 90% é cadastros  e sim que 90% é crud. Cadastros são uma parte do problema, e cadastros em si mesmos são 90% CRUD, mas a revelação é o sistema, como um todo é 90% crud.

A revelação é chamada assim porque dá base interpretativa à  Lei dos 90%, que diz :

“Os primeiro 90% do código são responsáveis pelos primeiros 90% do tempo de desenvolvimento. Os outros 10% do código, são responsáveis pelos outros 90% do tempo de desenvolvimento.”

Confuso ? Sim. Por isso que a Revelação de Sturgeon é tão importante e tão profunda. Podemos entender da seguinte forma. Se 90% de tudo é crud, então CRUD é sempre parte de 90% de tudo.Portanto, 90% do projeto é criar o CRUD em sim. Os outros10% é usar o CRUD. Mas os outros 10% são a razão de porque você precisou criar o crud em primeiro lugar, logo 10% são responsáveis pelos 90% do tempo de desenvolvimento.

A leis dos 90% lida na sua forma pura, leva a considerar que o projeto demora 180% do tempo. Claro que é uma provocação, mas a Revelação de Sturgeon torna explica realmente muitas coisas, sem provocação.

7.Lei da Ação-Reação

“Para cada ação de engenharia acontece uma ação social igual e oposta”

Esta lei é uma paráfrase da segunda lei de Newton também chamada Segunda Lei de Augustine. Esta lei explica várias coisas, mas entre elas a dificuldade que o corpo técnico tem em fazer seja o que for sem a interferência do resto das pessoas do projeto. Quem é técnico se preocupa com mecanismos, variáveis,  razões, e emoções que são irrelevantes ao software ou a criação do software. E por simples desconhecimento, qualquer ação que parte dos técnicos é vista com preocupação e descrédito o que leva a uma pressão social de a contrariar. “social” aqui não significa “da sociedade” mas “por meios sociais” em oposição a “por meios técnicos”.  É por isto que soluções brilhantes podem ser destruídas por gostos e desgostos do cliente, gerentes, diretores ,  com base em … Bom, com base em nada , realmente. Não existe nenhuma razão racional, apenas um desconforto em aceitar a ação técnica. O curioso é que nas poucas vezes que uma ação técnica consegue vencer o obstáculo da reação social, as pessoas quase sempre se surpreendem com os resultados.

 8. Lei dos Falsos Alertas

“À medida que a frequência de falsos alertas de problemas aumenta, a credibilidade de alertas subsequentes diminui”

Quando tudo o que o usuário não espera ver na tela é um bug, mesmo quando é um aviso do sistema dizendo que o usário fez algo errado (ou seja, mesmo quando é um erro previsto). Quanto todos os bugs são críticos e impeditivos, menos críticos impeditivos eles são de fato.  Esta lei representa o desconhecimento que os usuários e clientes têm do software que eles mesmos encomendaram e a tentativa estupida de manipular o fornecedor dizendo que tudo é erro e tudo é impeditivo para. Esta lei é fortemente presente em contratos de risco em que o cliente consegui colocar o fornecedor em uma posição de dívida e recompensa futura. Ou seja, tudo o que o cliente quer mudar, ele considera um erro. Isto porque o contrato considera que apenas quanto todos os erros estão resolvidos é que o software está pronto e o fornecedor irá receber seu dinheiro. Ora, isto é uma falácia (Lei fundamental do software – nunca todos os erros estarão resolvidos) . Assim o fornecedor se colocou em um situação em que perde sempre que o cliente encontra um erro. Então, tudo o que o cliente encontra é um erro para forçar o fornecedor e fazer o que se pede. O mesmo principio é usado com a prioridade. Tudo é impeditivo para que o fornecedor sinta que não irá receber o seu dinheiro se não resolver aquele problema.

Sabendo desta lei os fornecedores devem realizar bons contratos, com estipulação especifica do que significa “impeditivo”  e “erro”. Os fornecedores deve aconselhar e treinar o cliente a entender a escala. O fornecedor deve medir a razão “falsos alertas” / “todos os alertas”  e a sua frequência. Sempre conversar e mostrar estes números ao cliente explicando que isto está atrazando o projeto e causando esforço desnecessário. Claro, que medidas de minimização do problema devem ser propostas e aplicadas tais como o treinamento, a redação de manuais e o teste acompanhado.

 9. Lei de Hoare

“Dentro de cada grande problema, existe um pequeno problema lutando para aparecer”

Considerado a Lei de Pareto é sabido da probabilidade  de um grande problema pode ser originado um pequeno problema. O que a lei de Hoare no diz não isso. O que ela no diz é que depois de resolver um grande problema ou enquanto um grande problema é resolvido, pequenos problemas aparecem.  Isto leva à multiplicação dos problemas e por consequência a um aumento no esforço de corrigir o problema original.  Por outro lado, podemos interpretar que todo o grande problema é constituído de pequenos problemas.

Esta lei está diretamente relacionada com o problema da manutenção e como o design do sistema têm que ser simples de forma a que cada pequeno problema seja o mais facilmente solucionável, já que é bem provável os encontremos quando resolvemos problemas grandes.

10. Lei de Hofstadter

“Uma atividade sempre consome mais tempo do que esperado, mesmo quando você leva em consideração a Lei de Hofstadter”

Está é uma lei recursiva. A recursividade dá-lhe um ar nerd, mas realmente é necessária. Esta lei significa que você sempre irá estimar errado a duração de uma atividade e/ou ela sempre demorará mais do que esperado por si, mesmo quando você conhece esta lei, ou seja, mesmo quando você estima a mais do que a sua intuição. Aconteceu comigo quando escrevi este post. Afinal quão dificil é elencar o top 10 das leis do software. Bem, é mais dificil do que parece…

Existem muitas outras leis e corolários relacionados ao software [1][2]. Tomeis as 10 que são mais genéricas e com as quais me deparo todos os dias. Existem muitas outras especificas de tecnologias, situações, tipos de software , algumas ligadas a harware como a famosa Lei de Moore ou algumas demasiado genéricas para serem elencadas como leis de desenvolvimento como a Lei de Murphy ( “Se algo errado poder acontecer, irá”)

Em próximos posts irei discorrer sobre como estas leis se relacionam ao Scrum tentando demonstrar que porque o Scrum se aproveita destas leis, ele funciona. Também tentarei falar sobre leis mais próxima ao código e ao design que deriva destas leis mais genéricas.

O Java 7 traz algumas alterações na linguagem Java,  algumas alterações na JVM e algumas API novas. Além disso temos a primeira alteração no bytecode desde sempre. Podemos dizer que o tema do Java 7 é “Criar caminho para o Futuro” (leia-se Java 8 e 9). Como alterações na Linguagem temos : Swicth com Strings ,melhor inferência de tipos com operador diamante e alterações para invocação de var-args , melhores literais para números,  base binária e melhor suporte a tratamento de exceções (multi-catch , re-throw e try-with-resources) e suporte a unicode 6.0.  Para as API temos a nova API de processamento paralelo Fork-Join  e a nova , muito aguardada , FileSystem API (parte do novo pacote de IO:  NIO.2) .Existem também alguns melhoramentos na API java.util.Locale para  internacionalização como a nova enum Locale.Category que permite distinguir objetos Locale para display e para formatação. A NIO.2 traz também suporte a mais protocolos de cominicação como SCTP , SDP entre outros. A alteração no bytecode é a nova instrução invoke dinamic que traz consigo a nova API de manipulação de métodos. Além disso muitas melhorias na renderização. A lista completa de mudanças na pagina de release da Oracle

Não vou exemplificar cada alteração existem muitos sites sobre isso. Quero, em vez, me debruçar sobre  as causas e consequencias das alterações.

Switch com Strings. Esta funcionalidade é a mais perigosa de todas. Não vai ajudar a escrever programas melhores já que vivemos escrevendo programas sem ela ha 15 anos. Adicionar esta capacidade só vai ajudar a cria Programas Orientados as Strings (POS) ou pior, programas orientados a gambiarra (POG). Uma discussão interessante sobre switch e sua historia aqui. Mas o objetivo desta funcionalidade não é melhorar o Java. Esta era uma requisição de melhoria desde o java 1 que não viu a luz do dia devido ao problema associado à função de hash usada na classe String que foi modificada e melhorada ao longo do anos. É que, para isto funcionar, é necessário usar a função de hash para transformaro switch de string em switch de int que é o que realmente funciona eficientemente, mas para isso o resultado do hash tem que ficar hardcoded no .class. O Java 7 deu este passo estabelecendo que a implementação de hashCode do String não irá mudar mais. Mas será que não ? Eu por mim vou continuar não usando Strings para este tipo de coisa. Aliás uma regra bem válida do Efective Java.

Melhorias na inferência de tipos. O operador diamante é bem vindo já que nos livra de repetir um monte de assinaturas de tipo. Para quem já escreveu mapas de coleções sabe do que estou falando. Além disso usar tipos genéricos em var-args não causa mais um aviso do compilador.  Nada do outro mundo para o programador, mas o trabalho que o compilador faz para inferir os tipos e , no seu melhor, evitar erros, é extraordinário. Uma alteração direcionada a nos fazer escrever menos respondendo às criticas que o java é muito verborraico.

A possibilidade de escrever numeros em base binária é relativamente interessante. Útil se você mexe com protocolos/arquivos binários. A nova possibilidade de separação de algoritmos com underline ajuda bastante a formar os bytes ou as palavras. Uma mudança à primeira vista estética, mas que é direcionada a usar java como uma linguagem de “baixo nível” para ler e escrever binário.

A grande alteração da linguagem são as novas funcionalidades relacionadas ao bloco try-catch. A primeira é a possibilidade de capturar multiplas exceções de um catch só. Isto ajuda a escrever menos blocos de codigo e ajuda a seguir o principio DRY (Don’t repeat yourself – Não se Repita). Contudo criaria um problema caso você pense em relançar a exceção.  A inferencia de tipos entre em jogo aqui também. Ao relançar a exceção o compilador sabe fazer o traking de quais exceções são possiveis dentro do try e portanto quais são possiveis para relançamento.

A outra mecanica que se aproveita do relançamento é o novo try-com-recursos que é uma forma de trabalhar com recursos “fechaveis”. A nova instrução toma conta de chamar o .close no momento certo e tratar as exceções que são lançadas no close.   É um problema quando você acessa o banco, dá erro no resultset você captura e fecha a conexão, mas ai dá erro no fechar da conexão. A exceção que você recebia era a que aconteceu no close e não a que aconteceu no resultset. Isto era realmente um problema e se você quisesse controlar isto. Agora, o java 7 modificou essa regra – desde que use o try-com-recursos  – em que a exceção lançada é a exceção original, e a excação secundária (chamada de exceção suprimida) é adicionada ao stackstrace de forma “paralela” usando os novos métodos na class Throwable addSupressed e getSupressed. O controle de exceção ficou ainda mais robusto.

isto é importante porque é usado no URLClassloader. Este é o classloader mais utilizado que não tinha uma semantica de fechamento, e agora que tem, sem um mecanismo robusto como o try-com-recursos , continuaria dando memory-leaks. A sintaxe não é a mais intuitiva (estão planejadas melhorias para o java 8), mas é uma instrução de controle muito importante e que faltava no arcenal.

O tema do Java 8 será “Multicore” e o do Java 9 “Cloud”.

Para multicore dar certo o fork-join é um framework necessário. Existiu muita polemica se seria util lançar este framework sem lançar closures (lambdas), mas acabou saindo. Lembrar que esta versão do java é mais para desenvolvedores do que usuários e em particular para desenvolvedores que desenvolvem mecanismo em cimado java (como quem desenvolver as ‘vm’ de jruby, scala , etc…) . Com a liberação “adiantada” estas equipes têm mais tempo para se preparar para o mundo com lambdas do java 8.

Para o cloud dar certo, além do multicore, é preciso abstrair o sistema de arquivos. Servidores de aplicação poderão tirar partido disto. A nova API de Filesystem permite trabalhar não apenas com discos da máquina, mas criar sistema virtuais de arquivos , por exemplo, acessar um zip como se fosse uma pasta. Isto é uma tendencia e era aguardado ha muito tempo ( aliás eu já tinha abordado este assunto de arquivos virtuais no MiddleHeaven). Mas API que fará ainda mais diferença – expecialmente para criadores de ferramentas e servidores -  é a API WatchService que permite registrar listeners para escutar quando arquivos são modificados, incluidos ou excluidos. Hoje isto é feito com threads e timers, mas com a nova API estaremos ligados diretamente ao sistema operacional que avisará a API quando algo mudar e a API nos avisará a nós. Espero que as proximas versões de servidores de aplicação se baseiem nestas features.

Resta falar sobre o invoke dynamic. Esta instrução do bytecode permite que se invoque um método sem que se saiba qual a sua implementação. A implementação do método será pesquisada em runtime. É um mecanismo bem complexo que permite criar links dinamicos com métodos em runtime. Isto é ideal para linguagens como groovy e ruby que permitem chamar métodos em classes como se eles lhes pertencessem mas na realidade não estão definidos na classe (  e sim em alguma outra classe ). Esta instrução é orientada a simplificar a vida de quem tem que implementar as vm das linguagens dinamicas e com isto tornar a JVM realmente poliglota.

A API Java foi incrementada para poder manipular métodos de forma programática. Isto é interessante porque é agora possivel criar operações de currying e outras coisas interessantes da programação orientada a funções mesmo ainda sem lambdas.

À parte da swicth de strings que navega contra a maré o resto das alterações é bastante poderosa. O ponto é que toda esta capacidade é em potencial e não muito “pártica” ainda. É mais ou menos como o generic do java 5, demorou um tempo até que as pessoas se abituassem e começassem a fazer coisas interessantes com a ferramenta. O Java 8 promete uma mega alteração da forma de programar em java, e o 9 uma mega alteração na forma como entendemos JEE  , mas o Java 7 lança as bases e traça algumas direções dando ferramentas para aumentar a eficácia dos códigos e o alargamento da base de linguagens que rodam na JVM.

Se começasse um projeto novo hoje, muito provavelmente usaria java 7, não pelo que ele traz de novo, mas como preparação para o java 8 que, se tudo correr bem, irá ver a luz do dia em 2013.

O Java, e mais propriamente a Sun no seu compêndio de boas práticas, deixaram claro que a nomenclatura é vital para o sucesso de um API. A nomenclatura tem várias facetas, e todas elas devem ser consideradas.

Tipografia

A tipografia dos nomes é importante. Em java foi criado o padrão de usar nomes em Camel Case. Você deve conhecer o Upper Case ( Caixa Alta) que significa que todas as letras da palavra são maiusculas – por exemplo : SERVICODECOBRANCA -, o Lower Case (Caixa Baixa) em que todas as letras das palavras são minusculas – por exemplo : servicodecobranca. O Camel Case (Caixa Camelo) é quando todas as letras inicias das palavras são maiusculas e o resto minusculas – por exemplo: ServicoDeCobranca. Note como os seus olhos entendem melhor o camel case do que qualquer outro case já que as maiusculas atuam como separadores naturais.

Outras linguagens adotam padrões diferentes como o uso de underline (por exemplo: servico_de_cobranca) que o java utiliza também em certas circunstancias. A tipografia de uma constante é uma mistura do Upper Case com o uso de underline (SERVICO_DE_COBRANCA).

É importante que todo o seu codigo seja escrito com a mesma tipografia. Muitas pessoas se habituaram a usar o eclipse e as suas milhentas formas de pintar texto para separar as coisas, mas usando uma tipografia padronizada ( a que a Sun criou e recomendou por anos) você não precisa de cores e estilos.

Justaposição

A justaposição é um dos mecanismos que existe nas línguas para criar novas palavras. A justaposição se caracteriza por simplesmente justapor (colocar as palavras juntas) sem nenhum tipo de modificação das palavras. Por exemplo, guarda-chuva e passatempo. Note que as palavras não foram modificadas. Enquanto que outras formas de criação de palavras como a aglutinação levam à modificação das palavras originais. Por exemplo , planalto (= plano + alto) em que o ultimo ‘o’ de planalto desaparece.

A justaposição é a forma mais simples de criar nomes para classes, métodos e variáveis já que não é necessário modificar a palavra original, e, no caso, não nos precisamos preocupar com sinais como o hífen já que o Camel Case separa as coisas para nós.

Língua

É importante escolher a língua do seu código. Isto é mais complexo do que parece. A língua inglesa é mais simples de usar já que em inglês a justaposição é muito natural e soa bem. Em português nem sempre soa bem juntar várias palavras juntas. Além disso nomes de padrões de projeto são em inglês , e como veremos adiante, é comum usar esses nomes ao compor nossas nomenclaturas. DesktopSingleton (Desktop + Single + ion) soa bem melhor que TopoDeMesaSolteirao (Top da Mesa + Solteiro + ião). Poderiamos pensar num DesktopSolteiao ou TopoDeMesaSingleton, mas ai é misturar o pior de cada parte.  Usar inglês também tem a vantagem de não usar acentos e outros dilacrílicos (é por isso que se escreve facade e se lê façade), que embora a língua inglesa os aceite  ( Façade é uma palavra inglesa escrita com ç porque vêm do francês) não é comum vermos usar ( porque os teclados as pessoas que falam inglês nativamente, não têm o caractere ç).

A resistência de muitos a usar o inglês advém de dois problemas : 1) falta de vocabulário e 2) pode violar a regra de que se deve usar um glossário de projeto. O primeiro motivo é fútil e qualquer dicionario pode resolver isso. O segundo motivo é mais sério. Se o cliente fala português nativamente e define seus conceitos de negocio em português porque então traduzir isso para inglês? Algumas coisas até seriam triviais : produto -> product , cliente -> costumer , mas fatalmente cairíamos no Nota fiscal -> ? , Pedido -> ? ou CPF -> ? . Assim muitos preferem usar uma mistura de inglês com português, usando o inglês para código de infra e padrões e o português para objetos de negocio.

O meu argumento é que se você realmente quiser você consegue usar apenas nomes em inglês. O lance é utilizar o domínio em inglês também. Por exemplo, a nota fiscal é um documento que prova que o objeto é seu, que você o comprou. Desse ponto de vista ele é uma “nota de venda”  e a tradução seria “bill of safe”(literalmente nota (bill) de (of) venda (sale)).  Pedido seria Invoice, embora invoice possa ter significados mais refinados ligeiramente diferentes de pedido, mas contém os mesmos itens básicos: quais os itens, quantos, de quem, para quem. Já o CPF é algo próprio do pais e nem sequer do domínio do negocio de compra e venda. Está mais relacionado a impostos. Contudo poderíamos criar um nome que traduzisse o conceito em vez de traduzir o nome, por exemplo Individual Tax Registry Code (ITRC). Rebuscado ? Depende. Para um sistema feito em pais de língua oficial portuguesa para pessoas que falam português nativamente, definitivamente. Mas para software que será usado no estrangeiro ou que pretende se adequar a vários mercados, ou que se pretende que seja open source, talvez não seja tão absurdo.

A moral aqui é que deve ser considerado o objetivo e o publico alvo do software e do código de forma que para os usuários do software o código possa fazer sentido. Isto em DDD se chamaria de usar a linguagem ubiqua, mas na realidade estamos adequando o máximo possível o código ao glossário.  Por outro lado, se você consegue fazer código de infra em inglês por que não código de negocio ? A resposta é que você conhece o domínio “infra” muito melhor, e é natural para si – programador – usar inglês. Apenas isso.

Depois que decidir que língua usar , ou como misturar duas línguas, mantenha-se fiel à escolha.

Substantivos

Vimos várias coisas que ajudam na nomenclatura, mas existem regras para criar os nomes eles mesmos ? Existem.

Classes e Interfaces têm nomes simples que refletem diretamente os conceitos do modelo de negocio. Sem prefixos ou sufixos. Se quer modelar um cliente use “Cliente” como nome da classe. Se for uma interface não use “ICliente” por exemplo. A razão disto é simples : polimorfismo. Se eu digo “Veiculo” você não sabe se é uma interface ou uma classe. Ótimo. É assim mesmo que tem que ser. Se eu usar “IVeiculo” automaticamente estou dizendo que é uma interface, o que viola o proposito do polimorfismo.Além de que aquilo que hoje definiu como interface, amanhã pode virar um classe. O modelo evolui. O uso do I é uma remanescencia da notação hungara e é usado na corrente .NET já que essa corrente herdou várias coisas dos antepassados VB, Delphi e do codigo do windows, como comentei antes. É lícito usar o I em .NET porque essa é a convenção nesse ambiente, mas em pura orientação a objetos , e no java, não.

Se eu precisar criar um objeto utilizando o padrão Builder então justaponho os nomes como ClienteBuilder ou VeiculoBuilder. Normalmente os builders são mais usados com interfaces, mas isso não obrigatorio. Aqui a lógica é utilizar o nome do padrão como sufixo e aproveitar o nome do conceito. Usando este padrão de nomenclatura teriamos por exemplo ClienteProxy, ClienteRepository, ClienteFactory, etc… Contudo não se utiliza este padrão com singleton nem para as implementações do padrão Service. Não se nomeia ClienteSingleton. Isto pela mesma razão do uso do I em interfaces : quebra o polimorfismo e o que hoje é singleton, amanhã poderá deixar de ser.

Na questão do padrão service, definimos uma interface como o contrato do serviço e mais do que uma implementação. Cada implementação é especializada por alguma razão e isso distingue uma implementação do serviço das outras.Por exemplo , para o serviço PrintService poderiamos ter um PDFLocalFilePrintService , um SystemPrinterPrintService e um WebRemotePrintService (como exercício, experimente colocar estes nomes em português). Todas as implementações terminam com o nome do serviço mas descrevem o objetivo da implementação. É claro que a primeira implementação irá criar um PDF em disco local, a segunda usará uma impressora de fato e a terceira algum serviço de impressão via web ( sem dizer se será em uma impressora ou arquivo). Isto se aplica também ao padrão DAO (que é uma especialização do padrão de serviço) onde teremos coisas como JDBCClienteDAO ou BigTableClienteDAO ou LDAPClienteDAO. O uso de Impl com o sufixo (ClienteDAO e ClienteDAOImpl, por exemplo) além de ambíguo e desinformador (como é a implementação ?) é pura falta de imaginação.

A mesma regra de nomenclatura pode ser seguido em geral com interfaces onde antes do nome da interface é dito algo sobre como aquela implementação é diferente das outras. Exemplos classicos são ArrayList , LinkedList e HashSet e LinkedHashSet ( este é duplamente qualificado)

Este regra de momenclatura também funciona bem quando você quer juntar conceitos que não são necessáriamente padrões de projeto, mas que você definiu um conjunto de classes com um proposito semlhante, por exemplo ClienteManager se vc criou o conceito de Manager ou XMLTextTransformer se você criou o conceito de TextTransformer. Não necessáriamente estas classes herdam de Manager ou TextTransformer, pode ser uma classificação puramente conceptual. (Se for puramente conceptual recomenda-se que crie uma interface marcadora e faça todos os objetos que partilham o mesmo conceito implementá-la. Leia Herança e Interfaces para mais detalhes deste assunto)

Uma variante do padrão de sufixo indicando padrões de projeto, embora não utilize o nome de um padrão é o sufixo “Utils”. MathUtils ou DateUtils ou ClienteUtils. Este tipo de classes contém apenas métodos estáticos é final e sem construtor publico. Em certos casos é possível utilizar a variante no plural do nome como Clientes ou, retirando exemplos do próprio java : Collections e Arrays. Contudo é mais raro que esta forma de nomenclatura soe bem ou encaixe em qualquer situação.

Para classes abstratas é útil utiliza Abstract como prefixo AbstractCliente ou AbstractPrintService. Este padrão pode ser usado mesmo quando a classe não é abstrata no sentido técnico ( não é definida como “abstrat class”) mas é abstrata no sentido do modelo ou do negocio. Ou seja, olhando para o nome sabemos que não é suposto instanciarmos esta classe e sabemos também que devem haver classes herdando dela. Uma classe com Abstract no nome pode herdar de outra com Abstract no nome, contudo sabemos que no fim da linha de herança existirá pelo menos uma classe não abstrata que poderemos utilizar. Este padrão é especialmente util quando o nome a seguir a abstract se refere a uma interface, por exemplo, AbstractList do java.

Especialmente para interfaces muitas vezes elas caracterizam não entidades ( substantivos) mas ações que podem ser feitas (advérbios). Em inglês é muito fácil transformar qualquer palavra em adverbio e aqui é um dos exemplo onde é vantagem utilizar o inglês. Para um ação como Print, teriamos Printable (que pode ser impresso) ou mais complexo como Mergeable ( que pode ser jeito merge). Em português também funciona se usar o prefixo “-vel” ou suas variações como “Juntável” , “Imprimível” , “Fundível”, mas é aqui que começa a ficar esquisito. Na API do java temos Serializable e Clonable como exemplos desta forma de nomenclatura.

Um outro padrão de projeto que tem uma nomenclatura diferenciada é o Adapter. Aqui estamos tentando usar uma classe com a “cara” de outra. Para o adapter é bom usa a regra [InterfacePublica][ObjectoPrivado]Adapter. Por exemplo,  InjectorSpringContextAdapter. Daqui podemos inferir que se trata de um objeto no padrão adapter, que implementa uma interface chamada Injector e usa um SpringContext por baixo dos panos. Ou seja, o contexto do spring está sendo adaptado ao contrato de um Injector.

Resumo

Nomenclatura coerente das suas classes e interfaces é uma boa forma de documentação do ccódigo, ajuda a mantes os conceitos de negocio e os conceitos tecnicos frescos, evita ambiguidade e, se bem usada, ajuda a identificar a camada a que pertence a classe.  São regras simples que todos podemos seguir, e com isso ajudar que todos entendamos o código uns dos outros.

Esta nunca me pareceu forma de dividir ou distinguir as habilidades das pessoas. Aliás sempre achei o nome “programador” ofensivo para quem é mais que isso, embora reconheça que sim existem programadores. O ponto é que quem desenvolve software não é apenas um “programador” ele tem outras habilidades. Eu já fiz várias entrevistas e sempre procurava determinar o quantidade de aptidões e o nível dessas aptidões nas pessoas. Existem pessoas que simplesmente têm talento para testar e nenhum para desenvolver. E outros é ao contrário. Poucos têm as duas coisas em equilibrio. Portanto, não se pode esperar tudo de todos. Mas a pergunta que ficava sempre na minha cabeça era : “afinal o que estou procurando nesta pessoa”. E não estou falando de empenho e vontade de  aprender. Estou falando de vertentes, de perfis. Afinal quantos e quais perfis existem ?

A resposta é simples. Existem quatro : Especialistas, Generalistas, Generalistas com especialidades e fanfarrões.

“Programar” é uma coisas que o desenvolvedor faz , de entre as muitas possíveis. É uma especialidade. Quem apenas sabe programar e o faz bem e apenas faz isso, então é um Programador no verdadeiro sentido da palavra. É um especialista em programação. Um especialista em programação não apenas programa, ele programa seguindo diretivas, boas práticas, padrões e convenções de forma que outras pessoas também programadores saibam ler o codigo que escreveu e o saibam interpretar ( reconhecer as razões que levaram a pessoas a escrever o codigo daquela forma). Mas um software não se faz só de código. Se faz de levantamento de requisitos, analise, design, arquitetura, modelagem, teste, grafismo, ergonomia, etc… Cada uma dessas coisas em si mesma pode ser umas especialidade. Afinal todos ouvimos falar nos DBA e AD que comandam – apenas – banco de dados, de pessoas que ficam fazendo diagramas UML ou escrevendo casos de uso, os “testers” que são – em tese- pessoas especializadas em teste, etc…

No mundo do software tradicional é muito comum dividir o trabalho pelas especialidades e esperar que cada um faça sua parte para no fim juntar tudo. O problema é que se esquecem de que “juntar tudo” também é uma tarefa em que se pode ser especializado (designer) e é por isso que os projetos tradicionais falham.

Todos sabemos o que é um “Especialista de Dominio” (domain specialist). É uma pessoa especializada no dominio. Esta especialização é bem útil durante a construção de um software dirigido a um domínio especifico, e quanto mais complexo o domínio, mais necessárias são estas pessoas. Elas não necessariamente produzem software no sentido de por a mão na massa do código, mas ajudam a todos a entender o porquês e por que nãos das coisas que o software deve fazer.

Por outro lado, um generalista é uma pessoa que sabe fazer de tudo um pouco. Não se trata aqui de que o especialista faz com mais qualidade que o generalista. Não é esse o ponto. O ponto é que o generalista sabe fazer mais coisas que o especialista. O quão bem as sabe fazer advém da experiencia , esforço e talento de cada um. Um generalista não tem que saber tudo. Não é necessário desempenhar todos os papeis para ser um generalista mas mais do que dois ou três.

O iniciantes começar no mundo do software preocupados em saber programar, usar as bibliotecas etc… sem nunca dar atenção a coisas como modelagem ou levantamento de requisitos. Muitos passam sua vida sendo apenas programadores deixando com outros especialistas as outras atividades. Isto é comum em “fábricas de software”.

Como disse antes quem trabalha no modelo de fábrica com um bando de especialistas encadeados em uma linha de produção se esquece que alguém tem que conhecer todas as partes do processo, do produto e do resultado de forma a avaliar como a linha de produção se portou. Senão ficam todos a olhar uns para os outros peguntando a cada um como a parte dele deveria funcionar. Isto causa imenso ruido na informação relevante, perda de informação e até inclusão de erros.

No modelo ágil se pede que as equipes sejam multidisciplinares. Muitos interpretam isto como “muitos tipos diferentes de especialidades”, mas significa de fato “pessoas com várias aptidões” ou seja, generalistas. Um generalista pode fazer muito mais num período de tempo que vários especialistas.  A pessoa pode conduzir o ciclo inteiro. Levantar um requisito, implementá-lo, testá-lo reportar ao cliente e começar de novo. Implementar pode significa escrever java, html, javascript, usar a biblioteca A ou B, mexer com banco de dados, SQL, configurações, produzir documentos, uml, etc… Agora imagine dois, três , quatro , generalistas e compare com equipes de dez, quinze, vinte , cinquenta especialistas.

Quando imagino especilistas imagino o cara sentado numa mesa com aqueles oculos especias com muitas lentes procurando os detalhes. Eles são excelentes nos detalhes. Eles enxergam a “small picture”. Os generalistas enxergam a imagem maior (“big picture”). De longe, como uma águia que procura o problema e desce rapidamente na terra para matar o problema.

Uma equipe para ser produtiva tem que ter uma mistura saudável de especialistas e generalistas, sendo que é melhor ter generalistas com especialidades.

Mas cuidado, não se confunda “generalista” com fanfarrão, ou com o cara que diz que faz tudo mas não é bom em nada. Para ser um generalista legitimo, ha que fazer direito várias coisas. Os famosos bombeiros ( o cara que fica apagando fogo de um lado para o outro) não necessariamente é um generalista. Especialmente se ele que começa os incêndios.

Não ha nada de mal em ser um bom especialista, seja de domínio, de tecnologia , de modelagem , etc… nem ha nada de errado em ser um generalista. Contudo imagine que tem mais chances de sobreviver num ecosistema em constante mudança ? Por exemplo, à 40 anos atrás DBA era o cara. Os sistemas existiam em stores procedures. Hoje que o banco de dados é commodity e temos o NoSQL ( Not Only SQL) esta profissão – como especialidade única – coloca a pessoa em risco de não trabalhar mais. Não ha como negar que especialidade é sinônimo de limitação. Por outro lado, um generalista está limitado pela sua capacidade de saber os detalhes. Porque ele não sabe ou procura os detalhes pode fazer as coisas mais levianamente que um especialista faria.

Ser especialista ou generalista é inerente ao profissional , mas da mesma forma que uma pessoa apenas boa no serrote ou na glosa não pode se considerar um carpinteiro, da mesma forma uma pessoa que só sabe programar ou só sabe trabalhar com bando de dados, ou só sabe modelar, não se pode chamar de desenvolvedor. Ao entrar no mundo do trabalho voce pode entrar como especialista ou como generalista, é você que escolhe. É comum ver as pessoas entrarem como iniciantes e nem saberem sequer programar, quanto mais levantar requisitos e fazer testes, mas se nunca tentar a pessoa não sabe se é boa ou não nessas tarefas.  Por outro lado, ninguém é sênior sabendo apenas programar. Maior nivel de aptidão (skill) significa também mais aptidões.

É isto que diferencia os desenvolvedores. É isto que tem que procurar durante as entrevistas. É nisto que tem que pensar ao formar uma equipe. Você quer muitos especialistas, muitos generalistas, ou é melhor ter apenas alguns generalistas com especialidades ? Por outro lado, como membro de uma equipe, como você pode ser mais útil ?

A meu ver o mundo da especialização e das fábricas está mudando para o mundo generalista com especialidades e modelo de oficina. Em uma oficina de carpintaria qualquer um sabe serra e usar uma glosa. Senão, o produto sairia muito caro. Isto não significa que de vez em quanto uma peça especifica não tenha que ser feita fora, por alguém que percebe mais : um especialista… mas não é comum.

Em primeiro lugar vamos clarificar o que significa estar ou não na camada de business. Podemos entender “estar na camada de business” como estar no andar “business” ou dominio. Ora o andar de dominio vem a seguir ao de apresentação e antes da integração. É o andar central de uma arquitetura em  5 andares.
Ou podemos entender “camada business” como “o pacote das classes do andar de business” ou seja, em qual pacote ou sub-pacote estaria a classe.

A seguir mostro o esquema classico do MVC

Normalmente quando usamos o padrão MVC estamos interessados em dar alguma margem ao programador final de poder implementar variações do modelo ou da view de uma forma intercambiável, como menos ou mais facilidade tecnologica – isso não está em causa agora. Contudo o controller está sempre o dominio de quem implmentou o MVC. O propósito e objetivo final da estrutura está no Controller e normalmente ele é inalterável. Em alguns casos pode ser configurável ou extensivel mas nunca é possivel moficiá-lo por completo. O Controller é onde existe a razão de ser do MVC.

A View e o Model , são , portanto, normalmente não implementados, ou implementados em versões básicas. Por exemplo, a view é normalmente implementada numa versão simples já que sem ela não haveria funcionalidade nenhuma. Por exemplo, no swing a view é o look & feel e sempre existe um que funciona ( o look and feel padrão da JVM). Por exemplo, no Apache pivot é implementa uma view padrão, no JSF temos a implementação de referencia. Uma exceção a esta regra seria por exemplo o struts, onde a view serão as JSP criadas pelo programador.

Portanto um diagrama que leva em conta as implementações seria mais ou menos assim:

Estas implementações são classes java ou se traduzem em classes java e pertencem em algum pacote/ camada/ andar. Como disse no outro post o MVC é um padrão que se aplica em única camada, então por consequência das tudo está no mesmo andar que é o de apresentação ( supondo que estamos usando o MVC nesse andar, onde é mais comum).

Mas peguemos o exemplo do JSF em que o model é um managed bean. Em tese o managed bean pertence na camada de apresentação e ele contém regras relacionadas à apresentação. A chamada “lógica de tela”. Mas é possivel, por exemplo, usar um EJB Session Bean para fazer o papel do manged bean. E agora , em qual camada pertence ? Esta é a essência da conversa discutida no outro post.

Existe aqui uma pequena falacia de confundir tecnologias com camadas/andares e assumir que o EJB pertence na camada de negocio. O que não é verdade.Se usarmos EJB como porta de entrada e webservices ou message beans estamos usando na camada de integração, mas não vamos prender nisto que não interessa agora. Vamos assumir que o EJB é a nossa implementação do andar de business. Ora, ou usar também como managed bean não estamos misturandos as coisas ? Sim estamos. E o fazemos para facilidade prática.

Estamos fundindo duas partes , duas camadas e tornando-a “uma” sem costuras ( seamlessly – dai o JBoss Seam que faz exactamente isto).

Mas lá porque as estamos fundindo tecnicamente, não significa que não uma separação entre as duas. É como dizer que o ombro é o mesmo que a cabeça porque entre eles existe um pescoço que os une “sem costuras”. Mesmo sendo unidos podemos identificar as várias partes.

O MVC usado no JSF continua usando como managed bean um objeto java que é o que ele exige, o fato desse objeto java ser tambem um EJB é mera coincidência. Por outro lado o negocio está definido no EJB e o fato dele também um managed bean é mera coincidencia. O objeto pertence nas duas camadas simultaneamente. Isto é possivel ? sim, e está o seam ai para provar, mas isso não significa que seja algo desejável ou seja boa arquitetura. Mas funciona e é “simples”. Porque não é bom ? Ora, porque está acoplado. O principio de separação de repsonsabilida deixa claro que um objeto deve ter apenas uma responsabilidade. Ser de duas camadas obviamente é ter mais do que uma responsabilidade.

Bom, então o managed bean, não importa como é implementado pertence no andar/ camada de apresentação ,porque o MVC onde ele é usado pertence nessa camada/andar. Mas isto é válido para todos os modelos de MVC ?

Um outro ponto é discussão é a interface / contrato do modelo. Por exemplo, no JSF se exige um objeto com caracteristicas de bean. No swing se exisge que implemente uma certa interface java. Ou seja, sempre o controller tem uma forma de “ler” o modelo ou intrpretar certa informação como sendo o modelo. Essa forma de leitura é o contrato. O contrato é aquilo que se espera do objeto para que controller possa comunicar com ele. Este contrato, seja implicito ou explicito na forma de uma interface java ou uma classe abstrata sempre pertence no andar da apresentação.

Como eu implementaria uma interface sem que o objeto que a implementa estivesse na mesma camada ? Existem formas para isso ?

Sim, existem. A mais simples é o padrão Proxy, mas no caso do java este exige algum tipo de interface fisica. Um contrato conceptual não é suficiente.
Mas temos o padrão bridge que vai mais além e permite o desacoplamento entre a implementação e contrato de uso. O JDBC é todo baseado nisto. Ha uma definição rigorosa de como o driver dever responder, mas não como. Ou seja, o vendedor de bando de dados pode implementar o driver como quiser remoto ou local, como quiser, mas ele tem que responder às interfaces e contratos JDBC tal como explicitado na especificação JDBC. Tudo bem, que o JDBC não tem nada que ver com MVC, mas estamos de implementar uma interface de forma que a implementação fique em outra camada. Na maioria dos casos é incomum e até inutil usar uma camada diferente para a implementação é mais mais facil usar um adapter ou um business delegator, mas a tecnologia não nos impede de separar.

Portanto, no caso geral a implementação pode estar em outra camada, embora isso não seja nada comum ou útil. O Seam é uma tecnologia onde isso se torna comum e até quase que padrão, contudo isso limita , e muito, a evolução do sistema já que o Seam viola alguns principios basicos em nome da velocidade de desenvolvimento. Isto é bom no primeiro dia, mas pode ser um pesadelo no ultimo.

O model é onde o programador dá “inteligencia” a um robot automático que é o controlador. Essa inteligencia tende a mudar muito ao longo da vida do software e portanto não é bom misturar com outras coisas. Se quiserem de uma forma bem simples de memorizar : lógica de tela não se mistura com lógica de negocio. Não são a mesma coisa.

Espero que tenha esclarecido algo.

A palavra “Design” refere-se à moldagem de abstrações para alcançar um objetivo prático. Podem ser abstrações de textura e cor da roupa (Fashion Designer), as abstrações de formas de objetos (Car Designer) ou até de cabelos (Hair Designer) mas podem também ser as abstrações de construções mentais como aquelas usadas em Orientação a Objetos ou em código de programação. A palavra é de difícil tradução para o português já que não distinguimos desenho no sentido de “esboço” como “desenho animado” de desenho no sentido de plano ou projeção. O inglês e o espanhol são mais ricos com duas palavras diferentes (design/drawing e deseño/dibujo). É por isto que a expressão “design pattern” é em português “padrão de projeto“. Só que “projeto” pode significa outra coisa no mundo do software e se quisermos falar de “Project patterns” a tradução seria a mesma. Isto é um problema para os linguistas, mas nos deixa com um problema também: a falta de percepção da diferença entre fazer esboços e planejar.

Comumente ouvimos falar de arquitetos de software. Um cognome popularizado por Gates nos seus últimos momentos na microsoft e popularizado no mundo java pelo conceito de separação de papeis e com a famosa certificação. E por isso todos almejam ser arquitetos. E o que faz um arquiteto de software ?

Normalmente as pessoas ou dirão que um arquiteto faz diagramas (desenhos no sentido de esboços) ou que é responsável por decisões referentes a requisitos não-funcionais como segurança e performance. Alguns dirão ainda que são lideres ou responsáveis por equipes, mas isso não é verdade já que arquitetos normalmente atual como especialistas que finda sua contribuição ao projeto migram para outro. A visão tradicional do arquiteto como alguém que faz esboços em papel daquilo que será a realidade do software é uma imagem bem presente. Ouvimos, até, falar de “software blueprints” ou “plantas de software” no sentido de desenhos imensos que estabelecem o como as coisas serão. Esta comparação entre o arquiteto civil e o arquiteto de software é muito querida a aqueles que comparam fazer software com fazer pontes e edifícios.

No lingo do software falamos de andares e nodos que podemos comparar com edifícios , se realmente quisermos, mas essas abstrações estão muito longe daquilo que os programadores fazem no dia a dia: escrever software. São abstrações importantes para transmitir ideias como distribuição e organização de responsabilidades, mas muito pouco uteis no dia a dia. Se formos usar a comparar com edifícios temos que dizer que a planta é algo bem longe do trabalho do pedreiro que dia após dia ergue o edifício.

O Designer não está preocupado com esboços e bonecos em papel, está procurando uma harmonia entre as partes constituintes os materiais que tem à disposição e o objetivo ultimo do objeto que está desenhando. Está preocupado com um sentido estético que não apenas agradável à visão, mas principalmente à capacidade humana de entender o abstrato, as relações, e se maravilhar pela simplicidade de uma boa ideia. O objetivo do designer é que menos adições levem a mais efeitos. Em software isso significa menos código, menos classes, menos conceitos, levem aos mesmos resultados , ou a melhores resultados.

Da minha experiência projetos precisam de designers, pessoas que têm na cabeça como o software foi, é e será e como chegar lá. Arquitetos são apenas as pessoas de demonstram aos leigos como chegar lá, e programadores são quem chega lá. Sem designers na equipe os programadores não sabem que padrões seguir ou que código escrever, nem que objetivo estão tentando alcançar porque não ha um desenho, no sentido de ‘não ha um plano”. Por outro lado, muitos designers na mesma equipe pode ser problemático. Seria como dois pintores pintando o mesmo quadro ou dois escultores esculpindo a mesma pedra. Funciona se eles estiverem em sincronismo, mas se não, é um desastre.

Hoje se inventou o papel de Lider Tecnico e ha algumas coisas que esta pessoa deve alcançar, e muitas delas são as mesmas das que um Designer teria que alcançar, como derivar em termos tecnicos o significa dos requisitos e assegurar uma visão técnica clara do projeto , mas um Designer não tem atribuições de gerencia como ser responsável pelo o que a equipe é ou não capaz de fazer. Lider Tecnico é apenas uma expressão para “Responsável pelos resultados da equipe que sabe falar tecnikês com a equipe” e por isso é normalmente uma pessoa diferente do Gerente. No mundo ágil não ha tanto este sentido mais burucrático do termo, mas ainda fica a responsabilidade pelos resultados. Em termos ágeis o lider tecnico é responsável pelo débito tecnico da sua equipe. Ser um bom designer pode ajudar muito um lider tecnico, mas nem todo o lider tecnico precisa ser um designer. Pode, por exemplo, apenas ajudar a equipe a concretizar a visão do designer. Afinal estes são todos papeis, de que estamos falando, e não de pessoas. Portanto os papeis podem ser acumulados ou não.

Se um Arquiteto está para o modelo tradicional de fazer software e para as Fábricas de Software ( afinal só de pode produzir em massa o que está esquematizado em algum lugar) O Designer está para o modelo moderno de fazer software e para os Ateliês de Software. Talvez a analogia mais próxima seja a da fabricação de carros. Existe um fase de atelier onde o carro é desenhado, no sentido de conceptualizado e planejado. Isso é esquematizado em esboços e depois produzido em fábricas. A diferença é que em software só temos a parte da concepção porque o código que escrevemos para idealizar algo, já é o produto final e ‘produzir em massa” é apenas gravar mais CDs ou publicar para download. Algo que o mundo tradicional ainda não entendeu, já que continuam achando que fabricar software é um processo semelhante a uma linha de produção. Pobres coitados.

Bom, agora que sabe o que é um designer de software talvez queira reconsiderar se realmente você quer ser um arquiteto que fica escrevendo um monte de documentos e fazendo um monte de diagramas, ou se quer um de designer que sabe moldar o código à sua vontade. Afinal, a vantagem que o designer de software sobre os outros designers de outras áreas é que ele trabalha com material etéreo que ele mesmo pode criar, como, quando e quanto quiser. É muita liberdade criativa …

Ao contrário que podem lhe dizer, e podem lhe ensinar nas faculdades por ai, software não se faz em fábricas nem se planeja no papel. Se visiona e se molda, como um estilista que mentaliza o resultado que quer obter e molda o pano até que o resultado físico seja igual ao que ele mentalizou.

Bons desenhos.

Se podessemos colocar apenas em uma frase o que nossa profissão significa, seria algo como “Implementados requisitos em código”. Muitas escolas existem sobre o comportamento, as funcioanlidades, o codigo, mas poucas sobre requisitos. No seu livro Software Requirements, Karl Wiegers apresenta uma visão, quanto a mim especialmente esclarecedora de como existem diferentes tipos de requisitos, e como eles são influenciados por fatores externos. Além disso estabelece três marcos essenciais num produto de software: documento de visão, documento de casos de uso, e documento de especificação de software.

Começamos com a idealização do software. Isto significa dizer: para que servirá, porque as pessoas o usaram, porque devemos investir nele, o que o distingue dos outros o que fará dele um bom produto e o que fará dele um mau produto. Estes pensamentos são concentrados no documento de visão e são o estabelecimento de porque o software deve existir e qual é a sua finalidade a curto, médio e longo prazo. É um documento nada técnico, muito virado para potenciais utilizadores e investidores.  Este passo é normalmente esquecido para produtos “pequenos” cuja vida util é menores que 2 anos, mas é interessante para produtos de vida média (2 a 4 anos) e mandatório para produtos de vida long (5 anos ou mais).

Com base neste documento de visão, que é bem sucinto e ao ponto, é possível angariar o interesse de utilizadores, ou patronos que estejam dispostos a investir neste produto em nome de outros utilizadores. Aqui a ideia original é expandida e desenvolvida e evoluída para algo mais próximo ao que seria de esperar para alguém que utilizasse o software. A divisão de atores e o que cada um representa e como cada um interagiria com o software nos dá mais detalhada informação. Esta informação é registrada num documento de casos de uso. Também neste documento são descritas regras de domino. Regras de domino são regras do âmbito do negócio em que o software é usado ou no âmbito do contexto em que é usado. Estas regras são normalmente genéricas e aplicáveis a software que serão utilizados nos mesmos ambientes. Estas regras não são escolhas dos usuários mas imposições que eles devem seguir ou pretendem que o software as ajude a seguir.

Sabido como o software deverá interagir com o seu utilizador, é necessário definir detalhes mais minuciosos. Sabemos o que o software deve fazer e interagir com o usuário, mas não que comportamento deve ter. Ou seja, que tipo de ações o software tomará sozinho, quais ele necessitará da ajuda ou suporte do ser humano, se será passivo ou ativo, se será instrutivo.  É claro que a forma como ele se irá comportar basicamente com base numa abstração como a todas as interações descritas nos casos de uso, mas além disso existirão atributos de qualidade que também afetarão o seu comportamento.  Desde propriedades de ergonomia, design, facilidade de uso até propriedades como segurança, confiabilidade , resiliência a falhas, robustez  e durabilidade. Estas propriedades  desejáveis pelo usuário se tornaram depois guias fundamentais para a arquitetura final do software. Algumas regras de dominio que não podem ser forçadas com base em interação, devem ser forçadas com comportamento, como regras de apresentação de informação, formatação, internacionalização, entre outras. Outros fatores que influenciam fortemente o comportamento do software são requisitos de sistema, ou seja, regras que o sistema deve respeitar porque é um software. Regras relacionadas ao uso de memória, processador, placas gráficas, ou ambientes como navegadores e sistemas operacionais. Um software baseado em internet utilizando HTML num browser tem, à partida, um comportamento diferente de um sistema embarcado ou de um sistema desktop pela natruza do ambiente onde funcionará.

Alguns requisitos podem advir do ecossistema  onde o software irá funcionar, ou com quem irá compartilhar informações. Documentação das interfaces externas que o software oferece e das que ele necessitam também fazem parte do documentos de especificação de software.

Todos os requisitos de comportamento são colocados num documento de especificação de software, juntamente com todos os atributos de qualidades relevantes. Mas nem tudo são rosas. Muitas vezes, para que o software seja possível,  funcione, ou até para que seja comercialmente interessante ele tem que respeitar um serie de “não pode” conhecidos como constrangimentos.  Podem ser variados, desde tecnologia, a sistema operativos, ou qualquer outro detalhe técnico, a preocupações com o gasto de energia, a performance ou mesmo em relação à aparência gráfica. Todas estas regras são então compiladas num último documento de especificação.

É de notar que existem fatores que podem modificar o como um documento de visão é transformado num documento de casos de uso, e posteriormente numa especificação. Um único documento de visão, entregue a grupos diferentes de usuários pode promover diferentes interações e casos de uso, e um mesmo documento de casos de uso, entregue a grupos diferentes, com constrangimentos diferentes pode , sem dúvida , levar a especificações diferentes. As possibilidades são inumeráveis. Aliás até o mesmo grupo de pessoas, em momentos diferentes do tempo podem obter resultados diferentes pegando a mesma fonte. É por isto que em produção de software temos sempre a sensação de estarmos desenvolvendo sempre a mesma coisa, mas ligeiramente diferente.

Pode parecer daqui que o levantamento de requisitos segue uma ordem pré-determinada e bem definida. Na realidade não é bem assim. Ao conversar com um pessoas sobre um software que ela quer, ele irá misturar requisições de diferentes tipos, graus de importância, graus de relevância e de especificidade. O papel do Analista é reconhecer quais são quais e colocá-los em seus respectivos “balões”. Depois de ter um conjunto suficiente de informações contidas nos “balões” serão condensadas e depositadas nos respectivos documentos. Portanto, embora exista uma ordem lógica para a leitura destes documentos, na práticas eles podem, e devem, ser redigidos em paralelo.

O levantamento de requisitos é ainda mais uma arte que a produção do próprio software. Pode ser feito por pessoas que não conhecem das tecnologias envolvidas, mas, com certeza, não pode ser feito por pessoas que ignoram as tecnologias envolvidas e/ou que não dominam o plano tecnológico em causa. Não é missão de quem levanta requisitos impedir os interessados em fazer requisições e moldar requisitos mas é missão de quem levanta requisitos não alimentar falsas expectativas ou fazer promessas de realização se entendimento e/ou conhecimento da equipe irá realizar o software. Sim, eu não acredito nesse negócio de uma equipe levantar requisitos e outra implementar.

Existem algumas diretrizes para o levantamento de requisitos que acho importantes. Primeiro a questão da comunicação. É importante que todos tenham bem claro os conceitos e que eles não sejam ambíguos. Um glossário e o uso de uma linguagem de domínio são ferramentas essenciais. Segundo a atenção ao que o cliente está tentando expressar e não ao como está expressando. Nem todos são exímios com as palavras ou eloquentes.  Use formas de comunicação que sejam adequadas ao requisitante. Terceiro a analise. Levantar requisitos é um processo analítico e de alto risco para o projeto. Um levantamento mal feito pode ser desastroso para o resto do projeto. Portanto desconfie sempre que o requisitante usar as palavras “sempre” e “nunca”. Tente explorar cenários alternativos com frase do tipo “E se acontecer ?”. Tenha a certeza que não se está enganando a si mesmo por acreditar no requisitante e simplificar. Tente identificar o que são regras e requisitos gerais do tipo de negócio do requisitante e quais são específicos à forma como ele trabalha e ao seu negócio. Sempre tente entender o valor de negocio que o requisito tem e como ele, adicionado ao software, tornará a vida do requisitante melhor. Para o caso em que o requisitante é desconhecido ou não existe uma única pessoa que possas responder pelo processo de analise, utilize grupos de foco.

Levantamento de requisitos é a tarefa mais importante no desenvolvimento de software. É onde existe mais risco de falha e onde se estabelecem os conceitos que irão balizar a implementação.

Muitas pessoas acreditam, hoje em dia, que as metodologias ágeis são contrários ao levantamento de requisitos e/ou que elas ensinam que os requisitos devem ser obtidos on demand ou just-in-time apenas quando são necessários. Nada mais longe da verdade. Todas as metodologias começam com algum tipo de lista de histórias. Estas histórias não nasceram do nada e não nasceram sem um trabalho de analise. A montagem de dita lista ocorre sempre pre-linarmente ao desenvolvimento, mesmo quando ela é alterada durante o desenvolvimento. Scrum, por exemplo, aconselha que se estabeleça um documento de visão e o Product Backlog antes de mais nada. Sendo que os passos seguintes são a estimativa do backlog e o planejamento e só depois a execução.

Espero que as pessoas parem de menosprezar o levantamento de requisitos e o levem a sério. Senão continuaremos a não acertar no que o cliente quer e a produzir software que será abandonado.  Com Ágil, ou sem Ágil, o levantamento de requisitos tem que ser feito, e tem que ser bem feito.

O fracasso dos processos stage-gate usados nas outras engenharias é hoje óbvio a qualquer um que tenha tido o mínimo de interesses para ler sobre o assunto ou a hombridade para olhar os resultados dos projetos em que participou nestas últimos décadas. O conceito de que projetos grandes e complexos de software podem ser tratados da mesma forma que projetos de engenharia civil ou aeronáutica ainda assombra muitos projetos hoje em dia, mas uma nova geração de desenvolvedores está entendendo que esse não é o caminho da força. O caminho da força é exatamente a disciplina e o rigor mental de um conjunto de pessoas trabalhando para e por um mesmo propósito. Os desenvolvedores finalmente entendem que sem conversar com o cliente nada acontece, ou pior, más coisas acontecem muito freqüentemente.  Conversar é a chave para um bom software.

Mas ainda existem alguns achando que tudo isto é magia e jogo de espelhos e fumaça… Entre estes existem os que enfim são incapazes de raciocinar fora da caixinha onde vivem, mas existem bastantes que ainda pensam assim por falta de lhes ser mostrado um melhor caminho, ou por descrédito de já terem ouvido esta historia antes ou terem experimentado e falhado. Esta atitude é a mesma da pessoa que pensa que se o homem da TV engole facas, ela também pode. E ao tentar, e se cortar toda, acha que o homem da TV é uma fraude, um engano e uma estupidez. O fato é que é a esta pessoa falta a destreza para entender que para chegar naquele nivel é preciso treino, esforço, compreensão dos perigos e sobre tudo : profissionalismo e dedicação.

Como saberão as disciplinas metodológicas com Lean, Kanban, Scrum, XP e outros da linha ágil, propõem o seguimento de um conjunto de práticas. Algumas ainda propoem conjuntos de regras, cerimónias, mecanismo de temporização e papeis que as pessoas devem desempenhar. Isto é o equivalente, nas artes marciais ao ensinamento dos golpes fisicos. Como, onde e quando colocar o braço, as pernas, a cabeça, etc…  como usar a espada, a vara, a faca, etc … Mas os golpes não são a razão da arte marcial, são apenas a parte observável. Aquilo que é a essência das artes marciais está no porquê daqueles movimentos.  Da mesma forma, a essência das disciplinas metodologias está no porquê das mecanicas, regras, papeis e cerimónias. Em ultima análise existe uma filosofia que guia o desenvolvimento e uso destas coisas observáveis.  Se você é um curioso destas coisas, provavelmente já notou que a maior parte das práticas já existia antes da era ágil. O murro também existia antes das artes marciais. Isso não as torna menores. A vantagem não está no murro, mas no como, quando, onde e por quê usá-lo. O mesmo para as práticas.

A existência de uma filosofia que premeira todas as práticas de um disciplina metodológica é a grande diferença para os processos clássicos (eu disse clássicos, não disse tradicionais) baseados no stage-gate como o Unified Process e seus derivados. Estes processos se baseiam em metáforas e analogias entre o mundo do software e outros mundos, especialmente os das engenharias civil e aeronáutica. Repare que não há uma filosofia ou disciplina inerente a estas engenharias. Basicamente existe uma matemática e uma ordem de dependência e precedência entras atividades. Nada mais. O fato de que a casa se constrói de baixo para cima,  é porque simplesmente as fundações são feitas no chão, não no ar. E todo o resto vai em cima disso. É simples. É sempre assim, e é simplesmente óbvio. Não há uma disciplina envolvida, porque simplesmente não ha escolhas a serem feitas.

As disciplinas metodológicas foram criadas a partir do conceito de que construir software  é uma atividade complexa. Mais complexa que engenharia civil e aeronautica e que por isso, é necessário que siga outro tipo de princípios e regras. Mas quais regras ? Ninguém sabe. Esta que é a mudança de paradigma que é dificil explicar e demonstrar para alguém que não entende que estamos falando de disciplinas e não de um bando de regras. Isto não é um jogo onde cada um aplica as regras que mais gosta. Tente fazer isso com uma arte marcial e sairá machucado.  Ninguém são, é louco, para fazer isso. Então, porque as pessoas insistem em pensar que podemos escolher um conjunto de mecanismos, ou regras, ou cerimônias das disciplinas ágeis e simplesmente criar nosso próprio processo.  Atente, com atenção, às palavras da ultima frase. As pessoas querem escolher regras para criar seu próprio processo. É só isso que um processo é: um conjunto de regras. E quem pensa assim ainda não entendeu que os processos não funcionam. Não no mundo da construção de software.  O Mundo está indo para as disciplinas metodologicas e deixando para trás o conceito de processo de produção, mas estas pessoas insistem em querer criar um processo usando as “melhores regras” que estas metodologias usam. É como querer criar uma arte marcial usando os melhores golpes das artes marciais. É possível ? É. Mas um conjunto de golpes é uma arte marcial ? Não. É apenas marcial, não uma arte. Falta personalidade, falta alma, moral, disciplina.  Falta o por quê, a razão. E principalmente falta o Objetivo.

Porque não podemos usar um quadro kanban junto com um daily meating e não usar Scrum  ? Porque não funciona. Não está a disciplina. O daily meating é vazio sem a responsabilidade partilhada que o Scrum procura. Não ha razão para conversar, em conjunto, sobre as atividades de todos, se não ha unidade.  Porque não podemos usar planning poker num projeto waterfall ? Porque o planning poker não é um jogo de numeros, é um processo de aprendizando, dialogo e acordo. Este processo visa criar a unidade em vez da impor. Visa procurar a visão do projeto como um todo e um acordo de como o executar. A disciplina está em chegar nessa unidade através da prática, da mesma forma que a arte marcial procura a clareza da mente através do movimento físico.  Para muitos um sprint é uma unidade de tempo. Ela é uma unidade de tempo, também, mas é principalmente uma unidade de foco. É um tempo onde o desenvolvedor pode desenvolver o que estava acordado, sem interrupções ou alterações do acordo. É um período importante para criar e fortalecer a responsabilidade do desenvolvedor e o respeito dos outros para com ele. Num processo tradicional pede-se que o desenvolvedor faça algo, mas nunca se respeita o pedido inicial ou o tempo que o desenvolvedor tem que ter de paz, para realmente desenvolver. Então do que serve ter um cronometro ? Só para apressar ? ( a tradução de sprint poderia ser “apressar até à meta”).  Não. “Estamos nos sprint” é a forma educada de dizer “Estamos trabalhando. Deixe-me em paz!” Mover papeizinhos num quadro branco não é kanban, nem scrum. É apenas um quadro branco com papeis em diferentes posições. Significam algo? Claro que sim. Significam o que você quiser. As cartas do tarot também significam algo quando estão em certas posições da mesa , mas e daí ? Isso basta ? Não.  O quadro branco com os papeis não é para dar visibilidade. É para dar visibilidade, também, mas principalmente é para encontrar problemas e com isso melhorar o processo. Ah! melhorar o processo.. então o processo não é fixo ? Não. O processo não é fixo. As práticas não são fixas, as regras não são fixas, a filosofia é que é. A disciplina, os objetivos. Não o caminho. O que as disciplinas metodológicas nos dão é uma filosofia e um conjunto de regras iniciais do processo, e um mecanismo para melhorar esse processo continuamente, dependendo dos intrevenientes! É um processo adaptativo por natureza.  As regras inicias são iguais para todos, mas onde cada um vai chegar é totalmente obra de melhoria continua. Exatamente como um praticante de uma arte marcial.

Então por quê não podemos simplesmente pegar uma coleção de práticas, colocá-las no mesmo saco, baralhar, e cria nosso próprio processo ? Porque estaremos apenas criando um processo, não uma filosofia. Não uma disciplina.  Uma disciplina implica que haja coerência entre as práticas, que elas se complementem e fortaleçam umas às outras e para isso é preciso um conjunto de principio maiores que as práticas em si mesmas, e isso só podemos alcançar através de uma disciplina completa.

Finalmente, queria deixar uma palavra para quem acha que pode começar a usar uma disciplina metodologia, como Scrum, ou XP, por exemplo, sem se comprometer com ela. Sem se empenhar, e sem a seguir completamente. Se você é um dos que pensa que pode começar a usar estas disciplinas “por partes”, pense no desastre que seria tentar partir um bloco de cimento com os dedos sem o devido preparo físico e mental da disciplina marcial completa. Muitos podem emitar os movimentos que veêm um mestre de artes marciais executar, mas imitar os movimentos não é praticar a arte. A arte está em entender os movimentos. Da mesma forma, a boa forma de base software está em entender os principios por detrás das disciplinas metodologia e não em imitar os movimentos das suas práticas. Ninguém aprende a partir uma pedra com as mãos por tentativa e erro. É feito com treino. E treino é algo diferente de tentativa e erro.

Para entender as disciplinas é requerido estudo. E sem estudo, tentar praticar é um insulto. É como um cara que aprendeu a imitar meia-dúzia de golpes dos filmes querer se denominar mestre de artes marciais. Não é apenas um insulto aos verdadeiros praticantes da arte, mas ao Mundo, por querer que acreditemos nesse embuste.

Se você gosta das disciplinas metodológias modernas, se realmente vê vantagens nelas, e sente que ha algum mérito nelas, antes de mais as estude. Tente entender a filosofia primeiro, para depois começar a exercitar as práticas.

O primeiro erro é confundir objeto com estrutura de dados. Em algumas linguagens não orientadas a objetos é possivel trabalhar com tipos que compoem diferentes variáveis numa variável só agrupando dados de forma mais concisa. Estas estuturas auxiliam na passagem de parametros, e até na tipagem do programa, mas  não são objetos.Contudo, é comum não conseguir diferenciá-los porque ambos têm atributos.

Objectos não são apenas formados por atributos, eles são também formados por comportamento. Este comportamento pode, ou não, depender do valor dos atributos ou operar sobre eles. Claro que é possivel também conceber objetos que apenas detêm comportamento sem nenhum atributo ou propriedade. Mas não é isto que diferencia uma estrutura de dados de um objeto.

Um objeto se diferencia de uma estrutura de dados porque têm uma responsabilidade. A responsabilidade advém do papel que o objeto representa no sistema, e esse papel advém do significado que o objeto têm no sistema. A responsabilidade do objeto leva a uma classificação do objeto por papeis no sistema e a existência de vários objetos que se auxiliam para formar o sistema induz a uma classificação hierarquizada. Portanto, uma outra forma de dizer que objetos têm responsabilidade é dizer que objetos pertencem a uma hierarquia de classificações.A existencia de hierarquia de classificação está intimiamente ligada à operação de herança ( que seria impossivel existir sem dita hierarquia).  Estruturas de dados, não pertencem a uma hierarquia, e  portanto, embora fisicamente semelhantes, estruturas de dados não são objetos.

Mas podem objetos ser estruturas de dados ? A resposta rápida é : sim. A resposta longa é : podem, mas apenas se essa for a sua responsabilidade.

Objetos não se podem eximir de possuir responsabilidade e é um desafio manter apenas uma responsabilidade por objeto. Mesmo quando o desenvolvedor é inexperiente todo o objeto usado ganha uma responsabilidade no sistema mesmo quando o desenvolvedor não é consciente disso e atribuir a responsabilidade correta é que é o real desafio da programação orientada a objetos.

A programação orientada a objetos advém dos principios de modelagem orientada a objetos que é uma atividade abstrata em si mesmo e independente de qualquer tecnologia ou linguagem de programação.  Modelar o objeto corretamente passa por definir seus atributos e métodos, mas principalmente por definir sua responsabilidade.

Se um objeto pode ser uma estrutura de dados, isso significaria que a responsabilidade  do objeto é manter referencia a dados.  Isso nos leva a duas prespetivas. A primeira é a do objeto que é apenas um cabide de dados e permite transportar os dados de forma agrupada de um ponto do sistema para o outro, sendo o objeto totalmente neutro em relação à razão dos dados estarem agrupados daquela forma e terem aqueles valores. Esta seria a melhor aproximação a uma estrutura de dados convencional, não orientada a objetos. Por outro lado, podemos pensar no objeto que atua como protetor dos dados que guarda, mantendo coerencia nos valores e com pelo conhecimento de porquê aqueles dados estão agrupados.O primeiros são meros objetos de transporte (Transport Objects, TO) e os segundos são objetos de valor (Value Objects, VO). É clara a diferença entre estes dois tipos.  Poderiamos argumentar que o objeto de valor que agrupa os valores por uma razão e com conhecimento dessa razão, acaba servindo, também, para transportar esses dados de um ponto do sistema para outro. Aqui jaz a diferenciação:  os dados que o TO transporta podem ser utilizados em diferentes pontos do sistema, como o sistema bem entender. Todos os dados são publicos e a sua manipulação é livre. Os dados que o VO contém não podem ser utilizados desassociadamente ou condicionalmente conforme os interesses do sistema. O sistema está obrigado a seguir as regras que o próprio VO impõe.

Em modelagem orientada a objetos aprendemos que os conceitos do mundo real devem ser incorporados no sistema de uma forma que a cooperação lógica entre os objetos seja equivalente à cooperação dos conceitos ( ou dos objetos reais traduzidos por eles) no mundo real. É por isto que modelamos classes Cliente, Pedido e Produto e as identificamos com os conceitos de mesmo nome no mundo real  e ao dizermos que “O cliente faz um pedido composto de produtos” não existe diferença se essas palavras se referem a objetos no sistema ou às entidades no mundo real.  Para que este mecanismo funcione, é claro que precisamos conseguir converter os conceitos reais em objetos. A este processo que usamos para criar equivalencia entre objetos e conceitos reais dá-se o nome de: Abstração.

A abstração dos conceitos reais é a fonte da origem dos objetos. Abstração não significa neste contexto fazer as coisas mais dificeis, mais universais ou mais matemáticas, mas apenas e só significa mapear os conceitos reais com os objetos que temos no modelo/sistema. Na realidade não é correto dizer que o mapeamento é entre os objetos e os conceitos, e sim que é entre os conceitos e as classes de objetos do modelo/sistema. O nome “classe” não é aleatório. Nos remete ao conceito de que todos os objetos pertecem a uma hierarquia de classificação, e portanto pertencem a uma ou a mais categorias (classes).  Portanto, modelar de forma orientada a objetos é a realidade nada mais que criar uma (grande) arvore de categorias, ou melhor, de classes.

As classes de objetos que identificamos com conceitos do mundo real podem pertencer a 3 grandes classes de objetos : Entidades, Serviços e Valores. As classes de serviços são caracterizadas por não deter atributos ou propriedades. Todos os dados necessários à sua operação vêm do seu exterior. Entidades são caracterizadas como objetos de transporte(TO) de Valores para certas propriedades espeficicas que são,também,  mapeadas do mundo real. Por exemplo, o cliente terá uma propriedade nome cujo valor será um conjunto de caracteres que, numa certa lingua, compoem o nome do cliente. Entidades podem também ter métodos que trabalham sobre as suas propriedades e/ou cujo resultado é alterado pelos valores dessas propriedades.   Valores são objetos de valor (VO) que detém a informação sobre os valores , passo o plenoasmo, das caracteristicas das propriedades.

Existe atualmente uma confusão sobre o conceito de objeto como composição de dados e comportamento na forma de que certas pessoas confundem o fato dos objetos poderem ter dados e comportamento, com a obrigatoriedade de todos os objetos deverem ter dados e comportamento.  Isto é pura e simples sandice. O que o objeto tem que respeitar é a responsabilidade ( ou responsabilidades) inerentes à(s) classe(s) a que pertence. Por este motivo, objetos da classe de serviço não detém atributos e isso é perfeitamente normal.

No mundo real, os conceitos são muito mais maleáveis que no mundo do software. Nem sempre é trivial destinguir entre o que é um objeto da classe de entidade, e o que é um objeto da classe de valores. Os exemplos classicos são o número de telefone e o endereço. Para um sistema comercial de compras e vendas o numero de telefone ou o endereço não passa de um valor de uma propriedade de alguma entidade como casa, pessoa ou cliente. Mas para o sistema dos correios o endereço é uma entidade ela mesma com propriedades e relacionamentos com outras entidades num vasto sistema de classificação completamente diferente daquele do sistema comercial. O mesmo poderiamos dizer do numero de telefone e da companhia de telefones. Portanto, se o conceito é melhor modelado como um objeto da classe de entidades ou da classe de valores não é constante entre sistemas de tipos diferentes.

Tipos Primários

Todas as linguagens orientadas a objetos oferecem em maior ou menor numero um conjunto de objetos de valor pré-prontos que podem ser usados como objetos da classes de Valores facilmente em qualquer entidade ou sistema. Estes objetos nunca serão usados como sendo da classe de entidade ou serviço, e portanto é seguro para a linguagem/plataforma de programação assumir algumas caracteristicas para estes objetos e de certa forma prover otimizações para eles. Em java estes tipos primários (não confundir com os tipos primitivos do java) são representados, por exemplo, pelas classes: String, Date, Boolean, Integer, Double e BigDecimal.

Porque estes tipos  estão sempre disponiveis e são conhecidos de todos os desenvolvedores, é comum que eles sejam usados para os valores das propriedades de objetos de transporte e/ou de valor.  O problema aqui é que quando queremos modelar o numero de telefone, por exemplo, como sendo um objeto pertencente na classe de objetos de valor, decidimos escolher um dos tipos primários em vez de criar um novo tipo ( classe) para ele. Então em vez da propriedade “telefone” do cliente ser um objeto do tipo “NumeroTelefone” é apenas um objeto String ou  Integer.   O problema com esta abordagem é a falha do processo de abstração. O erro é tão grande e grosseiro como se a pessoa aceitasse modelar o numero de telefone usando um Double( afinal todos os Integer cabem num Double e o Double permite ter uma parte decimal que poderia ser usada para o ramal … não tente isto em casa).

Para a grande maioria dos desenvolvedores parece um preço muito elevado criar uma classe com uma duzia de linhas para representar um conceito de valor. O argumento é que isso aumentaria o numero de classes no projeto, como se existisse alguma regra dizendo que o numero de classes deve ser abaixo de algum numero mágico. Não entendo isto. Realmente não consigo entender como uma desculpa destas que advem de pura preguiça pode triunfar sobre um raciocinio lógico, cientifico, e comprovado da modelagem orientada a objetos. O que a modelagem orientada a objetos sugere é que o numero de abstrações seja o minimo possivel. Sendo que as palavras chave aqui são “possivel” e “abstração”.  É o numero de mapeamentos entre o mundo real e mundo dos objetos que tem que ser minimizado. Isto porque esses mapeamentos são complexos e frageis  ( como o exemplo do endereço e telefone demonstram)  e portanto, ter mapeamentos demais apenas aumenta a complexidade e risco do modelo estar furando em algum ponto.  Porque as pessoas pessoas entender “abstração==classe” então acham que minimizar o numero de classes estão respeitando este principio.  O problema é que o principio da separação de responsabilidade é mais importante do que a sugestão que comanda o numero de abstrações.  Ou seja, quando a pessoa mapeia o numero de telefone à classe NumeroTelefone está separando a responsabilidade de descrever um numero de telefone. Usar um objeto String, poupa uma classe, mas coloca sobre a classe String a responsabilidade de além de descrever texto, também descrever numeros de telefone. E convenhamos que isto é um pouco idiota, pois se eu quiser ter um método getRamal() no numero de telefone, isto seria trivial num objeto NumeroTelefone , mas impossivel num objeto String já que ele não é extensivel. Mas mesmo que String fosse extensivel, não o poderiamos extender e criar o nosso StringTelefone pois isso significaria aumentar uma classe no nosso projeto e seria vetado pelas mesma razão (idiota) que veta a criação de NumeroTelefone em primeiro lugar.

É importante seguir principios , sugestões e boas práticas.Eu acredito muito nisto. Mas veja, existe uma ordem em que estas coisas têm que ser seguidas e  existem prioridades. O principio de separação de responsabilidade tem prioridade sobre todos  as sugestões e boas práticas que alguem imaginar.

Isto nos leva ao conceito de que, embora aos olhos destreinados pareça pequeno o ganho de criar um novo tipo (classe)  fazer isso é a única saida lógica num caso assim. Estes “pequenos  tipos” ganharam um nome – Tiny Types – exactamente para deixar clara a sua importância.  Mas entenda que a necessidade de batizar estes tipos de objetos apenas advém do desconhecimento e incompetência tecnica da maioria dos desenvolvedores que não sabe seguir os principios mais básicos da orientação a objetos. Eles esquecem que todos os conceitos reais presentes no sistema precisam ser abstraidos e que violar isto é criar buracos no modelo e por consequencia no código e no sistema.

Existem outras formas de dizer a mesma coisa e revelar a mesma importância da operação de abstração para a correta modelagem orientada a objetos.   Uma que ganhou muita fama ultimamente é chamada de “Linguagem Ubiqua” (Ubiquos  Languagem) introduzida pelo pessoal adepto da filosfia Domain Driven Development (também chamada Domain Driven Design). O conceito aqui é que os mesmos termos (conceitos) que as pessoas usam no mundo real  para se referirem aos intrevenientes no processo do mundo real que o software irá mimetizar devem ser usados no codigo. Isto é exactamente o mesmo que dizer que os conceitos devem ser abstraidos.  A diferença é que dizer “os conceitos devem ser abstraidos” é uma expressão tecnica, enquanto “os mesmos termos que as pessoas usam no mundo real  para se referirem aos intrevenientes no processo do mundo real que o software” é uma expressão usada por pessoas comuns  não-tecnicos. As pessoas que estudaram orientação a objetos e conhecem a operação de abstração e não a confundem com “tornar as coisas mais complexas” sempre souberam que é excelente ideia colocar os nomes/termos/conceitos reais no código … afinal foi por causa disso que se inventou o próprio conceito de Objeto e o paradigma de Orientação a Objetos : porque queriamos que os programas tivessesm a mesma expressividade que o mundo real. É simples desconhecimento achar que isto é algo novo, e é simples maldade se aproveitar do desconhecimento da maioria dos desenvolvedores – que teve uma fraca preparação académica – para passar a “linguagem ubiqua” como algo novo e inovador.  No fundo não passa de uma ferramenta de marketing igual ao dos Tiny  Types para fazer as pessoas aceitarem o que elas deveriam ter aprendido na escola desde o começo : abstração.

Toda e qualquer impedimento em orientação a objetos, seja modelagem, seja implementação, advém do conceito de objeto ( redundante, mas importante ter sempre isto presente). O conceito de objeto significa entender que existe uma separação de responsabilidade e que isso que define “objeto” e o destingue de “estrutura de dados”. Simultaneamente essa responsabilidade classifica o objeto em uma hierarquia e a hierarquia de responsabilidades implica em sermos capazes de classificar em qual lugar dessa hierarquia o objeto pertence. A  operação que usamos para fazer isto é a : Abstração.

A correta abstração do problema que o sistema deve resolver leva à correta hierarquia  de objetos para aquele sistema e nem sempre essa hierarquia é a mesma para sistemas diferentes. Nem sempre é claro se o conceito será mapeado como um objeto de entidade, serviço, ou um valor, um objeto de transporte ou um objeto de valor. Contudo, independentemente da classificação é mandatório que o conceito seja mapeado para um tipo, uma classe e esse é a razão por detrás dos conceitos de Tiny Type e da Linguagem Ubiqua.

O principio de separação de responsabilidade ( um dos 5 principios da orientação a objetos) tem prioridade sobre a sugestão de manter um conjunto minimo de abstrações, e por consequencia de classes e em nenhum caso o aumento do numero de classes pode ser usado como desculpa para não respeitar o principio de separação de responsabilidade.

Modele corretamente o seu sistema. Aprenda Orientação a Objetos e poderá fazer seus sistemas tranquilamente sem precisar de muletas. Não tenha medo de criar classes. Tenha apenas medo delas não representarem nada de util ou real no processo que o seu software está tentando desempenhar. Se todos seguirmos isto teremos menos buzz words para nos preocupar e poderemos tornar nossa atenção para o que realmente interessa.

Fiz questão de fazer um curso não programático na finada Sun exatamente para descobrir esse outro lado. No curso que era guiado principalmente pelo Processo Unificado (Unified Process, UP) era levantada a lebre de um tal de XP. Eu tinha tido contato com o XP ainda quando fazia meu estágio em física. Afinal a física prática passa pelo processamento de sinal, e este passa por usar computadores.  Com o passar do tempo as práticas que observava na realidade não batiam com o que os livros diziam e o insucesso de vários projetos me fez entender que para entrar no mundo do software antes de saber programar é preciso saber escolher entre filosofias de desenvolvimento.  O Rational UP da  Rational Rose, depois IBM no tempo do CASE lançou o mote. A ideia era ter ferramentas onde especificar o software, apertar um botão e simplesmente teriamos um software funcionando. Não resulta. Ferramentas ainda são burras e precisam de alguém que as saiba usar.  Alguém muito esperto consegue vender esta ideia imbecil de que software pode gerar software automaticamente. Ainda hoje existem tentativas de enganar os pacóvios com esta artimanha. Repare que o engano advém de quem compra e não de quem vende. É quem compra que é muito desonesto, tapado, analfabeto ou burro para não entender a enganação.

Apenas pessoas sabem fazer software e existe uma razão muito simples para isso: fazer software é um processo criativo. Criativo aqui significa tanto ser um processo onde se cria algo, como um processo em que se precisa ter imaginação. E as máquinas não têm isso ainda.

Então por que é tão difícil fazer software? Fazer software não é dificil. O que é difícil é fazer software que alguém compre e atenda a uma demanda, a uma necessidade. Para qualquer produto comercial existem duas formas de demanda. Ou quem quer comprar, compra o produto já pronto que o produtor já criou antecipadamente (retail sell – venda a varejo) ou o interessado chega junto ao produtor e pede que seja feito um produto com certas características (tailored sell – venda sob medida). Na primeira categorias podemos encontrar muitos produtos como pão, fruta, vinho, carros, casas – e inclusive software – e no segundo podemos encontrar produtos como roupa (de alfaiataria), carros (Rolls Royce), aviões e também software. Qual é a diferença? Volume.  A primeira categoria ganha em vender barato e muito. A segunda em vender caro e pouco. Ambos têm o seu quinhão de mercado. Atenhamo-nos apenas ao software feito sob medida (sob demanda – on demand, como também é chamado) para o resto da conversa.

Em tudo o que é feito sob medida, e também num software, precisamos saber como o cliente deseja que seja o resultado final. Afinal o resultado final servirá a ele e apenas a ele. Tal como um casaco ou um terno que serve apenas a uma pessoa. Pode até ser que sirva para outros, mas nunca sem ajustes. Precisamos então saber quais são os requisitos. Requisito é um conceito muito importante neste tipo de produto, porque é à medida dele que será feito o produto final.

Um outro fator na equação é como será feito o produto. A tecnologia que será usada para realizar o produto afeta o preço, a qualidade, a durabilidade, e até o aspecto e usabilidade do produto.  Existem tecidos específicos para certos tipos de roupa e circunstâncias específicas. Existem razões técnicas de porque o mesmo casaco precisa ser de algodão em umas regiões e de lã em outras.  Se formos fazer um produto que nunca ninguém fez antes ou poucos tentaram e tenhamos que experimentar diferentes tecnologias será diferente daquele que utiliza uma tecnologia já muito entendida e aperfeiçoada.

Pondo estas duas forças num gráfico obtemos um cenários mais ou menos como o mostrado na figura a seguir.

Na zona verde estão os produtos menos complexos, os mais complexos na zona vermelha. Repare que o software é algo complexo.

Muita gente – gente demais, na minha opinião – adora comparar “fazer software” com “fazer casas, carros e aviões”. Não, essas coisas não são nem de longe tão complexas. Por quê? Porque os requisitos são muito bem conhecidos e a tecnologia também. Não há surpresas – tijolo é tijolo e metal é metal. Não há mudança de ideia no último momento. Não há uma tecnologia que surgiu no último momento e tornou tudo obsoleto.  Um pouco mais semelhante seria um carro costumizado ou um avião costumizado como Air Force One. Mais próximo ainda seria um vestido de noiva. A tecnologia é muito simples e conhecida, mas os requisitos são muito voláteis. É por isso que existem costureiros de grife cobrando caro por essas coisas. Do outro lado, temos as vacinas, aqui os requisitos são simples – evitar a doença , mas a tecnologia tem que ser criada. E algumas , como a da AIDS não tiveram sucesso até hoje.  A vacina é um exemplo muito mais próximo da complexidade de fazer um software com tecnologias novas (muitos projetos de vacinas falham, como falham os projetos de software). E talvez por isso as equipes tendam a usar tecnologias velhas. Dá-lhes uma margem maior de segurança emocional (se bem que uma plataforma de aplicação velha é um empecilho em si mesmo).  Armas de energia com o phaser do Star Trek ainda são uma ilusão, mas as armas  taser estão bem perto, e cada vez mais perto de uma arma de energia. Aqui, o requisto continua simples – desabilitar o adversário, mas a tecnologia é simplesmente desconhecida. Um exemplo de algo bem complexo de criar seria uma verdadeira  TARDIS , pois não apenas ela é um ser vivo que viaja no tempo e no espaço, como é maior por dentro do que por fora. Um desafio ao raciocínio humano mais fundamental, o que dizer ao raciocínio de engenharia.

Ao fazer software é raro que tenhamos requisitos bem conhecidos, e normalmente as empresas se encarregam de estragar a outra variável não tendo uma tecnologia padrão para desenvolver o software, o que significa que a cada projeto temos que começar de novo aprendendo novas tecnologias e refazendo funcionalidades que já tinhamos antes. Isto torna a produção de software inerentemente complexa. Não somos nós que a fazemos complexa, ela é complexa por natureza. O que podemos fazer é torná-la mais ou menos complexa, mas nunca apenas complicada ou  simples. Normalmente a tornamos mais complexa do que natural.

Aceitar este princípio básico – “princípio zero”, poderíamos chamá-lo – é fundamental para conseguir fazer software. Isto era verdade a 50 anos atrás, e com a velocidade com a tecnologia evolui,  é muito mais verdade hoje. Não é por acaso que nasceram coisas como o Java e o .NET para quebrar um pouco desse escalar de tecnologia que constantemente nos exigia mudar de ferramentas para fazer software. As plataformas virtuais nos trouxeram uma âncora que nos ajuda a diminuir a complexidade. Mas a âncora não durará por muito tempo e novas âncoras precisarão ser desenvolvidas.

Entendendo que fazer software é algo complexo, as pessoas esperam que a forma de gerenciar a produção do software tenha que ser igualmente complexa. E este é outro paradigma difícil de quebrar:  o complexo pode ser gerenciado com o simples.  O truque é mantermos os olhos nos objetivos. E são estes que têm que estar claros desde o dia um, e refinados todos os dias. Como já disse Dwight D. Eisenhower ”O plano não é nada, planejar é tudo”. Ou seja, a complexidade é tratada facilmente se o plano não for fixo e evoluir conforme as circunstâncias. Mas veja, o plano muda e é descartável, mas não os objetivos  (e se você tem algum sentido de ética, nem todos os caminhos são aceitáveis).  Algumas pessoas entendem esta frase assim: “não faça planos”. É errado. A mensagem é “Faça planos, e continue fazendo planos. Não pare de fazer  planos até chegar no objetivo”. A cada plano temos um mapa do caminho para os próximos tempos  ( horas, dias, semanas, meses, anos… não interessa), quando replanejarmos teremos um plano que vai um pouco mais à frente e assim continuamente. A mal intrepretação deste simples conceito leva a aberrações como a recusa de criar uma plataforma de aplicação coerente e coesa ou simplesmente achar que é possível levantar requisitos “on-the-fly” na medida que o projeto progride.

A complexidade do software demanda o processo criativo contínuo, e isso exige a atuação de pessoas em todos os pontos desse processo. Todo o resto são ferramentas.
Será que o processo unificado (UP) ou qualquer outro processo criado antes de 1990 se baseia nestes princípios? Quero crer que não. Todos os processos clássicos se baseiam num mecanismo Stage-Gate como o usado para construir carros e aviões (!). Este tipo de processo simplesmente não funciona quando a principal energia é a criatividade,  e é por isso que muitos de projetos de software falham.  Em qualquer outro ramo de atividade, tantos projetos falharem é inadmissível. Em software, fazemos de conta que não é verdade.

O que não é admissível é que seja possível viver construindo software sem ter um processo-base para tal.  Práticas de laboratório até temos algumas (vide práticas de XP ) e temos alguns candidatos a processos de gerenciamento realista de software como Scrum. Mas ainda aguardamos o santo graal do processo de software.  O Processo Unificado não é bom o suficiente porque ele é muito semelhante a um processo Stage-Gate  e é corrompido muito facilmente se transformado num processo que tradiconalmente é usado em empresas produtoras de software. Um processo criado “in-house”, híbrido e muito parecido com um Frankeistein , um monstro fabricado de partes de outrém.

A promessa de um processo padrão moderno, confiável, honesto, que tome em consideração a complexidade, os requisitos, as tecnologias, e as pessoas ainda está por vir.  A minha aposta é que será algo muito semelhante a uma fusão de Scrum com XP e diretivas do manifesto de software craftsmaship que apela a um certo padrão de qualidade e orgulho no trabalho que fazemos – que por exemplos os alfaiates têm – que nós,  produtores de software, ainda não temos.

Software é simplesmente complexo, e é por isso que gostamos de o fazer. Aceitemos de uma vez por todas a sua complexidade natural e façamos-o com o respeito que merece.