Ambiente de testes e desenvolvimento na nuvem

Ambiente de testes e desenvolvimento

Ilustração – Ambiente de testes e desenvolvimento

Toda equipe de desenvolvimento precisa da segurança de um ambiente de desenvolvimento para programar novas aplicações ou atualizações nos serviços. Mesmo quem tem pouca experiência em programação já deve saber da instabilidade que uma aplicação passa durante seu período de desenvolvimento. E ainda que tudo já esteja correto, ao ver dos desenvolvedores, um ambiente de testes  deve simular o produto que irá para produção.

Ambiente de desenvolvimento

O momento de desenvolvimento de um projeto é aquele período liberado para erros. E acredite, por melhor que seja o desenvolvedor envolvido no projeto uma coisa é certa, erros ocorrerão enquanto ele está programando uma classe ou integrando alguma api e etc.

E são diversos os erros: erros lógicos, de sintaxe, exceptions, sem contar em dados que podem ser apagados por uma simples linha de comando mal executada. Agora imagina se todos esses problemas ocorressem em pleno ambiente de produção, com os clientes acessando a todo tempo, enquanto você está descabelando para resolver o problema em uma maratona sem fim.

Via Giphy - Erros em ambiente de testes

Então, caso você ainda não tenha percebido esta necessidade, peço que pare a leitura aqui e vá configurar um ambiente de desenvolvimento para você, hehe. Afinal, esta prevenção pode evitar que você faça algo desastroso no final.

É muito comum desenvolvedores autônomos e individuais trabalharem em ambientes locais de desenvolvimento. Esta é uma opção barata e já garante grande autonomia para que você possa errar até acertar em cheio. Mas, em uma equipe grande e/ou que trabalhe remoto, como garantir as configurações ideais para que cada desenvolvedor consiga trabalhar e compartilhar seus códigos com toda equipe?

Ambiente de desenvolvimento em nuvem

Respondendo ao parágrafo anterior, um ambiente de desenvolvimento em nuvem é uma opção que foi adotada por diversas equipes. Pelo seu caráter instável, o ambiente de desenvolvimento exige das equipes necessidades muito variáveis de recursos, dependendo do ciclo de desenvolvimento das mesmas. Assim, uma solução em cloud computing se adapta bem fornecendo recursos sob medida para a necessidade atual. E quando esta necessidade acabar é possível reajustar cada recurso de volta para a nova necessidade.

Além disto, com a infraestrutura em nuvem é bem mais fácil de padronizar as configurações do ambiente.  E com um ambiente padrão seus desenvolvedores não terão surpresas de incompatibilidades durante esta etapa. Imagine manter padronizada as configurações de desenvolvimento de cada servidor local em uma equipe de 50 colaboradores que trabalham remoto.

Aqui na DialHost, por exemplo, temos um ambiente de desenvolvimento enxuto para que a equipe inicie qualquer projeto ou feature. E sempre que necessário reescalamos os recursos para um novo projeto. Além disto, ao vermos a necessidade, podemos reduzir nossos recursos caso eles estejam ociosos. Isto tudo é possível graças a estrutura que montamos para o DialCloud +

Ambiente de testes em nuvem

Durante todo o processo de desenvolvimento os testes são parte integrante. Cada item, cada funcionalidade deve ser testada em diversos aspectos. Claro que de acordo com a complexidade alcançada em cada empresa, este processo pode ser mais dividido ou ser um simples teste de usabilidade com o usuário final.

O fato aqui é que o ambiente de testes proporciona que seus testes mantenham a segurança dos dados que já estão em produção. Assim tudo que foi desenvolvido pode ser colocado a prova.

Neste ponto a escalabilidade da estrutura em cloud computing se torna ainda mais eficiente. Afinal, testes são frequentes mas, sempre possuem um ponto final para que sejam coletados os resultados e assim passemos para a correção dos problemas encontrados.

Com a escalabilidade podemos subir uma nova instância apenas as configurações necessárias. Ao final  da análise dos testes é possível finalizar a instância reduzindo assim seu custo operacional novamente.

Por fim, ao utilizar esta estrutura para testes, podemos simular funcionalidades avançadas, ainda na fase de testes. Exemplo disso seria a necessidade de balancear cargas após identificar algum gargalo durante um teste de carga.

Vantagens

  • Melhor custo e flexibilidade de recursos para o desenvolvimento do projeto
  • Melhor controle nas configurações padrões de cada ambiente para cada desenvolvedor
  • Facilidade na padronização das configurações de desenvolvimento, teste  e produção
  • Possibilidade de testar diferentes configurações, recursos e cargas
  • Possibilidade de utilizar serviços avançados que requerem tecnologias ou competências que não estão disponíveis em sua estrutura interna
  • No caso de uma equipe grande é possível reduzir bem o custo com infraestruturas nestes ambientes.

