Estava mudando de emprego, vida nova, novos ares.

Projeto do SourceRule esta retomado, novos posts a vista!

“O seu chefe o chama para uma reunião e diz que uma novo projeto deve ser feito.

Ele te explica por alto qual a necessidade do cliente e pergunta:

_Quando está pronto? Pode ser pro mês que vem?”

Todos sabem como é difícil lidar com este problema sem que as pessoas lhe interpretem mal.

Você se sente pressionado, porque sabe que se assumir aquele prazo corre um sério risco de não conseguir entregá-lo, ou pior, não vai conseguir entregar com a qualidade que  o cliente precisa.

Antes de dar qualquer resposta peça licença para pensar e marque uma nova reunião para discutir, não de respostas na hora.

Não chute um prazo, reflita bem os cenários:

Se tudo ocorrer bem, e nenhum contratempo aconteça qual o tempo mínimo para concluir o projeto?

E se tudo der errado? Quanto mais tempo vou levar?

Com uma estimativa baseada em suas experiências anteriores você passa a ter noção da quantidade de tempo que irá levar, mesmo que não muito preciso, e então vem a grande questão: O tempo está fora do que lhe foi pedido.

É hora de negociar, e isto não envolve nem uma linha de código ou algoritmo que você digita e manda executar. E agora?

Antes de tudo você precisa saber que você está lidando com pessoas. Tanto seu líder ou liderado, ou o comercial ou o cliente querem na verdade é que você e sua equipe entregue o projeto. O tempo que levará para concluir não é um mero detalhe, mas certamente será o menor dos seus problemas se o que você entregar não tiver qualidade.

Entendido isto o próximo passo é se por no lugar do outro. O modo que você vê o mundo depende do lugar que você se encontra, as pessoas tendem a ver o que lhe interessam.

Infelizmente, profissionais de tecnologia são criaturas de emoções fortes, tem dificuldades de comunicação e, principalmente, são extremamente sensíveis.

Os técnicos de nossa área, impulsionados pela escassa mão de obra qualificada que hoje há no mercado tendem sempre a barganhar com suas posições, o que agrava o problema na hora da negociação de prazos e tarefas, pois o ego da maioria dos profissionais passam a tomar conta do que deveria ser uma simples negociação.

É claro que, não podemos nos esquecer que a pessoa tem emoções, valores, diferentes antecedentes e ponto de vista diferente dos nossos, portanto devemos pelo menos tentar compreender o pensamento da outra parte.

O que ele quer realmente?

Ela realmente espera aquele prazo que lhe pediu?

Existe mesmo a real necessidade de ser fazer algo correndo e queimando etapas?

O que ele pensa que o cliente quer é realmente o que o cliente espera?

Pensar no lugar de quem você negocia é meramente uma atividade útil que irá ajudá-lo a solucionar seu problema.

Você começará a ver aquilo que as pessoas querem que VOCÊ veja. A Habilidade de se ver a situação do outro lado é a principal habilidade que um profissional pode ter.

Não deduza as intenções dos outros a partir de seu próprio medo, escute, perceba as deduções do ouro e  discuta as percepções de cada um.

Coloque para a pessoa cada etapa que lhe fez chegar ao prazo atual, ceda somente dentro dos seus limites. De a ele um interesse no resultado, certificando-se que ele está participando do processo.

Converse bastante até que vocês cheguem a um acordo sensato para ambas as partes, de modo que o relacionamento se aprimore quando se chegar a um consenso.

Conquistado o objetivo não encerre a reunião, prolongue um pouco, avaliem juntos os riscos envolvidos (como necessidade de treinamento de equipe, possibilidade de perder pessoas durante o projeto, etc.) e tente quantificar o quanto de tempo cada risco pode custar ao projeto, ele com certeza vai saber repassar ao cliente um tempo melhor ainda do que foi negociado com você.

Lembre-se: Ser muito gentil ou ser muito rude nunca é a resposta!

Autor: SINGH, SIMON
Editora: RECORD
Assunto: CIÊNCIAS EXATAS – MATEMÁTICA

Segue a sinopse:

