Boas práticas comportamentais do desenvolvedor de software

Durante os meus 11 anos trabalhando com desenvolvimento de software, pude perceber diversos comportamentos em nossa área que devemos evitar, a fim de não cairmos em fatores como problemas de relacionamento com os colegas de time, queda de produtividade e qualidade durante os processos de desenvolvimento de software. Desta forma, preparei 11 conselhos - um para cada ano. Dizem que, se conselho fosse bom, a gente não dava, vendia. Porém, as práticas comportamentais a seguir têm funcionado bem para mim e para os colegas de profissão que observo praticá-las. Espero que funcionem bem para você, também. Boa leitura!

1) Seja construtivo: ao ver um erro, trecho de código ou até uma arquitetura que você não concorde, não condene o trabalho feito por outros colegas. Se você considera ter um conhecimento de causa melhor, então dê não somente dicas, mas também mostre um exemplo prático, em forma de código, de como o trabalho realizado pode ficar melhor. Ficar jogando pedras no telhado do vizinho fará somente com que você passe uma imagem de alguém intragável, que só quer aparecer às custas dos outros, além de afastar seus colegas. Tenha em mente que o mesmo insulto que você faz aos outros de alguma forma se voltará contra você.

2) Respeite os novatos: você não nasceu sabendo tudo. Já passou pela mesma curva de aprendizado que outros profissionais que acabaram de entrar no mercado estão passando. Então não desanime seu colega novato quando perceber que ele ainda não possui níveis de maturidade em análise e código como os seus. Ajude-o a progredir, em vez de traumatizá-lo. Ele será eternamente grato a você por isso. Pode ter certeza que, como o mundo dá voltas, ele se lembrará de você caso em algum momento da vida ele esteja por cima e, você, precisando de um emprego. Se ele terá boas ou más recordações de você, só dependerá de suas atitudes para com ele no presente.

3) Respeite os antigos: sabe aquele profissional que trabalha na empresa desde longa data e faz manutenção de um software que possui tecnologia antiga que será migrada para uma tecnologia nova para a qual você foi contratado? Não subestime-o. Não pense que ele é o obsoleto da história e que você está na crista da onda. Ele possui um conhecimento que você simplesmente está longe de dominar: os processos e o negócio da empresa. Seja muito legal com ele, escute todas as suas considerações, absorva ao máximo sua experiência e seus conselhos e tenha-o como o seu tutor, não como o seu concorrente. Não tente pular os degraus à força. Até porque este cara que você menospreza e considera obsoleto pode se atualizar e aprender as técnicas modernas que você preza tanto no máximo em 12 meses, enquanto você ainda terá que comer muito arroz com feijão para entender todo o negócio da empresa, os meandros dos componentes, das dlls antigas registradas e do banco de dados.

4) Não (des)arrume o código demais: se você foi solicitado a fazer uma manutenção corretiva ou evolutiva no software, procure os pontos onde o código deve ser mudado. Não dê uma de herói, querendo mudar o código inteiro, a não ser que você possua um domínio pleno daquela parte específica do software e tenha tempo sobrando para fazer a mudança. Você não sabe o porquê de alguns métodos existirem. Querer apagá-los ou mudá-los completamente será como dar um tiro no pé, pois você gastará mais tempo que o necessário e poderá fazer com que erros que não ocorriam antes da manutenção passem a ocorrer.

5) Não pire na tecnologia: o mercado de desenvolvimento de software irá sempre trazer novidades que julga serem "boas práticas". Antes de querer sair aplicando tudo o que é novo, faça a si próprio as seguintes perguntas:
- A arquitetura de software que utilizamos na empresa já possui uma organização e performance adequadas?
- Estou querendo aplicar esta novidade por necessidade? Ou por pura vaidade?
Pense muito bem e, antes de aplicar novidades, sugira, demonstre com exemplos práticos que é benéfico aplicá-las. Não saia fazendo as coisas ao seu bel prazer. Até porque, depois que você fez a mudança, tudo estará muito claro para você, mas o resto do time irá penar para entender. Um dia você sairá da empresa e seus colegas devem ter condições de entender o código que você fez. Tenha o bom senso de aplicar tão somente as novidades que a empresa e seus companheiros de time precisam para o desenvolvimento de uma arquitetura simples, clara, coesa, fortemente orientada a reúso e com facilidade de manutenção do código. Quem gosta de complicar e não tem o pensamento de desenvolver para o time, não está sendo inteligente. Está sendo, no máximo, um "intellisense nonsense". Não seja egoísta, pense como time!

6) Não empaque: muitas vezes perdemos muito tempo tentando decifrar questões técnicas ou de negócio durante o desenvolvimento ou manutenção de software, enquanto um colega que está do nosso lado poderia "encurtar o sofrimento" e nos auxiliar, pois já solucionou algum problema parecido. Se você perceber que o tempo está passando e que não está conseguindo chegar a uma solução, não tenha vergonha de perguntar a um colega. É claro, a empresa deve proporcionar um ambiente colaborativo, onde as pessoas se ajudem com boa vontade e sem aqueles preconceitos competitivos do tipo "como é que você é analista se não sabe fazer isso?" Todo profissional possui seus pontos fortes e seus pontos a melhorar. Em um ambiente colaborativo, todos somente têm a ganhar com a troca de conhecimentos. Principalmente a empresa, com o consequente aumento da produtividade.