Desvantagens

  • Você dependerá sempre de uma conexão com a internet
  • Apesar de pequena a chance (Considerando bons data centers), é preciso pensar em uma solução para caso a nuvem falhe.
  • Ainda é necessário se preocupar com estratégias de backup e recuperação e possíveis perdas de dados durante testes.

Algumas Referências

Tenha controle e flexibilidade nos seus recursos com DialCloud +. Servidores em cloud com load balancing, VPN e todo o controle de rede que você precisa. Saiba Mais.

 

Felipe Moraes
Felipe Moraes

Gerente de desenvolvimento na DialHost, Designer Gráfico formado pela Universidade FUMEC, Minas Gerais e Pós graduando em Branding pelo Centro Universitário UNA, possuo interesse em design de interação e interfaces. Trabalha com programação e criação para web, desde 2006. Apreciador de Bacon, Pudim e music Tag.

DevOps não está matando os desenvolvedores, mas sim a produtividade deles

computacao cognitiva

Imagem ilustrativa

O DevOps não está matando os desenvolvedores – pelo menos não todos os desenvolvedores que conheço. Mas está matando o desenvolvimento, ou a maneira como a maioria de nós pensa em como devemos construir e entregar software. O Agile carregou a arma. O DevOps está puxando o gatilho.

Fluxo em vez de entrega
A mudança radical está acontecendo na maneira como o software é desenvolvido e entregue. Os projetos de desenvolvimento de software em cascata de grande escala deram lugar à entrega em fases e abordagens em espiral, e depois a equipes menores que entregam código de trabalho em caixas de tempo utilizando Scrum ou outros métodos Agile iterativos. Agora as pessoas estão passando de Scrum para Kanban, e um fluxo contínuo de entrega de uma peça por vez, com implementação imediata e contínua de código para produção em DevOps.

A escala e o foco do desenvolvimento continuam diminuindo e o mesmo acontece com o prazo para a tomada de decisões e para executar o trabalho. Fases, marcos e revisões de projeto para sprints e reviews de Sprint para controles Lean além de limites WIP e a otimização de nível de tarefa. O tamanho das entregas: do que uma equipe de projeto pode entregar em um ano para o que uma equipe Scrum pode fazer em um mês ou uma semana, para como um desenvolvedor individual pode começar a trabalhar na produção em alguns dias ou algumas horas.

A definição de “Feito” e “Software Funcionando” muda de algo que é codificado, testado e pronto para demonstração, para algo que está trabalhando na produção – agora (“Concluído Significa Lançado“).

A entrega contínua e a implementação contínua substituem a integração contínua. A implementação rápida para produção não deixa tempo para testes ou para testadores manuais, o que significa que os desenvolvedores são responsáveis pela captura de todos os próprios erros antes que o código alcance a produção – ou fazer testes na produção e tentar detectar os problemas quando eles acontecem (também conhecido como “Monitoring as Testing“).

Porque o DevOps aproxima muito mais os desenvolvedores da produção, riscos operacionais tornam-se mais importantes do que os riscos do projeto, e as métricas operacionais tornam-se mais importantes do que as métricas do projeto. O funcionamento do sistema e o tempo de ciclo para produção substituem o valor agregado ou a velocidade. O estresse de alcançar os prazos é substituído pelo estresse de combater incêndios na produção e estar de plantão.

DevOps não é sobre a entrega de um projeto ou mesmo fornecer recursos. Trata-se de minimizar o tempo necessário e maximizar o fluxo do trabalho para a produção, reconhecer e eliminar o trabalho sucata e os atrasos e transferir, aumentar a confiabilidade do sistema e reduzir os custos operacionais, a construção de loops de feedback da produção para etapas do desenvolvimento, da padronização e automatização o máximo possível. É mais sobre o controle de fabricação do que processo de engenharia.

DevOps também mata produtividade do desenvolvedor

DevOps também mata a produtividade do desenvolvedor.

Se você tentar medir a produtividade do desenvolvedor por LOC, pontos de função, pontos de recurso, Story Points, velocidade ou alguma outra medida do quanto de código é escrito, menos codificação é feita, porque os desenvolvedores estão gastando mais tempo em trabalhos ops e lidando com interrupções, e menos tempo escrevendo código.

Tempo de aprendizado sobre a infraestrutura e plataforma e compreensão sobre sua configuração, certificando-se de que é a configuração correta. Construir pipelines de distribuição contínua e implementação contínua e mantê-los em funcionamento. Ajudar ops a investigar e a resolver problemas, respondendo às solicitações urgentes de clientes e às perguntas, olhando para problemas de desempenho, monitorando o sistema para certificar-se de que ele está funcionando corretamente, ajudando a realizar experiências A/B, forçando alterações e correções… tudo rouba tempo do desenvolvimento e impede que eles pensem sobre requisitos, design, codificação e testes (o trabalho para o qual os desenvolvedores são treinados e são bons em fazer).

