Uma resposta comum à O Programador Ferengi:
Pelo que vejo, o problema dos “desenvolvedores com regras excessivas” não chega nem perto da magnitude do problema dos “desenvolvedores que realmente não têm a menor ideia”.
A maioria dos desenvolvedores não sofre com o excesso de padrões de projeto, nem com o excesso de SOLID, nem com o Agile, nem com o Waterfall. Eles sofrem com a criação de códigos de cowboy em um ambiente de puro caos, usando técnicas simplistas de arrastar e soltar, orientadas por dados e semelhantes a vb.
Com certeza.
Mas eis o paradoxo: os tipos de programadores que mais se beneficiariam dessas diretrizes, regras, princípios e listas de verificação são os menos propensos a lê-las e segui-las. Jogar um livro de regras em um programador terrível apenas cria um programador terrível com um hematoma na cabeça onde o livro bateu. Isso é algo que discuti anteriormente em Mort, Elvis, Einstein e o senhor:
Portanto, se o senhor leu o artigo, certamente está na categoria dos 20%. Os outros 80% não estão pensando ativamente sobre a arte do desenvolvimento de software. Eles nunca encontrariam esse artigo, muito menos leia . Eles simplesmente não leem blogs de programação – a não ser como resultado de pesquisas na Web para encontrar respostas rápidas para um problema específico que estejam tendo. Tampouco leram nenhum dos livros do meu lista de leitura recomendada. A característica que define a grande maioria desses programadores ditos “vocacionais” é que eles são inacessíveis. Não importa o que o senhor, eu ou qualquer outra pessoa escreva aqui – eles nunca verão.
Na ausência de orientação e aprendizadoa disseminação de melhores práticas de programação é muitas vezes convenientemente empacotada em processos e metodologias. Quantos deles o senhor conhece? Quantas o senhor já praticou?
E como esperamos que o desenvolvedor médio descubra isso? Em uma palavra, marketing. (Eu poderia ter substituído por religião aqui sem muita alteração no significado). Não é por acaso que muitos dos proponentes dessas metodologias ganham a vida prestando consultoria e ensinando sobre elas. E eles também têm muito trabalho pela frente, porque a maioria dos programadores é inacessível:
Eu estava sentado em meu escritório conversando com meu colega de trabalho Jeremy Sheeley. Jeremy lidera a equipe de desenvolvimento do Vault e do Fortress. Durante nossa conversa, percebi de repente que nenhum de nossos esforços de marketing chegaria a Jeremy. Ele não vai a feiras ou conferências. Ele não lê revistas. Ele não lê blogs. Ele não vai a reuniões de grupos de usuários.
Jeremy é um tomador de decisões sobre a ferramenta de controle de versão usada por sua equipe, e nada do que estamos fazendo o faria conhecer nosso produto. Quantos outros Jeremies existem por aí?
Milhões! Como observa Seth Godin, o inalcançáveis agora são realmente inalcançáveis – pelo menos não por meio do marketing.
Portanto, se sabemos que os programadores que mais se beneficiariam com essas regras, princípios e diretrizes são:
- é altamente improvável que os leiam por vontade própria
- quase impossível de alcançar por meio de
religiãomarketing
Lembre-me de novo – o senhor está se lembrando? Para quem, exatamente, estamos escrevendo esses princípios, regras, diretrizes e metodologias? Se estivermos atingindo apenas os programadores que são atenciosos o suficiente para se preocupar com seu trabalho, o que realmente conseguimos? Concordo com Jeff R., que deixou este comentário:
Não há nada de errado com o Princípios SOLID; eles fazem sentido para mim. Mas eu programo desde os tempos dos leitores de cartões e dos teletipos. Eles não vão fazem sentido para quem tem pouca experiência. Eles não sabem quando ou como aplicá-los adequadamente. Ficam atolados na tentativa.
Portanto, tentar segui-las muda o foco do resultado para o processo. E isso é fatal.
É função do programador ou gerente principal garantir que os bons princípios sejam seguidos, talvez orientando os outros de forma invisível, sem exigir explicitamente ou mesmo mencionar esses princípios.
Em meu esforço para chupar menos a cada anoJá li centenas de livros de programação. Pesquisei todas as metodologias modernas de programação. Sou até mesmo um Scrum Master certificadotm. Tudo isso, para mim, parece ser versões infinitamente repetidas de quatro fundamentos básicos. Mas “quatro fundamentos básicos?” é um marketing terrível. Ninguém me ouvirá com atenção e adoração enquanto eu pontificar, nem pagará os honorários exorbitantes de consultoria que exijo para sustentar o estilo de vida ao qual me acostumei. Simplesmente não dá. De jeito nenhum. Portanto, eu dublo isso:
O sistema Atwood de poder real e definitivo de programação
Todas essas regras, diretrizes, metodologias e princípios incrivelmente detalhados? YAGNI. Se não puder ser explicado em uma única folha de papel com espaço duplo, é uma perda de tempo para o senhor. Vá ler e escrever algum código! E se o senhor não conseguir entender esses fundamentos no primeiros três ou quatro anos, o senhor de sua carreira de programador, bem – esta citação de R. Lee Ermey ligeiramente modificada me vem à mente.
Meu nome é Jeff e não consigo parar de pensar em programação. E o nem o senhor deveria.