Monthly Archives: outubro 2013

Legibilidade, nomes e if

Boas práticas, C# 1 Reply

Olá, tudo bom?

Hoje vou falar sobre Legibilidade. No dicionário: s.f. Qualidade do que é legível.

Vamos começar com uma contextualização do que é legível e depois passamos para a parte de código.

Contexto dia-à-dia

Bom, para começar, temos que pensar no nosso cotidiano. Vamos entender que, o que escrevemos é para outras pessoas lerem.

“Mas Octávio, e o que eu escrevo no meu diário pessoal e nos bilhetes grudados no monitor?”

Pense o seguinte: “Amanhã você será outra pessoa” (Momento motivacional). Assim sendo, você vai ter que entender o que escreveu e entender o motivo. De preferência também vai ter que lembrar o que estava acontecendo naquele momento, logo, para um texto ficar bom tem que expressar claramente o contexto em que foi escrito e seu objetivo de ser.

Um texto legível portanto, é aquele que deixa claro que você não está subentendendo que a pessoa tenha poderes alienígenas de ler a mente de ninguém, nem uma máquina do tempo para perguntar o que você estava querendo dizer no momento (afinal, isso também muda).

Enfim, se quiser que o que você escreva seja fácil dos outros lerem e entenderem de verdade, imagine que está escrevendo para uma criança que, de preferência, não seja superdotada.

Código

Ok, eu estou aqui para falar de código. Eu estou escrevendo baseado em textos que li e conteúdo que estudei, portanto, é a minha visão e interpretação, ficando a brecha para ser aplicado^^.

Nomes

Isso é um tema para livros, então vou tentar ser simples:

O nome do que quer que você esteja escrevendo deve, no mínimo, significar o que você quer que seja.

Uma função que carrega os dados da tabela pessoas não vai se chamar “GerarVerdeComBolinhas”. Portanto, busque representar o significado das coisas pensando que:

  • Métodos fazem algo portanto, uso verbos
  • Atributos representam algo portanto, uso substantivos
  • Classes também represento algo portanto, uso a lógica de cima
  • Não tenha medo de nomes grandes e sim de códigos gigantes por causa de uma toupeira que não sabia que o método já fazia isso

É simples: o código de um programador deve ser tão fácil e agradável de ler quanto um livro infantil.

Métodos e Classes

Um método faz o que seu título está dizendo que faz, o mesmo acontece nas classes. Se um código está contendo mais do que uma atividade então é simples, divida-o ou se a classe chama Ovo, os atributos de pintinho ficam na classe Pintinho. Seus métodos e seu código, quanto mais específicos, melhores de se entender, pois é um inferno ficar inferindo o que alguém está querendo dizer com as 2000 linhas de uma função “CriarConta”. Não preciso dizer o que ela deveria fazer né?

Propriedades, atributos, variáveis e parâmetros

Em C#, propriedades e atributos começam com letras maiúsculas, enquanto variáveis e parâmetros usam minúsculas. Isso é importante pra diferenciar seu objetivo, mas não só, para entender o que é privado, o que é do escopo, quem está dentro e quem está fora. Os seus nomes devem representar o que irão conter, pois todos representam caixinhas, que terão um conteúdo específico.

Condição If

A coisa mais usada na lógica é o tratamento de condição, assim como também deve ser a mais evitada. Entretanto, sendo um mal necessário, temos que fazer o máximo para ser compreensível de se ler e prático de dar manutenção.

O problema de um If é que “se alguém entender errado, todo o resto vai ser interpretado errado”. Certa vez discordei muito de pessoas que reclamavam disso, mas hoje eu entendo que há peculiaridades (bonito né) que desenvolve um belo “macarrão” em códigos com “ifs estranhos”.

Comparação negativa

Comparação negativa é feita com “== false” e não com “!”, pois se eu estou fazendo tudo correndo (como normalmente fazemos), eu NÃO VOU REPARAR EM UMA MINHOCA COM UM PINGO DEPOIS DE UM PARÊNTESE. Fica difícil parar para identificar os caracteres e quanto mais claro estiver na tela, melhor para identificar.

Chaves

Eu coloco “{” depois da condição e “}” no fim da condição, pois sempre vai ter uma toupeira que irá fazer algo assim:

Outra coisa é “onde enfiar as chaves”. Se você está programando em Java, use o padrão de Java, se for C#, use o padrão de C#, assim por diante, pois o programador tem que sentar na máquina e saber o que está fazendo e é a pior coisa do mundo ficar reaprendendo padrões mundiais por frescuras internas.

If com else ou return?

Busque um padrão!!! If com else tem duas opções dentro de uma função, ou você usa o else, ou você da um retorno:

E qual é o melhor modelo? Não importa, os dois são bacanas, mas deve haver um padrão. Não comece com else e termine com return, seu código deve ser consistente, ler tem que ser algo que siga uma linha e não uma feira cultural.

Encadeamento

Noooooooooooooo! Se seu if puder ser separado, melhor. O cérebro não é feito para tratar tantas condições de uma vez de forma consciente. Imagine que uma coisa é encadear uma vez, a outra é fazer o sistema todo encadeado (Neste momento eu passo a ser fã do modelo “return” citado anteriormente). Quebre seu encadeamento, nem que seja com outros métodos afinal, se existem tantas condições em um método, tem algo de errado com a lógica do “faça apenas uma coisa” e não ficar assim:

Na versão que costumo fazer, uso bastante do return e separo funções, para tentar tornar o código mais linear:

Claro, há quem não goste disso, mas a essência é ceifar encadeamento abusivo.

And e Or

Não adianta, or é difícil de processar, tanto para o computador, quanto para a nossa cabeça. Lidar com os || do C# é complicado e fica ainda mais difícil quando a condição fica muito grande. Assim, se puder, migre seus Ors para Ands. Tente inverter a condição, pensar do outro lado ou usar alguma coisa mais complexa, como um array, pois além de tirar a condição literal do Or, ainda torna a condição mais flexível e reutilizável:

 

Concluindo…

É isso aí, estas são as coisas que eu acho que mais pegam no cotidiano do leitor de código e que eu, também como desenvolvedor, acabo usando como ferramenta de tortura com nomes e ifs (todos erramos na pressa). Enfim, o que se pode tirar disso é que um código é um texto e deve ser escrito como um “O pequeno príncipe” e não  “Senhor dos anéis” ou “Prolegômenos a toda metafísica futura”, pois seu objetivo é funcionar e ser mantido exigindo que seja o mais rápido de entender possível.

Até mais,

 

Do-it-youself & Manaus

Coisas aleatórias, Experiência do usuário 1 Reply

Olá, tudo bem?

Hoje vou falar um pouco de um artigo que participei da autoria e de uma experiência bacana: Apresentar num workshop em Manaus.Como?

Vista do Hotel Monaco

Vista do Hotel Monaco com o Rio negro e a floresta amazônica ao fundo.

Então, contextualizando, a Ana Carolina, eu e o nosso professor Ecivaldo Matos decidimos pegar nosso trabalho de conclusão e transformar em um artigo, pra submetermos à algum congresso, workshop ou algo assim.

Foi difícil, trabalhamos duro, mas escrevemos e fomos aceitos no WAIHCWS 2013, e vocês podem conferir aqui.

Nosso artigo teve um nome muito bizonho e longo, Técnicas de Avaliação de Usabilidade do Tipo Do-It Yourself e seus Impactos no Processo de Desenvolvimento de uma Rede Social na Web e foi sobre avaliações do tipo “Do-it-yourself” durante o processo de desenvolvimento da nossa rede social (que ainda está sendo maturada). No documento analisamos um pouco de como aplicamos algumas das técnicas de “faça você mesmo” para avaliação de experiência do usuário, que baseamos nas ideias de Steve Krug, com o intuito de fazer com que a interface do PetPatinhas (a rede social sendo maturada) fosse mais amigável.

Primeiro a gente questionou se valeria a pena fazer esse tipo de técnica, se serviria para nossa equipe, que não sabia quase nada desse assunto e depois a gente aplica 4 delas:

  1. Análise conceitual
  2. Lista de metas
  3. Teste Remoto
  4. Validação

Foi tudo meio que informal, bem descontraído, o usuário está ajudando a gente a conhecer melhor a nossa interface, seu comportamento, etc. A análise conceitual é mais um bate papo enquanto só tínhamos a ideia, enquanto o que foi mais complexo foi aplicar o teste de lista de metas e a validação, pois foram com a nossa interface já desenvolvida. Tivemos resultados muito bacanas.