O impacto de interrupções e multitarefas
Você não pode proteger os desenvolvedores de interrupções e alterações nas prioridades em DevOps, mesmo que utilize Kanban com limites WIP estritos, e você não quer. Os desenvolvedores precisam ser responsivos às operações e aos clientes, reagir aos comentários de produção, mergulhar nos problemas e ajudar a detectar e a resolver falhas o mais rápido possível. Isso significa que todos, especialmente os seus colaboradores mais talentosos, precisam estar disponíveis para ops na maioria do tempo, se não o tempo todo.

Os desenvolvedores se juntam aos ops de plantão após o horário, o que significa carregar um pager após o dia de trabalho. E o tempo desperdiçado em ligações de suporte para problemas que acabam não sendo problemas reais, longas noites e fins de semana no combate a incêndios e rastreamento de problemas de produção e ajudando a recuperar de falhas, chegando cansado no dia seguinte para passar mais tempo esgotado em incidente e testes de falhas e recuperação de avanço e roll-back e participando de pós-mortem e sessões de análise de causa raiz quando algo dá errado e a falha ou roll-forward ou roll-back não funciona.

Você não pode planejar as interrupções e os problemas operacionais, o que significa que os desenvolvedores vão perder seus compromissos com mais frequência. Então, por que assumir compromissos? Por que se preocupar com planejamento ou estimativa? Use a priorização just-in-time, em vez de se concentrar na coisa mais importante que os ops ou o cliente precisam no momento, e entregue o mais rápido possível – a não ser que algo mais importante venha à tona e se antecipe a isso.

À medida que os desenvolvedores aceitam mais tarefas e responsabilidades de suporte, multitarefas e alternância de tarefas – e as interrupções e as ineficiência que vêm com eles – aumenta-se a fragmentação do tempo destruindo a concentração. Isso tem um impacto imediato na produtividade e um de longo prazo sobre a capacidade das pessoas para pensar e resolver problemas.

Até mesmo o próprio loop de feedback da implementação contínua é uma interrupção no fluxo de um desenvolvedor.

Depois que um desenvolvedor verifica o código, executar os testes unitários em funcionamento na integração contínua deveria ser rápido, levando alguns segundos ou minutos para que eles possam seguir em frente com o seu trabalho. Mas para implementar imediatamente na produção significa executar por meio de um conjunto mais amplo de testes de integração e de sistemas e outras verificações na distribuição contínua (mais testes e mais verificações levam mais tempo), então execute as etapas até a implementação, e então faça o monitoramento da produção para se certificar de que tudo funcionou corretamente, e vá fundo se alguma coisa der errado. Mesmo que a maioria das etapas seja automatizada e otimizada, tudo isso tira tempo e atenção do desenvolvedor para trabalhar no código.

Otimizar o fluxo de trabalho dentro e fora das operações significa sacrificar o fluxo do desenvolvedor, e retardar o trabalho de desenvolvimento.

Expectativas, métricas e incentivos têm que mudar
No DevOps, a maneira como os desenvolvedores (e ops) trabalham e a maneira como eles precisam ser gerenciados mudam. Também é fundamental mudar as expectativas, as métricas e os incentivos para os desenvolvedores.

O sucesso de DevOps é medido por métricas operacionais de TI, e não pelo cumprimento das metas de entrega escopo do projeto, cronograma e custo, nem pelo cumprimento das metas de lançamento ou compromissos Sprint, ou até mesmo o cumprimento das metas de design de produtos.

  • Quão rápido o time pode responder às mudanças e aos problemas importantes: alterar tempo de entrega e tempo de ciclo para produção em vez de entregar milestones ou velocidade
  • Quantas vezes eles forçam as alterações para a produção (que ainda é a métrica com a qual a maioria das pessoas está mais animada – quantas vezes por dia, hora ou minuto Etsy, Netflix ou Amazon implementam mudanças)
  • Quantas vezes eles cometem erros – Taxa de mudança/erro
  • A confiabilidade do sistema e o tempo de atividade – MTBF e especialmente MTTD e MTTR
  • Custo da mudança – Operações gerais e os custos de suporte

 

DevOps é mais sobre Ops do que Dev

À medida que mais softwares são entregues mais cedo e com mais frequência para a produção, o desenvolvimento se transforma em manutenção. O gerenciamento de projetos é substituído pelo gerenciamento de incidentes e de tarefas. O planejamento de horizontes fica muito mais curto – ou o planejamento é substituído por priorização da fila e triagem just-in-time.

Com a infraestrutura como código, Ops se tornam desenvolvedores, projetando e codificando infraestrutura e mudanças de infraestrutura, pensando pensando sobre a reutilização e a facilidade de leitura, duplicação e refatoração, a dívida técnica, a capacidade de teste e a construção em TDD para implementar TDI (Test Driven Infrastructure). Eles se tornam mais e mais Agile, fazendo pequenas mudanças com mais frequência, mais tempo de programação e menos em trabalho burocrático.

