Bom, o livro Clean Coder faz parte de uma coleção de livros do autor Robert C. Martin (nosso queridíssimo Uncle Bob) que busca orientar desenvolvedores sobre boas práticas relacionadas ao mundo do desenvolvimento de software.
Minha primeira experiência com o autor foi com o livro Clean Code, livro voltado principalmente a boas práticas ligadas ao código - como o uso estratégico de comentários, a importância dos testes, a relevância de bons nomes para funções e variáveis, dentre muitos outros conselhos interessantes.
Já no segundo livro que tive contato, o foco é em se tornar um bom desenvolvedor, sabendo os momentos de dizer sim e não, como assumir e arcar com as responsabilidades, como interagir bem com o time, se manter sempre atualizado e agregar valor à empresa.
Profissionalismo - em relação ao profissionalismo, algumas mensagens importantes, em minha humilde opinião são os seguintes:
- Um bom profissional sabe como se portar no ambiente corporativo, de acordo com os códigos de conduta do lugar em que está;
- Um bom profissional mantém seu time sempre a par do status do projeto, independente de qual seja;
- Um bom profissional está sempre atento às demandas da empresa e do cliente;
- Fugir dos pontos supracitados, o transforma num mal profissional.
Dizer sim - um bom profissional sabe os momentos certos para dizer sim, sem ceder à pressão ou influência de terceiros, que poderia influenciar negativamente no decorrer do projeto; mais profissionais dizem sim pra tudo e acabam não conseguindo arcar com suas responsabilidades e comprometimento.
Dizer não - seguindo a linha do sim, bons profissionais também sabem o momento certo para dizer não, para evitar contrair mais responsabilidades do que podem atender. Da mesma forma, dizer não para tudo, o torna um mau profissional.
Testes de aceite - os testes de aceite são necessários para garantir que o sistema cumpra com o desejado. O ideal é que seja escrito pelo QA e pelo Analista de negócios (para garantir que os caminhos felizes e tristes estão cobertos e garantir maior qualidade do software. Vale lembrar que um bom desenvolvedor testa seu código e o envia funcional para o QA).
Praticar - é certo que a prática leva a perfeição e algumas considerações trazidas pelo autor são: seu tempo de trabalho não deve ser seu tempo de prática. Todas as profissões demandam prática e isso não seria diferente no desenvolvimento. Uma recomendação interessante é escolher um algoritmo e desenvolver soluções para ele, até o domínio completo e também o pair programming.
Pressão - a pressão é algo presente no cotidiano de todas as pessoas, o ponto alto é a forma que se lida com essas pressões impostas, seja em relação ao tempo ou as maneiras que as demandas que devem ser entregues.
Estimativas - em relação às estimativas, o ponto mais legal abordado foi a forma que diferentes profissionais/setores enxergam as estimativas.
O pessoal da área de negócios entende as estimativas como algo já definido, ou seja, eles precisam de um prazo e acreditam que essa estimativa de prazo é 100% real e fidedigna. Em contrapartida, para os desenvolvedores, uma estimativa é uma ideia do tempo que pode levar para que uma tarefa seja executada, variando para mais ou para menos.
Existe um modelo de cálculo de estimativas sugerido no livro que pode ajudar a encontrar um valor médio aceitável para as estimativas.
Colaboração - é importante entender que existem diversas relações em que a colaboração é necessária: entre desenvolvedores e pessoas, clientes, empregadores e até mesmo (creio que principalmente) entre desenvolvedores, afinal, compartilhar conhecimento, escrever um código inteligível, trabalhar em conjunto para resolver problemas facilita e agiliza bastante o processo de desenvolvimento.
Times e projetos - em suma, é preferível construir um bom time, bem integrado e capacitado, que possa atuar em diversos projetos do que desmembrar, criar e recriar times todas as vezes que um novo projeto for aprovado.
Top comments (0)