Hoje, chamamos a atenção para a
tradução contínua
de material sobre os perigos da chamada programação "funcional".
Sucesso é o caminho, não o objetivo.
Vamos admitir que nós programadores somos pagos pelo nosso tempo. Assim como os construtores que estão cavando buracos perto da minha casa há dois anos (a propósito, eles estão construindo um muro, ou seja, uma estrada).
Vamos procurar a fórmula de produtividade do programador. Todo mundo que trabalhou em qualquer grande empresa séria conhece uma fórmula simples para o sucesso:
= __ x __
▍Número de bugs corrigidos
O cérebro humano está muito mal adaptado para trabalhar com o que é chamado de "estado da aplicação" na programação. Em algum momento, podemos armazenar apenas cerca de cinco elementos em nossa memória de curto prazo. Um "estado" na programação é geralmente dados armazenados na memória. No OOP, esses são, por exemplo, campos ou variáveis de objetos. Trabalhar com um estado mutável é muito semelhante ao malabarismo. Poucos dos meus amigos conseguem fazer malabarismos com três bolas, para não mencionar cinco.
OOP faz bom uso dessas fraquezas. No POO, quase tudo pode sofrer mutação. Agradeço às forças superiores pelo fato de os criadores do OOP terem levado a sério a consideração de que depende a produtividade dos desenvolvedores! No OOP, todo estado mutável também está disponível para uso em diferentes locais de programas por referência. Isso significa que o programador não precisa apenas pensar no estado mutável do objeto com o qual ele está trabalhando atualmente. Ele precisa se lembrar dos estados mutáveis de outros 10 a 50 objetos com os quais ele interage! É como fazer malabarismos com 50 bolas de uma só vez. Este estado de coisas também agregou valor. Este é um ótimo exercício para o cérebro.
Erros? Sim - durante o processo de malabarismo, algumas bolas caem. O programador pode perder algumas pequenas coisas relacionadas à interação de 50 objetos. Mas quem, francamente, se importa? Erros de produção devem ser relatados pelos usuários. É assim que grandes organizações sérias funcionam. Em seguida, as mensagens de erro vão para o diário do JIRA (como você entende, é um produto de software de nível corporativo sério). Nem mesmo alguns anos se passarão, e os erros serão corrigidos. O problema está resolvido!
Senhor, como eu amo meu aplicativo de mobile banking. É muito funcional, o banco valoriza meus negócios e cuida dos meus dados pessoais. Erros são apenas possibilidades (me disseram)!
Os chamados programadores "funcionais" não entendem por que isolar o estado e torná-lo imutável. Isso implica as tristes conseqüências de reduzir a complexidade dos programas e, consequentemente, reduzir o número de erros. Se houver menos erros na base de código, isso significa que os programadores terão que resolver menos problemas. As empresas de desenvolvimento não poderão cobrar dos clientes pela correção de bugs. Usando métodos funcionais, os programadores que trabalham em qualquer empresa grande e séria vão ficar mal aos olhos de seus gerentes e, ao mesmo tempo, prejudicarão muito suas chances de carreira.
UmberNúmero de linhas de código
O programador precisa da oportunidade de demonstrar aos gerentes os resultados de seu trabalho, os resultados de avançar em direção à meta. Qual é a maneira mais eficaz de expressar os resultados de um programador? É claro que este é o número de linhas de código que ele escreveu! Se todos mudássemos para a programação funcional, incomodaríamos muito os gerentes e levantaríamos sérias suspeitas sobre a eficácia de nosso trabalho. Uma abordagem "declarativa" leva à escrita de códigos mais concisos. Seu uso reduz bastante o número de linhas de código nos programas. Eu acredito que é completamente inaceitável que, com uma abordagem declarativa, para atingir o mesmo objetivo, seja necessário de 3 a 5 vezes menos código do que quando se usa OOP.
Em outras palavras, na transição para a programação funcional, nossa produtividade literalmente entrará em colapso aos olhos de gerentes corporativos sérios. Isso, por sua vez, colocará nossos empregos em risco. Portanto, é do nosso interesse ficar longe da programação "funcional".
O mesmo conselho se aplica aos contratados que cobram dos clientes com base nas horas trabalhadas. Aqui está uma fórmula simples de sucesso para eles:
__ = ____ = $$$$$$
Essa fórmula de sucesso, é claro, também é diretamente aplicável a empreiteiros sérios que são pagos pelo número de linhas de código:
if (1 == '1') { doStuff(); } else { // }
▍Espaguete é o nosso pão com manteiga
Diferentemente da programação funcional, o OOP oferece uma abordagem consistente para escrever código de espaguete. Isso é extremamente benéfico para a produtividade do desenvolvedor. Escrever um código de espaguete significa passar mais horas escrevendo o código. Este é um benefício direto para qualquer programador sério orientado a objetos. Espaguete não é apenas muito saboroso. Também é um conceito extremamente importante para quem escreve no estilo OOP.
OOP é um presente real para contratados e funcionários de empresas sérias.
Departamento de prevenção de erros
Você não deve ter medo de usar OOP. Repito - erros irritantes são um pouco sobre os quais você não deve se preocupar. Em qualquer organização séria, existe um departamento para prevenção de erros (também chamado de departamento de suporte ao usuário), cuja principal tarefa é proteger os desenvolvedores da empresa contra clientes irritados. No final - se o cliente não puder usar o aplicativo corretamente - isso é culpa dele.
Os desenvolvedores não devem se incomodar com coisas que não são relevantes para seus negócios, como relatórios de erros. Isso ajuda a garantir um estado de coisas no qual os recursos da empresa não são desperdiçados. Como resultado, os desenvolvedores têm a oportunidade de implementar silenciosamente novos recursos de aplicativos e direcionar toda sua atenção para a criação de abstrações orientadas a objetos da classe corporativa e a aplicação de padrões de design complexos.
▍ Processo de relatório de erros
Esse processo cuidadosamente planejado e bem planejado geralmente existe para proteger os recursos humanos das organizações. Assim que o usuário encontra um erro, ele geralmente procura o número de telefone do departamento de suporte ao cliente. Em seguida, o usuário recebe um grande menu de telefone interativo, que inclui várias opções. Geralmente, leva de 2 a 5 minutos para ouvir informações sobre o menu e selecionar a opção desejada. Esta etapa permite filtrar os clientes menos persistentes.
Em seguida, o cliente geralmente é informado de que a empresa se depara com um "volume extraordinariamente grande de chamadas" e que "o tempo médio de espera é de 56 minutos". Ao mesmo tempo, geralmente pedem desculpas ao cliente pelo inconveniente e falam sobre como valorizam ele e seus negócios. Nesta etapa, a maioria dos clientes decide não relatar um erro. Para entreter aqueles que ainda se atrevem a esperar, eles costumam tocar música inspiradora. Além disso, eles são oferecidos para experimentar um novo aplicativo maravilhoso. Este é o aplicativo com o qual o cliente teve um problema.
Após o período de espera de 56 minutos, a chamada é redirecionada para um call center localizado em algum lugar da América do Norte. Os funcionários dessas centrais de atendimento costumam receber treinamento especial que lhes permite falar com um forte sotaque indiano ou búlgaro. O funcionário do call center responde que o aplicativo em questão está fora do escopo de sua responsabilidade, mas ele terá prazer em mudar o cliente para outro departamento.
Após outro período de espera, que agora dura 42 minutos, outro funcionário do call center com notas de felicidade em sua voz diz ao cliente que o erro que ele encontrou é realmente um recurso do aplicativo. Depois disso, o cliente é aconselhado a consultar a seção de ajuda do aplicativo. Se o cliente continuar insistindo que está lidando com um erro, ele poderá criar uma solicitação de suporte. O cliente pode até obter uma resposta - algo no espírito de "A reprodução falhou".
Espero que agora você esteja convencido de que os erros não são o que o programador deve se preocupar. As organizações geralmente tomam medidas sérias para proteger os desenvolvedores contra desperdícios de tempo desnecessários.
Evite "erros para iniciantes" nas entrevistas
Se você está procurando trabalho ativamente - faça algum esforço para remover todas as bobagens "funcionais" do seu currículo. Caso contrário, ninguém o levará a sério. Ninguém no mundo corporativo real gasta tempo estudando brinquedos infantis como "composição de funções", "pureza", "mônadas" ou "imunidade". Você quase não quer ser como alguém de fora. Se você começar a falar sobre essas coisas, a pessoa que está entrevistando ficará desconfortável. E se um representante de uma empresa empregadora em potencial achar que você é mais esperto que ele - suas chances de conseguir um emprego nessa empresa tenderão a zero.
Além disso, especialistas em RH, recrutando pessoal técnico em grandes empresas, recebem treinamento intensivo obrigatório. Isso lhes permite distinguir com confiança entre tecnologias sérias - como Java e JavaScript.
Certifique-se de que seu currículo contenha referências ao que demonstra seu amplo conhecimento em tecnologia, valorizado por grandes empresas. Inclua palavras e frases como "classe", "herança", "padrões de design", "injeção de dependência", "SOLID", "fábrica abstrata" e "singleton".
Quando você é solicitado a resolver o problema do FizzBuzz, geralmente oferecido em entrevistas, em um pedaço de papel, lembre-se da seguinte recomendação, que é a de que você deve estar preparado com antecedência para resolver esse problema. Esta é sua chance de mostrar seu profundo conhecimento nas áreas de programação que são valorizadas no mundo corporativo. Você deve começar com uma solução de rascunho abrangente que envolva o uso de padrões de design e outras técnicas de POO. Um bom ponto de partida para resolver esse problema pode ser o
FizzBuzzEnterpriseEdition . Muitos candidatos cometem o mesmo erro que é típico para iniciantes. Esse erro está no fato de que eles dependem de tecnologias limitadas, como funções. Depois disso, não há nada a surpreender que, após a entrevista, ninguém ligue e escreva para eles.
Provavelmente, a programação funcional não pode ser usada para desenvolver soluções de software sérias.
Tendo considerado os argumentos acima sérios e precisos, agora qualquer um pode ver claramente que nada de bom pode ser esperado com o uso da chamada programação "funcional". É muito claro que essa abordagem de programação deve ser evitada a todo custo.
Muito barulho foi gerado em torno da programação "funcional" nos últimos dois anos. Mas o bom é que esse hobby de curto prazo da comunidade de programadores já está acabando! Grandes players do mercado como o Facebook e a Microsoft há muito tempo percebem as limitações da programação funcional e a superioridade absoluta das abordagens orientadas a objetos para organizar o código sobre ela. Eles direcionam seus esforços para uma nova geração de linguagens orientadas a objetos, em particular - ao
ReasonML e ao
BosqueOOP . Essas linguagens levam a mutabilidade do estado do aplicativo a um nível totalmente novo e, felizmente, elas não suportam bobagens funcionais inúteis, como estruturas de dados imutáveis.
Resumo: presente dos deuses
Aqui você pode ter uma pergunta sobre quais alternativas a chamada programação "funcional" possui. Obviamente, isso é programação orientada a objetos. OOP é enviado a nós pelo verdadeiro deus da programação. OOP é uma força a ser reconhecida. Esta é uma ferramenta capitalizada que torna os programadores produtivos. Graças à OOP, você e sua equipe estarão sempre ocupados com os negócios (e você não perderá o emprego).
Aqui está o meu artigo no qual falo em detalhes sobre OOP.
Que uma força (orientada a objetos) esteja com você. E o seu código. Eu sou um com força. Paz a todos.
Como muitos de vocês já devem ter adivinhado, este é um material satírico. Se você é um programador iniciante, não leve tudo isso a sério.
A programação funcional é ótima. Passe algum tempo explorando esse paradigma de programação e você estará à frente de muitos de seus colegas de equipe.
Espero que você esteja tão interessado em ler isso como eu estava escrevendo.
Caros leitores! O que você não gosta mais em POO?