E os desenvolvedores começam a trabalhar mais como ops, assumindo responsabilidades de operações e suporte, colocando riscos operacionais em primeiro lugar, preocupando-se com a infraestrutura, construindo ferramentas de operações, encontrando formas de equilibrar as demandas imediatas de curto prazo para apoio operacional com objetivos de projeto de longo prazo.

Nada disso será uma surpresa para quem já vem trabalhando em um negócio online há algum tempo. Uma vez que você oferece um sistema e os clientes começam a usá-lo, as prioridades mudam, tudo sobre a maneira como você trabalha e plano têm que mudar também.

Essa forma de trabalhar não é, necessariamente, melhor ou pior para os desenvolvedores. Mas é fundamentalmente diferente de como muitos desenvolvedores pensam e trabalham hoje. É mais frenético e baseado em interrupções. Ao mesmo tempo, é mais disciplinado e mais improdutivo. Mais transparente. Exige mais responsabilidade e prestação de contas. É menos sobre desenvolvimento e mais sobre o lançamento, a implementação, as operações e o apoio.

Os desenvolvedores – e seus gestores – precisarão se acostumar a fazer parte do panorama geral de executá-lo, o que é muito mais do que projetar aplicativos, escrever e entregar o código. Esse pode ser o futuro do desenvolvimento de software. Mas nem todos os desenvolvedores vão gostar, ou ser bom no que fazem.

—–

Artigo publicado no iMasters.

Quatro jeitos simples de reduzir custos com software

 

Imagem ilustrativa

Imagem ilustrativa

As festas acabaram – pelo menos até o carnaval. Para muitos, 2015 já começou… e será um ano com tendência a ser complicado (especialmente no Brasil). O contexto é uma razão a mais para “economizar dinheiro” ser uma boa resolução para por em prática nos próximos 12 meses.

Uma maneira fácil de cortar custos é reavaliar o pacote de softwares pelos quais você está pagando, e porque você está pagando por eles. Há muitas alternativas nessa frente que podem ser cortadas ou substituídas por versões mais baratas ou até gratuitas. Por que não experimentar?

Eis aqui quatro sugestões de software livre listadas pela PC World que podem ajudá-lo no brainstorming para que crie sua própria lista de medidas que permitam cortar custos com software. Um conjunto mais abrangente de soluções está disponível no site da publicação norte-americana (em inglês).

Segurança

Pagar por software antivírus há 10 anos era uma necessidade. Desde então, no entanto, uma série de suítes AV gratuitos têm aparecido. Vale ressaltar que algumas dessas versões grátis trazem também um pacote de aborrecimentos, como alguns anúncios durante o processo de instalação e o constante pedido para que o usuário migre para versões premium.

Dá para contornar isso usando apenas o que a Microsoft oferece gratuitamente. Caso esteja rodando Windows 7, faça o download do Security Essentials para antivírus e proteção contra malwares. Para as versões 8 e 8.1 do sistema operacional há uma ferramenta incorporada chamada Defender, que faz praticamente o mesmo que o MSE, acrescentando um reforço no rootkit e proteção bootkit.

Experimente-o por um tempo, pois, embora a ferramenta da Microsoft não seja tão cheia de recursos quanto a de fabricantes de segurança, trata-se de uma solução que pode dar conta do recado naqueles usuários que seguem “práticas inteligentes” de segurança. Caso não fique satisfeito, há sempre a possibilidade de testar outra suíte grátis ou partir para uma versão paga.

Edição de imagem

Graças a oferta de subscrição do Adobe Creative Cloud é possível ter o Photoshop e o Lightroom pagando US$ 10 por mês. É possível, ainda, economizar US$ 120 por ano se você recorrer as imensas ofertas grátis disponíveis. Se você gosta de apps de desktop, avalie o GIMP, o leve Irfanview ou o meio termo Paint.net. Caso goste de editar imagens online, poderá se surpreender com o Pixlr ou o Canva.

Gerenciamento de senhas

Dependendo do software que você escolher, pode gastar pouco (US$ 12 ao ano) para um gerenciador de senhas que funciona tanto em desktop e quanto em dispositivo móvel. Mas se você não quer pagar nada, experimente KeePass, uma opção grátis de código aberto que funciona em múltiplos aparelhos. A desvantagem da ferramenta é que você tem que ser responsável pelo seu próprio banco de dados de senha criptografada, enquanto que soluções superiores muitas vezes fazem esse trabalho para você.

Produtividade

A menos que você precise de uma tonelada de armazenamento no OneDrive, requer funcionalidades avançadas ou está preocupado com possíveis questões de compatibilidade – pagar pelo Office, independente da versão – talvez não faça muito sentido (pelo menos para uso pessoal).

Existem inúmeros pacotes de produtividade robustos e grátis. Nomes como o LibreOffice e OpenOffice. A suíte de produtividade Google Drive é muito poderosa para usuários casuais e agora embala funcionalidade off-line bem decentes.

