O Desenvolvedor Cérebro Grug
Um guia para leigos sobre pensar como alguém auto-consciente de seu cérebro pequeno

Traduzido do original em: The Grug Brained Developer

Introdução

esta coleção de pensamentos sobre desenvolvimento de software reunidos pelo desenvolvedor com cérebro grug

Desenvolvedor com cérebro grug não tão inteligente, mas desenvolvedor cérebro grug programar muitos anos e aprender algumas coisas embora maioria seja confusa

Desenvolvedor cérebro grug tentar coletar aprendizados em página pequena, fácil digestão e engraçada, não apenas para você, jovem grug, mas também ele porque desenvolvedor do cérebro grug envelhece e esquece coisas importantes, como o que comeu café da manhã ou colocar calças

desenvolvedores com cérebro grande são muitos, e alguns não gostar de pensamentos grug, fazer cara feia

muitos, muitos mais os que PENSAR que é cérebro grande, esses mais provavelmente com certeza, fazer muita cara feia (assim é a internet)

(nota: grug uma vez achar que tem cérebro grande, mas aprender da maneira mais difícil)

tudo bem!

é país livre mais ou menos e não importa muito, mas grug esperar você se divertir lendo e talvez aprender com muitos, muitos erros que o grug cometer em longa vida de programador (hah! programador não tem vida)

O Eterno Inimigo: Complexidade

inimigo natural de grug é complexidade

complexidade ruim

diga novamente:

complexidade muito ruim

você diz agora:

complexidade muito, muito ruim

entre complexidade ou mano a mano com t-rex, grug escoher t-rex: pelo menos grug ver t-rex

complexidade é espírito demônio que entrar no código através de desenvolvedores de cérebro não-grug e gerentes de projeto bem intencionados, mas merecedor de porretada, que não temer o espírito demônio complexidade ou nem mesmo saber sobre ele algum dia

um dia código compreensível e grug pode fazer trabalho, de boa!

dia seguinte impossível: espírito demônio da complexidade entrou em código e situação muito perigosa!

grug não ver demônio da complexidade, mas grug sentir sua presença no código

espírito de complexidade demoníaca zombar dele quando fazer mudança aqui e quebrar coisa não relacionada lá, o quê!?! ha ha ha! tão engraçado! grug adorar programar e não virar especulador de pedra brilhante como grug sênior aconselhou! ha ha ha!

porrete não funcionar em espírito demônio da complexidade e má ideia acertar desenvolvedor que deixou espírito entrar: às vezes próprio grug!

infelizmente muitas vezes próprio grug

então grug dizer novamente e dizer sempre: complexidade muito, muito ruim

Dizendo Não

melhor arma contra espírito demônio da complexidade é palavra mágica: “não”

“não, grug não construir essa feature”

“não, grug não construir essa abstração”

“não, grug não colocar água no corpo todo dia nem beber menos suco preto de pensar, parar de repetir isso agora!”

veja, este bom conselho de engenharia, mas conselho de carreira ruim: “sim” palavra mágica para mais pedra brilhante e ficar encarregado de grande tribo de desenvolvedores

triste, mas verdadeiro: aprender “sim” e depois aprender botar culpar noutros grugs quando falhar, conselho de carreira ideal

mas grug ser verdadeiro, e “não” é a palavra mágica do grug. Difícil dizer no começo, especialmente se você grug legal e não gostar de decepcionar pessoas (muitos desses grugs!), mas mais fácil com o tempo, mesmo que pilha de pedras brilhantes não seja tão alta quanto poderia ser

mas de boa: quanto de pedra brilhante grug realmente precisa?

Dizendo ok

às vezes necessário ceder ou nada de pedra brilhante, significar nada de carne de dinossauro, não é bom, a esposa lembra grug de jovens grugs em casa precisar de teto, comida e por aí vai, sem interesse em grug discursando sobre espírito demônio da complexidade pela quinquagésima vez

nesse caso, grug recomenda “ok”

“ok, gug construir esse recurso”