Assim, pegamos esse conteúdo, que estava em um trabalho bem maior, e compusemos um artigo curto (6 páginas) e submetemos para revisão pelo pessoal do workshop. Nós fomos aprovados, revisamos o artigo e preparamos a apresentação.

Tivemos 10 minutos para apresentar tudo, a Ana e eu treinamos horas, desde as falas até o tempo de passar os slides, foi suadouro viu. Estudamos pacas e o professor ajudou muito. Ficamos discutindo bastante com ele alguns pontos sobre a apresentação, o que arrumar, o que corrigir, o que ajustar, pois tínhamos que passar a sensação de referência do artigo para pessoas que nem nos conheciam. Era algo totalmente novo afinal, estávamos acostumados a apresentar para pessoas conhecidas, curso, faculdade, mas demos conta do recado e espero ter passado bem a ideia para o pessoal que assistiu.

Foto do Teatro Amazonas

Lustre do Teatro Amazonas

Enfim, se puderem, deem uma olhada no conteúdo, eu achei bem bacana. Apresentamos, participamos de uma dinâmica, encaramos 38 graus em Manaus, horas de voo e um pouco do mercado de peixe. Valeu a pena, se puderem, ousem, nada como fazer o que se gosta em um lugar bizonho.

Até mais ^^

Horizontalização

Coisas aleatórias, Horizontalização Leave a reply

Olá, hoje vou falar sobre um assunto que não é da área da tecnologia, mas gosto muito de discutir: Gestão Horizontal.

Mas o que seria isso? Como isso aqui não é nenhum artigo acadêmico, me dou o direito de não citar fontes e deixar aqui conhecimentos e termos que eu costumo usar, se alguém discordar, ficarei feliz em ler o comentário, até pra ajudar a todos nós né… ^^.

Gestão horizontal seria um perfil administrativo de empresa em que não há uma figura de poder. Não estou dizendo que não há uma figura DECLARADA de poder, mas sim que, realmente não existe uma figura que esteja acima dos outros, ou hierarquia. Como ouvi em uma história uma vez, resumidamente:
“Se você pode me demitir, então você é meu chefe”

Simples assim, se existe alguma pessoa que pode decidir a contratação, a demissão ou tomar decisões sozinha, então ela tem mais poder que você e, nesse caso, não é horizontal.

Mas Octávio, então #comofaz? Eu vou colocar a minha visão como referência (Tipo desfile que veste modelos com abóboras para as outras pessoas pegarem o que é bacana para se inspirarem):

Na minha visão de gestão horizontal, toda tomada de decisão é feita em grupo, com toda equipe ou, em último caso, representantes, podendo ser definidos por unanimidade ou maioria inquestionável. O que isso quer dizer? Caso tenha um time com 20 pessoas e 18 decidam que 1 seja o representante, bom, isso é uma maioria inquestionável. Neste caso, esse 1 ou 2 ou quantos forem necessários, se juntam a vários uns e decide pelo grupo que representa. A definição de quantidade é proporcional à complexidade e importância da decisão, fazendo assim com que o grupo se responsabilize pelas manobras efetuadas pelo grupo.

Assim, basicamente, uma empresa horizontal é aquela em que os interessados e fornecedores tomam as decisões. Isto gera uma cadeia de iniciativa e respeito, fazendo com que os envolvidos participem ativamente em todo o processo de desenvolvimento de um serviço ou produto, fazendo com que a empresa tenha mais porcos do que galinhas.

Com esta forma de trabalho não existem setores, nem cargos, nem nada disso, apenas papéis e equipes. Uma pessoa assume um papel e se responsabiliza pelas coisas que estão atreladas à ela, desta maneira, a mocinha do RH não vai ser cobrada de trabalhos do programador .NET. Um papel é como um grupo de responsabilidades que as pessoas adotam por espontânea vontade ou por acordo. Você não vai atuar em um papel em que não irá se comprometer, portanto, seu trabalho vai ser o melhor que alguém no seu lugar faria e, ao mesmo tempo, não ficará amarrado, preso em obrigações exclusivas de um cargo.

