Código de má qualidade

Li um artigo do Luis Suares extremamente interessante que resolvi partilhar.

É comum deparar-me com falhas nas boas práticas mais básicas de programação. Tais problemas, embora não correspondam necessariamente a bugs, dificultam a leitura do código, o debug e as alterações. São cometidas por programadores com diversos níveis de experiência. Muitas vezes porque algo foi “feito à pressa”, porque não quiseram arriscar um pequeno refactoring, ou porque não puseram em causa a forma mais correta de o fazer.

Poderia dar inúmeros exemplos, mas vou tentar centrar-me nos mais comuns. Este artigo aplica-se a linguagens de alto nível orientadas a objetos (e.g. Java, C#) mas a maior parte aplica-se à maioria das linguagens funcionais.

Se der por si a fazer alguma das seguintes situações, pense duas vezes e aposte num refactoring.

“Copy/paste” de código

A “lei” fundamental a reter é: quanto mais código, mais bugs; por isso pare de copiar código. Ter código repetido no mesmo programa pode resultar em, ao corrigir um bug ou adicionar funcionalidade num lugar, se esquecer de mudar em todos os lugares. Copiar mais de 1 linha de código devia por si só lançar o alerta. Quase de certeza que:

  1. Se pode isolar a parte repetida (ex: um switch deve apenas conter aquilo que varia);
  2. Se pode construir um procedimento de alto nível parametrizando as diferenças;
  3. Se pode isolar funcionalidade em classes/bibliotecas reutilizáveis;
  4. Entre outros.

Mais de 3 níveis de blocos

if (cond1)
{
    if (cond2) 
    {
        for(Classe c : listagem) 
        {
            if (c.getN() gt; 1) 
            {
                while(...)
            }
        }
    }
}

Este tipo de código além de menos “elegante”, torna a sua leitura extremamente aborrecida e difícil. Pode suceder que (especialmente alguns meses depois), alguém se perca facilmente neste código. A sua leitura obriga a frases como: “estou neste if se X, não Y, após chamar Z, a iterar um array, se K mas não B…”.
Assim, deve evitar-se nesting ao máximo. Quando o nível de nesting é maior ou igual a 3, deverá realizar um refactoring, isolando uma parte da funcionalidade num método auxiliar.

Há até situações em que nem precisa de o fazer. Por exemplo, pode recorrer a syntactic sugar para simplificar uma decisão:

if (estaBomTempo) 
{
    return "sim";
} 
else 
{
    return "não";
}

return estaBomTempo ? "sim" : "não";

Mesmo em setters, esta abordagem pode ser útil (poupa-se 4 linhas):

if (mimetype == null) 
{
    multimedia.setMimetype("");
}
else
{
    multimedia.setMimetype(mimetype);
}

multimedia.setMimeType(mimetype == null ? "" : mimetype);

Em métodos em que todo o seu corpo depende de uma condição:

if (tempo != null) 
{ 
    // várias linhas de código 
}

…. porque não apenas (menos nesting)?

if (tempo == null) 
{
    return;
}

// várias linhas de código

try/catch(Exception e)

O tratamento de exceções e a tolerância a erros num software é algo extremamente importante mas quase sempre encarado como secundário. Por exemplo, fazer um “try/catch(Exception)” pode ser apenas definido como “muito mau”, pois:

  • Estamos a desligar o mecanismo de exceções, “abafando” toda e qualquer exceção, até as exceções de Runtime (ex.: NullPointerException); o programa pode acabar num estado incoerente e “estranho”.
  • Estamos a tratar da mesma forma toda e qualquer exceção. Cada exceção tem uma natureza (e.g. gravidade) diferente; como tal, deve ser tratada de forma diferente. Algumas são recuperáveis, outras requerem interação do utilizador, outras são apenas sinónimo de bug, etc.

Conclusão: fazer “try/catch(Exception)” é “varrer o lixo todo para baixo do tapete”.

Também não tem lógica nenhuma fazer try/catch(NullPointerException) ou um try/catch(ArraysOutOfBoundsException); deve-se sim testar e resolver as condições que podem originar tais exceções. Deve-se ir à origem do problema evitando-o em vez de o corrigir. As exceções servem para coisas que não se podem evitar.

Quanto a esta temática, haveria muito mais por dizer… contudo, o essencial a ter em mente é que deve encarar o mecanismo de exceções de forma séria.

Por fim, deve sempre manter alguma dissociação entre camadas (decoupling): exemplo clássico: é desvantajoso “abafar um IOException” mas enviá-lo “para cima” também o é, visto que estamos a comprometer as duas camadas (se amanhã se mudar de ficheiros para um banco de dados, a camada de cima não precisa saber); a minha sugestão é lançar uma exceção nossa (ex.: RepositoryException) e guardar a exceção original.

// no tratamento:
} 
catch(IOException ex) 
{
    throw new RepositoryException(ex);
}

// a nossa exceção:
public class RepositoryException extends Exception 
{
    public RepositoryException(Throwable ex) 
    {
        super(ex);
    }
// ...

Lixo no código

Quanto menos linhas de código (que fazem a mesma coisa) e ainda assim são legíveis, melhor: menos código para manter. Assim:

  1. Evite espaços a mais e código não indentado: dificulta a navegação e a compreensão (o Visual Studio faz isso sozinho);.
  2. Apague os “imports” desnecessários;
  3. Declarar uma variável e defini-la separadamente não tem muito sentido:
    StringBuffer resp;
    resp = new StringBuffer("teste");
    // basta fazer:
    StringBuffer resp = new StringBuffer("teste");
    

    Declarar variáveis no início ainda é pior (mesmo em C não faz sentido).

  4. Não deixe blocos de código comentados pelo caminho… é para isso que serve o controlo de versões;
  5. Evite os comentários completamente inúteis; isto é, comentários que apenas dizem o que está bem patente:
    // aqui estou a adicionar o elemento ao vetor
    // este método adiciona os dois resultados
    

    Não fale de programação mas sim de funcionalidade. É preferível que os nomes dos métodos, funções e variáveis falem por si. Já lá vai o tempo em que os nomes tinham de ter 8 caracteres no máximo. Já agora, chamar “map” ou “array” a algo é inútil. O nome deve refletir o que o elemento contém e se possível, a sua ligação ao negócio (ex. “clients”, “accounts”).

