Havia um pouco de brouhaha recentemente sobre alguns comentários feitos por Joel Spolsky em nosso podcast:
Na semana passada, eu estava ouvindo um podcast sobre Hanselminutescom Robert Martin falando sobre o Princípios SOLID. (Esse é um termo realmente fácil de pesquisar no Google!) É um design orientado a objetos, e eles o chamam de design ágil, o que realmente não é. São princípios de como projetar suas classes e como elas devem funcionar. E, quando eu estava ouvindo, todos eles me pareceram uma programação extremamente burocrática que veio da mente de alguém que, francamente, não escreveu muito código.
Não há nada realmente questionável no Os princípios de design orientado a objetos de Bob, ao que parece. (Observe que todos os links na tabela abaixo são PDFs, portanto, clique de acordo).
Embora eu acredite que toda equipe de desenvolvimento de software deva se esforçar para seguir as instruções da lata de tintaO senhor sabe que há um limite para o que cabe em uma lata de tinta. Essa é a informação mais básica e mais importante de que o senhor precisa para prosseguir e não fazer uma grande bagunça no processo. Por mais breves que sejam as instruções em uma lata de tinta, elas representam o limite superior do que a maioria das pessoas lerá, compreenderá e obterá benefícios imediatos de forma realista.
Expandir de algumas diretrizes em uma lata de tinta para um manual de pintura detalhado é muito mais arriscado. Quanto maior e mais grandioso for o conjunto de regras que o senhor criar, mais grave será o perigo. Algumas diretrizes gerais em uma lata de tinta geram trinta regras de pintura, que geram cem princípios detalhados de pintura.
Em pouco tempo, o senhor vai acabar acreditando que todas as situações possíveis no desenvolvimento de software podem ser prescritas, se ao menos o senhor pudesse criar um conjunto de regras suficientemente detalhado! E, é claro, uma massa crítica de programadores com paciência suficiente para ler os Volumes I a XV dessas regras. O senhor também deve criar alguns quadros de mensagens para que esses programadores discutam incessantemente entre si sobre o significado e a interpretação das regras.
Isso me parece que um pouco como a programação Ferengi.
O Ferengi fazem parte do universo de Star Trek, principalmente em Deep Space Nine. Eles são uma raça de ultra-capitalistas cujas transações comerciais são regidas pelo as 285 Regras de Aquisição. Há uma regra para cada situação comercial possível e, inevitavelmente, uma interpretação dessas regras que dá aos Ferengi licença para trapacear, roubar e distorcer a verdade para atender às suas necessidades.
Em que ponto o senhor deixa de ter um conjunto de diretrizes básicas e razoáveis de programação e começa a ser um programador Ferengi, uma manifestação imperfeita do conjunto de regras?
Como James Bach, descobri que o cada vez menos utilidade para as regras em minha carreira. Não porque eu seja um gênio que se fez sozinho e que segue minhas próprias regrasmas porque valorizo muito mais as habilidades, a experiência e o julgamento da minha equipe do que qualquer conjunto estático de regras.
Quando Ron diz que há um “mínimo absoluto de prática” que deve existir para que um projeto ágil seja bem-sucedido, quero responder que acredito que há um mínimo absoluto de prática necessário para se ter uma opinião competente sobre as coisas que são necessárias e que, em sua postagem, ele não atinge esse mínimo. Acho que parte desse mínimo é entender o que palavras como “prática”, “ágil” e “sucesso” podem significar (reconhecendo que são ideias maleáveis). Parte disso é reconhecer que as pessoas podem e têm se comportado de forma ágil sem qualquer conceito de ágil ou capacidade de explicar o que fazem.
Meu estilo de desenvolvimento e teste é altamente ágil. Sou ágil porque estou preparado para questionar e repensar qualquer coisa. Eu mudo e desenvolvo meus métodos. Posso aprender com ideias empacotadas como Extreme Programming, mas nunca sigo eles. O seguinte é para iniciantes que estão sob supervisão ativa. Em vez disso, eu crio métodos em uma base de projeto por projeto e incentivo outras pessoas a fazerem isso também. Assumo a responsabilidade por minhas escolhas. Isso é engenharia para adultos como nós.
Diretrizes, especialmente na ausência de especialistas e mentores, são úteis. Mas há também um perigo muito real de que o seguir com muita fidelidade os conjuntos de regras. Os programadores já são bastante sistemáticos por disposição, portanto, a ideia de que é possível criar um conjunto de regras, sub-regras e sub-sub-regras detalhado o suficiente para que o senhor possa literalmente programar o senhor mesmo para ter sucesso com um “sistema” de sofisticação suficiente – isso, infelizmente, é natural para a maioria dos desenvolvedores de software. Se o senhor não for cuidadoso, pode até cometer um deslize e cair em uma metodologia. Então o senhor está em real problemas.
Não se torne um programador Ferengi. Regras, diretrizes e princípios são joias de experiência destilada que devem ser estudadas e respeitadas. Mas elas nunca substituem o pensamento crítico sobre seu trabalho.