O Último Teorema de Fermat, como ficou conhecido, tornou-se o santo graal da matemática. Vidas inteiras foram devotadas- e até mesmo sacrificadas- à busca de uma demonstração para um problema aparentemente simples. Várias pessoas tentaram demonstrá-lo mais não conseguiram até que surgiu, um professor de Princeton, Andrew Wiles, que sonhava em demonstrar o Último Teorema de Fermat desde que o vira pela primeira vez, ainda menino, ba biblioteca de sua cidade. Com medo da sucessão de fracassos de seus antecessores, durante sete anos publicou artigos sobre outros assuntos, de modo a despistar os colegas, enquanto trabalhava em sua obsessão. Em 1993, passados 356 anos desde o desafio de Fermat, Wiles assombrou o mundo ao anunciar a demonstração. Mas sua luta ainda não tinha terminado. Um erro o fez voltar às pesquisas por mais quatorze meses, até que em 1995 ele ganhou as páginas de jornais do mundo inteiro e 50 mil libras da Fundação Wolfskehl. ‘O Último Teorema de Fermat’ é a história da busca épica para resolver o maior problema de matemática de todos os tempos. Um drama humano de grandes sonhos, brilho intelectual e extraordinária determinação.

Esta abordagem que reúne um conjunto de conceitos, técnicas e princípios com foco no domínio do negócio e na lógica do negócio para criar seu modelo de domínio traz grandes vantagens para o programador:

Quanto mais próximo do negócio, menos ele irá sofrer com suas mudanças, e, quanto mais o desenvolvedor entende do negócio, menos ele erra e mais preparado ele fica para melhorar e questionar a arquitetura do processo.

Acho muito pertinente que começamos a discutir e praticar negócios genéricos para pordermos desenvolver aplicações nestas abordagens com qualidade, é nisto que quero focar em alguns de meus artigos.

Durante um curto período de minha carreira profissional aceitei o desafio de um amigo e me envolvi paralelamente em um projeto de Garantia da Qualidade. Meu desafio era o de enxergar os processos de uma Fermentaria controlá-los e dentro do possível, aperfeiçoar-lo. Claro que tive a orientação de pessoas do ramo, mais o mais interessante foram me desligar um pouco dos códigos e pensar mais em um todo da organização.

Sempre tive uma visão voltada para lógica, o básico de processo para mim era bastante claro: todas as tarefas tinham um motivo, algo tinha que entrar, precisaria fazer alguma coisa com ela e algo tinha que ser produzido. Isto valia para um processo de tornearia, de escritório ou até mesmo da limpeza, por exemplo:

Processo de Negócio – Tornear uma peça.

Entrada: PECA, TORNEIRO MECANICO, TORNO, FERRAMENTA, DESENHO.
Processamento: O TORNEIRO MECANICO LE O DESENHO,
ESCOLHE A FERRAMENTA, AJUSTA O TORNO,
PRENDE A PECA E EXECUTA A OPERACAO.
Saída: PEÇA TORNEADA

Processo de Negócio – Varrer o chão

Entrada: VASSOURA, FAXINEIRA, LUGAR
Processamento: A FAXINEIRA PEGA A VASSOURA E VARRE O LOCAL.
Saída: LUGAR LIMPO

Mesmos com as características básicas de cada processo de negócio (e são estas características que garantem seu emprego e tornam os sistemas tão diferentes) os modelos de negócios tem princípios básicos que podem e deve ser observados.

É importante identificamos as necessidades (ou saídas) de cada processo de negócio, pois este é o objetivo de sua aplicação, nelas deve estar focados o domínio de sua aplicação.

Pensando em desenvolvimentos orientados a negócios, note que as entradas podem ser visualizadas como as entidades do domino, os processamentos como os serviços a serem executados e a saída será o que o usuário espera encontrar. Se você estiver aplicando TDD verá que o processamentos são o grandes tema de seus testes unitários, cuja classe do teste pode ter o mesmo nome do objetivo ou saída.

Vamos começar a rabiscar o domínio como sabemos?

namespace Entidades {
     enum StatusLocal {Limpo, Sujo};

     class Vassoura {}
     class Faxineira {}
     class Local { StatusLocal  Status; }
}