  6. “Logs” por todo o lado devem ser evitados. Domine o debugger em vez de “sujar” o código com instruções de debug… Há situações em que é útil, mas a maioria das vezes abusa-se (ex.: “agora entrei aqui”, “adicionando o produto…”). Idealmente, o código deve tender para ter só a parte que “interessa ao negócio”; tudo o que é acessório/auxiliar deve “tender para zero”.
  7. Resolva os warnings identificados pelo IDE (é provável que ele tenha razão).
  8. Não complique o que é simples:
    if (xpto <= MAX) 
    { 
        return true; 
    }
    else
    { 
        return false;
    }
    
    return xpto <= MAX;
    
    ou:
    
    function Cliente getCliente(int id) 
    {
       Cliente cliente = bd.getCliente(id);
       return cliente;
    }
    
    function Cliente getCliente(int id) 
    {
       return bd.getCliente(id);
    }
    

Quantidade de código

Tal como ao escrever um texto, se deve ter cuidado com frases e parágrafos muitos extensos, também os métodos e classes de código-fonte devem ter um tamanho sensato. Uma classe com 1000 linhas ou um método com 100 é longe de razoável. De certeza que é possível subdividir, repartir responsabilidades, separar, limpar, etc. É uma questão de bom senso.

Um método/função deve concentrar-se apenas num objetivo, seja ele um algoritmo, tarefa, ou outro. Uma classe também deve ter código que sirva algo em comum. Não deve ser um “saco” de conceitos e operações heterogêneas.

De qualquer forma, ao seguir as recomendações dadas em “Lixo no código”, é bem provável que reduza o tamanho do código em mais de 30%…

Conclusão

Em conclusão, faço um resumo dos sinais que (embora não sejam prova garantida) devem lançar o alerta na mente do programador:

  • “Copy/paste” de código dentro do mesmo software;
  • Fazer catch e/ou throw de exceções demasiado genéricas (ex.: Exception ou Throwable em Java);
  • Fazer catch e/ou throw de exceções de runtime do ambiente (ex.: as SystemException do C# ou qualquer derivada);
  • Abusar do nesting (ter nível 3 é de evitar; nível 4, muito mais);
  • Ter um método com mais de 50 linhas;
  • Ter uma classe com mais de 1000 linhas;
  • Ter tanto código de debug como “de negócio” (mais de 20% já deve lançar o alerta);
  • Código que precise de explicações (bom código fala por si; apenas precisa de comentários que o liguem à funcionalidade/negócio);
  • Blocos de código comentado;
  • Warnings do IDE por resolver.

Fonte

Análise: Avell FullRange G175 FIRE XR

Desde o ano 2000, a fabricante de notebooks Avell, com foco somente em notebooks, tem inovado o mercado Brasileiro de portáteis com modelos de notebooks de alto desempenho, personalizados com as mais variadas cores, configurações e tamanhos.

Foi na primeira semana de Julho de 2015 que a Avell anunciou o lançamento de uma nova opção para quem está em busca de um notebook de alto desempenho especializado em games, o FullRange G175 Fire XR.

“Este novo modelo agrega para o cliente mais potência em placas de vídeo e processador, tudo dentro de um gabinete leve e de espessura fina, que já são características únicas da marca”

Afirma Emerson Salomão, fundador da empresa. Assim como outros produtos da companhia, a novidade se destaca pelas possibilidades de customização oferecidas, que se adaptam às necessidades de cada consumidor.

“O produto também apresenta tela de 17 polegadas, a mais utilizada para os jogos virtuais e, ainda, todas as entradas e saídas para ganhou de conectividade em campeonatos nacionais e internacionais”

Complementa Salomão. Com 10 anos de mercado, a Avell comercializa seus produtos em lojas físicas nas cidades de Joinville, Florianópolis e Curitiba. Além disso, também é possível adquirir o portfólio de produtos da fabricante através do site www.avell.com.br que distribui equipamentos para todo o Brasil.

Primeiras Impressões

Para quem não viu ou tem curiosidade a ver segue o unboxing que fiz:

A partir do momento em que pegamos na caixa parece-me que é clara a mensagem que a Avell quer transmitir, que é de termos acabado de comprar um notebook top. Quando finalmente se abre a caixa, vemos que valeu totalmente a pena.

IMG_20150902_180848 IMG_20150902_180913 IMG_20150902_181006 IMG_20150902_181018Hardware e Design

O tamanho e o peso podem assustar um pouco, mas, assim que você abre a tampa pela primeira vez, percebe como todos os detalhes foram bem trabalhados nesse modelo. Toda a tampa externa e região interna — que fica próxima ao touchpad — possuem uma textura emborrachada. Apesar de o seu visual ser relativamente elegante e parecer ser frágil, é construído com uma base sólida e com uma textura estilizada, o desenho do equipamento se destaca em alguns pontos.

Especificações técnicas Avell FullRange G175 FIRE XR

CPU-Z

  • Processador: Intel Core i7 Haswell – 4710MM 2,5 GHz, 6 MB cache (3,5 GHz com Max Turbo);
  • Memória: 16 GB HyperX Impact DDR3 (1600 MHZ) / (2x 8 GB);
  • Armazenamento: SSD 240 GB Crucial BX100 SATA III + SSHD 1 TB com 8GB SSD Seagate;
  • GPU: NVIDIA GeForce GTX 950M (2GB Dedicado);
  • Tela: 17,3″ 16:9 (1920×1080) Full HD LED-Backlit Matte
  • Conectividade: Bigfoot Killer Wireless-N 1202 – 802.11 A/B/G/N – Wifi + Bluetooth 4.0 Combo;
  • Sistema operacional: Sem sistema operacional, mas instalei o Windows 10:

Para mais informações ver o arquivo CPU-Z.html

Os ângulos são bons, e tudo junto faz com que tenha uma coloração perfeita. A falta de pormenores no acabamento não ajuda a evitar os reflexos quando se está no exterior, apesar da qualidade de imagem ser fantástica, tendo uma excelente nitidez, uma iluminação homogênea e uma fidelidade no que toca a cores exímia.

Pela própria textura, mesmo um uso regular, consegue verificar que ele foi pensado, exatamente, para quem passa muito tempo no notebook, pois não são visíveis marcas de impressões digitais ou de outras texturas.

CONTRA: O botão de ligar/desligar, quando ligado à corrente, funciona perfeitamente, por sua vez, quando ligado só com a bateria, é preciso aplicar alguma força para conseguir ligá-lo. Contatei a Avell para perceber o porquê onde o Armstrong me informou que, por ser um notebook de alto desempenho, ele pesa um pouco no arranque, sendo necessário, inclusive, manter o dedo pressionado.

Deixo algumas imagens retiradas do site da Avell e que são fidedignas do notebbok.

3_19_7 4_16_5 5_12_47 6_10_35 8_7_23 9_5_21 11_3_25 2_21_8 1_20_10 18_3_4 17_3_4 16_2_9 15_3_7 14_3_9 13_3_12 12_3_16

Teclado e Mouse

Para quem faz do computador uma ferramenta de trabalho, sabe da importância que é ter um bom teclado e o da Avell FullRange G175 FIRE XR, é fantástico. As teclas estão devidamente distanciadas, são de toque fácil e preciso, não há folgas nem imperfeições, e gosto principalmente do tamanho das teclas e do toque preciso. Outra coisa que gosto é a forma como ele se enquadra com o computador. O teclado de 102 teclas tem retroiluminação discreta, poderia ser automática e adequar-se à iluminação do ambiente, mas por ser discreto, é um bônus, já que a maioria dos teclados retro iluminados tendem a ser excessivamente brilhantes em ambientes escuros. A luz de fundo não é perceptível durante o dia.

O teclado é iluminado e possui teclas com um ótimo acabamento, além de elas serem bastante firmes ao toque. Como o notebook possui um tamanho “avantajado”, é possível ter um teclado numérico completo, assim como acontece com os teclados para desktops.

CONTRA: o layout do teclado não é o do Brasil, o que dificulta a habituação ao início.

O touchpad tem uma dimensão razoável e tem uma superfície suave, tendo suporte para um bom número de gestos multi toque, como aumentar/diminuir o zoom, subir e descer as páginas usando três dedos, entre outras.

O botão de clique é grande, e pode-se clicar em qualquer parte para produzir o efeito do clique. É de salientar a boa precisão do mouse.

CONTRA: o botão direito do mouse aparenta uma certa dificuldade, pois a maioria das vezes comporta-se como se fosse clicado no botão esquerdo, tendo um local exato para se clicar e que funcione.

Portas disponíveis

Pelo fato do Avell FullRange G175 FIRE XR não ser nada fino, e ter um tamanho considerável, seria de esperar algumas portas USB a mais.

No demais ele conta, na parte esquerda, com uma portas USB 3.0, uma entrada HDMI, e-Sata, VGA, Ethernet e cabo de força. Já no lado direito, tem entrada para microfone e auscultador, duas portas USB (sendo uma 3.0),  e uma drive óptica, o que acaba por ficar feio, uma vez que solicitei sem a drive e vem com o layout dela, apesar de não conter nenhuma, e por fim uma entrada de Kensington Lock. Já na parte da frente do lado direito, encontra-se a entrada para o cartão de memória (SD).

No teste que fiz para a bateria adotei um uso tipicamente normal, onde a bateria foi carregada a 100%, o desempenho escolhido foi o padrão do Windows, com uma luminosidade da tela a 50%. Assim, e com um uso típico, como leitura de uns artigos, navegação na Internet, email, facebook, chat, edição de textos, sempre com música a tocar e ocasionalmente um vídeo no YouTube, consegui uma autonomia de 4h e 02 minutos, o que considero bom.

Performance e Benchmarks

A primeira coisa que se faz assim que se vai para o computador é ligá-lo, e neste caso, temos uma agradável surpresa no tempo de boot, já que um PC normal pode demorar até um minuto ou mais entre o momento em que carregamos no botão on/off até ele estar pronto a usar. No caso do Avell FullRange G175 FIRE XR ele demora uns incríveis 10 segundos. Já se falarmos em suspendê-lo, por exemplo, fechando a tampa, é praticamente instantâneo.

O desempenho deste Avell é de topo, já que podemos fazer praticamente qualquer coisa com ele, exceto, por exemplo, inclusive jogar jogos 3D como Call of Duty: Modern Warfare 3. O SSD de 250GB está entre o mais rápido que já testei, isso facilmente é denotado pelo tempo de arranque dele que, juntamente com o seu processador i7, faz com que não tenhamos que esperar praticamente nada para fazer qualquer ação.

Durante praticamente 2 semanas de utilização não tive qualquer problema com o desempenho, sendo que o i7 incorporado dá conta do recado para qualquer ação que pretenda fazer no seu dia-a-dia ou mesmo a nível profissional, como foi o meu caso.

No entanto vou deixar aqui alguns dos resultados dos testes que obtive:

CrystalDiskInfo

O CrystalDiskInfo é uma ferramenta que nos permite saber um pouco mais sobre o disco rígido instalado no computador para a unidade C e D:

CrytalDiskInfo_UnidadeC

CrytalDiskInfo_UnidadeD

CrystalCPUID

O CrystalCPUID é uma ferramenta simples cujo objetivo é o de obter e informar as especificações do microprocessador instalado no computador:

CrystalCPUID

CrystalMark 2004 R3

O CrystalMark é uma ferramenta para benchmark, ou seja, ele testa os recursos e o desempenho do computador. Com ele podemos testar o processador, a memória, o disco rígido e recursos de vídeo (entre eles GDI, Direct Draw e OpenGL):

CrystalMark2004R3

Para uma informação mais detalhada pode consultar o arquivo CrystalMark2004R3.html

Problemas técnicos

Após ter comprado o meu notebook no terceiro dia de uso efetivo, ele apresentou problemas, tendo travado completamente, apenas realizando uma vídeo chamada no skype, e fazendo um barulho que parecia vir da parte de baixo do notebook.

O esperado seria, que assim que fosse comunicado houvesse prontidão em reparar o sucedido, enviando um novo, agendando uma recolha, emitindo um guia de recolha pelos correios, ou algo, porém tal não se verificou. Reportei o incidente a 2 de setembro de 2015 às 18:03, somente a 9 de setembro de 2015 às 14:52 foi liberado a ordem de recolha do equipamento para que houvesse reparo, sendo que a dia 4 de setembro de 2015 às 14:17 foi expressamente dito “vai aguardar um código de postagem que enviaremos em seu e-mail em até 24hrs“, bem mais que 24 horas se passaram. No pré venda o atendimento fantástico, porém no pós venda, quando se necessita da garantia o atendimento não é tão ágil.

Depois de enviar o meu notebook NOVO com apenas 3 dias de uso dando problema, no dia 11 de setembro de 2015 às 09h43, e apesar de ser explícito no email que nas Agência de Correios Própria – AC fariam a embalagem e que estava coberta pelo código de autorização de postagem o que é certo é que os Correios indicaram que não consta embalagem nessa autorização bem como não dispunham de plástico bolha, isopor ou algo para embalar devidamente o equipamento conforme era descrito pelo email, pelo que tive de arcar com o custo de embalagem no valor de R$ 12.00 sendo esse valor restituído depois pela Avell no dia 21 de setembro de 2015.

Ainda no dia 11 de setembro de 2015 às 15:51 enviei um email para garantia@avell.com.br sem resposta, outro a 15 de setembro de 2015 às 13:23 também ele sem resposta. Sendo que Simplesmente a 15 de setembro de 2015 às 16:14  recebi um email que parecia daqueles emails “automáticos” sobre a abertura da Ordem de Serviço, que em nada me esclarece a situação. Era de se esperar muito mais de uma empresa como a Avell visto o note ter dado problema logo com 3 dias de uso, ter o adquirido, faz hoje (dia 18 de Setembro de 2015) exatamente 1 mês e de o ter usado por 4 ou 5 dias. Faz hoje (dia 18 de Setembro de 2015) também 1 semana que enviei o notebook, de acordo com o site dos correios foi recebido no dia 14 de setembro de 2015 às 16h31 e faz mais de 72h (hoje às 16h31 fará 96h) que estão com o notebook.

rastreamento

Demoraram praticamente 24h para abrir o chamado, pelo menos de acordo com o email que recebi a 15 de setembro de 2015 às 16:14 e que indicava que os trabalhos só iniciariam no dia seguinte, ou seja, após terem o notebook, somente com mais 36h é que iniciavam a averiguação do problema.

Até hoje, diferentemente de quando comprei recebia um email diário a saber o estado da encomenda, se estava em montagem, em testes e tudo mais, estou sem saber o estado da situação nem tampouco uma perspectiva de quando a situação estará sanada.

Depois a dia 18 de setembro de 2015 às 09:19 foi verificado que o problema era na motherboard o qual foi reparado e o notebook postado nos correios a dia 21 de setembro de 2015 às 14:23, porém só avisado e notificado do seu envio e código de rastreio a 23 de setembro de 2015 às 14:03

Dessa forma recebi o notebook em casa a 25 de setembro de 2015 às 19h00, e a 10 de outubro de 2015 às 11:40 reportei novamente um problema com o notebbok, curiosamente, o mesmo problema, o qual foi respondido a 13 de outubro de 2015 às 10:03, com início de produção de uma nova máquina e que em até 24h receberia um código para poder postar nos correios o notebook defeituoso.

Desta segunda vez, bem mais prestáveis e ágeis no atendimento.

Assim, enviei o notebook aos correios no dia 16 de outubro de 2015, e o envio do novo notebook feito a dia 23 de outubro de 2015, sendo que o recebi dia 26 de outubro de 2015.

NEGATIVO: atendimento pós venda na solicitação da garantia.

Acessórios

Mochila Case Logic 17″ VNB-217

A mochila tem um estilo aerodinâmico e recursos inteligentemente colocado somam uma pegada minimalista. A mochila Case Logic VNB-217 possui compartimento acolchoado que comporta um nootebook de 17″, divisória separada para revistas, pastas e arquivos. Também tem painel de organização para eletrônicos portáteis, canetas e demais acessórios, bolso especial para celular e compartimento externo em malha para squeezes ou garrafas de água. É transportada por alças acolchoadas e ajustáveis.

Mouse Opt Tarantula Fortrek OM702 PT

O mouse Spider Tarantula da Fortrek tem características e traços muito parecidos com o  Team Scorpion X-Luca II, parecendo uma cópia, o produto da Fortrek se diferencia em detalhes mínimos.

Mesmo com todas estas ressalvas de construção e design, o OM-702 é confortável de se utilizar, e para quem tem uma mão grande, é ergonomicamente bom, pois a parte traseira do mouse se encaixará perfeitamente na palma da mão e esse é o principal elemento para fazer do equipamento um bom acessório. Em termos de visual, por fora reparamos um tom um pouco mais invocado e uma boa combinação das cores preta e vermelha. Embora a estrutura seja de plástico nas laterais, podemos observar uma textura de borracha para dar mais firmeza às mãos. Os botões de clique direito e esquerdo são bastante suaves mas não silenciosos, e são acompanhados por dois botões na parte esquerda que podem ser utilizados como macros ou como avançar e retroceder por exemplo. Já na parte central do mouse, fica o botão de ajuste de DPI, que, contrariamente no que diz no site da Avell “O Mouse Tarantula possui iluminação em LED que muda de cor de acordo com o DPI, facilitando a identificação do DPI selecionado.” o mouse não muda o LED após mudança do DPI, o que é ruim pois dificulta saber qual está selecionado.

Como tal achei que deveria notificar a Avell, visto que a própria descrição encontra-se no site da Fortrek http://fortrek.com.br/mouse-gamer-optico-spider-tarantula-om702-pretovermelho-fortrek-243.html, pelo que mesmo não sendo culpa direta deles, prontificaram na resposta por parte do Laércio Esteves, corrigiram a informação no site deles e ainda me ofereceram de brinde um case de neoprene, que é utilizada para proteção do notebook. Achei bem legal a atitude deles.

fone-headset-gamer-e-mouse-usb-tarantula-com-frete-gratis-21882-MLB7584368269_122014-F mouse_fortrek_gamer_spider_tarantula_54623_2391_2_20141205184730Fortrek-Spider-Tarantula-OM702-17-1024x768 Fortrek-Spider-Tarantula-OM702-34-1024x768 Fortrek-Spider-Tarantula-OM702-42-1024x768 Fortrek-Spider-Tarantula-OM702-43 Fortrek-Spider-Tarantula-OM702-46-1024x768 Fortrek-Spider-Tarantula-OM702-411-1024x768

PS: Imagens do mouse retiradas na internet.

Meu Veredito

Muitas são as marcas que estão no mercado dos notebboks e computadores, no entanto poucas são as que conseguem chegar aos pés da qualidade/design dos produtos da Apple. Hoje em dia não basta um computador ter características potentes, é preciso ter um design cativante, já que, cada vez mais, os olhos são também um fator de decisão. E hoje em dia, principalmente com a vinda dos tablets, há um novo fator a ter em consideração, o tato. Quando falo em sentir/tato, falo principalmente no conforto depois de várias horas a trabalhar com ele, e acreditem que faz toda a diferença. É claro que tudo isto tem um preço, principalmente quando deste conforto depende o nosso desempenho.

O Avell FullRange G175 FIRE XR é praticamente perfeito em quase tudo, com exceção do seu sistema de som O ecrã 17,3″ 16:9 (1920×1080) Full HD LED-Backlit Matte confere uma qualidade de imagem fantástica, com ângulos de visualização muito bons. O desempenho é excelente, uma inicialização completa leva menos de 11 segundos. O teclado retro iluminado é de alta qualidade e o touchpad é bastante preciso. É bem refrigerado porém um pouco barulhento quando se puxa por ele. Por último, mas não menos importante, a qualidade da construção é aceitável, não é das melhores, e pelo preço pago bem que poderia e deveria ser bem melhor, já o design é relativamente elegante sem ser exagerado.

Pontos Fortes

  1. Tela de alta resolução e qualidade de imagem fantástica;
  2. Excelente desempenho;
  3. Excelente teclado retro iluminado;
  4. Boa duração da bateria;

Pontos Fracos

  1. Sistema de som;
  2. A quantidade limitada de portas USB;
  3. O botão ligar / desligar;
  4. Preço;
  5. Caixa de drive ótica quando não existe;
  6. Botão direito do mouse (touchpad);
  7. Problemas técnicos;

Como não gerir um projeto de software

Li um artigo no pplware extremamente interessante que resolvi partilhar.

A gestão de projetos não é uma ciência exata, muito menos a de projetos de software. Em engenharia de software, existe alguma incerteza nas metodologias, nas estimativas, nas representações, entre outros. Um programador não é um robô (tal como um designer).

Ao contrário do que se passa noutras engenharias, é muito fácil falhar, porque não existe uma “receita” de como fazer as coisas bem. Sendo uma pessoa por si só complexa, um conjunto de pessoas e as suas dinâmicas podem ser muito mais.

É necessário perceber o que costuma falhar quando os projetos derrapam no tempo e nos custos associados. É importante que um gestor “dê dois passos atrás” e tente perceber os padrões emergidos ao longo do tempo. Existem diversas técnicas que podem ser usadas para o efeito (ex: 5 whys, análise de casos de insucesso).

Desenvolvimento de software vs. produção em massa

Uma das principais falhas que identifico são modelos de gestão inadequados e desatualizados; muitos gestores de hoje acham que estão a gerir uma fábrica ou linha de montagem, quando na realidade a criação de software não é um processo mecânico e envolve muita criatividade e inspiração.

Um programador não é um robô; o processo de programação envolve iterações, otimizações e colaboração. Pode, por vezes, ter semelhanças com a arte: envolve inspiração (variável), tem cunho pessoal e não há uma receita para se programar bem, pelo que o algoritmo/programa ideal é o culminar de algo e não uma tarefa sistematizável.

Tal como com artistas ou designers, colocar pressão nos programadores para trabalhar mais rápido e mais horas, só traz resultados a curto prazo. A médio/longo prazo, a qualidade do produto é comprometida e a motivação dos programadores afetada (ambos de muito difícil retorno). O gestor que não perceba isto talvez esteja no ramo errado.

Imposição de metodologias

Outro problema comum é a inflexibilidade. Há gestores que consideram que modelos de gestão usados com sucesso em alguns projetos podem-se aplicar indefinida e indiscriminadamente noutros. Mesmo o Scrum, uma metodologia na moda, ágil e pragmática, não é a solução para tudo. Por outro lado, alguns gestores gostam de impor o uso de ferramentas que muitas vezes são inadequadas ou desnecessárias (ex: de imputação de horas); é sempre preferível que seja a equipa a decidir aquilo que mais valor traz ao projeto e à empresa.

O uso incorreto de metodologias pode ter um grande impacto, podendo mudar drasticamente o decorrer do projeto. Por exemplo, a maioria dos gestores/chefes desvaloriza ou desconhece por completo técnicas como a análise de tarefas, prototipagem em papel, pair programming ou o valor das iterações no desenvolvimento.

Transparência

Outra questão importante é a comunicação. Os gestores devem comunicar com a equipa informando sobre o negócio, objetivos, enquadramento, próximos passos, datas, parceiros, etc. Nenhum programador gosta de ser “um simples executante” sem voto na matéria ou sem poder questionar. A maioria dos programadores gosta de fazer uso do seu espírito crítico. A causa por detrás de um pedido alimenta a motivação do programador em implementá-lo.

Pouco ou nada deve ser escondido da equipa. Só na posse de todos os dados do projeto é que os programadores podem dar o seu melhor (ex: se um programador souber que algo se pode complicar, pode preparar o código para tal). Pela mesma razão, é nocivo afastar muito os programadores do negócio, do cliente e principalmente dos utilizadores.

Tratar de todo um processo e só depois dar à equipa para implementar é demonstrar falta de confiança nas suas capacidades. Por outras palavras, separar o levantamento e análise de requisitos de quem os vai implementar é nocivo para a motivação da equipa e consequentemente para o desenvolvimento do projeto. Análise e implementação devem estar de mãos dadas.

A bottom line é que todos estão a lutar pelo mesmo fim: o sucesso do projeto/empresa, pelo que todos devem partilhar da mesma informação.

Imposição de tecnologias

Um dos pontos mais graves na gestão de projetos talvez seja quando se impõe a utilização de certas tecnologias. Ou porque o gestor já usou e gostou, ou porque leu num blogue, por capricho, ou porque um amigo lhe contou… Pior ainda, é quando o faz antes sequer dos requisitos serem analisados. As tecnologias usadas devem emanar das necessidades e devem ser decididas pela equipa, isto é, devem ser consequência de uma necessidade e não o oposto.

Na verdade, impor seja o que for só pode resultar em desmotivação das equipas. Mesmo que a tecnologia faça todo o sentido, há que “conquistar as pessoas” através da justificação e não da imposição.

Dimensionamento

Outro problema grave que costuma ocorrer no fim do projeto é quando, em desespero de causa, os gestores (que mal conhecem a equipa) começam a adicionar mais elementos, convictos que isso vai acelerar a conclusão do projeto. A história clássica que ilustra esta situação é a de que 9 mulheres não têm um filho num mês

A integração de um novo elemento exige tempo e esforço extra da equipa inicial e faz com que o processo se atrase, para além de que a própria pessoa tem um período de ramp up em que a produtividade é relativamente baixa. Por isso, o crescimento de uma equipa deve ser gradual e sustentado. Novos elementos devem ser adicionados previamente e devidamente guiados, mas para isso é necessário uma boa capacidade de antevisão e conhecimento das capacidades das pessoas.

Outro problema é quando os gestores acham benéfico espalhar um projeto por múltiplos locais do mundo, acreditando que isso vai acelerar o processo ou “criar sinergias”. Na realidade, está-se a lidar com culturas e timezones diferentes, o que só pode piorar as coisas. É impossível trabalhar dessa forma a não ser que estejamos a falar de um projeto em fase de manutenção e com componentes bem separados e de fronteiras bem definidas.

Proximidade da equipa

Pessoalmente sempre defendi um modelo de gestão mais informal, em que o chefe é um líder e não um chefe clássico. Um líder não dá ordens; um líder comanda a direção e velocidade do “barco” e evita os obstáculos. Idealmente, o chefe deve ser parte integrante da equipa, metendo as “mãos na massa” de vez em quando ou em alocação reduzida. Na realidade, isto tem consequências benéficas como:

  • Criar um espírito de equipa mais coeso pela partilha dos problemas e dos sucessos;
  • Saber, em tempo real, o estado corrente do projeto;
  • Imbuir autonomia e poder de decisão no seio da equipa;
  • Conhecer melhor os elementos da equipa (ex: problemas);

(O Scrum leva isto mais longe dizendo que não há chefes de equipa: todos o são e ninguém é; a equipa é responsável por analisar, atribuir prioridades e implementar.)

É verdade que a gestão de projetos é uma disciplina por si só, aplicável a qualquer domínio. No entanto, sou cético no que toca a gestores “genéricos” sem formação/experiência em software, que consigam levar tal tipo de projeto a bom porto. O chefe, ou melhor, o líder, deve emergir naturalmente, quando isso é possível. Mais importante que saber mexer no MS Project é ter empatia: perceber as pessoas e ter sensibilidade para as suas potencialidades, preocupações e aspirações.

Qualquer programador se incomoda (e desmotiva) com estimativas infundadas do estilo «isso são 5 minutos», «está tudo feito» ou «são 5-10 linhas de código», mostrando total desconhecimento das tecnologias/projeto e desrespeitando a equipa e o seu trabalho.

Gestores que só falam em termos genéricos, buzzwords para impressionar e frases sem conteúdo (mumbo jumbo), estão distanciados da realidade da equipa e pouco podem ajudar (podem é prejudicar). Um gestor deve conhecer a equipa e só estando perto da mesma a pode proteger e apoiar. Gestores e chefes isolados em gabinetes pertencem ao passado.

Em resumo, o que não fazer:

  • Tratar a equipa como máquinas; na realidade, são criativos;
  • Esconder dados importantes da equipa, criando um fosso entre a mesma e a gestão;
  • Impor o uso de metodologias, técnicas ou tecnologias;
  • Adicionar novos elementos na ilusão de que isso acelera a execução do projeto;

Fonte

8 erros mais comuns do programador

Li um artigo no pplware extremamente interessante que resolvi partilhar.

É importante analisar os projetos de software que correm mal. Nem sempre são resultado dos prazos impossíveis ou de maus gestores. Geralmente é um somatório de fatores que entra numa espiral causa-efeito. Tentarei agora identificar alguns erros comuns dos programadores (também aqui me incluo). Tais erros não são exclusivos do programador júnior. De facto, alguns são cometidos mais frequentemente pelo programador sênior.

Por outro lado, não se pretende aqui falar em más práticas de programação mas sim de soft skills e de gestão pessoal.

Os papéis do Programador

A palavra ‘programador’, neste artigo, é usada para representar ‘developer’ (já que ‘desenvolvedor’ não é muito usado em Portugal). Vejo um developer não só como um técnico, mas como um engenheiro de software:

  • Opera em várias stacks do software: interface, lógica de negócio, bases de dados, …
  • Pode ter diferentes responsabilidades: sys. admin., tester, designer de interfaces, etc.
  • Passa pelas várias fases do projeto: pré-estudo, desenho da solução, implementação, etc.

É também um gestor, pois:

  • Nem sempre um chefe está presente.
  • O chefe não deve realizar microgestão (gestão de subtarefas).
  • Há metodologias em que nem existe o chefe (ex: Scrum) e todos o são.

Um programador também é um cientista: coloca, testa e descarta hipóteses, optando por algo com base em factos. Demonstra ceticismo perante afirmações infundadas.
Por fim, é um consultor: usa a sua experiência para aconselhar, reconhecendo padrões e propondo soluções. É um ser social que deve respeitar o cliente e o ambiente do projeto em causa. Sem essa componente, é o chamado code monkey.

Comecei por falar em culpa; na verdade, a culpa não é de quem erra, mas sim de quem não tem humildade para reconhecer os erros e nem os tenta corrigir. Um bom programador reconhece os seus defeitos e limitações em vez de os desconhecer ou ignorar; deve ser humilde para realizar esta introspeção, não achando que sabe tudo e assim melhorando no dia-a-dia.

1. Estimativas idealistas

«Faço isso em 2h»

Por vezes, os programadores falham nas estimativas por uma questão de orgulho: prometem que são capazes de entregar algo em pouco tempo quando, na realidade, isso aconteceria apenas em condições perfeitas e ideais (o que é muito raro; há sempre problemas). Estimar algo é difícil por natureza (o Scrum, com as suas estimativas relativas em vez de absolutas, pode aligeirar isso) e reconhecê-lo é o primeiro passo para minorar o problema.

É certo que os programadores são muitas vezes pressionados a prometer prazos impossíveis. No entanto, quando no fim esses prazos não são cumpridos, foi o gestor que ficou a perder (com o projeto prejudicado e a equipa cansada e desmotivada). Se o resultado final seria semelhante, mais valia ter sido realista. Será preferível viver na feliz ilusão ou no realismo sólido dos prazos? É preferível criar falsas expectativas? O programador deve tentar, progressivamente, incutir estas ideias nos seus superiores

2. Alienação do negócio

«Não tenho nada a ver com isso»

Alguns programadores ficam de tal forma empedernidos no código que perdem a ligação ao negócio. Seja porque estão a fazer algo muito complexo, porque estão a gostar muito ou porque simplesmente não querem saber. Muitas vezes não lhes é explicado o negócio em que está inserido, mas outras, ele também não procura saber mais. Contudo, o programador, acima de tudo, é um engenheiro de software, pelo que é geralmente contratado para resolver problemas do negócio, e não para simplesmente programar.

Fazem-me alguma confusão ofertas de emprego do estilo “especialista em JavaScript”, quando o que uma empresa devia procurar era um especialista em frontend muito bom em JavaScript (talvez haja exceções a esta afirmação). A empresa poderia ter mais a ganhar com alguém com uma noção mais abrangente de como as peças se encaixam.

3. Delegação da culpa

«A culpa é do utilizador»

Programar, por mais gratificante que seja (e por mim falo), é apenas uma ferramenta ao serviço do projeto/produto e, por conseguinte, da empresa/cliente. Em última análise, programa-se para o utilizador (nem sempre assim é, mas regra geral, e especialmente em sistemas de informação), pelo que as nossas ações devem envisioná-lo direta ou indiretamente.

Culpar o utilizador (“ele que atualize o browser”, “não são muito inteligentes”, “ele é que não viu o botão”, …), além de nada fazer para resolver o problema, desculpabiliza os verdadeiros culpados que não conhecem o seu público-alvo. Por outro lado, descaracteriza a profissão, pois os utilizadores são a razão da existência dos sistemas de informação e dos consultores informáticos.

“Não fui eu que fiz isso”

Por outro lado, há casos em que o programador, por não ter sido ele a fazer e/ou não ser da sua área, se descarta e/ou oferece resistência a mexer em algo. Admite ignorância sobre um assunto para fugir à realização de uma tarefa. Passado algum tempo, adquire a chamada “visão em túnel” do negócio.

O que o programador deve perceber é que,“no fim do dia”, todos são de todas as áreas e todos são da empresa. Todos devem lutar pelo bem do projeto, pelo que não devem haver “lugares marcados”. O bem de um é o bem de todos e há que evitar que as agendas pessoais interfiram no sucesso dos projetos.
Descartar de imediato a culpa ou responsabilidade não acrescenta valor. Geralmente, não se procura um culpado mas sim uma solução.

4. Medo do refactoring

Por motivos de pressão superior e/ou medo de estragar alguma coisa, há muitos programadores que optam por “mexer o mínimo possível”. Quando é preciso uma alteração, acabam por (na gíria do software) “dar marteladas” ou fazer “copy/paste” de código, entre outras péssimas práticas. O código transforma-se então em “código-esparguete”, que já ninguém consegue manter. O programador deixa assim morrer o seu perfeccionismo e o projeto perde a sua melhoria contínua.

Como em tudo na vida, deve haver um balanço. Não defendo que se deva estar sempre a mudar tudo, mas o bom código muda. Muda porque os requisitos mudam, as dependências (ex: S.O., browser) mudam, porque aparecem (ou se aprendem) novas técnicas, porque algo trará mais valor ao utilizador, etc.

Portanto é melhor aceitar a mudança que negá-la. É certo que há produtos com um término bem definido, mas mesmo esses entram em fase de manutenção e têm novas funcionalidades de tempo a tempo.

Para evitar criar o medo da mudança, deve-se reduzir o risco associado à mesma:

  • O bom código fala por si: é simples, estruturado e elegante o suficiente para estar preparado ser modificado.
  • Comentar o código todo é utópico; por isso, deve-se comentar pelo menos as operações destrutivas, as importantes e as diretamente ligadas ao negócio.
  • Devem existir testes que permitam verificar que tudo continua bem após uma mudança (para tal, é bom conhecer o TDD).
  • Deve-se considerar a preparação de ambientes de teste e de staging.
  • Deve ser fácil voltar atrás caso algo negativo aconteça (inclui reverter código facilmente assim como realizar deploys rápidos).
  • Todos os programadores devem tentar conhecer todo o código; para tal, o pair programming e o code reviewing podem ajudar.
  • Todos os programadores devem conhecer muito bem a arquitetura do projeto (e do sistema onde ele se insere) antes de alterar código; isso pode mudar tudo. Para isso, bastam simples diagramas e páginas em wikis internas.

5. Deslumbramento pela tecnologia

«Vamos converter tudo para Swift»

É comum o programador sofrer de “entusiasmo pela tecnologia”. Como consequência, acaba por caprichar ou até forçar o uso de determinadas tecnologias, nem que isso implique mudar todo um projeto. Não tem mal ser um entusiasta. De facto, até pode ser importante. Não se deve é deixar de se fazer uma análise imparcial às várias tecnologias, antes de se optar por uma. Eis alguns falsos argumentos para a escolha de uma tecnologia:

  • «Já usei isto em muitos projetos»
  • «Ele já tem muita experiência; vamos usar»
  • «Estou mesmo curioso em experimentar»
  • «Sinto que é o ideal»
  • «Li num blogue que é espetacular» ou «É o que o Google usa»
  • «Toda a gente usa isto agora!» ou «É o que está a dar»

Não há soluções universais e a oferta tecnológica está em constante mudança, pelo que é provável que seja sempre necessário pôr as coisas em causa.

O bom programador, mesmo que entusiasta, sabe refrear os ânimos quando conhece uma tecnologia ou sai o “último grito” de uma framework. Sabe que o negócio está à frente da tecnologia e que quanto menos tecnologias um projeto tem, melhor. O mau programador enche um projeto com dezenas de bibliotecas e frameworks que o tornam “sensível” (em que não se pode mexer), com inúmeras dependências e potenciais pontos de falha.

6. Desvalorização de “desenhos”

«Desenhar no PC é muito melhor»

É fácil cair no erro de se achar que já se resolveu tudo na cabeça. Isto aplica-se tanto a um algoritmo, a uma interface, ou até a uma arquitetura de software.

Quem não se lembra do liceu, em que um simples desenho ajudava a resolver e acompanhava a solução de problemas de matemática, física e química? Poder visualizar algo complexo em imagens é determinante, na solução e no caminho para lá chegar.

Com “desenhos” refiro-me a simples protótipos de baixo nível (wireframes), fluxogramas e outros esquemas e esboços. Não me refiro a usar ferramentas do tipo Visio ou Photoshop, mas sim papel (ou quadro) e caneta/lápis. Passo aos exemplos, para melhor expressar esta ideia:

  • Fluxogramas para expressar algoritmos, interações e outros fluxos.
  • Protótipo de baixo nível não funcional (mockups ou throwaway prototypes) para representar interfaces gráficas (GUI).
  • Diagramas de classes (e de outros tipos) para representar conceitos arquiteturais.

Este tipo de desenhos tem as seguintes vantagens:

  1. Cativam a reflexão sobre o problema, colocando-o numa linguagem (tal como falar sobre um problema a alguém). Isto permite desde cedo abandonar ideias sem futuro e reforçar outras interessantes. Ter um modelo mental coeso da solução permite ser muito mais objetivo na hora de a pôr em prática.
  2. Promovem a comunicação: é muito mais fácil apresentar uma ideia a alguém se ela for gráfica. Por outro lado, é mais fácil que 2 ou mais pessoas construam um modelo mental semelhante da solução, em vez de cada um ter o seu.

Como consequência, poupam-se custos desnecessários. Um desenho que custou 20 minutos a fazer pode poupar muito mais tempo ao programador e à empresa, evitando muito refactoring desnecessário. Mesmo após esse refactoring, o código pode nem ficar com a qualidade que teria caso se tivesse uma ideia bem definida do problema desde cedo.

6. Desvalorização do pair programming

A técnica do pair programming é valiosa e devia ser mais aplicada. Implica que dois programadores estejam no mesmo computador. É desvalorizada exatamente por isso: porquê ter duas pessoas no mesmo local quando podiam estar ambas a programar sozinhas?

A questão é que um programador não é uma máquina; comete erros, distrai-se e não tem produtividade e motivação lineares. Ter alguém ao lado permite:

  • Maior foco
  • Menos erros
  • Melhor conhecimento do código
  • Maior partilha de conhecimento

Não é objetivo deste artigo explicar esta técnica pelo que recomendo que leia mais sobre o tema.

7. Zona de conforto

«Ele disse para fazer assim…»

Este talvez seja o tópico mais sensível, na medida em que pode afetar zonas de conforto e não é trivial colocar um superior em causa. Quando um programador recebe uma tarefa, não deve simplesmente executá-la. Deve fazer algumas perguntas básicas primeiro: “faz sentido?”, “será que é mesmo isto que o utilizador quer?”, “deve ser exatamente assim?”. Só depois de a tarefa passar neste teste inicial é que se deve avançar. Isto é ainda mais premente quando dizem não só o que fazer, mas como fazer. O programador deve, fazendo uso de argumentos lógicos, debater se essa é a melhor forma de resolver o problema.

Por outro lado, o bom programador sugere melhores formas de atuar e questiona as metodologias e tecnologias em uso.

8. O programador não é um computador

«Não te preocupes, eu trato disso»

Como lidamos com máquinas tão frequentemente, sucede o fenómeno de acharmos que também somos uma, especialmente em termos de memória. De certeza que já passou pela situação de dizer para si “não me posso esquecer disto”. É então que reserva um espaço de memória para o efeito. As tarefas e o stress da sua memorização vão acumulando e algumas vão sendo esquecidas.

Mesmo que haja um sistema de tracking (ex: JIRA), há tarefas muito pequenas que nem “merecem” lá entrar (microgestão). Por exemplo. pequenos detalhes que alguém sugere, coisas que nos lembramos “do nada” mas que não podemos implementar no momento ou subtarefas de uma tarefa.

Para isto, ter simples listagens (to do lists, checklists, etc.) pode ser muito produtivo. Um caderno, post its, ou um EcoBook sempre à mão é quase sempre suficiente. Contudo, se preferir uma versão eletrónica, pode usar o Google Keep ou o Trello (ou um utilitário semelhante). Ambos suportam listagens, sendo ágeis e colaborativos.

Há também um efeito psicológico benéfico: a vontade de completar uma listagem está sempre patente (provavelmente está ligada ao colecionismo). Sentimos motivação ao ver essa lista (principalmente se estiver sempre presente) encurtar à medida que a vamos completando.

Em suma, o que não fazer:

  • Promover a cultura do medo da melhoria.
  • Ser muito otimista nas estimativas: é melhor para o programador e gestor que o primeiro seja realista.
  • Trabalhar em função da tecnologia: os sistemas de informação devem atender e servir as necessidades de negócio e utilizadores e não o contrário: as pessoas e as empresas não deveriam ter que se adaptar aos sistemas de informação.
  • Não ter iniciativa para conhecer o negócio, o cliente e os utilizadores (e, pior ainda, culpar estes últimos).
  • Desvalorizar técnicas aparentemente rudimentares (de papel e caneta) como a prototipagem em papel, o desenho de fluxos ou simples “to do lists”.
  • Aceitar tarefas, tecnologias e metodologias sem nunca as questionar.

Fonte

A importância de dizer NÃO!

Desde pequenos somos educados para agradar o outro. Quando ganhávamos roupa ao invés de brinquedos, éramos incentivados a agradecer, mesmo não gostando do presente, isto faz com que o ser humano esteja sempre pré disposto a agradar, a dizer sim.

Quando o filho deseja algo e não consegue, de imediato abre um berreiro, e aí vem a mamãe correndo e faz a sua vontade. Sendo assim, as crianças vão adquirindo hábitos de que conseguem o que querem se houver uma resistência ou uma insistência. Dizer não, demonstra o quanto a pessoa tem personalidade e resistência a determinadas situações. Dizer não engrandece o homem.

No trabalho, quem diz sim para todos os pedidos do chefe e dos colegas, em vez de parecer um funcionário dedicado, pode acabar demonstrando falta de determinação e de postura profissional. No amor, quem se mostra extremamente disponível, é visto como sem graça – ou até como desesperado. E quem faz tudo o que os amigos pedem passa a atrair amizades oportunistas.

Para quem é da área de TI, tem sempre aquele amigo que pensa que somos “o tipo dos com­puta­dores e dos sites web”, e que pensam que isso se faz em “5 min­u­tos”, e com isso cer­ta­mente já tiveram na situ­ação de vos pedirem para fazer um site ou “desen­ras­car” alguma situ­ação. E o meu con­selho, é o seguinte… sejam cínicos e pensem sempre primeiro em vocês. Pois pedir é fácil, sem­pre foi, para um largo número de pes­soas. Assim, vejam quem vos pede.

É preciso ter consciência de que é importante aprender a dizer não, porque caso contrário, perde-se o controle de nossa vida, e sentiremos raiva por fazer coisas que, na realidade, não queremos. A isso se chama de ASSERTIVIDADE, e refere-se à capacidade de ter confiança em si mesmo para poder dizer não, sempre que for necessário.

Analisem primeiro o que essa pes­soa pode fazer por vocês, um favor prestado é um favor emprestado! Se notarem que o favor é pedido naquele modo de “a ver se pega”, e se quem pediu, sai com um prob­lema resolvido a custo zero, cobrem o serviço, ou é não direto. Não vale a pena, a não ser que não val­orizem o vosso tempo! Como já falei anteriormente, como explicar que não existem almoços grátis?

Se, entre­tanto, quis­erem fazer o favor, certifiquem-se que a pes­soa fica a saber real­mente o que custa efetuar esse favor.