então, grug gastar tempo pensando em solução 80/20 para problema e construir isso.
solução 80/20 diz que solução “80 de pedido para 20 de código” talvez não ter toda firula que gerente de projeto quer, talvez um pouco feio, mas funciona e entrega valor, e afastar espírito de complexidade demoníaca quase sempre

às vezes, provavelmente, melhor não contar gerente de projeto e fazer 80/20. mais fácil pedir desculpa que licença, mente de gerente de projeto como borboleta, muito sobrecarregados e lidar com muitos grugs. muitas vezes esquecer o que mesmo feature deveria fazer ou mudar de projeto ou pedir demissão ou ser demitido
grug ver muito disso

de qualquer forma ser do interesse dos gerentes de projeto de qualquer maneira, então grug não se sentir muito mal por essa abordagem geralmente

Fatorando seu código

próxima estratégia muito mais difícil: quebrar a base do código corretamente (palavra chique: “fatorar seu código corretamente”) aqui é difícil dar conselho geral porque cada sistema tão diferente. no entanto, uma coisa que grug acredita: não fatorar aplicação muito cedo!

no início de projeto tudo muito abstrato e como água: muito pouco suporte sólido para o cérebro em dificuldades do grug se agarrar. reserve um tempo para desenvolver a “forma” do sistema e aprenda o que está fazendo. Grug tentar não fatorar na parte inicial do projeto e então, em algum momento, bons pontos de corte emergir da base de código

bom ponto de corte tem interface estreita com o resto do sistema: pequeno número de funções ou abstrações que escondem o demônio da complexidade internamente, como preso em cristal

Grug bastante satisfeito quando o demônio da complexidade preso corretamente no cristal, melhor sentimento é prender o inimigo mortal!

Grug observar pacientemente enquanto pontos de corte emergem do código e refatorar lentamente, com a base do código tomando forma ao longo do tempo junto com a experiência. nenhuma regra rígida / rápida para isso: o grug sabe o ponto de corte quando o grug vê o ponto de corte, apenas reservar um tempo para desenvolver habilidade em ver, paciência

às vezes o grug vai cedo demais e erra abstrações, então o grug tende a esperar

desenvolvedores de cérebros grandes geralmente não gostam disso e inventar muitas abstrações no início do projeto

grug tentado a pegar o porrete e gritar “cérebro grande, não manter código! cérebro grande, ir para o próximo comitê de arquitetura, deixar código para grug manter!”

mas o grug aprender a controlar paixões, principal diferença entre grug e animal

em vez disso, o grug tentar limitar danos do desenvolvedor do cérebro grande no início do projeto, dando pra ele algo como diagrama UML (não prejudicar código, provavelmente jogar fora de qualquer maneira) ou exigir demo funcionando para amanhã

demo ser truque especialmente bom: forçar grande cérebro a fazer algo realmente funcionar para falar e, ajudar o cérebro grande a ver realidade mais rapidamente

lembrar! cérebro grande tem cérebro grande! só precisa ser usado para o bem e não a serviço do espírito demônio da complexidade por acidente, muitas vezes visto

(melhores cérebros grug capaz de reunir vários cérebros grandes na direção certa e produzir muitos cristais complexos armadilhas de demônio. grande pilha de pedra brilhante aguarda tal grug!)

às vezes também chamar a abordagem de demonstração de “protótipo”, soa mais chique para gerente de projeto

grug diz protótipo no início da fabricação de software, especialmente se muitos cérebro grande

Testes

grug ter relacionamento de amor/ódio com teste: teste salvar grug muitas, muitas incontáveis vezes e grug ter amor e respeito por teste

infelizmente também existir muitos xamãs de teste. alguns xamãs de teste faz ídolo de teste, exigir coisas como “testar primeiro” antes mesmo de grug escrever código ou ter alguma idéia do que grug está fazendo!

como grug testar se grug nem entender domínio ainda!?

“Ah, não se preocupe: os testes mostrarão o que você precisa fazer.”

grug mais uma vez se pegar lentamente alcançando o porrete, mas grug manter calma