Às vezes, pagar por software é a única opção se você tiver necessidades específicas, mas para o uso mais geral, alternativas livres podem servir tão bem quanto. Teste as alternativas sem custo… talvez, fazendo isso, você não tenha muito a perder. Certo?

——

Artigo publicado no ComputerWorld.

 

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

Vícios e manias de quem aprende a programar sozinho

Imagem ilustrativa: Tela de códificação

Imagem ilustrativa: Tela de codificação

Atualmente, é muito comum encontrar desenvolvedores, programadores e demais profissionais que aprenderam a programar sozinhos. Neste artigo vou comentar um pouco sobre os tipos de vícios e manias que acabo vendo em profissionais com este perfil.

Para começar, gostaria de destacar que fiz questão de não utilizar a palavra autodidata. O motivo é que este termo certamente não tem mais a mesma conotação e peso que tinha há algum tempo atrás. Isso se deve à necessidade de sempre aprender coisas novas da área e à grande quantidade e facilidade de acesso às informações disponível na Internet, especialmente para desenvolvedores. Sendo assim, não acredito que utilizar o termo autodidata contribui para expressar o tipo de pessoa que possui os comportamentos que vou descrever aqui. Afinal de contas, somos todos autodidatas em algum nível e isso não torna necessariamente alguém melhor ou pior que outra pessoa.

Outro aspecto que é importante citar antes de descrever os vícios e manias, é que tenho noção do fato que nem todo mundo que aprendeu a programar sozinho pode ter os vícios e manias que citei aqui. Sim, eu sei que muita gente passa longe das atitudes descritas, mas, infelizmente, durante a minha experiência profissional, tenho visto muitos perfis comprovando que, de fato, o aprendizado individual acaba fortalecendo vícios nada adequados para o ambiente de trabalho profissional com programação. Destaco também que não tenho nada contra quem aprende programação sozinho, até porquê sou um forte incentivador e produtor de conteúdo para este público.

Dificuldade no trabalho com uma equipe

Quem aprende a programar sozinho está acostumado a passar horas e horas isolado ou com pouca interação com outras pessoas. Enquanto este isolamento auxilia na concentração e esforço mental, ele possui um efeito colateral: a falta de entrosamento e a pouca aptidão para se trabalhar em equipe. Esta dificuldade envolve muitos pontos, mas vou me concentrar em apenas três: dificuldade de comunicação, desprezo por opiniões divergentes e atritos no relacionamento com superiores.

A comunicação é uma das mais importantes habilidades (soft skills) quando se trabalha com programação em uma equipe. É preciso saber avisar o que foi feito, pedir opiniões, comunicar problemas, descrever cenários, solicitar tarefas, negociar prazo e mais uma série de outras atividades que não podem ser feitas sem boas habilidades comunicativas. Contudo, as pessoas que aprendem a programar desenvolvem um vício que chamo de economia verbal, pois na mente destas pessoas quanto menos palavras forem ditas, melhor. É complicado conversar com um profissional com este vício em uma reunião, por exemplo, pois ele está tão aplicado em seu pensamento que praticamente despreza e dá o mínimo de atenção à comunicação.

Muitos programadores que conheci possuíam uma resistência e desprezo pelas sugestões, opiniões ou comentários relacionados aos códigos que eles escreveram, especialmente quando se cita alguma falha, problema ou possível melhoria. Estas atitudes mostram que há um forte senso de propriedade (algo como “o código é meu e eu sei o que faço!”) e falta de traquejo social para aceitar que nem sempre suas “crias” são as mais bonitas ou funcionam da melhor maneira possível. A provável razão deste comportamento é que quando a programação é realizada por uma pessoa que aprendeu sozinha, ela não recebeu críticas, aconselhamento, opiniões, revisão e outros inputs durante seu aprendizado. Esta falta de um par extra de olhos acaba levando o programador a adotar atitudes defensivas e, às vezes, até agressivas quando ele se depara com o que outras pessoas acham do seu código.

O aprendizado individual acaba reduzindo a noção de que durante o trabalho provavelmente teremos algum tipo de hierarquia, onde uma ou mais pessoas vão assumir papéis de liderança. Quando se aprende sozinho, o aprendiz é o seu próprio chefe e a cobrança é dele para ele mesmo. Contudo, no mundo real as coisas são um pouco diferentes, pois superiores (gerentes de projeto, supervisores, coordenadores e outros) possuem formas diferentes de pedir tarefas, cobrar resultados, trocar prioridades e gerenciar pessoas. Este conflito acaba levando a situações onde há algum nível de insubordinação que pode levar a ações punitivas. Na melhor das hipóteses, o aprendiz reconhece que ele deve ficar quieto, ouvir e obedecer. Na pior das hipóteses, pessoas abandonam equipes e juram que nunca mais vão trabalhar sob a supervisão de outros profissionais.

