O Codificador limpo — O que aprendi — Parte 3
Terceira e última parte do artigo sobre meu aprendizado em alguns anos de experiência e também com livros como o codificador limpo
Estados mentais do código
Nossa profissão demanda muita concentração, ja que trabalhamos basicamente usando o cérebro e as mãos para segui-lo, portanto é muito importante seguir alguns pontos importantes:
- Obviamente, seu código deve funcionar, então você deve entender o problema que está resolvendo e atuar da melhor forma possível
- Seu código precisa se enquadrar na proposta do projeto em que está trabalhando, assim como na arquitetura e linguagem. Não pode tornar o código mais complicado, frágil.
- O código necessita ser compreensível para outras pessoas, então as vezes fazer a funcionalidade utilizando métodos mais avançados e complicados nem sempre é a resposta certa.
É claro que falar é fácil, fazer é que fica complicado. A grande questão é tentar o máximo possível seguir bons princípios.
Quando estamos desenvolvendo, nem sempre estamos na nossa melhor forma, as vezes estressados, com fome, sono, tristes e ou ansiosos. As vezes os prazos nos complicam tanto que nos vemos as 3h da manhã em frente ao computador esperando as mágicas linhas de código pularem do nosso cérebro pra tela do computador. Muitas vezes somos tomados pela adrenalina de estar altas horas codando, nos sentindo o(a) MVP (Sigla do basquet para jogador(a) mais valioso(a)), mas geralmente o que acontece é que provavelmente esse código voltar a nos dar dores de cabeça muitas vezes no futuro. O mesmo acontece quando entramos na tão aclamada zona, um estado em que estamos 100% focados e nada pode nos atingir, e não entenda errado, realmente produzimos mais nesse momento, mas para isso acabamos por abrir mão do aspecto geral, e por isso, a qualidade do que foi feito tende a ser menor.
As interrupções que ocorrem durante o dia também acabamos por nos tirar de nossa concentração, e hoje em dia, com produtos e processos cada vez mais ágeis, a comunicação tende a ser mais necessária, por isso, é sempre interessante tentar ser o mais solicito possível, pois como diz o próprio Uncle Bob:
“Da próxima vez, pode ser você a interromper outra pessoa”
Portanto uma dica que o mesmo da é trabalhar em par, onde um pode continuar o desenvolvimento e o outro parar para ajudar no que foi solicitado. Claro, existem momentos em que você pode avisar seus/suas colegas a não lhe atrapalharem a não ser em casos de emergência, e a comunicação é importante nesse aspecto, mas não é sempre que isso será possível.
Ajuda
Saber pedir ajuda deve ser uma das melhores coisas que você deveria aprender na sua vida, mas se encaixa muito bem em nosso contexto de programação, pois é uma área completamente intelectual e portante, muitas vezes o que é difícil para nós, é simples para outra pessoa, e sendo assim, saber a hora de pedir auxilio de outra pessoa pode te poupar horas de estresse e ainda por cima, conhecimento. Mas não entenda errado, o ideal é que isso não ocorra o tempo inteiro, a não ser que seja iniciante, e sim que isso venha a ocorrer de tempos em tempos.
Além de pedir ajuda, existe o outro lado da moeda, ajudar os outros tende a ser muito gratificante e mais que isso, pode ajudar a fomentar algum conhecimento, portanto tente ser o mais aberto possível a ajudar seus colegas e ou quem estiver interessado, pode ser uma experiência muito valiosa.
Estudo e Experiências
Não é dever de seu/sua empregador/empregadora lhe ensinar ou pagar cursos para aprimorar seu conhecimento.
(Tirando estagiários e estagiarias, por favor. Eles já sofrem sozinhos).
Isso é algo que você mesmo deve se cobrar. Conhecer seu ramo de trabalho e variantes pode te ajudar muito e com certeza lhe tornará um profissional melhor.
Busque aprender constantemente e tente extrair sempre o melhor de suas experiências, mesmo que sejam ruins.
Vou lhe dar um exemplo. Certa vez trabalhei em uma empresa que prestava serviço terceirizado, portanto ficava alocado no cliente e a experiência realmente foi desagradável, a falta de organização e discriminação com terceirizados que frequentemente aconteciam eram cansativas e estressantes, fora o volume de trabalho extra. Naquele momento, não conseguia enxergar muitos pontos positivos, mas depois percebi que aprendi a lidar sob pressão e com equipes maiores nesse processo. A grande questão aqui é tentar tirar o bom do ruim, é difícil, mas renderá frutos.
A melhor forma de aprender é praticando, portanto tente sempre exercer o que aprendeu para ajudar a fomentar o assunto. A colaboração com outros/outras desenvolvedores(as) pode ser muito interessante, pois terá diversos pontos de vistas e conhecimentos variados entre cada um, sendo sempre uma ótima fonte de conhecimento, portanto, recomendo que engula o orgulho e busque aprender com o próximo.
Tudo isso nada mais são que experiências e lições que aprendi e estou aprendendo em minha carreira de desenvolvedor juntas com conhecimentos do livro “O codificador Limpo” do Robert C. Martin (Uncle Bob). Imagine isso como um resumão que pode te ajudar a abrir os olhos para alguma melhoria em seu próprio desenvolvimento profissional.
Muitíssimo obrigado por ler até aqui, caso tenha caído de paraquedas e não tenha lido as duas primeiras partes, aqui estão