grug preferir escrever maioria dos testes após fase de protótipo, quando o código já começou a se firmar

mas, note bem: o grug aqui deve ser muito disciplinado!

grug fácil de seguir em frente e não escrever testes porque “funciona na máquina de grugs”!

isso muito, muito ruim: sem garantia de funcionar outra máquina e sem garantia de funcionar na máquina grug no futuro, muitas vezes

O xamã de teste tem um bom ponto sobre a importância do teste, mesmo que o xamã de teste muitas vezes não terminar nenhuma feature na vida e falar apenas sobre teste o tempo todo, merece porretada, mas tem boa intenção

também, o xamã de teste costuma falar muito sobre o teste unitário, mas grug não acha tão útil. experiência do grug de que os testes ideais não são testes unitários ou de ponta a ponta, mas testes intermediários

teste unitário bom, ok, mas quebrar com mudança de implementação e tornar refatoração difícil e, francamente, ter muitos bugs de qualquer maneira, muitas vezes por interação com outro código. muitas vezes jogar fora quando código muda.

grug escrever teste de unidade principalmente no início do projeto, ajuda a fazer as coisas, mas não se apegar demais ou espera valor por muito tempo

testes de ponta a ponta bons, mostram todo o trabalho do sistema, mas! difícil de entender quando quebra e enlouquece o grug com muita frequência, às vezes os grugs acabam ignorando porque “oh, isso quebra o tempo todo” muito ruim!

testes intermediários, grug ouve o xamã chamar isso “testes de integração” às vezes, muitas vezes de cara feia. mas o grug dizer teste de integração ser ponto ideal de acordo com o grug: nível alto o suficiente para testar sistema está correto, nível baixo o suficiente, com bom debugger, fácil de ver o que quebra

O grug prefere alguns testes de unidade, especialmente no início, mas não 100% em todos os testes de código e definitivamente não no “primeiro teste”. “testar ao longo do caminho” funciona muito bem para o grug, especialmente enquanto o grug descobre as coisas

grug foca muito esforço de teste de integração à medida que ponto de corte emerge e o sistema se estabiliza! api de ponto de corte estável comparada a implementação e teste de integração permanecer valiosos por muito tempo e depuração fácil

também pequeno e bem organizado conjunto de testes de ponta a ponta é criado para ser mantido funcionando religiosamente sob pena de porretada. importante focar teste de ponta a ponta nos recursos de interface do usuário mais comuns e poucos casos de borda mais importantes, mas não muitos ou ficar impossíveis de manter e depois ignorados

este conjunto ideal de teste para grug

você pode não gostar, mas este ser o melhor para grug

além disso, grug não gosta de mock em teste, prefere apenas quando absolutamente necessário (raro/nunca) e apenas mocks grandes de pontos de corte/sistemas

uma exceção a grug não gostar de “primeiro teste”: quando bug é encontrado. grug sempre tentar primeiro reproduzir bug com teste de regressão e depois corrigir bug, apenas neste caso por algum motivo funcionar melhor

Ágil

grug pensar que ágil não é terrível, nem é bom

fim do dia, não é pior maneira de organizar desenvolvimento, talvez melhor que outros, o grug supõe que tudo bem

perigo, porém, é xamã ágil! muita, muita pedra brilhante perdida para xamã ágil!

sempre que projeto ágil falha, xamã ágil diz “você não fez ágil certo!” grug percebe isso muito conveniente para xamã ágil, pedir mais pedra brilhante para treinar jovens grugs em ágil melhor, perigo!

grug tentado pegar porrete quando muita conversa ágil acontece, mas sempre ficar calmo

prototipagem, ferramentas e contratação de bons grugs melhor chave para o sucesso do software: processo ágil ok e ajuda alguns, mas às vezes prejudica levado muito a sério

grug diz que nenhum porrete de prata corrige todos os problemas de software, não importar o que xamã ágil diga (perigo!)

Reestruturação

refatoração uma boa atividade e muitas vezes boa ideia, especialmente mais tarde no projeto, quando o código foi consolidado