Falta de padronização na codificação

Quem aprende a programar sozinho presta pouca ou nenhuma atenção a detalhes como, por exemplo, a padronização dos nomes de elementos do programa. Se, por um lado, esta tarefa requer mais esforço e consome um pouco mais de tempo na codificação, por outro lado ela facilita muito a manutenção do código.

Apesar de muitos materiais didáticos, cursos, vídeos e outros recursos de ensino de programação recomendarem o uso de padrões de codificação, ainda é muito comum encontrar profissionais que ou fogem destas práticas ou as implementam de forma parcial. Este tipo de comportamento acontece com todo mundo durante a carreira, mas tenho visto uma tendência muito forte ao desrespeito aos padrões de codificação para nomes de variáveis, classes, métodos, funções, procedures, interfaces e outros elementos de programação em profissionais que aprenderam a programar sozinhos.

Em alguns momentos, a coisa ficou tão comum que já tive a impressão que estava perante uma epidemia de nomes ruins utilizados em variáveis, métodos, funções e procedures.  A vacina? Revisão de código e regras que forçam certos padrões ao ponto do código fonte não ser utilizado por ter uma qualidade abaixo do mínimo aceitável para que outra pessoa trabalhe com ele no futuro – mesma se esta pessoa for o autor original deste código e que o programa esteja atendendo os requisitos funcionais.

Falta de conhecimento de ferramentas do mercado

Quem está aprendendo a programar geralmente escolhe alguma linguagem, ambiente, plataforma ou tecnologia para “pegar o jeito da coisa”. Agir desta maneira é OK, mas é preciso lembrar que uma coisa é como você está aprendendo e outra é como o mercado e as empresas usam esta tecnologia.

Por exemplo: durante o aprendizado básico de criação de CRUDs raramente são citados aspectos de controle de transação para situações, onde há a possibilidade de operações conflitantes. Já na realidade, é relativamente comum encontrar problemas clássicos como deadlocks, phanton records e outros que vêm de reboque quando um sistema começa a ter muitos usuários e alguma atitude para atender a escalabilidade já foi tomada.

Outro exemplo clássico é a falta de conhecimento e uso de sistemas de controle de versão. Afinal de contas, quem aprendeu sozinho não se depara com a necessidade de compartilhar seu código com outras pessoas. Esta falta de conhecimento e uso de ferramentas de controle de versão (GitHub, CVS, Mercurial, Team Foundation e outras) é tão notória quanto o desconhecimento de ferramentas de automação de build como o ANT, Maven e Gradle. Devido à necessidade de uso destas ferramentas nas empresas, é praticamente obrigatório um treinamento de novos colaboradores nestas tecnologias (o que acaba consumindo tempo e recursos valiosos que poderiam ser empregados em outras tarefas mais nobres).

Por fim, a prática de revisão de código (code review) soa como algo alienígena para quem estuda sozinho, afinal de contas por que eu pediria para alguém revisar o meu código enquanto estou aprendendo? Bem, sem entrar mais detalhes, basta dizer que sessões de revisão de código não podem mais ser consideradas um luxo, uma vez que seus benefícios já foram largamente comprovados em diversos estudos e situações reais.

Não investir na documentação

A documentação de código pode assumir vários formatos e, independente de como ela exista, é muito importante investir na sua criação. Esta documentação não é útil apenas para ajudar a esclarecer aspectos técnicos, mas também para organizar e gerenciar o trabalho de todos os profissionais envolvidos em um projeto de software, seja no presente ou no futuro.

Ao contrário do que alguns podem pensar, a documentação não é apenas um trabalho desnecessário que toma tempo e torna tudo mais lento. Ela é um item obrigatório em qualquer projeto, servindo a vários propósitos. Contudo, por questões culturais e outros motivos tradicionalmente o brasileiro não é conhecido pelas suas habilidades de organização e documentação.

Novamente, uma forma de traçar a origem deste sério problema é analisar quem aprende sozinho. Neste cenário, a tarefa de investir na criação de documentação recebe prioridade, pois o pensamento é que quem criou o código sempre vai se lembrar dele no futuro. Já escrevi um pouco sobre isso com foco no DBA, mas acredito que as lições e tipos de artefatos apresentados naquela ocasião ainda são válidos e podem ajudar quem dá pouca ou nenhuma atenção à documentação.

Foco na implementação e não no design

Durante o período de aprendizado, é comum gastar mais tempo tentando resolver os problemas do que analisando suas características. Isso já foi destacado no artigo que escrevi aqui no blog, onde discuti e apresentei recomendação sobre como focar no problema, ao invés da solução.

Quando me deparo com pessoas que aprenderam a programar sozinhas, na maioria das vezes fica claro o padrão de comportamento representado pela dificuldade de analisar, conceber e pensar no design da solução e como este design deve ser separado da implementação do código. A avidez por sair codificando e utilizando os recursos de produtividade das plataformas de desenvolvimento mostra que o design e arquitetura acabam ficando de lado perante aspectos de implementação.