7) Não gaste seu tempo com bobagens: a internet é uma poderosa ferramenta para o desenvolvedor de software que sabe explorá-la. Portanto, aproveite-a durante o expediente, navegue e faça as suas pesquisas, mas com o objetivo de solucionar as questões inerentes ao seu trabalho. É claro que, quando bater aquele stress, não há problemas em ler os e-mails pessoais, fazer alguma ligação extra trabalho, ir tomar um café e conversar um pouco sobre assuntos aleatórios para descontrair. Não somos máquinas. Mas não exagere, mantenha o foco. Cada empresa por onde você passar oferecerá um leque de aprendizados técnicos e de negócio. Estude os códigos que seus colegas fizeram, aprenda "pulos do gato" que você desconhece. E, principalmente, procure realizar um bom trabalho e passar uma imagem verdadeira de dedicação, tanto nas atividades mais empolgantes quanto nas mais "burocráticas". Não procrastine. Não adianta ser um excelente técnico e deixar uma fama de preguiçoso e/ou sem foco por onde passa.

8) Teste exaustivamente o que desenvolveu: atualmente, o mercado de desenvolvimento de software oferece ferramentas bastante úteis de testes unitários. É recomendável utilizá-las, a fim de documentar os testes realizados e, também, como forma de mostrar a um novo colega desenvolvedor as formas possíveis de acesso e utilização dos métodos existentes. Por outro lado, esta forma de automatização de testes não exime o desenvolvedor de "utilizar o boné do usuário" e navegar pelo software que desenvolveu. Desta forma, antes de afirmar que o seu trabalho está concluído, navegue bastante pelo software, faça buscas, cadastros, atualizações e exclusões. Procure testar o máximo de cenários que conseguir imaginar. Se possível, passe o software para outros colegas testarem também. Eles podem imaginar outros cenários que possam gerar falhas. Não seja visto como "aquele cara que leva dois minutos para realizar o trabalho e dois meses para deixá-lo funcionando corretamente".

9) Documentação escrita em português estruturado não é bobagem: se você acha que documentar um software somente com um diagrama de classes é o suficiente e que o resto é bobagem, está cometendo um ledo engano. Por mais usabilidade que um software possa oferecer, existem regras de negócios e formas de navegação que devem ser documentadas. Portanto, um manual de usuário demonstrando as formas de navegação do software e uma documentação técnica explicando os casos de uso em português estruturado, versão do framework utilizada e, também, com diagramas que sejam úteis, entre outros, serão sempre bem vindos para o time, principalmente para seus membros que ainda não conhecem o software e que, em uma empresa humana e saudável, não possuem a menor obrigação de adivinhar o que aconteceu no passado do desenvolvimento daquele software específico. Ah, é claro, uma vez escrita a documentação, a mesma deve ser atualizada conforme o software seja modificado, para não confundir a cabeça do time e não transformar um trabalho minucioso em "papelada para fogueira de São João". Se você não possui uma redação razoável em português e, por isso, reluta em documentar o que você faz, a sugestão é que você se aprimore no nosso idioma, tanto na leitura quanto na escrita. Mas não diga que algo é ruim só porque você não sabe ou não gosta de fazer. Observação: não é necessário ser um professor Pasquale para escrever uma documentação. Basta ser claro nas informações que deseja passar.

10) Não fuja do material de estudo em inglês: grande parte do material de qualidade na internet e das boas literaturas de desenvolvimento de software está no idioma inglês. Busque proficiência neste idioma, que é de extrema importância não somente para a parte técnica, mas também lhe auxiliará a abranger boas oportunidades profissionais.

11) Seja objetivo: quando um colega quiser tirar uma dúvida sobre o código que precisará mexer, atenha-se exatamente ao que ele está perguntando. Não dê voltas tentando demonstrar toda a sua erudição técnica, pois, desta forma, ele, além de não entender a sua explicação, poderá achá-lo arrogante (se o colega for levar para o lado da maldade) ou maluco (se o colega for levar para o lado da piedade).
A objetividade também deve sempre ser levada para o desenvolvimento do software, desde seu nome, até as camadas que farão parte dele. Alguns exemplos:
a) Se o objetivo do software for "estoque de produtos", é muito mais prático e claro nomeá-lo "Estoque de Produtos" do que "Thunder Cats".
b) Nomes de variáveis, métodos e camadas são muito importantes para que o time entenda o software. Então, não abuse da criatividade e nomeie, por exemplo, a variável de quantidade de produtos como qtdProdutos em vez de observeAndCount e o método de obtenção de produtos como ObterProdutos() em vez de GetThings(). Se o objetivo de uma camada da arquitetura for acesso a dados, basta nomeá-la com o seu objetivo primário, em vez de chamá-la de "Data Cave".
c) Há uma corrente que diz que código bem feito não precisa de comentários. No mundo dos sonhos, é assim que a coisa funciona. Porém, no mundo real, o código pode estar muito bem feito, mas sempre há aquele trecho meio obscuro, não tem jeito. Há situações em que é de muito bom gosto inserir um comentário que explique o que determinado trecho de código faz. Afinal, "comentários existem para comentar".
d) Não reinvente a roda: não faça um código de difícil entendimento só porque é bonito e utiliza recursos eruditos. O que é bonito aos seus olhos pode ser aterrorizante aos olhos dos outros. O que pode ser simples, deve sempre continuar simples.