no entanto, grug observa que muitas vezes na carreira “refatorações” saem de controle e acabam causando mais mal do que bem

o grug não sabe exatamente por que algumas refatorações funcionam bem, algumas falham, mas grug percebe que refatoração maior, mais provável falha, parece ser

portanto, tentar manter refatorações relativamente pequenas e não “afastar muito da margem” durante a refatoração. idealmente sistema funciona o tempo todo e cada etapa acaba antes de outra começar.

testes ponta a ponta são mao na roda aqui, mas muitas vezes é muito difícil entender por que quebrou… assim é a vida do refatoramento.

também observar que introdução de muita abstração geralmente leva à falha de refatoração e falha do sistema. bom exemplo foi a introdução de J2EE , muitos cérebros grandes ficam pensando em muita abstração, nada de bom veio disso, muitos projetos sofrer

outro bom exemplo quando a empresa que grug trabalhou introduziu o OSGi para ajudar a gerenciar/aprisionar o espírito demônio da complexidade na base de código. não apenas OSGi não ajudar, mas tornar demônio da complexidade muito mais poderoso! levar vários anos dos melhores desenvolvedores para implementar e também para jogar fora! espírito mais complexo e agora apresenta implementação impossível! muito mal!

Cerca de Chesterton

o sábio grug xamã chesterton disse uma vez

aqui existe em tal caso uma determinada instituição ou lei; digamos, por uma questão de simplicidade, uma cerca ou portão erguido em uma estrada. O tipo mais moderno de reformador caminha alegremente até ele e diz: “Não vejo utilidade nisso; vamos remove-lo.” Ao que o tipo mais inteligente de reformador fará bem em responder: “Se você não vê a utilidade disso, certamente não vou deixar você remove-lo. Vá embora e pense. Então, quando você puder voltar e me dizer que você vê o uso dele, eu posso permitir que você o destrua.”

muitos grugs mais velhos aprendem bem essa lição, não sair apagando código à toa, não importa o quão feio pareça

grug entende todos programadores ser platonistas em algum nível e desejar perfeição da música das esferas no código. mas o perigo está aqui, o mundo é feio e grotesco muitas vezes e o código também ser

humildade nem sempre vem facilmente com cérebro grande ou que pensa que é cérebro grande ou até mesmo grug, mas grug muitas vezes encontra “ah, grug não gosta de olhar para isso, grug conserta” leva muitas horas de dor a grug e depois sistema nem melhor nem pior

grug no início da carreira muitas vezes se atirar no código sacudindo porrete sem controle e quebrar tudo, aprender que não é bom

grug não diz não melhorar o sistema nunca, bastante tolo, mas recomendar levar um tempo para entender sistema primeiro, especialmente sistema grande e respeitar o código que funciona hoje, mesmo que não perfeito

aqui testes muitas vezes ser boa dica de porque a cerca não deve ser esmagada!

Microsserviços

Grug se pergunta por que o cérebro grande pega o problema mais difícil, fatorar sistema corretamente e bota uma chamada de rede no meio

parece muito confuso para grug

Ferramentas

grug ama ferramenta. ferramenta e controle da paixão é o que separar grug dos dinossauros! ferramenta permite que o cérebro grug crie código que não seria possível de outra forma, pensando pelo grug! que alívio! grug sempre gasta tempo em um novo lugar aprendendo ferramentas ao seu redor para maximizar produtividade: aprender ferramentas por duas semanas tornar o desenvolvimento muitas vezes duas vezes mais rápido e muitas vezes procure por ajuda de outros desenvolvedores, sem documentos

completar código no IDE faz grug não ter que lembrar de todas as APIs, muito importante!

programação java quase impossível sem ele para grug!

realmente fazer grug pensar algum tempo

bom depurador vale o peso em pedras brilhantes, até mais: quando confrontado com bug grug, muitas vezes trocaria toda a pedra brilhante e talvez alguns filhos por um bom debugger e, também, o debugger não pesa nada, até onde grug sabe

grug sempre recomenda que o novo programador aprenda o debugger disponível muito profundamente, recursos como pontos de interrupção condicionais, avaliação de expressão, navegação na pilha, etc.

