O Codificador Limpo - Um código de conduto para programadores profissionais
(9699) (2)
CategoriasAndroid, Design, Protótipo
AutorVinÃcius Thiengo
VÃdeo aulas186
Tempo15 horas
ExercÃciosSim
CertificadoSim
CategoriaDesenvolvimento Web
Autor(es)Robert C. Martin
EditoraAlta Books
Edição1ª
Ano2023
Páginas416
Opa, blz?
Terminei a leitura do livro “O Codificador Limpo" de Robert C. Martin, editora Alta Books. O autor é o mesmo de “Código Limpo”. Já lhe adianto: novamente um livro excelente.
Diferente de “Código Limpo”, em “O Codificador Limpo" o autor não utiliza códigos, o livro é sobre a conduta do programador como profissional. As dicas do autor são das mais variadas, desde adotar TDD (Test Driven Development) como técnica de desenvolvimento à assistir ou ler Romances Fictícios para manter a criatividade em alta (sério! Essa é uma das dicas do autor).
No primeiro capítulo o autor não consegue passar o potencial do livro, pois ele apenas conta algumas das histórias que viveu como programador, conta em um nível de detalhes a ponto de colocar as falas dos participantes do evento na época. Nesse início de livro a ideia foi passar os problemas que ele enfrentou e o que aconteceu por ele não ter tido o código de conduta correto, mesmo ele sendo em muitas vezes o melhor developer da equipe.
As histórias persistem no decorrer do livro, porém o conteúdo de conduta é em maior densidade do que as histórias vividas por ele.
O autor mostra no capítulo 2 o custo de dizer sim para tudo quando se falando de desenvolvimento de software. Ele comenta sobre a decepção que o developer causa no ambiente quando não consegue cumprir a meta que ele tinha definido com os outros participantes do projeto, uma data de entrega que ele concordou com o gerente de projeto, por exemplo.
Segundo o autor algumas vezes até é possível entregar o projeto, porém com mais dedicação, trabalhando mais de 12 horas dia, incluindo finais de semana, mas essa estratégia tende a ser falha segundo Martin, devido a vida extra emprego dos developers (filhos, amigos, namorada).
Outro problema é entrar em mais de um projeto sem ao menos questionar, mesmo quando o projeto atual já estiver consumindo boa parte do tempo. Aproveitando esse conteúdo, “O Custo de Dizer Sim” no contexto de mais de um projeto, faço um link ao livro “Previsivelmente Irracional” de Dan Ariely, onde o autor provou por meio de testes que fazer mais de uma coisa ao mesmo tempo diminui suas chances de sucesso em qualquer uma das tarefas sendo executadas.
Uma dica de Martin: leia qualquer outra coisa fora do contexto de programação, computação em geral. A recomendação é para aumentar a criatividade, mais precisamente ele recomenda a leitura de Romances na Ficção, para ele o resultado muito positivo. Eu fico com economia comportamental e estudo do cérebro (Daniel Kahneman, Dan Ariely, Nassim Nicholas Taleb, Deepak Chopra e outros).
Em “O Codificador Limpo” é ensinado também como falar “não” (ainda capítulo 2), como discutir uma data justa para a entrega do projeto, que o calculo dessa data deve levar em conta um pensamento pessimista, onde é colocado também o tempo de quando algumas coisas dão erradas, alias, muitas coisas saem erradas. O autor mostra que o developer tem de ser firme com a definição das datas de entrega, não ceder aos gerentes de projetos que querem tudo pronto o mais rápido possível. Somente em casos extremos é que o developer deve se dedicar ainda mais para cumprir com a data definida pelo gerente de projeto.
Martin fala no capítulo 5 sobre o mito que gira em torno do TDD (Desenvolvimento Orientado a Testes, em tradução livre). Mito esse que diz que levará muito mais tempo para desenvolver seguindo essa linha de desenvolvimento. Segundo o autor isso não é verdade, você tem de levar em conta, quando não utilizando o TDD, os pequenos testes que terá de fazer de forma inevitável (verificar se o cadastro está ocorrendo, por exemplo) e as voltas que terá de ter para corrigir um trecho de código aqui, um ali. Segundo o autor, esses pequenos testes e correções não planejados no desenvolvimento fazem com que o tempo de desenvolvimento seja ainda maior que com o TDD sendo aplicado.
O autor fala, praticamente em todos os capítulos, sobre o pessoal da Garantia de Qualidade (GQ), uma equipe que existe somente para tentar destruir seu software… não é bem assim, eles estão ali para manter a maior qualidade possível, porém para fazer isso eles aplicam testes que podem desvendar vários bugs atrasando ainda mais a entrega do software. Esse atraso, segundo Martin, é necessário se bugs ainda forem encontrados. Sinceramente acredito que esse tipo de equipe em empresas de software de pequeno e médio porte são luxo e algo não comum. Muitas vezes, nós developers temos de ser os camaradas que levam nossos softwares ao limite para conseguir encontrar ainda mais problemas.
O pessoal da GQ também é responsável, junto a outros stakeholders (esses outros, muitas vezes são os participantes de mais alto nível do projeto, os diretores e clientes), pelos testes de aceitação no sistema, se o sistema está cumprindo com todos os algoritmos definidos, isso em um contexto maior de abstração, por exemplo: se eu fizer XYZ no sistema um relatório em PDF deve ser gerado... e assim seguem os testes de aceitação. Caso todos os testes de aceitação passem, ai sim o time de developers (as vezes somente um camarada) pode falar que esse está finalizado.
O autor fala no capítulo 9 sobre gerenciamento de tempo, que reuniões são em maior parte improdutivas e têm muito de nosso tempo dedicado a elas. Comenta também sobre o “Foco-mana” que é uma espécie de foco absoluto na tarefa, que para o autor é algo traiçoeiro, pois o developer tende a ficar totalmente fora do contexto (ambiente de trabalho) e acaba sempre fazendo as tarefas sozinho, sem trabalho em equipe, pensando ser mais produtivo com esse comportamento. Isso é péssimo segundo o autor, tendo em mente que os melhores desenvolvimentos que ele, Martin, teve foi com trabalho em duplas. Detalhe, esse “mana” de “Foco-mana” se refere a vida que obtemos nos games, mana = vida.
Uma das dicas para melhor gerenciamento de tempo junto a foco, segundo o autor é utilizar aqueles tomates de cozinha, os utilizados para marcar tempo ao fogo que funcionam como uma espécie de despertador. O autor indica que devemos marcar 25 minutos e então se dedicar totalmente a tarefa nesse tempo. Finalizado o tempo de 25 minutos é hora de ter 5 minutos para relaxar, depois mais 25 de trabalho intenso. Assim seguir essa linha até onde for possível, porém a cada quatro tomates de 25 minutos é hora de ter um intervalo de aproximadamente 15 minutos, para depois voltar a rotina. O autor alerta que tem dias que será difícil, devido a problemas pessoais ou outras preocupações. Nesses dias o developer ficará com um ou dois tomates na contagem apenas, algo normal de ocorrer.
Algo interessante no livro é que o autor frequentemente alerta sobre os possíveis problemas pessoais que param o programador. E a dica dele é: vá resolver os problemas que estão atrapalhando seu momento de codificar, caso contrário você developer tende a construir um software de pouco qualidade.
No capítulo 10 Martin aborda o conteúdo sobre estimativa. Que estimativa para o developer significa "algo que pode ser possível de ser alcançado" caso tudo dê certo e que para os outros integrantes do projeto, os que não são developers, estimativa significa a "definição exata da data de entrega". Logo o autor alerta para que nós developers saibamos interpretar e também passar para os outros integrantes do projeto qual foi nosso verdadeiro entendimento do que foi dito. No caso o autor mostra como realizar as perguntas corretas para não restarem dúvidas. Caso algo dê errado, a culpa é nossa, developers, por não termos realizado as perguntas corretas para certificar que nosso entendimento foi o exato.
No capítulo 11 o autor fala sobre a pressão no ambiente para correr com um projeto, como lidar com isso. Fala sobre colaboração, sobre trabalho em equipes. E um assunto interessante é quando ele fala sobre “Ensino, Aprendizagem e Habilidade” (capítulo 14), nesse ele cita um belo exemplo, a vida de um médico, que o médico mesmo depois de formado, em alguns casos mais críticos, nem mesmo participar efetivamente de uma cirurgia ele pode. Os médicos passam ainda muitos anos somente observando os mais experientes, para então depois de mais alguns 5-7 anos de estudos (além dos 6 anteriores na graduação) para obtenção de residência e outros, somente depois de todo esse tempo ele receber autoridade o suficiente para começar a colocar a mão na massa, digo, na parte mais critica do problema.
Segundo Martin, Isso é algo que não acontece com developers, muitas vezes o camarada sabe desenvolver e mesmo antes de deixar o ensino médio já está com um emprego de developer, e o pior, sem nenhum developer com mais experiência acompanhando ele de perto, as vezes no mesmo ambiente, mas sem estar o orientando. Algo que segundo o autor deveria acontecer por mais alguns anos depois da recente formatura do developer, digo, o acompanhamento de um profissional mais experiente. Indo ainda mais longe, segundo Martin, o fracasso de alguns developers de hoje é devido ao mais experientes não os acompanharem no inicio de suas carreiras.
No final do livro o autor tem um apêndice muito show de bola indicando algumas das ferramentas que podem em muito aumentar nossa produtividade. Algumas são: Eclipse, IntelliJ IDEA e Git.
O livro é show de bola e é muito elogiado, sendo até mesmo indicado como leitura obrigatória para recém-formados em curso de computação. A parte decepcionante pode estar na espera de falas empreendedoras. Se você tiver um cunho empreendedor, digo, aquele de montar sua própria empresa de software, o livro tem, se você conseguir enxergar isso, o foco no trabalho como funcionário, trabalho de excelência, aquele que vai levar a empresa, que ele é funcionário, para um outro nível, algo que não deixa de ser empreendedor, mas como funcionário.
Martin comenta muito também que estudar e praticar fora do trabalho é essencial para poder entregar sempre um software ainda melhor. Para estudo e prática em dias úteis Martin indica algo em torno de 3 horas por dia além do entregue no trabalho (as 8 horas).
Outro ponto a se observar é que há muitas dicas pessoais que podem soar como caminhos a serem seguidos, por exemplo: quando o autor indica a leitura de romances fictícios, ele na verdade está indicando o consumo de conteúdo diferente de sua rotina como developer, porém na maneira que ele coloca dá a entender que quando você estiver naquele tempo livre é para você ler isso, romance. Importante ficar ligado para você não seguir exatamente o que é a vida dele e sim pegar algumas dicas e descobrir o que funciona para ti e então aprimorar o que funciona.
O livro é pequeno e fácil de ler, sem códigos. Dicas são valiosas para a vida de developer, o camarada tem quatro décadas como developer. Vou de cinco estrelas.
Vlw
Comentários Facebook