Talvez você já tenha lido o livro “The Clean Coder” [1] ou a versão traduzida, “O Codificador Limpo” [2], de Robert C. Martin. Caso não saiba quem é Robert Martin, talvez o conheça por Uncle Bob. Um defensor de princípios relacionados ao software craftmanship (“artesanato de software”), ao desenvolvimento ágil, entre outros. Ele é uma das 17 feras que estavam na estação de ski em Fevereiro de 2001, em Utah, discutindo princípios e valores do desenvolvimento de software, confrontando métodos pesados e métodos leves. Se esse evento não lhe é familiar, foi de onde surgiu o Manifesto Ágil. Independente deste evento, podemos afirmar que esses 17 caras entendem (e muito!) de desenvolvimento de software. Uncle Bob aborda no livro citado acima o seu entendimento sobre o que é um desenvolvedor profissional. É sobre isso que vamos falar agora.
Mais que Títulos, Mais que Certificações
Ser um desenvolvedor profissional é mais do que sair da faculdade como um engenheiro de software ou um analista de sistemas. É mais do que conhecer linguagens, frameworks e métodos. É mais do que construir um app mobile e colocar nas stores. É mais do que suas vinte e cinco certificações.
Para ser um desenvolvedor profissional é preciso ser responsável. Parece óbvio, mas o que é isso? Talvez a primeira imagem que venha à sua cabeça é cumprir prazos ou jornadas de trabalho, porém a responsabilidade real vai muito além disso.
Fazendo uma analogia grotesca, pense em um médico. Ele vai fazer uma operação e precisa garantir que não irá causar nenhum estrago ao corpo do ser humano que está em sua mesa de cirurgia. Talvez o mesmo raciocínio devesse ser aplicado ao software. O software é complexo, mas nem sempre lida com consequências tão drásticas, então parece ser pedir demais que não escape nenhum erro ou problema quando a release vai para produção. E se esse erro gera ao dono do produto ou ao seu empregador, por exemplo, um custo alto ou perdas financeiras? Isso é um problema. Se você entende que esse problema não é seu, aí reside um motivo de alerta. Se o software lidasse com vidas, talvez o exemplo parecesse mais drástico e tocasse seu coração.
Como o Desenvolvedor Profissional Deveria Agir?
Você causou falhas. Você causou custo. Se você é um desenvolvedor responsável, então você deve fazer todo o possível para que seu software seja executado corretamente. É sua responsabilidade saber que aquilo funciona como deveria. Desse modo, para se assegurar disso, o que você precisa fazer? TESTES.
Você deveria ser o tarado dos testes. “Ah, mas minha empresa tem uma área de QA e eles são responsáveis por encontrar erros”. Não, você é responsável por encontrar todos os erros que puder. Você, desenvolvedor, é o responsável por garantir a cobertura do seu código. Além disso, você precisa garantir que, ao incluir uma nova funcionalidade, não estragou algo que já funcionava. Mas como fazer isso? Novamente, TESTES.
Você precisa pensar em mecanismos para automatizar os testes que garantam a qualidade do que você está produzindo. Sendo assim, faça testes de unidade e de aceitação. Automatize ao máximo. Você precisa ter certeza que, após executá-los, é bastante provável que seu produto esteja perfeitamente funcional.
O Código Funciona, Então Está Bom?
Claro que não. Como um desenvolvedor profissional, você sabe que a estrutura do código é importante. É ela que, quando bem feita, permite flexibilidade e dinamismo para atender as necessidades de mudança sem comprometer o todo. É ela que garante a sustentabilidade do negócio do seu cliente, empregador ou até mesmo do seu próprio negócio.
Se você trabalha com desenvolvimento de software, certamente já participou de um projeto em que a equipe costumava ter as entregas sob controle. O escopo era facilmente mensurado e as funcionalidades eram criadas em uma semana. Entretanto, de repente, sem entender exatamente o que mudou, funcionalidades demoraram semanas para serem entregues. Ficou cada vez mais difícil estimar o tempo de construção. O desespero pelo aumento da equipe tomou conta dos gestores.
Situações como essa, possivelmente, foram causadas por uma estrutura frágil e insustentável. Os desenvolvedores, provavelmente, não fizeram refatorações tempestivas para garantir que as próximas mudanças fossem fáceis. Toda vez que o software começa a tornar-se difícil de mexer, mexa! O medo da mudança é um dos principais sintomas de que ações precisam ser tomadas. A mudança é da essência do software. O desenvolvedor profissional sabe disso e cria artifícios para que isso seja possível – através da utilização de padrões de projeto, de refatoração, de testes automatizados.
Ok, Funcionalidade e Estrutura. E o Que Mais?
Robert Martin cita mais alguns aspectos que devem fazer parte do mindset do desenvolvedor profissional. São alguns deles:
- Conhecimento de negócio (ou domínio). Você não deveria depender exclusivamente de uma especificação ou de poucos achismos. O desenvolvedor profissional deveria conhecer o domínio a ponto de ser propositivo.
- Conhecimento sobre software, algorítimos, princípios (por exemplo, SOLID), disciplinas (TDD, OO, programação estruturada, programação funcional, integração contínua etc).
- Conhecimento sobre métodos e processos (métodos ágeis, métodos tradicionais etc).
- Conhecimento sobre artefatos e recursos de modelagem de problema e processos (BMPN, UML, Diagramas etc).
- Mindset de crescimento. Não parar de estudar e estar sempre disposto a aprender com livros, colegas, cursos, conferências etc.
- Hábito de praticar. Não basta executar as tarefas diárias. É preciso praticar exercícios de execução de resolução de problemas através da repetição. Leia sobre Katas [3]. Algumas referências com esse tipo de prática são disponibilizadas no final do artigo [4][5][6][7].
- Comportamento ético em relação à sua carreira.Você é responsável pela sua evolução profissional, não seu empregador. Sobre este tópico, inclusive, Robert Martin cita que você deveria dedicar as 40 horas semanais para o seu empregador, mas deveria também dedicar 20 horas para o seu crescimento profissional.
O Comportamento Profissional: Dizendo Sim e Não Como Um Mestre
Você já sabe codificar, sabe padrões de projeto, artefatos, pratica com frequência, define testes automatizados e realiza refatoração frequente. O que falta, então?
Coragem
Termo forte, mas que tem relação forte com o profissionalismo. O desenvolvedor profissional precisa ter coragem, proficiência e educação, pois ele precisa saber dizer SIM e também dizer NÃO. Inclusive, para os gestores. Não estamos dizendo que você vai sair dizendo “não’s” ao seu bel-prazer. Não estamos falando em caprichos. Estamos falando em comprometimento e palavra. Sua palavra é sua fonte de credibilidade. Se você é capaz de estimar e indicar que é possível fazer algo, faça. Mas se entender que não será possível, diga.
Tentar
Uma falha muito comum é assumir compromissos com o termo “tentar”. Não adianta dizer que vai tentar entregar na sexta. Tentar implica em, quase sempre, falhar. Implica em dizer que sua estimativa não foi boa, mas que tem uma “gordurinha” que você pode se esforçar pra conseguir alcançar o resultado. Implica em dizer que você tem uma nova estratégia que permite entregar algo, quando você nem sempre tem.
Comprometimento
Quando o desenvolvedor profissional assume um compromisso ele diz que o fará (sendo honesto) e cumpre com sua palavra. Se há desconforto ou incerteza, negocie. Indique o que é possível cumprir até o prazo acordado e o que não é possível. E, principalmente, não dê a opção de entregar algo que viole seus princípios como um bom profissional (“eu entrego na sexta, mas sem os testes”). Você estará se comprometendo com uma entrega falsa.
Atrasos
Eventualmente, o desenvolvedor vai atrasar uma entrega. Nestes casos, o melhor a fazer, mostrando-se profissional, é detectar este atraso tempestivamente e comunicá-lo com honestidade e transparência.
Em caso de atraso ou de um primeiro “Não”, pode ser que o desenvolvedor seja questionado sobre realização de horas extras. Avalie o quanto entende que pode produzir a mais nessas horas. Dificilmente sua performance será a mesma que nas horas normais. É mais provável, inclusive, que ela seja reduzida drasticamente. Desse modo, idealmente, essa saída deve ser utilizada por pouco tempo e em situações específicas.
Pressão
Atenção à pressão! Uma habilidade a ser adquirida pelo desenvolvedor profissional é a administração do pânico. É muito importante que o desenvolvedor se mantenha disciplinado para não abandonar seus valores pois, quando está em seu estado de consciência normal, ele sabe que abandonar as boas práticas e sujar seu código só o farão ter mais trabalho e ficar mais atrasado.
Atenção à Meta
Acima de tudo, a responsabilidade do desenvolvedor profissional, é estar alinhado às metas da organização, do cliente, do negócio. De nada adianta fazer um código impecável, submergir no mar das tecnologias e novidades, enquanto sua organização e sua equipe estão desmoronando.
O Custo do Sim
Dizer Sim a qualquer custo e assumir compromissos impossíveis tem consequências para o desenvolvedor. Alguns efeitos colaterais começam a ser percebidos.
Geralmente, quando o desenvolvedor assume a postura de cumprir algo que considera impossível, sai de cena o desenvolvedor profissional e entra o desenvolvedor herói. Ele salva!
Ele espera ser reconhecido. Se ele não fizer o que está sendo pedido, alguém o fará (e ele não quer perder o posto). O problema é que, com isso, o software entregue, muitas vezes, não atende as expectativas. Depois de entregue nem sempre haverá tempo para “correr atrás do prejuízo” e fazer o software tornar-se sustentável. Pode ser que o herói tenha que continuar entregando funcionalidades em um software, agora, inflexível. O esperado reconhecimento pelo esforço pode não chegar (justamente porque seu trabalho não foi dos melhores ou porque as prioridades mudaram no meio do caminho, desconsiderando seu sacrifício).
Sou Gestor: Como Lidar com Sim’s e Não’s?
É comum o conflito entre os papéis do gestor e desenvolvedor. Ambos defendem seus objetivos e, no caso do gestor, ele precisa garantir as entregas, os prazos, os compromissos com clientes em função da competitividade que o mercado exige.
Por conta desse conflito natural, se você observar que sua equipe não te confronta e não apresenta conflitos, desconfie. As melhores tomadas de decisão são realizadas pelo confronto, pois é a partir da negociação entre papéis com interesses distintos que é possível criar uma meta compartilhada e colaborativa. Evitar o confronto pode ser um grande tiro no seu próprio pé, Gestor.
Além disso, sempre que possível, crie condições para que os desenvolvedores façam estimativas como elas são: probabilidades. A visão sobre as estimativas difere quando está sob a ótica do desenvolvedor ou o gestor. Geralmente, o desenvolvedor as vê como uma suspeita, enquanto o gestor as vê como deadline e compromisso. É preciso tratar as estimativas, sempre que possível, com seu caráter de hipótese.
Na realidade, enquanto uma entrega está associada a uma estimativa, está relacionada também a um conjunto de riscos e incertezas. Desse modo, é interessante tratá-la como uma distribuição de probabilidades onde há, pelo menos, uma abordagem otimista, uma realista e uma pessimista. Trabalhe com a equipe estratégias como planning pocker, estimativas trivariadas etc. Encare-as, sempre que possível, como estimativas, e acompanhe os riscos. Gerenciamento de riscos, nestes casos, costuma ser muito mais importante do que acertar todas as datas de primeira.
O Caso Challenger
Para ilustrar o papel do gerente e do desenvolvedor nesse processo de tomada de decisão e comprometimento, Robert Martin ilustra um caso emblemático: a explosão da nave espacial Challenger.
Esta viagem espacial seria a primeira a levar uma civil (uma professora do ensino médio) para o espaço, além de uma tripulação de outros seis astronautas. O motivo da explosão deveu-se, resumidamente, ao escapamento de gases, que fizeram o tanque de hidrogênio líquido explodir. Então você se pergunta, mas como os gases escaparam? Há anéis de vedação cuja função é justamente manter os gases onde deveriam estar. Entretanto, seu correto funcionamento depende de uma temperatura mínima. No dia do lançamento, a temperatura do ambiente estava 23 graus abaixo do mínimo para o correto funcionamento dos anéis de vedação. Esta temperatura deixou os anéis duros, o que não permitiu a dilatação e correta vedação das turbinas.
O mais curioso (e trágico) deste episódio foi o fato de que os engenheiros que projetaram a turbina sabiam dos riscos. Embora tivessem projetado a solução de contorno, seu desenvolvimento foi adiado. Com base nas temperaturas do dia, os engenheiros tinham conhecimento do problema e alertaram os gestores através de memorandos repletos de dados, recomendando o adiamento do lançamento. Os gestores, sob pressão, não cederam. Eis que a Challenger, como avisado pelos especialistas, explodiu logo após o lançamento em 28 de Janeiro de 1986.
Veja essa matéria a respeito do sentimento dos engenheiros.
Fica a reflexão sobre o profissionalismo e o papel dos especialistas e gestores, cuja negligência pode causar maiores ou menores consequências. Profissionais assumem riscos com consciência. Profissionais se comprometem. Profissionais são responsáveis pelas consequências.
Referências
[1] The Clean Coder – A code of conduct for professional programmers (Robert C. Martin)
[2] O Codificador Limpo – Um código de conduta para programadores profissionais (Robert C. Martin)
[3] https://en.wikipedia.org/wiki/Kata_(programming)
[5] https://github.com/gamontal/awesome-katas
[6] http://kata-log.rocks/software-design
[7] http://www.thesoftwaregardener.com/agile/dojo-code-katas/