Olá ouvintes do CoderCast, Me chamo Micael Pereira e nesse podcast vou falar sobre Código de conduta, você sabe o que é código de conduta? É um conjunto de regras que devem ser seguidos durante o exercício do seu ofício.
Vamos ao cast pois falaremos sobre o código de conduda para devs!
1- Nunca crie ou distribua malware
O termo malware é a contração do termo “malicious software” em português seria software maligno. Existe formas éticas de fazer dinheiro com software não malicioso. Trabalhando para algum empreendedor, fazendo freela, criando um curso, criando app, criando PWA, criando extensões do chrome.
2- Nunca escreva código difícil de dar manutenção
Lá em 2009, uma década atrás.. Existiam devs que escreviam códigos complicados de dar manutenção, pois assim eles acreditavam se manter empregados. A ótica do dev era escrever de forma que só ele mesmo tivesse a habilidade de compreender. Alguns exemplos eram as variáveis com nomes como A, B entender um algoritmo aonde as variáveis não fazem o mínimo sentido, é muito complicado!
3- Nunca escreva documentação confusa
Em 2019 não é mais tão comum ter documentação de software, hoje escrevemos wikis. Mas quanto menos confusa for as instruções melhor será para o dev que entrou na empresa ou na equipe seguir com o desenvolvimento. Minha dica é evite ser redundante, escreva simples e de forma conclusiva. Sempre com um início aonde colocaremos para que é tal funcionalidade, no meio como executar e por fim um sumário dos principais pontos abordados no como executar.
4- Nunca negue a possível presença de bugs
Eu já cometi essa falha na época que testes unitários não eram tão comuns. Eu escrevi um código para ajustar um bug simples, e liberei para teste sem eu ter feito nenhum teste. Como resultado a funcionalidade não funcionou no momento que o testador foi fazer um teste básico.
Hoje com os testes unitários isso é evitado, pois quanto maior a cobertura dos seus testes, menor a possibilidade de ter alguma falha. Mas sempre teste, mesmo que não seja de forma unitária.
5- Nunca use código proprietário sem comprar a licença
Atualmente, não é tão comum ter pessoas usando bibliotecas como na década passada. Eu cheguei a usar duas DevExpress e Telerik. As empresas que trabalhei pagaram por essas bibliotecas. Mas se precisar usar hoje, algum código proprietário. Não deixe de pagar pois existem pessoas que trabalharam para criar o código proprietário. Pague pelo que pedem para ser pago ou não use.
6- Não pegue o crédito de outra pessoa
Atualmente é muito comum ter software proprietário, mas com licença para uso aberta. Muitos tem a condição informando para que se coloque a assinatura do proprietário. Sempre que o software tiver uma licença com essa condição, deixe a assinatura da pessoa deixando bem claro que, não foi você que criou. Porém você está usando algo de outro dev criou.
A minha reflexão é se estou usando algo que outra pessoa criou tenho alegria de divulgar quem criou, pois dessa forma a pessoa que criou continua motivada a criar mais novidades.
7- Esteja atualizado com a área que está atuando
Atualmente está mais fácil se manter atualizado. Pois a internet veio para ajudar nesse sentido, pois facilita a forma de distribuir o conteúdo e ajdou bons professores a distribuirem seus conteúdos, com custo acessível.
Deixarei aqui alguns cursos que acho válido para estudo.
Mobile:
React Native, para criar apps híbridos e nativos para cada plataforma: link
Ionic, criar apps híbridos para ambas as plataformas: link
Web:
Vuejs um framework progressivo: link
Seja um Full-stack, profissional em alta demanda no mercado: link
Curso de Java, existe muita vaga de Java. Esteja preparado com esse curso: link
8- Nunca force atualização do software sem o conhecimento do usuário ou aprovação
Nesse tópico quero dizer que é importante ter atualizações invisíveis no software do cliente. É importante para maturidade do software, conter atualizações frequentes, com novas funcionalidades e ajustes de erro.
Porém tem algo que irrita muito o cliente é ter uma atualização que o mesmo só descobre no final do mês quando ele vai pagar a conta. Esse tipo de atualização, precisa ter a aprovação do usuário, não é somente colocar uma nova funcionalidade e aumentar o valor da fatura a ser paga.
9- Nunca esconda obstaculos conhecidos para a conclusão do software
É muito comum o dev não levar o problema para o gerente do projeto mais de uma vez. Porém quando o problema vai atrasar muito a conclusão do projeto. Mostre o porque o problema vai atrasar e se tem uma solução fale da possível solução. Mas não esconda pois você pode ser o responsável pelo atraso do software.
10- Nunca esconda informações de outros membors da equipe
Compartilhar informações é algo que pode ajudar o companheiro de equipe a entregar o software mais rápido, e perder menos tempo analisando código. Se você é do tipo de pessoa que é introvertido e tem o conhecimento do negócio, experimente usar uma wiki que seja acessível ao time para escrever as anotações do projeto. Desta forma vai ajudar o compartilhamento do conhecimento.
11- Nunca escreva códigos para intencionalmente quebrar códigos de outros programadores
Se o seu código quebrar o código de outro programador, na verdade ele estará quebrando o código da empresa. E se isso for uma constante. Vocês podem acabar perdendo o emprego, pois não a empresa que sobrevive com erros em produção. A facilidade para se trocar de software hoje em dia é muito grande. Faça seu melhor e faça teste unitário.
12- Nunca deturpe seus conhecimentos, experiências e habilidades
Nesse tempo de mercado tenho encontrado todos os tipos de profissionais. A ultima vez que vivi essa situação foi em uma entrevista para vaga de front-end e o profissional que eu estava entrevistando tinha conhecimento não só de front, mas de Java, C#, Python, Ruby e todas de forma avançada.
O alerta foi ligado, e foi enviada a prova para o profissional, até hoje espero o retorno das questões respondidas em JavaScript.
13- Nunca escreva código ruim com a intenção de ganhar o crédito por conseguir melhorar.
Escrever código ruim propositalmente é algo que me da muita vergonha alheia, pois é como um boomerang você vai jogar e vai voltar. E quando volta, e outra pessoa precisa ajustar. É muito chato pois se perde muito tempo para entender e concluir. E se o dono do código ruim pega e resolve rápido não quer dizer que ele é o melhor. Ele apenas foi o pai do monstro. Evite essa abordagem. Pois quanto melhor seu código mais lembranças positivas você vai despertar nas pessoas do seu time.
Concluindo
Terminamos o código de conduta do dev no número 13, para quem é superticioso o 13 pode ser um númerto de azar. Mas para o Zagalo é um número da sorte.
E para mim, sabe o que isso quer dizer?
Isso mesmo, NADA.
Tem mais algum item para colocar no código de conduta do dev, que você acha que esqueci de colocar?
Deixe nos comentários e ou manda no twitter, instagram ou e-mail.
No twitter eu sou o @MicaelPereira_ no Instagram @guiadev_ me siga lá e comente sobre o podcast com seus amigos devs, ajudando o crescimento do podcast. E o meio de comunicação bem antigo, que ainda respondo é o e-mail. Para entrar em contato o e-mail é [email protected]