-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.html
More file actions
750 lines (711 loc) · 47.4 KB
/
Copy pathindex.html
File metadata and controls
750 lines (711 loc) · 47.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
<!DOCTYPE html>
<html lang="pt">
<head>
<title>grug</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style type="text/css">
body {
margin: 40px auto;
max-width: 768px;
line-height: 1.6;
font-size: 20px;
color: #444;
padding: 0 10px;
}
pre {
font-size: 16px;
}
h1,
h2,
h3 {
line-height: 1.2
}
a:link {
text-decoration: none;
}
a:visited {
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
h1 a {
color: #444;
}
h2 a {
color: #444;
}
</style>
</head>
<body>
<div>
<a href="https://www.redbubble.com/i/sticker/Programmer-Grug-by-colossalbreaker/42915272.EJUG5">
<img alt="grug" src="https://grugbrain.dev/grug.png"
style="float: left; height: 120px; margin-right: 20px; clear: both">
</a>
<h1>
O Desenvolvedor Cérebro Grug
<br>
<small>Um guia para leigos sobre pensar como alguém auto-consciente de seu cérebro pequeno</small>
</h1>
<small>Traduzido do original em: <a href="https://grugbrain.dev">The Grug Brained Developer</a></small>
<h1 id="introdu%C3%A7%C3%A3o">Introdução</h1>
<p>esta coleção de pensamentos sobre desenvolvimento de software reunidos pelo desenvolvedor com
cérebro grug</p>
<p>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</p>
<p>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</p>
<p>desenvolvedores com cérebro grande são muitos, e alguns não gostar de pensamentos grug, fazer
cara
feia</p>
<p>muitos, muitos mais os que <em>PENSAR</em> que é cérebro grande, esses mais provavelmente com
certeza,
fazer muita cara feia (assim é a internet)</p>
<p>(nota: grug uma vez achar que tem cérebro grande, mas aprender da maneira mais difícil)</p>
<p>tudo bem!</p>
<p>é 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)</p>
<h1>
<a id="o-eterno-inimigo-complexidade"></a>
<a href="#o-eterno-inimigo-complexidade">
O Eterno Inimigo: Complexidade
</a>
</h1>
<p>inimigo natural de grug é complexidade</p>
<p>complexidade ruim</p>
<p>diga novamente:</p>
<p>complexidade <em>muito</em> ruim</p>
<p><em>você</em> diz agora:</p>
<p>complexidade <em>muito</em>, <em>muito</em> ruim</p>
<p>entre complexidade ou mano a mano com t-rex, grug escoher t-rex: pelo menos grug ver t-rex</p>
<p>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</p>
<p>um dia código compreensível e grug pode fazer trabalho, de boa!</p>
<p>dia seguinte impossível: espírito demônio da complexidade entrou em código e
situação muito perigosa!</p>
<p>grug não ver demônio da complexidade, mas grug sentir sua presença no código</p>
<p>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!</p>
<p>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!</p>
<p>infelizmente muitas vezes próprio grug</p>
<p>então grug dizer novamente e dizer sempre: complexidade <em>muito</em>, <em>muito</em> ruim</p>
<h2>
<a id="dizendo-nao"></a>
<a href="#dizendo-nao">
Dizendo Não
</a>
</h2>
<p>melhor arma contra espírito demônio da complexidade é palavra mágica:
“não”</p>
<p>“não, grug não construir essa feature”</p>
<p>“não, grug não construir essa abstração”</p>
<p>“não, grug não colocar água no corpo todo dia nem beber menos suco preto de pensar,
parar
de repetir isso agora!”</p>
<p>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</p>
<p>triste, mas verdadeiro: aprender “sim” e depois aprender botar culpar noutros grugs quando
falhar,
conselho de carreira ideal</p>
<p>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</p>
<p>mas de boa: quanto de pedra brilhante grug realmente precisa?</p>
<h2>
<a id="dizendo-ok"></a>
<a href="#dizendo-ok">
Dizendo ok
</a>
</h2>
<p>à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</p>
<p>nesse caso, grug recomenda “ok”</p>
<p>“ok, gug construir esse recurso”</p>
<p>então, grug gastar tempo pensando em <a
href="https://en.wikipedia.org/wiki/Pareto_principle">solução 80/20</a> para problema e construir
isso.<br>
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</p>
<p>à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<br>
grug ver muito disso</p>
<p>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</p>
<h2>
<a id="fatorando-seu-codigo"></a>
<a href="#fatorando-seu-codigo">
Fatorando seu código
</a>
</h2>
<p>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!</p>
<p>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</p>
<p>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</p>
<p>Grug bastante satisfeito quando o demônio da complexidade preso corretamente no cristal, melhor
sentimento
é prender o inimigo mortal!</p>
<p>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</p>
<p>às vezes o grug vai cedo demais e erra abstrações, então o grug tende a esperar</p>
<p>desenvolvedores de cérebros grandes geralmente não gostam disso e inventar muitas
abstrações
no início do projeto</p>
<p>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!”</p>
<p>mas o grug aprender a controlar paixões, principal diferença entre grug e animal</p>
<p>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ã</p>
<p>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</p>
<p>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</p>
<p>(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!)
</p>
<p>às vezes também chamar a abordagem de demonstração de “protótipo”, soa
mais chique para gerente de projeto</p>
<p>grug diz protótipo no início da fabricação de software, <em>especialmente</em> se muitos
cérebro grande</p>
<h1>
<a id="grug-on-testing"></a>
<a href="#grug-on-testing">
Testes
</a>
</h1>
<p>grug ter relacionamento de amor/ódio com teste: teste salvar grug muitas, muitas incontáveis vezes
e
grug ter amor e respeito por teste</p>
<p>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!</p>
<p>como grug testar se grug nem entender domínio ainda!?</p>
<p>“Ah, não se preocupe: os testes mostrarão o que você precisa fazer.”</p>
<p>grug mais uma vez se pegar lentamente alcançando o porrete, mas grug manter calma</p>
<p>grug preferir escrever maioria dos testes após fase de protótipo, quando o código já
começou a se firmar</p>
<p>mas, note bem: o grug aqui deve ser muito disciplinado!</p>
<p>grug fácil de seguir em frente e não escrever testes porque “funciona na máquina de
grugs”!</p>
<p>isso muito, muito ruim: sem garantia de funcionar outra máquina e sem garantia de funcionar na
máquina
grug no futuro, muitas vezes</p>
<p>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</p>
<p>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</p>
<p><a href="https://en.wikipedia.org/wiki/Unit_testing">teste unitário</a> 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.</p>
<p>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</p>
<p><a href="https://smartbear.com/solutions/end-to-end-testing/">testes de ponta a ponta</a> 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!</p>
<p>testes intermediários, grug ouve o xamã chamar isso <a
href="https://en.wikipedia.org/wiki/Integration_testing">“testes de integração”</a>
à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</p>
<p>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</p>
<p>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</p>
<p>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</p>
<p>este conjunto ideal de teste para grug</p>
<p>você pode não gostar, mas este ser o melhor para grug</p>
<p>além disso, grug não gosta de <a href="https://en.wikipedia.org/wiki/Mock_object">mock</a> em
teste,
prefere apenas quando absolutamente necessário (raro/nunca) e apenas mocks grandes de pontos de
corte/sistemas</p>
<p>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 <em>depois</em> corrigir bug, apenas
neste caso por algum motivo funcionar melhor</p>
<h2 id="agil">Ágil</h2>
<p>grug pensar que ágil não é terrível, nem é bom</p>
<p>fim do dia, não é pior maneira de organizar desenvolvimento, talvez melhor que outros, o grug
supõe que tudo bem</p>
<p>perigo, porém, é xamã ágil! muita, muita pedra brilhante perdida para xamã
ágil!
</p>
<p>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!</p>
<p>grug tentado pegar porrete quando muita conversa ágil acontece, mas sempre ficar calmo</p>
<p>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</p>
<p>grug diz que <a href="https://en.wikipedia.org/wiki/No_Silver_Bullet">nenhum porrete de prata</a> corrige
todos
os problemas de software, não importar o que xamã ágil diga (perigo!)</p>
<h2 id="reestrutura%C3%A7%C3%A3o">Reestruturação</h2>
<p>refatoração uma boa atividade e muitas vezes boa ideia, especialmente mais tarde no projeto, quando
o
código foi consolidado</p>
<p>no entanto, grug observa que muitas vezes na carreira “refatorações” saem de controle
e
acabam causando mais mal do que bem</p>
<p>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</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
<p>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!</p>
<h2 id="cerca-de-chesterton">Cerca de Chesterton</h2>
<p>o sábio grug xamã <a href="https://pt.wikipedia.org/wiki/G._K._Chesterton">chesterton</a> disse uma
vez
</p>
<blockquote>
<p>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.”
</p>
</blockquote>
<p>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</p>
<p>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</p>
<p>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</p>
<p>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</p>
<p>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</p>
<p>aqui testes muitas vezes ser boa dica de porque a cerca não deve ser esmagada!</p>
<h2 id="microsservi%C3%A7os">Microsserviços</h2>
<p>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</p>
<p>parece muito confuso para grug</p>
<h2 id="ferramentas">Ferramentas</h2>
<p>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</p>
<p>completar código no IDE faz grug não ter que lembrar de todas as APIs, muito importante!</p>
<p>programação java quase impossível sem ele para grug!</p>
<p>realmente fazer grug pensar algum tempo</p>
<p>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</p>
<p>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.</p>
<p>grug diz nunca estar não melhorando o ferramental</p>
<h2 id="sistemas-de-tipos">Sistemas de Tipos</h2>
<p>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.</p>
<p>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</p>
<p>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</p>
<p>também, muitas vezes, às vezes, cuidado, cuidado com os grandes cérebros aqui!</p>
<p>algum tipo de cérebro grande pensa em sistemas de tipos e fala em teoremas, perigo potencial!</p>
<p>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</p>
<p>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</p>
<p>genéricos tentação muito grande é truque! espírito demônio da complexidade
adora
este truque! cuidado!</p>
<p>sempre a maioria do valor dos sistemas de tipo: aperte ponto veja o que o grug pode fazer, nunca
esqueça!
</p>
<h2 id="complexidade-de-express%C3%A3o">Complexidade de Expressão</h2>
<p>grug uma vez gostaria de minimizar as linhas de código tanto quanto possível. escreva o código
assim:</p>
<pre data-role="codeBlock" data-info="java" class="language-java"> <span class="token keyword keyword-if">if</span><span class="token punctuation">(</span>contact <span class="token operator">&&</span> <span class="token operator">!</span>contact<span class="token punctuation">.</span><span class="token function">isActive</span><span class="token punctuation">(</span><span class="token punctuation">)</span> <span class="token operator">&&</span> <span class="token punctuation">(</span>contact<span class="token punctuation">.</span><span class="token function">inGroup</span><span class="token punctuation">(</span>FAMILY<span class="token punctuation">)</span> <span class="token operator">||</span> contact<span class="token punctuation">.</span><span class="token function">inGroup</span><span class="token punctuation">(</span>FRIENDS<span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
<span class="token comment">// ...</span>
<span class="token punctuation">}</span>
</pre>
<p>com o tempo, o grug aprende essa depuração difícil, aprende prefere escrever assim:</p>
<pre data-role="codeBlock" data-info="java" class="language-java"> <span class="token keyword keyword-if">if</span><span class="token punctuation">(</span>contact<span class="token punctuation">)</span> <span class="token punctuation">{</span>
<span class="token keyword keyword-var">var</span> contactIsInactive <span class="token operator">=</span> <span class="token operator">!</span>contact<span class="token punctuation">.</span><span class="token function">isActive</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
<span class="token keyword keyword-var">var</span> contactIsFamilyOrFriends <span class="token operator">=</span> contact<span class="token punctuation">.</span><span class="token function">inGroup</span><span class="token punctuation">(</span>FAMILY<span class="token punctuation">)</span> <span class="token operator">||</span> contact<span class="token punctuation">.</span><span class="token function">inGroup</span><span class="token punctuation">(</span>FRIENDS<span class="token punctuation">)</span><span class="token punctuation">;</span>
<span class="token keyword keyword-if">if</span><span class="token punctuation">(</span>contactIsInactive <span class="token operator">&&</span> contactIsFamilyOrFriends<span class="token punctuation">)</span> <span class="token punctuation">{</span>
<span class="token comment">// ...</span>
<span class="token punctuation">}</span>
<span class="token punctuation">}</span>
</pre>
<p>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</p>
<p>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!”</p>
<p>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</p>
<p>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</p>
<h2 id="dry">DRY</h2>
<p>DRY significa Don’t Repeat Self, máxima poderosa na mente da maioria dos desenvolvedores</p>
<p>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</p>
<p>grug percebe que gráfico humorístico de Lea Verou corresponde com paixão de grug de não
repetir:</p>
<p><img src="https://grugbrain.dev/over-time.png" alt="preocupação com código ao longo do tempo"
style="width: 100%; clear: both"></p>
<p>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</p>
<p>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</p>
<p>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</p>
<h2 id="separation-of-concerns-soc">Separation of Concerns (SoC)</h2>
<p>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</p>
<p>exemplo canônico do desenvolvimento web: separação de estilo (arquivo css), marcação
(arquivo html) e lógica (arquivo javascript)</p>
<p>aqui grug faz cara muito mais feia do que para DRY e de fato escrever ensaio de cérebro grande sobre a
<a href="https://htmx.org/essays/locality-of-behaviour/">localidade de comportamento (LoB)</a> princípio
alternativo de design contra o SoC
</p>
<p>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!</p>
<p>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!</p>
<h2 id="closures">Closures</h2>
<p>grug gosta de closures para o trabalho certo e esse trabalho geralmente abstrair operação sobre
coleção de objetos</p>
<p>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</p>
<p>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.</p>
<h2 id="logging">Logging</h2>
<p>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</p>
<p>história engraçada: grug descobre que ídolo <a href="https://en.wikipedia.org/wiki/Rob_Pike">rob
pike</a> 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 <em>muito</em> importante para o google,
então é claro que melhor programador trabalha nisso, grug!</p>
<p>não seja tão cérebro grug, grug! muito menos pedra brilhante agora!</p>
<p>tudo bem, grug acabar em boa empresa de qualquer maneira e jeito de vestir de rob pike <a
href="https://www.youtube.com/watch?v=KINIAgRpkDA">cada vez mais esquisito</a>, então tudo bem no
final,
mas o ponto é: log muito importante!</p>
<p>As dicas do grug sobre o log são:</p>
<ul>
<li>logar todas as principais ramificações lógicas dentro do código (if/for)</li>
<li>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</li>
<li>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!)</li>
<li>se possível, faça o nível de log por usuário, para que possa depurar um problema
específico do usuário</li>
</ul>
<p>os dois últimos pontos são especialmente úteis para combater bugs em sistemas de
produção com muita frequência</p>
<p>infelizmente, as bibliotecas de log geralmente são muito complexas (java, <a
href="https://stackify.com/logging-java/">por que você faz isso?</a> )</p>
<p>o logging precisa ser ensinado mais nas escolas, pensa grug</p>
<h2 id="concorr%C3%AAncia">Concorrência</h2>
<p>Grug, como todo desenvolvedor sensato, teme a concorrência</p>
<p>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</p>
<p><a href="https://en.wikipedia.org/wiki/Optimistic_concurrency_control">concorrência otimista</a> parece
funcionar bem para coisas da web</p>
<p>ocasionalmente, o grug usa <a href="https://en.wikipedia.org/wiki/Thread-local_storage">variável thread
local</a> , geralmente ao escrever código de framework</p>
<p>algumas linguagem tem boa estrutura de dados concorrente, como java <a
href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html">ConcurrentHashMap</a>
, mas ainda precisa de um trabalho cuidadoso de grug para acertar</p>
<p>grug nunca usou <a href="https://en.wikipedia.org/wiki/Erlang_(programming_language)">erlang</a> , ouve
coisas
boas, mas linguagem parece estranha para grug desculpe</p>
<h2 id="otimiza%C3%A7%C3%A3o">Otimização</h2>
<p>desenvolvedor ultra maior do cérebro grande uma vez dizer:</p>
<blockquote>
<p>otimização prematura é a raiz de todo o mal</p>
</blockquote>
<p>isso todo mundo quase sabe e grug está em acordo com o ultra maior do cérebro grande</p>
<p>grug recomenda sempre ter um profile de desempenho concreto e real mostrando um problema específico de
desempenho antes de começar a otimizar.</p>
<p>nunca se sabe qual pode ser o problema real, grug muitas vezes surpresa! muitas vezes!</p>
<p>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
</p>
<p>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?</p>
<p>desenvolvedor inexperiente com cérebro grande vê loop aninhado e muitas vezes diz “O(n^2)?
No
meu código não!”</p>
<p>espírito demônio da complexidade sorri</p>
<h2 id="api">API</h2>
<p>grug ama boas apis. boas apis não fazem grug pensar muito</p>
<p>infelizmente, muitas apis são muito ruins, fazem grug pensar bastante. isso acontece por muitas
razões,
aqui duas:</p>
<ul>
<li>Os criadores de API pensam em termos de implementação ou domínio da API, e não em
termos
de uso da API</li>
<li>Os criadores de API pensam muito abstrato e tem cérebro grande</li>
</ul>
<p>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</p>
<p>mas desenvolvedores de APIs de cérebro grande dizer:</p>
<p>“peraí, grug! esse arquivo está <em>aberto para escrita</em> ? você definiu um
<em>Comparator</em> para essa ordenação?”
</p>
<p>grug sente a mão agarrar porrete de novo</p>
<p>não me importo com essas coisas agora, só quero classificar e escrever o arquivo, senhor
cérebro
grande!</p>
<p>grug reconhece que designer de APIs de cérebro grande ter alguma razão e que <em>às vezes</em>
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</p>
<p>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</p>
<p>também, se orientado a objetos, coloque api na coisa em vez de em outro lugar. java pior nisso!</p>
<p>grug quer filtrar lista em java</p>
<p>“Você converteu em um stream?”</p>
<p>tudo bem, grug converter para stream</p>
<p>“OK, agora você pode filtrar.”</p>
<p>OK, mas agora precisa retornar lista! tem fluxo!</p>
<p>“Tá, você coletou seu stream em uma lista?”</p>
<p>que?</p>
<p>“Defina um Collector<? super T, A, R> para coletar seu stream em uma lista”</p>
<p>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</p>
<p>coloque coisas comuns como filter() na lista e faça retornar lista, ouça bem desenvolvedor de java
api
do cérebro grande!</p>
<p>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!</p>
<h2 id="parsing">Parsing</h2>
<p>grug adora criar linguagem de programação e dizer descida recursiva maneira mais divertida e bonita
criar parser</p>
<p>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!</p>
<p>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</p>
<p>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!</p>
<p>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: <a
href="https://craftinginterpreters.com/">Crafting Interpreters</a></p>
<p>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!)</p>
<h2 id="o-padr%C3%A3o-visitor">O padrão Visitor</h2>
<p><a href="https://en.wikipedia.org/wiki/Visitor_pattern">mau</a></p>
<h2 id="desenvolvimento-front-end">Desenvolvimento Front-End</h2>
<p>alguns não-grugs, quando confrontados com o desenvolvimento web dizem:</p>
<p>“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)”</p>
<p>agora você tem dois covis de espírito demônio de complexidade</p>
<p>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</p>
<p>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</p>
<p>mesmo quando o site só precisa colocar o formulário no banco de dados ou site informativo simples!
</p>
<p>todos fazer isso agora!</p>
<p>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</p>
<p>grug não gosta grandes bibliotecas de front-end complexas que todos usam</p>
<p>grug construir <a href="https://htmx.org/">htmx</a> e <a href="https://hyperscript.org/">hyperscript</a> para
evitar</p>
<p>manter complexidade baixa, HTML simples, evitar muito javascript, o éter natural do espírito
demônio da complexidade</p>
<p>talvez funcionem para você, mas nenhum anúncio de emprego, desculpe</p>
<p>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</p>
<h2 id="modas">Modas</h2>
<p>grug nota muitos modismos no desenvolvimento, especialmente o desenvolvimento de front-end hoje</p>
<p>back-end melhor mais chato porque já tentar todas as más ideias dias de hoje (mas ainda tentar
novamente!)</p>
<p>ainda tentando todas as más ideias no desenvolvimento de front-end, ainda há muitas mudanças e
é difícil saber</p>
<p>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</p>
<p>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</p>
<h2 id="medo-de-parecer-burro">Medo de Parecer Burro</h2>
<p>Nota! muito bom se grug sênior disposto a dizer publicamente: “hmmm, isso é muito complexo
para
grug”!</p>
<p>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”
</p>
<p>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!
</p>
<p>tire o poder do MPB, muito bom do grug sênior!</p>
<p>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</p>
<p>seja forte! abaixo MPB!</p>
<p>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</p>
<h2 id="s%C3%ADndrome-do-impostor">Síndrome do Impostor</h2>
<p>grug ter muitos desses sentimento de impostor em desenvolvimento</p>
<p>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</p>
<p>grug estar principalmente o último estado na maioria das vezes, esconder muito bem</p>
<p>agora, grug faz software muito trabalhoso e <a
href="https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date">sucesso
moderado
de código aberto</a> , 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!</p>
<p>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</p>
<p>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</p>
<h2 id="pra-ler">Pra ler</h2>
<p>grug gosta desses:</p>
<ul>
<li><a href="https://www.dreamsongs.com/WorseIsBetter.html">Pior é melhor</a></li>
<li><a href="https://www.dreamsongs.com/Files/worse-is-worse.pdf">Pior é melhor é pior</a></li>
<li><a href="https://www.dreamsongs.com/Files/IsWorseReallyBetter.pdf">Pior é realmente melhor?</a></li>
<li><a href="https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design">Uma filosofia de
design de software</a></li>
</ul>
<h2 id="conclus%C3%A3o">Conclusão</h2>
<p><em>você</em> diz: complexidade <em>muito</em> , <em>muito</em> ruim</p>
</div>
</body>
</html>