grug diz nunca estar não melhorando o ferramental

Sistemas de Tipos

grug gosta muito sistemas de tipos que tornam a programação mais fácil. para grug, sistemas de tipo têm valor quando grug digita ponto no teclado e lista de coisas que grug pode fazer abre feito mágica. para grug isso 90% ou mais do valor do sistema de tipos.

O xamã de sistema de tipo de cérebro grande costuma dizer ponto mais importante de sistema de tipo de ponto ser correção de tipo, mas grug vê que um xamã de sistema de tipo de cérebro grande não costuma comitar código. grug supõe que o código nunca comitado esteja correto, em certo sentido, mas não realmente o que o grug quer dizer quando diz correto

grug diz ferramenta mágica pop-up do que pode fazer e completar código o maior benefício do sistema de tipos, a correção também é boa, mas nem tanto

também, muitas vezes, às vezes, cuidado, cuidado com os grandes cérebros aqui!

algum tipo de cérebro grande pensa em sistemas de tipos e fala em teoremas, perigo potencial!

perigo de abstração muito alta, código de cérebro grande do sistema de tipo se torna projeção astral do modelo turing genérico platônico de computação na base do código. grug confuso e concorda em algum nível muito elegante, mas também muito difícil fazer algo como registrar no estoque a quantidade de porretes da Grug Ltda. que é tarefa atual

generics especialmente perigoso aqui, o grug tenta limitar os generics às classes de contêiner na maior parte onde a maior parte do valor agrega

genéricos tentação muito grande é truque! espírito demônio da complexidade adora este truque! cuidado!

sempre a maioria do valor dos sistemas de tipo: aperte ponto veja o que o grug pode fazer, nunca esqueça!

Complexidade de Expressão

grug uma vez gostaria de minimizar as linhas de código tanto quanto possível. escreva o código assim:

  if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGroup(FRIENDS))) {
    // ...
  }

com o tempo, o grug aprende essa depuração difícil, aprende prefere escrever assim:

  if(contact) {
    var contactIsInactive = !contact.isActive();
    var contactIsFamilyOrFriends = contact.inGroup(FAMILY) || contact.inGroup(FRIENDS);
    if(contactIsInactive && contactIsFamilyOrFriends) {
        // ...
    }
  }

grug ouve gritos de jovens grugs com horror de muitas linhas de código e variáveis inúteis e grug se prepara para se defender com porrete

briga de porrete começa com desenvovedores atancandpo e grug grita: “debug mais fácil! ver resultado de cada expressão com mais clareza e bom nome! mais fácil entender expressão condicional! DEBUG MAIS FÁCIL!”

depuração definitivamente mais fácil e uma vez que a luta de porrete se acalma e o jovem grug pensa um pouco, eles percebem grug certo

grug ainda pega código escrito por grug como o primeiro exemplo e muitas vezes se arrepende, então grug não julga o jovem grug

DRY

DRY significa Don’t Repeat Self, máxima poderosa na mente da maioria dos desenvolvedores

grug respeita DRY e bons conselhos, porém grug recomenda equilíbrio em todas as coisas, como grug do maior cérebro aristóteles recomenda

grug percebe que gráfico humorístico de Lea Verou corresponde com paixão de grug de não repetir:

preocupação com código ao longo do tempo

ao longo do tempo passado dez anos de programação grug não se preocupa tanto com código repetido. contanto código repetido é simples o suficiente e óbvio o suficiente, grug sente que repetir/copiar e colar o código com pequena variação é melhor do que muitos callbacks e closures ou modelo de objetos elaborado: muito complexo para pouco benefício às vezes

equilíbrio difícil aqui, repetir código sempre ainda faz grug olhar e dizer “mmm” com frequência, mas experiência mostra o código de repetição às vezes melhor que solução DRY complexa

veja bem! grug incentiva o desenvolvedor que leva tudo ao pé da letra a não levar a linha de “será que funciona” muito a sério, é piada

Separation of Concerns (SoC)