Tal atitude também fortalece e favorece o trabalho customizado, no sentido de que a cada novo problema a maneira de resolvê-lo vai ser diferente da anterior. Este modo de trabalho ad hoc pode ser bom para cenários altamente voláteis e com requisitos imprevisíveis (algo raro) que tornam a previsão da próxima necessidade impossível de ser conhecida. Não obstante, geralmente o trabalho no dia a dia requer um nível alto de sistematização das atividades onde processos e práticas comuns são largamente empregadas sem muito desvio.

Este tipo de trabalho sistematizado, previsível e altamente compartimentalizado é visto com bons olhos na programação profissional, pois ele permite que sejam feitas previsões e que metas sejam completadas com sucesso dentro do prazo. O que quero dizer aqui é que o vício do modo cowboy de programação (também chamado de heróico) é muito comum em cenários onde o programador tem a convicção de resolver tudo sozinho e que sem sua “mágica” nada vai funcionar corretamente. Contudo, agir desta maneira pode acabar sendo contraproducente quando é preciso encarar a programação de modo profissional.

Muita duplicação de código e pouca reusabilidade

Quando analiso o código de outras pessoas, fico atento a um dos principais indícios que me permite identificar se estou lidando com alguém que aprendeu sozinho: o abuso dos recursos de copiar e colar representado pela alta taxa de duplicação de código e quase nenhuma usabilidade.

Os recursos de copiar e colar estão entre os principais truques que aumentam a produtividade de quem programa. E pela facilidade destas operações é quase uma consequência observar que tanta gente acaba duplicando de forma inadequada o código ao invés de utilizar técnicas adequadas de reusabilidade.

O abuso das técnicas de copiar e colar e códigos fontes é tão disseminado que uma vez conversando com um colega ele sugeriu uma atitude radical: a criação de um “polícia do copy & paste”. Esta polícia seria responsável por detectar, julgar, sentenciar, punir e criar novas leis para erradicar e obliterar o uso bizarro de copiar e colar em código fonte. Acho que não preciso dizer que este meu colega era responsável por dar manutenção em código fonte legado e não conhecia ou não praticava algumas das técnicas descritas para manipular código legado descritas em outro artigo meu.

Aqui vale a pena investir em design patters, refatoração, componentização, uso de frameworks e o tão negligenciado olhar focado no design através da boa modelagem de classes, relacionamentos, interfaces e outros elementos.

Para fechar este artigo, gostaria de terminar com um tom otimista: todas as pessoas que trabalham com programação possuem um ou outro hábito, vício ou mania ruim que pode ser melhorado. Isso faz parte do jogo. Mas acredito que nunca é tarde para para tentar reduzir o impacto que este hábito ruim pode trazer na vida profissional de um desenvolvedor.

—–

Artigo publicado no iMasters.

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

12 passos para não errar ao implantar políticas de home office

Home office

Home office

Com o avanço da internet e surgimento de tantas ferramentas de comunicação, muitos profissionais de TI já estão exercendo atividades remotamente, pelo menos um ou dois dias por semana. O Brasil regulamentou esse modelo de trabalho, considerado uma tendência no mundo para redução de custos e melhora da qualidade de vida de seus colaboradores.

Assim o home office tem se tornado uma alternativa cada vez mais frequente e viável no mercado de trabalho atual, principalmente com a dificuldade de locomoção nas grandes cidades. Mais conhecido na Europa como Smart Working e nos EUA como Workplace Flexibility, permite “mover o trabalho para os trabalhadores, em vez de mover os trabalhadores para o trabalho”, segundo Jack M. Nilles, no livro “Fazendo do Teletrabalho uma Realidade”.

No Brasil a adoção dessa modalidade ainda está em processo de construção.

Estudo recente da SAP, de agostos de 2014, comprova que o perfil das empresas que adotam a prática de Home Office no país é de origem internacional com uma concentração de 70% junto aos mercados de TI, indústria Química/Petroquímica, P&D, Autoindústria, Eletroeletrônicos e Bens de Consumo. Já os pilares para elegibilidade adotados pelas empresas estão mais direcionados ao nível hierárquico do que propriamente às áreas específicas, sendo que 45% estendem para todos os níveis.

E das organizações que já possuem a prática, 42% têm política estruturada, sendo a maior parte delas existentes a menos de cinco anos.

Como objetivo da política, as empresas apontam, entre os principais indicadores listados, a flexibilidade no ambiente de trabalho e a melhoria na qualidade de vida. Os itens que apresentam maior destaque em relação aos ganhos para as corporações são a satisfação dos colaboradores envolvidos, o aumento de produtividade, a retenção dos colaboradores e o diferencial no processo de contratação.

Sua empresa pretende ter uma política para home Office?

Seguem aqui 12 práticas que julgamos consistentes para ajudar no dilema.