class TestarLugarLimpo {
     void testarSetarVassoura(Faxineira faxineira, Vassoura vassoura) {}
     void testarSetarLocal(Faxineira faxineira, Local  local) {}
     void testarVarrer(Faxineira faxineira, Local  local) {}
}

class LugarLimpoServico {
     void Varrer(Faxineira faxineira, Vassoura vassoura, Local local) {
        faxineira.setarvasoura(vassoura);
        faxineira.setarlocal(vassoura);
        faxineira.varrer();
     }
}

//p.s: não programe em portugues!

Bom, de maneira bem simplista estou tentando exemplificar como começar com o DDD:  aprenda o negócio, rabisque a implementação do domínio e por ultimo faça o que você sempre fez: preocupe com infra-estrutura de sistemas (banco de dados, acesso e segurança e interface gráfica).

Mas estes assuntos irão render outros posts!

Marcus Alexandre

Os nomes que escolhemos para nosso código devem ser bons. Independente de este código ser um método, uma variável, função ou classe devemos adotar com critério, como se você estivesse dando um nome a um filho (menos os desenvolvedores que tenham filhos de nome  Jucemildo e Etelvina ).

Mesmo que você leve mais tempo para conseguir pensar em um bom nome é extremamente necessário que você o faça. O ideal é que todos os desenvolvedores que lerem seu código devem entender seu propósito sem precisar pesquisar ou se esforçar para tal, deve-se até mesmo evitar que seu leitor não precise nem de desviar o nome da linha para saber do que se trata.

Vamos aos casos:

Várivaveis e Constantes

A maneira mais prática de saber se o nome de uma váriável é bom ou não é que ele deve eliminar automaticamente a necessidade de um comentário de explicação. Por exemplo:

private DateTime _btDt; //Data do Nascimento

Notou como o comentário está deixando o código mais extenso e chato? Mesmo que _btDt para o autor do código possa ser claro, dentro do contexto de sua classe esta regra não se aplica a todos os desenvolvedores, pessoas são diferentes e por isto, podem e devem pensar diferente. Principalmente no meio daquela regra de negócio na linha 433 do código:

private int Age() {
    return (int) (DateTime.Now().Subtract(_btDt).TotalDays/365)
}

Refatorando este código:

private DateTime _birthDate;
private const DAYS_PER_YEAR = 365;

private int Age() {
    var differenceDays = DateTime.Now().Subtract(_birthDate).TotalDays;
    return (int) differenceDays/DAYS_PER_YEAR)
}

Viram a diferença? Neste caso é impossível que alguém não entenda que _birthDate seja Data do Nascimento (A não ser é claro que o desenvolvedor não entenda nada de inglês, mais isto rende outro post…). A eliminação no comentário reduziu a quantidade de informação inútil da linha de código, mesmo quando esta declaração não estivesse perto da declaração. Pronto! Recuperamos o tempo que gastamos para pensar em um nome objetivo, com propósito.

Em tempo: Utilizamos em nossa equipe, por consenso de todos, que variáveis privadas comessem com _travessao. Isto se dá ao fato que podemos deixar compatível a bibliotecas em outras linguagens ao migrar de linguagem que não são case. Constantes escrevemos TODAS_EM_MAIUSCULAS, achamos mais convenientes. Aconcelho a você seguir estes padrões, desde que toda sua equipe também os sigam.

Pode parecer banal, mais uma única linha bem escrita, e, principalmente em sintonia com toda a equipe, muda tudo ao final…

Métodos

Quanto aos métodos a mesma regra se aplica, tomamos como exemplo:

// Retorna uma lista de usuários pela idade
List<User> Find(int Age) {
    return GetAllUsers().Where(user =&gt; user.Age == Age);
}

Mais uma vez este comentário poderia ser eliminado sem deixar menos claro o código fonte e a chamada da função para uma pessoa que esteja a pouco tempo no projeto pode ser bem mais intuitiva gastando menos tempo de análise de código. É claro que, se o método for publico é válido que você o comente da mesma maneira a fim de gerar o xml de documentação do código e acesso a documentação via intellisense.

Refatorando:

///<summary>;
/// Filtra os usuários pela idade
///<summary>;
public List<User> FindByAge(int Age) {
    return GetAllUsers().Where(user =&gt; user.Age == Age);
}

Bem mais direto não? Ao ler um código de chamada olha a diferença:

//Exemplo Ruim:
userRepository.Find(18);
//Exempo Bom:
userRepository.FindByAge(18);

No primeiro caso ao escrever a primeira função você receberá do intellisense a documentação e verá que precisa de passar o parâmetro idade. Mais será que isto é realmente direto e objetivo? No segundo caso, independente de intellisense ou não é claro o objetivo da função, inclusive para quem ‘imprime’ o código em papel ou simplesmente desliza a barra de rolagens na tela.

“Coisas simples facilitam nossas vidas e a dos outros membros de nossa equipe, portanto: simplifique!”

Sobre Clean Codes

Clean Code Tips serão postagens constantes neste blog, se alguem leu – ou está lendo Clean Code de Robert Martin, ou “Tio Bob” perceberá que ele está me influenciando muito com suas teorias de Código bem feito. Alguns posts irão concordar com a prática outros nem tanto… Portando fica a dica de leitura:

Código Limpo – Habilidades Práticas do Agile Software de Robert C. Martin Editora Alta Books. (Em tempo, a tradução é de ruim para péssima, tenha o PDF em inglês em mãos….)

Desculpas

Aos Jucemildos: me desculpem este nome eu inventei e nem sabia que existia alguém que chamasse assim… (em tempo o google gerou 0 resultados)

Às Etelvinas: perdão mais este é o nome de minha sogra eu não poderia deixar passar …

Sempre que começamos um projeto novo tendemos a partir para uma maneira de programar aplicando o que os Gurus do Software prometem ser a mais inovadora e o melhor conceito de desenvolvimento que o mundo já viu…  A onda do momento agora é o DDD:  Domain-Driven Design.

Eric Evans, seu criador, descreve o DDD como uma maneira de pensar e de um conjunto de prioridades, visando acelerar projetos de software que têm de lidar com assuntos complicados, segundo ele o que é Business, ou Domínio da Aplicação deve ser o tema principal do foco do projeto e toda a sua arquitetura deve ser sustentada por estes princípios não tecnológicos mais de negócio em si.

Lindo não!?

Só que… Vamos lembrar alguns momentos:

No final dos Anos 90 era verdade absoluta que a aplicação da regra de negocio alinhada e impregnada com tecnologia, no caso Banco de Dados não só se restringia em garantir a integridades dos dados mais tinha o alto ganho de desempenho e automatização, pois, as famosas  ‘triggers’ eram disparadas a partir de eventos que eram capazes de avaliar uma gama enorme de alternativas que o programador seria capaz de realizar, tudo em tempo de execução pelo sistema de gerenciador de dados. Isto era tão maravilhoso que ainda hoje, mais de 10 anos após, inúmeras organizações ainda mantêm seus produtos nesta arquitetura, umas com facilidade em manter outras nem tanto. (Em tempo, o projeto em que trabalho hoje migra deste paradigma para o DDD).

Nesta época colocávamos o Core da aplicação no banco de dados e a programação tratava de apresentar para edição e leitura os dados para o usuário, rapidamente (questão de pouco mais de um ano) os gurus da informática um novo modo de enxergar esta arquitetura, a aplicação de três camadas: Apresentação, Negócio e Dados.  Pregavam que, deveríamos deslocar a lógica de negócios e a conexão com o banco de dados da camada do cliente para a camada de negócios e a camada de dados.  Se você precisar fazer qualquer alteração na lógica de negócios ou no código de acesso aos dados não vai ter que alterar nada nos aplicativos clientes. Era o que muitas pessoas já estavam fazendo, mais a partir dali tínhamos um padrão a seguir… (Porque alguém relativamente com nome falou!)

Com o .Net da Microsoft criando força e corpo um conceito mais inovador precisaria ser lançado, pois agora a Microsoft já suportava orientação a objetos e precisaria  dar um atrativo para que seus desenvolvedores e de seus concorrentes migrassem para sua tecnologia.  Muitos dos gurus então foram contratados – e bem remunerados para falar de um novo jeito de fazer as coisas certas: Precisaríamos trabalhar com DataSets desconectados!