Separation of Concerns (SoC) outra ideia poderosa na mente de muitos desenvolvedores, ideia de separar diferentes aspectos do sistema em seções distintas de código

exemplo canônico do desenvolvimento web: separação de estilo (arquivo css), marcação (arquivo html) e lógica (arquivo javascript)

aqui grug faz cara muito mais feia do que para DRY e de fato escrever ensaio de cérebro grande sobre a localidade de comportamento (LoB) princípio alternativo de design contra o SoC

grug acha mais melhor colocar código na coisa que faz a coisa. daí quando grug olha a coisa grug sabe a coisa que a coisa faz, de boa!

se tudo separado, grug tem muitas vezes chafurdar muitos arquivos para entender o que o botão faz, muita confusão e perda de tempo: ruim!

Closures

grug gosta de closures para o trabalho certo e esse trabalho geralmente abstrair operação sobre coleção de objetos

grug adverte que closures como sal, sistemas de tipos e generics: pequena quantidade muito gostoso, mas fácil estraga as coisas muito uso dá ataque cardíaco

desenvolvedores javascript chamam espírito demônio de complexidade muito especial em javascript “callback hell” porque muito closure usado por bibliotecas de javascript. muito triste, mas desenvolvedor de javascript tem o que merece, grug manda real.

Logging

grug é grande fã de logs e incentiva muito isso, especialmente na nuvem implantada. alguns não-grugs dizem que o registro é caro e não é importante. grug costumava pensar assim não mais

história engraçada: grug descobre que ídolo rob pike trabalhando em log no google e decide: “se rob pike trabalhando em log, que grug faz lá?!?” então não persiste. Só que log muito importante para o google, então é claro que melhor programador trabalha nisso, grug!

não seja tão cérebro grug, grug! muito menos pedra brilhante agora!

tudo bem, grug acabar em boa empresa de qualquer maneira e jeito de vestir de rob pike cada vez mais esquisito, então tudo bem no final, mas o ponto é: log muito importante!

As dicas do grug sobre o log são:

logar todas as principais ramificações lógicas dentro do código (if/for)
se a “solicitação” abranger várias máquinas na infraestrutura de nuvem, inclua o ID da solicitação em todas para que os logs possam ser agrupados
se possível, faça com que o nível de log seja controlado dinamicamente, para que o grug possa ligar/desligar quando precisar achar bug (muitos!)
se possível, faça o nível de log por usuário, para que possa depurar um problema específico do usuário

os dois últimos pontos são especialmente úteis para combater bugs em sistemas de produção com muita frequência

infelizmente, as bibliotecas de log geralmente são muito complexas (java, por que você faz isso? )

o logging precisa ser ensinado mais nas escolas, pensa grug

Concorrência

Grug, como todo desenvolvedor sensato, teme a concorrência

tanto quanto possível, o grug tenta confiar em modelos de concorrência simples, como stateless web request handlers e filas de job remotas simples, onde os jobs não interdependem e api simples

concorrência otimista parece funcionar bem para coisas da web

ocasionalmente, o grug usa variável thread local , geralmente ao escrever código de framework

algumas linguagem tem boa estrutura de dados concorrente, como java ConcurrentHashMap , mas ainda precisa de um trabalho cuidadoso de grug para acertar

grug nunca usou erlang , ouve coisas boas, mas linguagem parece estranha para grug desculpe

Otimização

desenvolvedor ultra maior do cérebro grande uma vez dizer:

otimização prematura é a raiz de todo o mal

isso todo mundo quase sabe e grug está em acordo com o ultra maior do cérebro grande

grug recomenda sempre ter um profile de desempenho concreto e real mostrando um problema específico de desempenho antes de começar a otimizar.

nunca se sabe qual pode ser o problema real, grug muitas vezes surpresa! muitas vezes!

cuidado apenas com o foco na cpu: fácil de ver cpu e muito pensar em notação big O foi feito na escola, mas muitas vezes não é a raiz de toda lentidão, surpresa para muitos, incluindo o grug

