- 5 minutos de leitura

Como ser um desenvolvedor de software melhor.

Acho que estou ficando louco, mais enquanto eu estiver aproveitando, tudo bem. Ozzy Osbourne.

A teoria das janelas quebradas?

Em resumo: A teoria afirma que a desordem visível em um local, como uma janela quebrada sem reparo, transmite uma mensagem de falta de cuidado e controle, o que pode encorajar mais vandalismo e outros comportamentos criminosos.

E o qual ligação que a teoria tem com o desenvolvimento de software?

É bem simples, se você está trabalhando em um projeto, e tem alguns “bugs” que outros desenvolvedores não ligam e deixam de arrumar ou que ninguém de produto se importa com aqueles erros, se não tem testes unitários, se o código escrito está feito de qualquer forma, cheio de repetições, funções sem uso, etc… Seu software está cheio de janelas quebradas.

Mas se os outros desenvolvedores (normalmente mais antigos) não se importam porque eu deveria? Justamente para mostrar que você pode melhorar o software, não precisa refatorar o software inteiro, mas aos poucos você consegue ir tapando as janelas, criando testes unitários, removendo códigos duplicados, deixando pequenos comentários em trechos complexos. Com isso se software vai perdendo a cara de abandono e todos envolvidos começam a se interessar mais pelo projeto e olhar com outros olhos.

Preocupe-se com os seus colegas de trabalho.

Motive seus companheiros a melhorarem, mostre artigos, vídeos e até mesmo podcasts sobre tecnologia, para que a régua técnica da equipe possa subir, dessa forma pode chegar um momento em que todos nesse grupo comecem a compartilhar bons conteúdos.

Seja responsável.

É muito comum na área de desenvolvimento, nos culparmos mutualmente. Não seja assim, se você causou um bug assuma a responsabilidade por isso e resolva o problema.

Se o código que fez está mal escrito com desculpa do tempo, arrume um tempo extra para resolver o problema e não deixar “uma janela quebrada” para trás.

Numa empresa de tecnologia a stack dos projetos podem ser bem grandes, com ferramentas de monitoramento, métricas, data, devops e muitas outras ferramentas, não é um demérito você não conhecer uma ferramente numa stack sei lá de trinta ou quarenta ferramentas, seja sincero e diga que não conhece, mas que está disposto aprender sobre a ferramenta.

Nunca se canse de ver códigos.

Na hora de revisar um Pull Request, reserve um tempo, para poder fazer uma boa revisão, afinal quando você faz a revisão de um código e esse código é aprovado para ir para produção você também é responsável, então faça o trabalho direito.

Documente tudo que puder.

Eu sempre usei dois editores de texto (vim e outro qualquer), mas mudei atualmente de vim para lunarvim e apesar de serem parecidos, tem suas diferenças e me peguei lendo a documentação e pelo fato de ser bem escrito isso me ajudou muito com as dificuldades que tive nesse início.

É bem comum (mesmo que não devesse) as aplicações não ter nada de documentação, ou ter uma documentação bem escassa, isso é um erro que você deve apagar.

Documente tudo que você faz, se você é frontend, documente a arquitetura que seu projeto tem, escreva sobre as APIs consumidas em cada tela, se você cria componentes, documente eles com alguma ferramenta tipo um storybook.

Um projeto de pode ser bem grande, então se puder escrever fluxos de telas e como eles funcionam, faça.

Busque conhecimento sobre o produto.

Muitas vezes somos negligentes sobre o produto que trabalhamos, querendo somente desenvolver coisas novas e criar telas bonitas, tudo bem isso não é um problema, mas precisa chegar o momento em que você precisa começar a entender mais sobre o produto que está trabalhando.

Devemos entender mais sobre o produto, pois quando surgirem os refinamentos de coisas novas você poderá ajudar em coisas que fazem sentido para o produto e como podem ser desenvolvidas de forma mais fácil, vai auxiliar na criação de bons contratos com o backend e frontend.

Nunca para de buscar conhecimento.

Sempre continue lendo artigos, lendo livros, vendo vídeos e até mesmo fazendo alguns cursos (se forem bons e não prometam milagres). Isso vai te ajudar muito em construção de produtos bons e consistentes, vai mostrar que a tecnologia é um fim e não um meio de fazer as coisas acontecerem. Pensando nisso vou deixar uma lista de alguns livros que possam te ajudar como profissional

Espero ter podido ajudar com esse artigo não técnico, mas esse é um pequeno trecho da minha visão com alguns anos de experiência com desenvolvimento de software, comentem é bem importante para deixar o artigo mais rico e qualquer coisa que eu possa deixar melhor. É isso abraços quentes para vocês.