-
@ Bolsonitro Ucrânia 🇺🇦🇻🇦
2024-10-06 00:44:32Assumindo responsabilidades
O autor dá um exemplo bem interessante: Caso você escreva um código ruim que cause um prejuízo de 10 mil dólares para a empresa, um profissional deve fazer um cheque no mesmo valor para a empresa.
Isso enfatiza uma maior responsabilidade com o código que está sendo escrito, porque com certeza se o dinheiro que estivesse em jogo naquele código fosse nosso, testaríamos ele 70 vezes 7, porque haveria de ser diferente com o código sendo escrito para nosso empregador?
Ele ainda dá outro exemplo, onde em sua trajetória profissional, para manter sua reputação e entregar uma task no prazo, negligenciou o testes (que demorariam horas) para entregar uma atualização na data combinada, em fitas magnéticas que foram entregues aos clientes, resultado? Houve um problema nesse software e gerou um grande atrito dos clientes com a empresa, houve um custo muito alto e ele passou dias “debuggando” o código que era escrito em Assembly.
No final, o custo para a reputação dele foi muito maior do que se tivesse entregado com atraso, mas com qualidade. A responsabilidade sobre nossas entregas deve estar acima da nossa reputação.
Já me aconteceu de estar em um projeto com um prazo apertado, em que features do projeto foram deixadas para depois para ter o projeto entregue na data determinada, enquanto os membros da equipe faziam horas extras e corriam contra o tempo - No final, o projeto não era urgente e não foi usado por duas semanas após a data do deploy em produção 🤡, era algo que poderia ter sido bem feito da primeira vez, e sem fazer tantas horas extras, mas isso não era responsabilidade exclusiva de um dev em si, mas uma decisão alinhada com o product owner para que fosse entregue na data combinada.
Trazendo para meu exemplo, me lembro vagamente da mesma coisa já ter acontecido comigo no começo da minha carreira como desenvolvedor backend, onde testei mal algumas features, liberei para teste do QA, por conta da pressão constante para que a equipe entregasse mais e mais, e acabou tendo retrabalho como deffect (bug encontrado pelo QA), ou pior, bug (quando está em produção), ou seja, saíndo bem mais caro do que se tivesse demorado mais alguns dias no board de desenvolvimento.
Primeiro, não cause danos
Causamos danos no software quando implementamos bugs, e apesar de ser bem difícil desenvolver software sem bugs, o autor argumenta que ao longo da trajetória profissional, o número de bugs deve tender à zero - O que faz sentido, dado que a senioridade aumenta.
Mas o autor também apresenta um outro conceito interessante: O QA não deve pegar nada. Basicamente devemos entregar um código tão bom, tão bem testado e tão bem feito que o QA não deve encontrar nenhum problema, ou seja, não devemos enviar ao QA algum código que não temos certeza se funciona ou não, pois demonstra falta de profissionalismo.
Para alcançar isso: testes, testes, testes unitários, testes de regressão, esteira de testes automatizados etc.
Um software deve ser testável, e principalmente de fácil manutenção, o autor recomenda a técnica de refatoração impiedosa, apenas para verificar se o código está fácil de mudar.
Ética de trabalho
Sua carreira é sua responsabilidade, e somente sua - Não do empregador. Se o empregador te envia para eventos ou te patrocina cursos, isso é um favor que ele te faz, mas não é obrigação.
O autor argumenta a necessidade do profissional estudar sempre, buscando melhorar como desenvolvedor, praticar, aprender linguagens diferentes, e dá uma lista de conceitos. que todo profissional deve conhecer.
Isso lembra bem uma dica que vi no livro “O programador pragmático”, onde o autor também recomenda a aprendizagem de uma linguagem de programação diferente da qual o programador está acostumado.
As dicas continuam, ele também recomenda o ensino aos outros, como forma de assimilar melhor os conceitos e aprender mais, ao ensinar os demais - Realmente quando buscamos aprender algo para ensinar os outros, acabamos assimilando ainda mais o conteúdo, e ao ensinar, aprendemos mais e desenvolvemos outros tipos de habilidades.
E por última coisa recomendada pelo autor, é o conhecimento do domínio onde se está inserido, domínio no sentido do contexto de negócio no qual nosso empregador está inserido, por exemplo: Se trabalho numa empresa de transporte por navio, eu aprender mais sobre as características desse negócio. Lembro-me do livro Domain Driven Design que fala justamente de escrever código que reflita o domínio de negócio que aquele código está inserido, principalmente na parte de linguagem oblíqua, que é quando o desenvolvedor e o código falam a mesma língua dos stakeholders, entendendo os termos que são específicos daquele tipo de empresa.