usar rede é equivalente a muitos, muitos milhões de ciclos de CPU e sempre a ser minimizado, se possível. entendeu, desenvolvedor de microsserviços com cérebro grande?

desenvolvedor inexperiente com cérebro grande vê loop aninhado e muitas vezes diz “O(n^2)? No meu código não!”

espírito demônio da complexidade sorri

API

grug ama boas apis. boas apis não fazem grug pensar muito

infelizmente, muitas apis são muito ruins, fazem grug pensar bastante. isso acontece por muitas razões, aqui duas:

Os criadores de API pensam em termos de implementação ou domínio da API, e não em termos de uso da API
Os criadores de API pensam muito abstrato e tem cérebro grande

geralmente grug não se importa muito com detalhes da API: quer escrever arquivo ou ordenar lista de classificação ou qualquer outra coisa, só quer chamar write() ou sort() simples

mas desenvolvedores de APIs de cérebro grande dizer:

“peraí, grug! esse arquivo está aberto para escrita ? você definiu um Comparator para essa ordenação?”

grug sente a mão agarrar porrete de novo

não me importo com essas coisas agora, só quero classificar e escrever o arquivo, senhor cérebro grande!

grug reconhece que designer de APIs de cérebro grande ter alguma razão e que às vezes essas coisas importam, mas muitas vezes não. melhor desenvolvedores de API de cérebro grande projetar para casos simples com api simples, possibilitar casos complexos com api mais complexa

o grug chama isso de apis em “camadas”: duas ou três apis diferentes em diferentes níveis de complexidade para várias necessidades do grug

também, se orientado a objetos, coloque api na coisa em vez de em outro lugar. java pior nisso!

grug quer filtrar lista em java

“Você converteu em um stream?”

tudo bem, grug converter para stream

“OK, agora você pode filtrar.”

OK, mas agora precisa retornar lista! tem fluxo!

“Tá, você coletou seu stream em uma lista?”

que?

“Defina um Collector<? super T, A, R> para coletar seu stream em uma lista”

grug jura pelo túmulo dos ancestrais que descer porretada em todas as pessoas na sala, mas conta até dois em vez disso e acalma

coloque coisas comuns como filter() na lista e faça retornar lista, ouça bem desenvolvedor de java api do cérebro grande!

ninguém se importa com “stream” ou mesmo ouvir falar de “stream”, não é api de rede, todos os grugs java usam lista senhor cérebro grande!

Parsing

grug adora criar linguagem de programação e dizer descida recursiva maneira mais divertida e bonita criar parser

infelizmente, muitas escolas de cérebro grande ensinam apenas a ferramenta geradora de parser. aqui amor usual de grug por ferramenta não tem: ferramenta geradora de parser gerar código de ninho de rato horrível: impossível entender, de baixo para cima, o quê? esconder a natureza recursiva da gramática do grug e depurar impossível, muito ruim para grug!

grug acha isso porque o demônio da complexidade muito ruim para código e entendimento, mas demônio da complexidade muito bom para gerar muitos trabalhos acadêmicos, é triste mas verdade

analisador de produção quase sempre recursivo descendente, apesar de ignorado pelas escolas! Grug furioso ao saber como parsing é simples! parsing não é magia apens para cérebro grande: você também pode!

grug muito eufórico encontra o desenvolvedor do cérebro grande Bob Nystrom redimir a tribo do big brain e escreve um excelente livro sobre parser recursivo descendente: Crafting Interpreters

livro disponível on-line gratuitamente, mas o grug recomendo fortemente que todos os grugs interessados compre o livro por questão de princípio, fornece muitos conselhos de cérebro grande e o grug adora livro, exceto o padrão Visitor (armadilha!)

O padrão Visitor

mau

Desenvolvimento Front-End

alguns não-grugs, quando confrontados com o desenvolvimento web dizem:

“Eu sei, vou dividir minha base de código em front-end e back-end e usar uma biblioteca SPA novinha da moda pra conversar com um back-end GraphQL JSON API em HTTP (o que é engraçado porque não estou transferindo hipertexto)”