Agora tínhamos um banco de dados em memória e a camada de regra de negócios deveria voltar ao código da aplicação e não mais deveríamos, embora pudéssemos – e com certeza o faríamos – aplicar as regras no banco de dados.

Como o DataSet foi acabando prefiro nem falar que os calos ainda doem!

Bom… Para não estender tanto vou ser mais direto: Desde que programação se tornou algo relativamente fácil de fazer (não se ofenda, só programadores que lêem isto aqui J) vários Gurus surgem todos os dias para nos ensinar que o que sabemos hoje não é tão bom assim e que a visão X é bem melhor e mais barata.

Isto é ruim? Não! Isto é ótimo. Sem duvidas estamos evoluindo muito no decorrer destes anos e em especial nos últimos cinco. Porem hoje, um pouco mais calejado insisto no que vou dizer:

“Martim Fowler, Matthen Foemmel, Robert Martin, Erich Gamma, Eric Evans e vários outros são bons, ou até como se diz em minha cidade Betim: são fodas!”

Porem, eles não donos da melhor maneira, apesar de escreverem ainda a melhor maneira atual. Amanhã outros desbancaram seus conceitos e tudo que você aprendeu virá a desabar para que uma nova construção de conhecimento seja reerguida.

Meu conselho é que não sejam metódicos demais ao desenvolver uma aplicação, procure sempre os padrões e conceitos para servirem de base de sua aplicação mais não os adote como verdade absoluta, adapte-os para sua necessidade. Mantenha um vocabulário em comum com os demais arquitetos e desenvolvedores do mundo e siga linhas de raciocínio mais principalmente mantenha o SEU raciocínio como principal. Não tenha medo de melhorar o que já é demasiadamente bom. Lembre-se: o ótimo sempre estará por vir, mais ele nunca chega.

É  linha de desenvolvimento que este blog pretende seguir portanto interajam comigo, opine, concorde e discorde o que for colocado! Quem sabe não conseguimos juntos fazer a roda de a tecnologia girar mais um pouco?

Mãos a obra!

Sempre que vejo um novo padrão de projeto ou modelo de aplicação lembro-me que, por mais perfeitos que eles possam ser sempre é bom que nós possamos adaptá-los ao nosso contexto, porque somos nós, desenvolvedores, analistas e arquitetos que vamos ter que arcar com ele no futuro.

Portanto ao iniciar um projeto sempre procuro identificar os padrões em que meus objetos se enquadram, mais principalmente procuro ver se vou precisar adaptar estes padrões a realidade de minhas aplicações. De maneira nenhuma tento fugir das nomenclaturas usuais dos grandes arquitetos de software.

Portanto a idéia deste Blog é mostrar como procuro lidar com estas adaptações que ocorrem no dia a dia de desenvolvimento, não que sejam melhores ou piores dos usuais, mais simplesmente expor para avaliação e julgamento dos meus leitores. Portanto este blog não poderá existir se você, leitor, não me der seu feedback!

Fico no aguardo sempre!

Sobre o Autor:

Marcus Alexandre é um Analista Programador com 10 anos de experiência na área de desenvolvimento e manutenção de sistemas, sendo os últimos anos focados fortemente em Sistemas de Integração e em Sistemas ERP.  Com uma breve passagem em sistemas de Business Intelligence e Workflow este programador tem como meta sempre a satisfação de seus usuários – ou clientes finais.

Sobre a Arquitetura de softwares para o autor:

A Arquitetura sempre será apreciada se o acabamento da obra for perfeito! O acabamento neste caso pra mim não é o design ou a visualização da aplicação – embora também imprescindível – mais o quanto de inteligência de negócio, redução de custos e automatização de processos que possamos entregar… E sobre esta visão vejo que nunca serei um Arquiteto de Oficio e meu perfil sempre será do chato que quer fazer um ‘algo a mais’ desde que deixa a janela do meu prédio mais bonita….

Portando, um abraço deste Desenvolvedor!