Mas para quê? Sabe aquela situação chata de “isso não é comigo, é com fulano” ou “eu não fiz porque ciclano nao fez”? Acaba aí, você tem um papel com N responsabilidades, e elas são seu alvo, você é o dono delas, e todas devem ser respeitadas e cumpridas, se o fulano não ajudar, vá até o fulano e cobre, ou converse com ele e faça você mesmo, se ciclano não terminou, não importa, aqui não é eu ou você, em uma empresa horizontal, todos tem conhecimento do processo e interesse no sucesso do grupo, todos os comprometidos irão atuar de maneira que obtenham resultados.

A setorização gera a segregação, que faz com que grupos compitam entre si e pessoas tentem derrubar umas às outras e, eliminando isso, funciona como o seu corpo, todas as células são iguais quando nascem, daí vão se especializando e assumindo as responsabilidades que cabem a elas e com a seleção natural, algumas coisas mudam, outras não, mas estão todos fazendo parte de um corpo que, se falhar, todos morrem.

Mas Octávio, toda essa visão é tão utópica, é tão perfeito assim? Sim e não. Sim pois isso é possível, não pois irá gerar alguns agravantes como politicagem, já que o grupo define, aquele que for melhor em “sorrir e acenar” provavelmente irá se dar melhor, podem surgir influenciadores, pessoas fracas, pessoas querendo tomar o poder fingindo que respeitam, quando na verdade só estão assumindo pontos estratégicos para tomarem o poder. Mas tudo isso é inerente às relações sociais portanto, se houver realmente uma coesão no time, ou seja, todos sabem o motivo de estar ali, sabendo que se algo der certo, todos ganham e o oposto também, os políticos e manipuladores pouco a pouco serão mitigados.

Enfim, esse é meu primeiro ponto sobre horizontalização, espero que tenham gostado e que algo ajude em alguma coisa. Lembrem-se, quando você faz o que realmente gosta por um objetivo que acredita, sua vida passa a valer mais a pena.

Até mais,

REST e Estados

Boas práticas 1 Reply

Olá, primeiramente, o que é REST?

Basicamente é um acrônimo para Representative State Transfer, ou seja, uma forma de transferir uma representação de um determinado estado de uma aplicação. Vou explicar com OO pois é como me sinto mais confortável.

Pense em uma classe Pessoa. Ela tem Nome, Sexo e um boolean representando se ela está on-line ou não em um determinado sistema:

Quando instanciamos esta classe, obtemos um objeto que, neste caso, vou chamar de “josecrildo”, ficando da seguinte maneira:

Bom, o objeto josecrildo tem o estado determinado por suas propriedes. Podemos dizer que ele está on-line e tem sexo masculino e nome Josecrildo. Se mudarmos EstaOnline para false, temos outro estado para Josecrildo, pegou a pegada?

Assim, serviços REST foram pensados para transferir representações de estado, através de tecnologias simples, como o protocolo HTTP e pacotes de texto, ao contrário das práticas de serviços SOAP, no qual a complexidade é muito maior. Enquanto neste último é necessário definir um contrato, configurações, eventualmente protocolos específicos e uma certa burocracia, o REST utiliza apenas os mesmos princípios da exibição de páginas web.

Por consequência, um cliente do serviço que irá consumir objetos gerados à partir da classe Pessoa, fará requisições ao servidor, que retornará o conteúdo, normalmente, em função do método. Por ex:

PESSOA -> http://aplicacao/Pessoa

GET /Pessoa -> retorna uma lista de pessoas

GET /Pessoa/:id -> retorna um objeto de pessoas específica de acordo com :id (/Pessoa/10)

POST /Pessoa -> cria um novo objeto de pessoa

PUT /Pessoa/ -> substitui pessoa por outro objeto de pessoa

PATCH /Pessoa/:id -> altera o objeto de pessoa com :id

DELETE /Pessoa/:id -> exclui o objeto de pessoa com :id

OPTIONS /Pessoa -> lista os métodos disponíveis para /Pessoa

O produto resultante dessas requisições pode variar de acordo com o content-type ou ser fixo e, como resposta, o cliente irá receber o conteúdo em formato texto, representando o estado citado acima:

 

Enfim, todo sistema possui estados, que são os valores atuais de seus atributos ou propriedades e eles podem ser representados em modo texto. REST trata de transferir estes estados através de requisições HTTP, permitindo prover serviços simples e de fácil consumo.

Até mais,