agora você tem dois covis de espírito demônio de complexidade

e, o que é pior, o espírito demoníaco da complexidade do front-end é ainda mais poderoso e tem uma profunda influência espiritual em toda a indústria de front-end, na opinião de grug

desenvolvedores de back-end tentam manter as coisas simples e funcionar direito, mas os desenvolvedores de front-end tornam muito complexo muito rapidamente e introduzem muito código, espírito demoníaco da complexidade

mesmo quando o site só precisa colocar o formulário no banco de dados ou site informativo simples!

todos fazer isso agora!

grug não saber por que, exceto talvez o facebook e o google digam isso, mas isso não parece muito bom motivo para grug

grug não gosta grandes bibliotecas de front-end complexas que todos usam

grug construir htmx e hyperscript para evitar

manter complexidade baixa, HTML simples, evitar muito javascript, o éter natural do espírito demônio da complexidade

talvez funcionem para você, mas nenhum anúncio de emprego, desculpe

react melhor para emprego e também para alguns tipo de aplicação, mas também você se torna o seguidor do demônio da complexidade, quer você goste ou não, desculpe, essa é a vida do front-end

Modas

grug nota muitos modismos no desenvolvimento, especialmente o desenvolvimento de front-end hoje

back-end melhor mais chato porque já tentar todas as más ideias dias de hoje (mas ainda tentar novamente!)

ainda tentando todas as más ideias no desenvolvimento de front-end, ainda há muitas mudanças e é difícil saber

grug recomenda adotar toda nova abordagem revolucionária com cuidado: cérebros grandes trabalham há muito tempo em computadores agora, a maioria das ideias já tentou pelo menos uma vez

grug não dizendo que não pode aprender novos truques ou nenhuma boa ideia nova, mas também muito tempo desperdiçado com ideias ruins recicladas, muito poder do espírito demônio de complexidade vem de colocar uma nova ideia na base de código

Medo de Parecer Burro

Nota! muito bom se grug sênior disposto a dizer publicamente: “hmmm, isso é muito complexo para grug”!

muitos desenvolvedores ter Medo de Parecer Burro (MPB), grug também uma vez ter MPB, mas o grug aprende a superar: o grug sênior muito importante diz “isso é muito complicado e me confunde”

isso torna ok para grugs juniores admitirem muito complexo e não entenderem bem, muitas vezes esse caso! MPB ser grande fonte de poder demoníaco de complexidade sobre o desenvolvedor, especialmente os jovens grugs!

tire o poder do MPB, muito bom do grug sênior!

nota: importante fazer cara de pensamento e parecer cérebro grande ao dizer não entender. para para cérebro grande ou, pior e muito mais comum, o que ACHA que é cérebro grande fazer comentários sarcásticos sobre grug

seja forte! abaixo MPB!

porrete às vezes útil aqui, mas mais frequentemente senso de humor e especialmente o último projeto fracassado do cérebro grande muito útil, então segurar onda e ficar calmo

Síndrome do Impostor

grug ter muitos desses sentimento de impostor em desenvolvimento

sempre grug em um de dois estados: grug é o senhor de toda região, empunha porrete de código como thor OU grug não ter ideia do que fazer

grug estar principalmente o último estado na maioria das vezes, esconder muito bem

agora, grug faz software muito trabalhoso e sucesso moderado de código aberto , e ainda assim, próprio grug muitas vezes não ter nenhuma idéia do que fazer! muitas vezes! grug ainda ter medo cometer erros quebrar o código de todos e decepcionar outros grugs, impostor!

talvez seja a natureza da programação para a maioria dos grugs se sentir impostor e melhor ficar bem: ninguém impostor se todo mundo impostor

qualquer jovem grug que leu até aqui provavelmente vai dar bom na carreira de programar, mesmo que frustração e preocupação sempre esteja lá, desculpe

Pra ler

grug gosta desses:

Conclusão

você diz: complexidade muito , muito ruim

O Desenvolvedor Cérebro Grug Um guia para leigos sobre pensar como alguém auto-consciente de seu cérebro pequeno