1. Trabalho remoto não serve para todos
Entenda que nem todos estão preparados para o trabalho remoto e algumas funções não são compatíveis com o modelo. Tudo depende da sua empresa, da cultura corporativa ou até do tipo de trabalho realizado. Fazer uma avaliação honesta da missão da sua organização, dos diversos times e departamentos, funcionários e papéis é o primeiro passo. Os próprios funcionários podem oferecer ideias valiosas de como eles, e suas atividades, podem fazer parte do processo.

2. Apenas cancele trabalho remoto por questões de trabalho
Se você precisar negar o trabalho remoto, tenha certeza de fazer de forma articulada e com raízes em justificativas claras de negócios. Escolhas pessoais não podem ser motivo para negar a opção para pessoas ou equipes.

3. Estabeleça metas claras
As vantagens do trabalho remoto estão muito bem documentadas – aumento de produtividade, satisfação dos funcionários, menos tempo gasto de transporte, acesso facilitado a clientes e serviços, redução da pegada de carbono e redução das despesas com escritório. Mas você precisa ter bem claro o que quer ao implementar o programa remoto e como ele vai beneficiar sua empresa. Isso ajuda a desenvolver métricas e critérios de avaliação para determinar se está tendo sucesso ou se precisa melhorar.

4. Comece com um programa-piloto
Mudar para um modelo remoto é um grande passo. Experimente a água antes de mergulhar de cabeça. Criar um programa-piloto de menores proporções vai ajudar a otimizar os recursos necessários e avaliar se tudo o que precisa ser definido está mesmo no lugar. Coisas como hardware, software para acesso remoto e treinamento dos funcionários, por exemplo.

5. Crie políticas consistentes de trabalho remoto
As políticas precisam incluir inputs do RH, departamento jurídico e até mesmo de sindicatos, se necessário. Certifique-se de que elas espelham as responsabilidades de empregados e empregadores; endereçam todas as expectativas e incluem um check-list de equipamentos e recursos necessários para garantir que o trabalho remoto possa ser feito (acesso a internet, equipamento, software de segurança, dispositivos móveis etc.). Qualquer funcionário que venha a requisitar trabalho remoto deveria entender e concordar com os termos e com as ações disciplinares no caso de falhar com as obrigações.

6. Dê treinamento
Educação e treinamento são fatores importantes de sucesso em um programa de trabalho remoto. Podem ser meramente técnicos (como usar dispositivos e tecnologias de acesso remoto seguro) ou endereçar práticas de trabalho em grupo para garantir a colaboração entre equipes que estão em locais diferentes. Podem ainda abranger práticas de segurança e ergonomia em casa; ou também repassar questões pertinentes a recursos humanos, como feedback e solução de conflitos.

7. Estabeleça práticas de relacionamento entre equipes
Definir regras de como a equipe do escritório vai interagir com equipes remotas pode garantir uma transição tranquila e ajudar a resolver eventuais crises entre quem pode e quem não pode trabalhar remoto. Garanta, especialmente, que a carga de trabalho de quem está remoto é equivalente à carga de trabalho de quem está no escritório, de forma que o senso de justiça e igualdade prevaleça.

8. Encoraje os empregados a separar vida pessoal e vida profissional
Para montar um home office é preciso que o funcionário tenha em casa um local no qual possa trabalhar com a porta fechada e longe dos olhos da família. Essa é uma prática essencial. Também assegure-se que todos os funcionários entendem claramente que o trabalho remoto dá flexibilidade mas que não pode ser usado para atender problemas domésticos como falta de babá para os filhos ou cuidados a familiares idosos.

9. Reformule processos de avaliação de performance
Um dos grandes desafios de programas remotos é a falta de interação diária, a conversa cara a cara e o feedback. Avaliar o engajamento do funcionário no trabalho pode tornar-se um desafio. As companhias geralmente precisam criar um novo conjunto de métricas de performance para avaliar funcionários remotos.

10. Contato direto é fundamental
É importante manter contato humano com os funcionários remotos. Nem sempre é possível planejar uma reunião periódica que reúna todos os funcionários remotos ou não, por isso é preciso definir momentos em que essa reunião aconteça – treinamento, eventos internos, conferências também podem contribuir.

11. Checar ativamente o funcionário é essencial
Mesmo que seja apenas por telefone ou videochamada, assegure uma rotina de contato ao menos semanal com cada um dos membros da equipe para garantir motivação e engajamento.

 12. Resolva os problemas tão logo apareçam
É literalmente impossível que qualquer iniciativa de negócios funcione sem crises ou problemas e um programa de trabalho remoto não é exceção. Lide com crises imediatamente. Funcionários remotos tendem a imaginar problemas maiores que eles realmente são ou eventualmente não ver os problemas pelo mesmo motivo: estão longe do escritório e perdem boa parte do movimento interno e das conversas de corredor.

—–

Artigo publicado no ComputerWorld.

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.