grug dev

引言

本文是《原始人脑开发者》 --- the grug brained developer的原文及翻译。

the grug brained developer

a layman's guide to thinking like the self-aware smol brained
《原始人脑开发者》——一个普通人的自我意识小脑思维指南

introduction  引言

this collection of thoughts on software development gathered by grug brain developer
关于软件开发的想法集合，由格鲁大脑开发者整理

grug brain developer not so smart, but grug brain developer program many long year and learn some things although mostly still confused
格鲁大脑开发者并不聪明，但格鲁大脑开发者编程多年并学到了一些东西，尽管大多时候仍然很困惑

grug brain developer try collect learns into small, easily digestible and funny page, not only for you, the young grug, but also for him because as grug brain developer get older he forget important things, like what had for breakfast or if put pants on
格鲁大脑开发者尝试将所学知识整理成小而易于消化且有趣的页面，不仅是为了你，年轻的格鲁，也是为了他自己，因为随着格鲁大脑开发者的变老，他会忘记重要的事情，比如早餐吃了什么，或者是否穿上了裤子

big brained developers are many, and some not expected to like this, make sour face
聪明的大脑开发者有很多，有些人可能不会喜欢这个，会露出难看的表情

think they are big brained developers many, many more, and more even definitely probably maybe not like this, many sour face (such is internet)
很多人认为他们是大脑发达的开发者，数量多得多，甚至更多，肯定可能也许不是这样，很多愁眉苦脸（互联网就是这样）

(note: grug once think big brained but learn hard way)
（注：格鲁曾经认为大脑发达，但后来吃了苦头）

is fine!  很好！

is free country sort of and end of day not really matter too much, but grug hope you fun reading and maybe learn from many, many mistake grug make over long program life
这是一个自由的国家，到头来真的不太重要，但格鲁希望你阅读愉快，也许能从自己长期编程生涯中犯的许多错误中学习到一些东西

the eternal enemy: complexity 永恒的敌人：复杂性

apex predator of grug is complexity
格鲁的顶级掠食者是复杂性

complexity bad  复杂性是坏事

say again:  再说一遍：

complexity very bad  复杂性非常糟糕

you say now:  你说现在：

complexity very, very bad
复杂性非常非常糟糕

given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex
在复杂性和一对一对抗霸王龙之间做选择，格鲁会选择霸王龙：至少格鲁能看到霸王龙

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime
复杂性是会进入代码库的精神恶魔，它通过那些善意但最终非常容易结交的、非格鲁脑开发者以及项目经理进入，这些人既不害怕复杂性的精神恶魔，甚至有时都不知道它的存在

one day code base understandable and grug can get work done, everything good!
有一天代码库变得可以理解，格鲁可以完成工作，一切都很好！

next day impossible: complexity demon spirit has entered code and very dangerous situation!
第二天就不可能了：复杂性的恶魔之灵进入了代码，情况非常危险！

grug no able see complexity demon, but grug sense presence in code base
格鲁看不见复杂性恶魔，但能感觉到代码库中的存在

demon complexity spirit mocking him make change here break unrelated thing there what!?! mock mock mock ha ha so funny grug love programming and not becoming shiney rock speculator like grug senior advise
恶魔之灵在嘲弄他，在这里做改动会破坏那里无关的东西什么！？！嘲弄嘲弄嘲弄哈哈太搞笑了，格鲁喜欢编程，不想成为像格鲁前辈建议的那种闪亮的岩石投机者

club not work on demon spirit complexity and bad idea actually hit developer who let spirit in with club: sometimes grug himself!
俱乐部对恶魔灵魂的复杂性不起作用，实际上击中的是让灵魂进来的开发者：有时是格鲁自己！

sadly, often grug himself
不幸的是，往往是格鲁自己

so grug say again and say often: complexity very, very bad
所以格鲁再次说，经常说：复杂性非常非常糟糕

saying no  说“不”

best weapon against complexity spirit demon is magic word: "no"
对抗复杂精神恶魔的最佳武器是魔法咒语：“不”

"no, grug not build that feature"
“不，格鲁不会构建那个功能”

"no, grug not build that abstraction"
“不，格鲁不会构建那个抽象”

"no, grug not put water on body every day or drink less black think juice you stop repeat ask now"
“不，格鲁不会每天给身体浇水或喝较少的黑思考果汁，你停止重复询问现在”

note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
注意，这虽然是好的工程建议，但却是糟糕的职业建议："是"是获得更多闪亮岩石并负责管理大型开发者部落的魔法词。

sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
悲哀但真实：先学会"是"，然后学会在失败时责怪其他古鲁，这才是理想的职业建议。

but grug must to grug be true, and "no" is magic grug word. hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be
但古鲁必须对古鲁保持真实，而"不"是古鲁的魔法词。一开始很难说出口，特别是如果你是个友善的古鲁并且不喜欢让人失望（许多这样的古鲁！）但随着时间推移会变得更容易，即使闪亮岩石堆可能没有像预期中那么高。

is ok: how many shiney rock grug really need anyway?
这也可以接受：一个古鲁真正需要多少闪亮岩石呢？

saying ok  说好的

sometimes compromise necessary or no shiney rock, mean no dinosaur meat, not good, wife firmly remind grug about young grugs at home need roof, food, and so forth, no interest in complexity demon spirit rant by grug for fiftieth time
有时候妥协是必要的，或者没有闪亮的石头，就意味着没有恐龙肉，这不太好。妻子坚定地提醒格鲁关于家里年轻的格鲁们需要屋顶、食物等等。对格鲁第五十次关于复杂恶魔精神的咆哮不感兴趣

in this situation, grug recommend "ok"
在这种情况下，格鲁建议"ok"

"ok, grug build that feature"
"好，格鲁建造那个功能"

then grug spend time think of 80/20 solution to problem and build that instead.
然后格鲁花时间思考问题的 80/20 解决方案，并构建那个方案。
80/20 solution say "80 want with 20 code" solution maybe not have all bell-whistle that project manager want, maybe a little ugly, but work and deliver most value, and keep demon complexity spirit at bay for most part to extent
80/20 解决方案说"用 20%的代码实现 80%的需求"，这个方案可能没有项目经理想要的所有花哨功能，可能有点丑，但能工作并交付最大价值，并且在很大程度上保持恶魔复杂性的精神。

sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. often forget what even feature supposed to do or move on or quit or get fired grug see many such cases
有时候可能最好的办法就是不去告诉项目经理，而是用 80/20 的方式来做。更容易被原谅而不是被批准，项目经理的心态有时像蝴蝶一样，在过度劳累和处理许多格鲁时容易忘记功能本应做什么，或者继续前进，或者辞职，或者被解雇。格鲁见过很多这样的案例。

anyway is in project managers best interest anyway so grug not to feel too bad for this approach usually
无论如何，这对项目经理来说也是最好的选择，所以格鲁通常不会对这个方法感到太难过。

factoring your code  分解你的代码

next strategy very harder: break code base up properly (fancy word: "factor your code properly") here is hard give general advice because each system so different. however, one thing grug come to believe: not factor your application too early!
下一个策略非常困难：正确地拆分代码库（时髦的说法：“正确地分解你的代码”）。这里很难给出一般性建议，因为每个系统都如此不同。然而，有一种事情是格鲁逐渐相信的：不要过早地分解你的应用程序！

early on in project everything very abstract and like water: very little solid holds for grug's struggling brain to hang on to. take time to develop "shape" of system and learn what even doing. grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base
在项目早期，一切都非常抽象，就像水一样：几乎没有坚实的部分能让格鲁混乱的大脑抓住。花时间去发展系统的“形状”，并了解它实际上在做什么。格鲁尝试在项目的早期阶段不要分解，然后，在某个时刻，好的分解点会从代码库中显现出来。

good cut point has narrow interface with rest of system: small number of functions or abstractions that hide complexity demon internally, like trapped in crystal
好的分解点具有与系统其他部分的窄接口：少量的函数或抽象，它们隐藏了内部的复杂性恶魔，就像被困在水晶中。

grug quite satisfied when complexity demon trapped properly in crystal, is best feeling to trap mortal enemy!
格鲁在复杂恶魔被正确地困在水晶中时非常满意，这是困住凡敌的最佳感觉！

grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience
格鲁尝试耐心地观察，看代码中的切点如何显现，并慢慢重构，随着经验的积累，代码库逐渐成型。没有硬性/快速规则：格鲁知道切点何时出现，格鲁看到切点时就知道，只是需要时间来培养观察的技能，需要耐心

sometimes grug go too early and get abstractions wrong, so grug bias towards waiting
有时格鲁过早地行动，导致抽象错误，所以格鲁倾向于等待

big brain developers often not like this at all and invent many abstractions start of project
聪明的大脑开发者通常完全不喜欢这种方式，并且在项目开始时就发明了许多抽象

grug tempted to reach for club and yell "big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!"
格鲁格想伸手拿起棍棒大喊"大智慧不维护代码！大智慧去参加下一个架构委员会，把代码留给格鲁格处理！"

but grug learn control passions, major difference between grug and animal
但格鲁格学会了控制自己的激情，这是格鲁格和动物之间的主要区别

instead grug try to limit damage of big brain developer early in project by giving them thing like uml diagram (not hurt code, probably throw away anyway) or by demanding working demo tomorrow
相反，格鲁格试图在项目早期通过给大智慧开发者类似 uml 图（不会伤害代码，但可能还是会被扔掉）或要求明天就有一个可工作的演示来限制大智慧的破坏

working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly
可工作的演示是一个特别好的技巧：强迫大智慧做出实际能运行的东西来讨论，并让他们看到能做这件事的代码，这将帮助大智慧更快地认清现实

remember! big brain have big brain! need only be harness for good and not in service of spirit complexity demon on accident, many times seen
记住！大头脑有大头脑！只需为善所用，而非服务于精神复杂性恶魔，这往往是不经意间发生的，我见过很多次。

(best grug brain able to herd multiple big brain in right direction and produce many complexity demon trap crystals, large shiney rock pile awaits such grug!)
（最聪明的古鲁大脑能够引导多个大头脑走向正确的方向，并制造出许多复杂性恶魔陷阱水晶，等待着这样聪明的古鲁的闪亮大石堆！）

also sometimes call demo approach "prototype", sound fancier to project manager
有时也把这种做法称为“原型”，听起来对项目经理来说更高级。

grug say prototype early in software making, especially if many big brains
古鲁说，在软件开发早期就要做原型，尤其是当有很多大头脑的时候

testing  测试

grug have love/hate relationship with test: test save grug many, many uncountable time and grug love and respect test
格鲁与测试有着爱恨交织的关系：测试多次拯救了格鲁，无数次的不可计数的时间中，格鲁热爱并尊重测试

unfortunately also many test shamans exist. some test shaman make test idol, demand things like "first test" before grug even write code or have any idea what grug doing domain!
不幸的是，也存在许多测试萨满。一些测试萨满将测试视为偶像，要求在格鲁甚至编写代码或对所做领域有任何想法之前进行“首次测试”！

how grug test what grug not even understand domain yet!?
格鲁如何测试他们连领域都不理解的代码？

"oh, don't worry: the tests will show you what you need to do."
"哦，别担心：测试会告诉你该做什么。"

grug once again catch grug slowly reaching for club, but grug stay calm
格鲁再次抓住格鲁慢慢地伸手去拿棍子，但格鲁保持冷静

grug instead prefer write most tests after prototype phase, when code has begun firm up
格鲁反而更喜欢在原型阶段之后写大部分测试，当代码开始稳固成形时

but, note well: grug must here be very disciplined!
但是，请注意：格鲁在这里必须非常自律！

easy grug to move on and not write tests because "work on grugs machine"!
对笨蛋来说很容易就放弃不写测试，因为可以找借口说"在笨蛋的机器上工作"！

this very, very bad: no guarantee work on other machine and no guarantee work on grug machine in future, many times
这非常非常糟糕：没有保证能在其他机器上运行，也没有保证未来能在 grug 机器上运行，很多次

test shaman have good point on importance of test, even if test shaman often sometimes not complete useful feature in life and talk only about test all time, deserve of club but heart in right place
测试萨满对测试的重要性有很好的见解，即使测试萨满经常有时没有在生活中完成有用的功能，并且总是谈论测试，值得俱乐部，但心在正确的位置

also, test shaman often talk unit test very much, but grug not find so useful. grug experience that ideal tests are not unit test or either end-to-end test, but in-between test
此外，测试萨满经常大量谈论单元测试，但格鲁觉得这没什么用。格鲁的经验是，理想的测试不是单元测试，也不是端到端测试，而是介于两者之间的测试。

unit tests fine, ok, but break as implementation change (much compared api!) and make refactor hard and, frankly, many bugs anyway often due interactions other code. often throw away when code change.
单元测试很好，没问题，但会随着实现变化而失效（与 api 相比变化很大！），并且让重构变得困难，而且坦白说，很多时候还会因为与其他代码的交互导致很多 bug。当代码变更时，这些测试往往会被丢弃。

grug write unit test mostly at start of project, help get things going but not get too attached or expect value long time
原始人主要在项目开始时写单元测试，这有助于让事情启动，但不要过于依赖或期望它能长期有效。

end to end tests good, show whole system work, but! hard to understand when break and drive grug crazy very often, sometimes grugs just end up ignoring because "oh, that break all time" very bad!
端到端测试很好，能展示整个系统的工作情况，但！当它们失效时很难理解原因，这常常让原始人抓狂，有时候原始人最终只能选择忽视，因为“哦，那东西总是出问题”，这非常糟糕！

in-between tests, grug hear shaman call "integration tests" sometime often with sour look on face. but grug say integration test sweet spot according to grug: high level enough test correctness of system, low level enough, with good debugger, easy to see what break
介于两者之间，原始人有时会听到萨满的呼唤，称之为“集成测试”，脸上常常带着不情愿的表情。但原始人说，集成测试的完美之处在于：测试系统正确性时足够高层，但足够底层，配合好的调试器，就能轻松看出问题所在。

grug prefer some unit tests especially at start but not 100% all code test and definitely not "first test". "test along the way" work pretty well for grug, especially as grug figure things out
grug 更喜欢一些单元测试，尤其是在开始阶段，但并非所有代码都需要 100%测试，当然更不是“先测试”。"边开发边测试"对 grug 来说效果很好，尤其是当 grug 逐渐弄清楚事情的时候。

grug focus much ferocious integration test effort as cut point emerge and system stabilize! cut point api hopefully stable compared implementation and integration test remain valuable many long time, and easy debug
grug 在关键点出现和系统稳定后，会投入大量精力进行凶猛的集成测试！关键点 api 希望保持稳定，而实现和集成测试则长期有价值，且易于调试。

also small, well curated end-to-end test suite is created to be kept working religiously on pain of clubbing. focus of important end-to-end test on most common ui features and few most important edge cases, but not too many or become impossible maintain and then ignored
此外，还会创建一个小型、精心策划的端到端测试套件，并严格坚持维护，否则将面临棍棒惩罚。重要端到端测试的重点是最常见的 ui 功能以及少数几个最重要的边缘案例，但不要太多，否则会变得难以维护，然后被忽视。

this ideal set of test to grug
这套理想的测试对 grug 来说是完美的。

you may not like, but this peak grug testing
你可能不喜欢，但这是最顶级的格鲁测试

also, grug dislike mocking in test, prefer only when absolute necessary to (rare/never) and coarse grain mocking (cut points/systems) only at that
此外，格鲁不喜欢在测试中进行模拟，只有在绝对必要时（极少/从不）才会使用，并且只对粗粒度模拟（切点/系统）进行模拟

one exception "first test" dislike by grug: when bug found. grug always try first reproduce bug with regression test then fix bug, this case only for some reason work better
一个例外是“第一个测试”，格鲁不喜欢：当发现 bug 时。格鲁总是首先尝试用回归测试重现 bug，然后修复 bug，这种情况下只有某种原因会更好

agile  敏捷

grug think agile not terrible, not good
格鲁认为敏捷并不糟糕，但也不好

end of day, not worst way to organize development, maybe better than others grug supposes is fine
一天结束时，这不是组织开发的最佳方式，或许比其他格鲁认为的方式更好

danger, however, is agile shaman! many, many shiney rock lost to agile shaman!
然而，危险的是敏捷巫师！许多许多闪亮的石头都因敏捷巫师而丢失！

whenever agile project fail, agile shaman say "you didn't do agile right!" grug note this awfully convenient for agile shaman, ask more shiney rock better agile train young grugs on agile, danger!
每当敏捷项目失败时，敏捷巫师会说“你没用对敏捷！”格鲁注意到这对敏捷巫师来说非常方便，他们要求更多闪亮的石头来训练年轻的格鲁使用敏捷，这是危险的！

grug tempted reach for club when too much agile talk happen but always stay calm
当敏捷话题太多时，格鲁很想去拿棍子，但总是保持冷静

prototyping, tools and hiring good grugs better key to success software: agile process ok and help some but sometimes hurt taken too seriously
原型设计、工具和雇佣优秀的“古鲁”是成功的关键：敏捷流程可以提供帮助，但有时也会造成伤害，如果过于认真对待

grug say no silver club fix all software problems no matter what agile shaman say (danger!)
“古鲁”说没有银质俱乐部可以解决所有软件问题，无论敏捷巫师说什么（危险！）

refactoring  重构

refactoring fine activity and often good idea, especially later in project when code firmed up
重构是一项很好的活动，并且通常是好主意，尤其是在项目后期，当代码已经稳定时

however, grug note that many times in career "refactors" go horribly off rails and end up causing more harm than good
然而，格鲁注意到在职业生涯中，“重构”很多时候会出严重问题，最终造成的伤害大于益处

grug not sure exactly why some refactors work well, some fail, but grug notice that larger refactor, more likely failure appear to be
格鲁不确定为什么有些重构会成功，有些会失败，但格鲁注意到，规模越大的重构，失败的可能性似乎越高

so grug try to keep refactors relatively small and not be "too far out from shore" during refactor. ideally system work entire time and each step of finish before other begin.
因此，格鲁尽量保持重构规模相对较小，并在重构过程中不“离岸太远”。理想情况下，系统在整个过程中都能正常运行，并且每一步都完成后再开始下一步。

end-to-end tests are life saver here, but often very hard understand why broke... such is refactor life.
端到端测试在这里是救星，但通常很难理解为什么出问题……这就是重构生活的常态。

also grug notice that introducing too much abstraction often lead to refactor failure and system failure. good example was j2ee introduce, many big brain sit around thinking too much abstraction, nothing good came of it many project hurt
此外，古鲁注意到，引入过多的抽象往往会导致重构失败和系统失败。一个很好的例子是 j2ee 的引入，许多聪明人围绕着思考过多的抽象，最终什么好的结果都没有，许多项目都受到了损害。

another good example when company grug work for introduce osgi to help manage/trap spriit complexity demon in code base. not only osgi not help, but make complexity demon much more powerful! took multiple man year of best developers to rework as well to boot! more complex spirit and now features impossible implement! very bad!
另一个好例子是，古鲁所在的公司引入 osgi 来帮助管理/捕捉代码库中的精神复杂性恶魔。不仅 osgi 没有帮助，反而让复杂性恶魔变得更加强大！花费了多年最佳开发者的努力来重新工作，启动也变得困难！更复杂的精神和现在无法实现的功能！非常糟糕！

chesterton's fence  切斯特顿的栅栏

wise grug shaman chesterton once say
聪明的格鲁萨满切斯特顿曾说过

here exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. the more modern type of reformer goes gaily up to it and says, “i don’t see the use of this; let us clear it away.” to which the more intelligent type of reformer will do well to answer: “if you don’t see the use of it, i certainly won’t let you clear it away. go away and think. then, when you can come back and tell me that you do see the use of it, i may allow you to destroy it.”
在这种情况下，存在某种制度或法律；为了简单起见，我们可以说，是在道路上竖起的一堵篱笆或一个门。更现代的改革者兴高采烈地走上前去，说：“我看不出这个有什么用；让我们把它清除掉。”对此，更聪明的改革者最好回答：“如果你看不出它的用处，我当然不会让你清除它。走开，好好想想。然后，当你能回来告诉我你确实看到了它的用处时，我或许会允许你摧毁它。”

many older grug learn this lesson well not start tearing code out willy nilly, no matter how ugly look
许多年长的格鲁人很好地学到了这个教训，不会随意地拆代码，无论它看起来多么丑陋

grug understand all programmer platonists at some level wish music of spheres perfection in code. but danger is here, world is ugly and gronky many times and so also must code be
格鲁人理解所有程序员的柏拉图主义者，在某种程度上都希望代码像天体的音乐一样完美。但危险在于，世界很多时候既丑陋又笨拙，因此代码也必须如此。

humility not often come big brained or think big brained easily or grug even, but grug often find "oh, grug no like look of this, grug fix" lead many hours pain grug and no better or system worse even
谦逊并不常出现在大脑发达的人身上，或者他们不容易认为自己大脑发达，即使是格鲁，但格鲁常常发现“哦，格鲁不喜欢这个样子，格鲁会修理”导致许多小时的痛苦，格鲁并没有变得更好，系统甚至变得更糟。

grug early on in career often charge into code base waving club wildly and smash up everything, learn not good
格鲁在职业生涯早期常常冲进代码库挥舞着棍棒，把一切都搞砸了，学到的教训不太好。

grug not say no improve system ever, quite foolish, but recommend take time understand system first especially bigger system is and is respect code working today even if not perfect
格鲁不会说永远不改进系统，这很愚蠢，但建议先花时间理解系统，尤其是更大的系统，并且要尊重今天正在运行的代码，即使它并不完美。

here tests often good hint for why fence not to be smashed!
这里测试通常是为什么栅栏不应该被破坏的好提示！

microservices  微服务

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
格鲁不明白为什么大脑会处理最困难的问题，正确地分解系统，并引入网络调用

seem very confusing to grug
这对格鲁来说似乎非常困惑

tools  工具

grug love tool. tool and control passion what separate grug from dinosaurs! tool allow grug brain to create code that not possible otherwise by doing thinking for grug, always good relief! grug always spend time in new place learning tools around him to maximize productivity: learn tools for two weeks make development often twice faster and often have dig around ask other developers help, no docs
格鲁喜欢工具。工具和控制欲是区分格鲁与恐龙的关键！工具让格鲁的大脑能够通过思考来创建原本不可能的代码，这总是能带来很好的解脱！格鲁总是在新地方花时间学习周围的工具，以最大化生产力：学习两周的工具可以使开发速度通常提高一倍，而且经常需要四处寻找并询问其他开发者的帮助，没有文档

code completion in ide allow grug not have remembered all api, very important!
ide 中的代码补全功能让 grug 不必记住所有 api，非常重要！

java programming nearly impossible without it for grug!
没有它，grug 几乎不可能进行 java 编程！

really make grug think some time
真的让格鲁思考一段时间

good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell
好的调试器值得闪闪发光的石头，事实上还更多：当面对 bug 时，格鲁经常会用所有闪闪发光的石头，或许还有几个孩子来换取好的调试器，而且无论如何，调试器在格鲁看来什么重量都没有

grug always recommend new programmer learn available debugger very deeply, features like conditional break points, expression evaluation, stack navigation, etc teach new grug more about computer than university class often!
grug 总是建议新程序员深入学习可用的调试器，像条件断点、表达式求值、栈导航等功能，比大学课堂往往能教给新 grug 更多关于计算机的知识！

grug say never be not improving tooling
grug 说工具永远不会停止改进

type systems  类型系统

grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug
grug 非常喜欢类型系统，因为它们让编程变得更容易。对 grug 来说，类型系统最有价值的地方是当 grug 在键盘上敲击点时，能够弹出一个可以执行的操作列表。这占类型系统价值的大约 90%或更多。

big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct
那些聪明的大脑类型系统萨满经常说类型正确性是类型系统的要点，但 grug 注意到有些聪明的大脑类型系统萨满并不经常发布代码。grug 认为没有发布的代码是正确的，在某种意义上是这样，但这并不是 grug 说正确时的真正含义。

grug say tool magic pop up of what can do and complete of code major most benefit of type system, correctness also good but not so nearly so much
grug 说工具魔法弹出能做什么，完成代码主要好处是类型系统，正确性也不错，但几乎没那么多了

also, often sometimes caution beware big brains here!
此外，常常有时候要小心谨慎，这里需要大智慧！

some type big brain think in type systems and talk in lemmas, potential danger!
某些类型的大脑在类型系统中思考，用公理来交谈，潜在的危险！

danger abstraction too high, big brain type system code become astral projection of platonic generic turing model of computation into code base. grug confused and agree some level very elegant but also very hard do anything like record number of club inventory for grug inc. task at hand
抽象层次过高是危险，大脑类型系统的代码变成柏拉图通用图灵计算模型的灵体投射到代码库中。格鲁感到困惑，并在某种程度上同意它非常优雅，但也非常难以完成像记录格鲁公司俱乐部库存数量这样的任务

generics especially dangerous here, grug try limit generics to container classes for most part where most value add
泛型在这里尤其危险，格鲁尝试将泛型限制在容器类中，大部分情况下最有价值

temptation generics very large is trick! spirit demon complex love this one trick! beware!
诱惑泛型非常大是陷阱！恶魔复杂的爱情这就是一个陷阱！小心！

always most value type system come: hit dot see what grug can do, never forget!
永远最重要的是类型系统：点一下看看格鲁能做什么，永远不要忘记！

expression complexity  表达复杂性

grug once like to minimize lines of code much as possible. write code like this:
格鲁格曾经尽可能减少代码行数。像这样写代码：

  if(contact && !contact.isactive() && (contact.ingroup(family) || contact.ingroup(friends))) {
    // ...
  }

over time grug learn this hard debug, learn prefer write like so:
随着时间的推移，格鲁学会了这种艰难的调试，学会了更倾向于这样编写：

  if(contact) {
    var contactisinactive = !contact.isactive();
    var contactisfamilyorfriends = contact.ingroup(family) || contact.ingroup(friends);
    if(contactisinactive && contactisfamilyorfriends) {
        // ...
    }
  }

grug hear screams from young grugs at horror of many line of code and pointless variable and grug prepare defend self with club
格鲁听到年轻格鲁们对代码行数过多和无用变量的恐惧的尖叫，格鲁准备用棍棒自我防卫

club fight start with other developers attack and grug yell: "easier debug! see result of each expression more clearly and good name! easier understand conditional expression! easier debug!"
棍棒战斗开始，其他开发者攻击，格鲁喊道："更容易调试！更清晰地看到每个表达式的结果！好名字！更容易理解条件表达式！更容易调试！"

definitely easier debug and once club fight end calm down and young grug think a bit, they realize grug right
确实更容易调试，一旦棍棒战斗结束，冷静下来，年轻格鲁们稍微思考一下，他们意识到格鲁是对的

grug still catch grug writing code like first example and often regret, so grug not judge young grug
原始人仍然像第一个例子那样写代码，并且经常后悔，所以原始人不会评判年轻的原始人

dry

dry mean don't repeat self, powerful maxim over mind of most developers
dry 的意思是“不要自我重复”，这是一个对大多数原始人来说非常有力的准则

grug respect dry and good advice, however grug recommend balance in all things, as gruggest big brain aristotle recommend
原始人尊重 dry，这是一个好建议，但是原始人推荐凡事都要保持平衡，就像最聪明的原始人亚里士多德所建议的那样

grug note humourous graph by lea verou correspond with grug passion not repeat:
lea verou 创作的有趣 grug 笔记图表与 grug 的热情相呼应，不重复：

over time past ten years program grug not as concerned repeat code. so long as repeat code simple enough and obvious enough, and grug begin feel repeat/copy paste code with small variation is better than many callback/closures passed arguments or elaborate object model: too hard complex for too little benefit at times
过去十年间，程序猿不再像以前那样担心重复代码。只要重复的代码足够简单且明显，程序猿就会开始觉得，用稍作修改的复制粘贴代码比传递大量参数或复杂的对象模型更好：有时这样做虽然复杂，但收益甚微。

hard balance here, repeat code always still make grug stare and say "mmm" often, but experience show repeat code sometimes often better than complex dry solution
这里需要谨慎平衡，重复代码总是让 grug 盯着并经常说"mmm"，但经验表明重复代码有时比复杂的 dry 解决方案更好

note well! grug encourage over literal developer not take does work line too serious, is joke
注意！grug 鼓励字面意义的开发者不要对每行代码太认真，这是个玩笑

separation of concerns (soc) 关注点分离

separation of concern (soc) another powerful idea over many developer mind, idea to separate different aspects of system into distinct sections code
关注点分离（soc）是许多开发者思维中的一个强大理念，即将系统的不同方面分离到不同的代码部分

canonical example from web development: separation of style (css file), markup (html file) and logic (javascript file)
来自网页开发的规范示例：样式（css 文件）、标记（html 文件）和逻辑（javascript 文件）的分离

here grug much more sour faced than dry and in fact write big brained essay on alternative design principle locality of behavior (lob) against soc
这里的 grug 比 dry 更不高兴，实际上他写了一篇关于替代设计原则“行为局部性”（lob）的大脑发达的论文，反对 soc

grug much prefer put code on the thing that do the thing. now when grug look at the thing grug know the thing what the thing do, alwasy good relief!
grug 更倾向于把代码放在执行任务的物体上。现在当 grug 看这个物体时，他知道这个物体做什么，总是能带来很好的解脱！

when separate of concern grug must often all over tarnation many file look understand what how button do, much confuse and time waste: bad!
当关注点分离时，格鲁必须常常在许多文件中到处翻找才能理解按钮该怎么做，这非常令人困惑且浪费时间：真糟糕！

closures  闭包

grug like closures for right job and that job usually abstracting operation over collection of objects
对于合适的任务，grug 喜欢使用闭包，而这类任务通常涉及对对象集合进行抽象操作

grug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use give heart attack
grug 警告说闭包就像盐一样，少量使用效果显著，但过度使用会适得其反，甚至造成严重后果

javascript developers call very special complexity demon spirit in javascript "callback hell" because too much closure used by javascript libraries very sad but also javascript developer get what deserved let grug be frank
javascript 开发者将 javascript 中非常特殊的复杂恶魔精灵称为"回调地狱"，因为 javascript 库使用了太多的闭包，这很悲伤，但 javascript 开发者也得到了他们应得的。让 grug 坦诚一些。

logging  日志记录

grug huge fan of logging and encourage lots of it, especially in cloud deployed. some non-grugs say logging expensive and not important. grug used think this way no more
grug 是日志记录的狂热粉丝，并鼓励大量使用，尤其是在云部署中。一些非 grug 人说日志记录很昂贵且不重要。grug 曾经这样认为，但现在不再这样了。

funny story: grug learn idol rob pike working on logging at google and decide: "if rob pike working on logging, what grug do there?!?" so not pursue. turn out logging very important to google so of course best programmer work on it, grug!
有个有趣的故事：grug 学习了偶像 rob pike 在谷歌从事日志记录的工作，并决定："如果 rob pike 在谷歌从事日志记录，那 grug 在那里该做什么呢？"所以没有继续追求。结果证明日志记录对谷歌非常重要，所以当然最好的程序员会负责它，grug！

don't be such grug brain, grug, much less shiney rock now!
不要有这种 grug 式的思维，grug，现在更没有闪亮的石头了！

oh well, grug end up at good company anyway and rob pike dress habit increasingly erratic, so all work out in end, but point stand: logging very important!
哦，不坏，格鲁最终去了个好公司，而且抢皮克的衣服习惯越来越不稳定，所以最后一切都解决了，但要点明确：记录非常重要！

grug tips on logging are:
格鲁关于记录的建议是：

• log all major logical branches within code (if/for)
  在代码中记录所有主要的逻辑分支（if/for）
• if "request" span multiple machine in cloud infrastructure, include request id in all so logs can be grouped
  如果"请求"跨越云基础设施中的多台机器，请在所有记录中包含请求 id，以便可以按请求分组记录
• if possible make log level dynamically controlled, so grug can turn on/off when need debug issue (many!)
  如果可能的话，让日志级别可以动态控制，这样 grug 在需要调试问题时（问题很多！）可以打开或关闭
• if possible make log level per user, so can debug specific user issue
  如果可能的话，为每个用户设置日志级别，以便能够调试特定用户的问题

last two points are especially handy club when fighting bugs in production systems very often
最后两点尤其方便，在处理生产系统中的 bug 时非常常用

unfortunately log libraries often very complex (java, why you do?) but worth investing time in getting logging infrastructure "just right" pay off big later in grug experience
不幸的是，日志库通常非常复杂（java，你为什么这么做？），但值得花时间让日志基础设施“恰到好处”，后期在 grug 经验中会有大回报

logging need taught more in schools, grug think
日志需要在学校里教得更多，grug 认为

concurrency  并发

grug, like all sane developer, fear concurrency
格鲁，像所有理智的开发者一样，都害怕并发

as much as possible, grug try to rely on simple concurrency models like stateless web request handlers and simple remote job worker queues where jobs no interdepend and simple api
尽可能多地，格鲁试图依赖简单的并发模型，比如无状态的网络请求处理器和简单的远程工作队列，其中任务没有相互依赖，以及简单的 api

optimistic concurrency seem work well for web stuff
乐观并发似乎对网络事务效果很好

occasionally grug reach for thread local variable, usually when writing framework code
偶尔，格鲁会使用线程局部变量，通常是在编写框架代码时

some language have good concurrent data structure, like java concurrenthashmap but still need careful grug work to get right
某些语言有良好的并发数据结构，比如 java 的 concurrenthashmap，但仍然需要仔细的 grug 工作才能正确使用

grug has never used erlang, hear good things, but language look wierd to grug sorry
grug 从未使用过 erlang，听说评价很好，但语言看起来很奇怪，对 grug 来说抱歉

optimizing  优化

ultra biggest of brain developer once say:
ultra 最大的脑开发者曾说：

premature optimization is the root of all evil
过早优化是万恶之源

this everyone mostly know and grug in humble violent agreement with ultra biggest of big brain
这一点大家大多都清楚，grug 在谦逊而激烈地同意超级大大脑的看法

grug recommend always to have concrete, real world perf profile showing specific perf issue before begin optimizing.
grug 建议在开始优化之前，一定要有具体的、现实世界的性能分析报告，显示具体的性能问题。

never know what actual issue might be, grug often surprise! very often!
永远不知道实际问题可能是什么，grug 经常感到惊讶！非常经常地！

beware only cpu focus: easy to see cpu and much big o notation thinking having been done in school, but often not root of all slowness, surprise to many including grug
小心仅关注 cpu：容易看到 cpu 和大 o 表示法在学校里被大量使用，但往往不是所有缓慢的根本原因，这对包括 grug 在内的人来说是个惊喜

hitting network equivalent of many, many millions cpu cycle and always to be minimized if possible, note well big brain microservice developer!
网络操作相当于数百万 cpu 周期，总是尽可能最小化，注意好，大脑发达的微服务开发者！

inexperienced big brain developer see nested loop and often say "o(n^2)? not on my watch!"
经验不足的大脑发达的开发者看到嵌套循环，经常说“o(n^2)？不可能在我看管期间发生！”

complexity demon spirit smile
复杂性的恶魔之灵微笑

apis

grug love good apis. good apis not make grug think too much
grug 喜欢好的 api。好的 api 不会让 grug 想太多

unfortunately, many apis very bad, make grug think quite a bit. this happen many reasons, here two:
不幸的是，许多 api 非常糟糕，让 grug 想了很多。这发生了很多原因，这里有两个：

• api creators think in terms of implementation or domain of api, rather than in terms of use of api
  api 创建者从实现或 api 领域角度思考，而不是从 api 使用角度思考
• api creators think too abstract and big brained
  api 创建者思考得太抽象，太“大脑”

usually grug not care too deeply about detail of api: want write file or sort list or whatever, just want to call write() or sort() or whatever
通常 grug 不太关心 api 的细节：想要写文件或排序列表或诸如此类，只需要调用 write() 或 sort() 或诸如此类

but big brain api developers say:
但是大脑 api 开发者说：

"not so fast, grug! is that file open for write? did you define a comparator for that sort?"
"慢着，古鲁！这个文件是打开用于写入的吗？你为那个排序定义了比较器吗？"

grug find self restraining hand reaching for club again
古鲁发现自己又在伸手去拿棍子了

not care about that stuff right now, just want sort and write file mr big brain!
现在不想管那些东西，只想排序和写入文件，大智慧先生！

grug recognize that big brain api designer have point and that sometime these things matter, but often do not. big brain api developers better if design for simple cases with simple api, make complex cases possible with more complex api
grug 认识到大脑 api 设计者有观点，而且有时这些观点很重要，但通常并不重要。大脑 api 开发者如果为简单情况设计简单的 api，让复杂情况通过更复杂的 api 成为可能

grug call this "layering" apis: two or three different apis at different level complexity for various grug needs
grug 称之为“分层”api：两个或三个不同复杂度的 api 用于满足不同 grug 的需求

also, if object oriented, put api on thing instead of elsewhere. java worst at this!
此外，如果面向对象，将 api 放在对象上而不是其他地方。java 在这方面最糟糕！

grug want filter list in java
grug 想在 java 中过滤列表

"did you convert it to a stream?"
"你把它转换成流了吗？"

fine, grug convert to stream
好的，格鲁把它转换成流

"ok, now you can filter."
"好的，现在你可以过滤了。"

ok, but now need return list! have stream!
好的，但现在需要返回列表！已经有流了！

"well, did you collect your stream into a list?"
"嗯，你把你的流收集到一个列表里了吗？"

what?  什么？

"define a collector\ to collect your stream into a list"
"定义一个 collector\来将你的流收集到一个列表中"

grug now swear on ancestor grave he club every single person in room, but count two instead and remain calm
grug 现在在祖先的坟墓上发誓，他棒打房间里的每一个人，但只数到两个就保持冷静

put common thing like filter() on list and make return list, listen well big brain java api developer!
将常见事物如 filter() 列入清单并生成返回列表，仔细听大智慧 java api 开发者！

nobody care about "stream" or even hear of "stream" before, is not networking api, all java grugs use list mr big brain!
没人关心"流"甚至没听说过"流"，这不是网络 api，所有 java 大笨蛋都使用列表，大智慧！

parsing  解析

grug love make programming language at drop of hat and say recursive descent most fun and beautiful way create parser
大笨蛋喜欢在帽子尖上创造编程语言，并说递归下降是创建解析器最有趣和最美的方式

unfortunately many big brain school teach only parser generator tool. here grug usual love of tool is not: parser generator tool generate code of awful snakes nest: impossible understand, bottom up, what? hide recursive nature of grammar from grug and debug impossible, very bad according grug!
不幸的是，许多大智慧学校只教解析器生成工具。这里大笨蛋通常喜欢的工具不是：解析器生成工具生成的代码是可怕的蛇形巢穴：难以理解，自底向上，什么？隐藏了语法的递归性质，让大笨蛋调试变得不可能，非常糟糕，按照大笨蛋的说法！

grug think this because while complexity demon bad for code base and understand, complexity demon very good for generation of much academic papers, sad but true
grug 认为这是因为虽然复杂性对代码库和理解有害，但复杂性对生成大量学术论文非常有益，虽然令人难过但事实如此

production parser almost always recursive descent, despite ignore by schools! grug furious when learn how simple parse is! parsing not big brain only magic: so can you!
生产用解析器几乎总是递归下降的，尽管学校对此视而不见！grug 在学到解析有多简单时会非常愤怒！解析并不需要高智商，只需要魔法：所以你也可以做到！

grug very elated find big brain developer bob nystrom redeem the big brain tribe and write excellent book on recursive descent: crafting interpreters
格鲁非常兴奋地发现大脑开发者鲍勃·尼斯特罗姆救赎了大脑部落，并写了一本关于递归下降的优秀书籍：《制作解释器》

book available online free, but grug highly recommend all interested grugs purchase book on general principle, provide much big brain advice and grug love book very much except visitor pattern (trap!)
书在网上免费提供，但 grug 强烈建议所有感兴趣的 grugs 根据一般原则购买这本书，因为它提供了很多高智商的建议，grug 非常喜爱这本书，除了访问者模式（陷阱！）

the visitor pattern  访问者模式

bad  糟糕

front end development  前端开发

some non-grugs, when faced with web development say:
有些非古鲁人，在面临网页开发时会说：

"i know, i'll split my front end and back end codebase up and use a hot new spa library talking to a graphql json api back end over http (which is funny because i'm not transferring hypertext)"
"我知道，我会把前端和后端代码库分开，并使用一个热门的新 spa 库与一个通过 http 连接的 graphql json api 后端进行通信（这很有趣，因为我并没有传输超文本）"

now you have two complexity demon spirit lairs
现在你有了两个复杂性的恶魔之巢

and, what is worse, front end complexity demon spirit even more powerful and have deep spiritual hold on entire front end industry as far as grug can tell
更糟糕的是，前端复杂性的恶魔之巢甚至更强大，并且对整个前端行业有着深远的精神控制，这是古鲁所能感知到的

back end developers try keep things simple and can work ok, but front end developers make very complex very quickly and introduce lots of code, demon complex spirit
后端开发者尽量保持简单，工作也能顺利进行，但前端开发者很快就会变得非常复杂，引入大量代码，表现出复杂的精神

even when website just need put form into database or simple brochure site!
即使网站只需要将表单放入数据库或是一个简单的宣传网站！

everyone do this now!
现在都这样做！

grug not sure why except maybe facebook and google say so, but that not seem very good reason to grug
grug 不确定为什么，也许是因为 facebook 和 google 说，但这似乎不是很好的理由让 grug

grug not like big complex front end libraries everyone use
grug 不喜欢大家都在用的大型复杂前端库

grug make htmx and hyperscript to avoid
grug 通过 htmx 和 hyperscript 来避免

keep complexity low, simple html, avoid lots javascript, the natural ether of spirit complexity demon
保持低复杂性，简单的 html，避免大量 javascript，这是精神复杂性的自然领域，是恶魔

maybe they work for you, but no job post, sorry
也许它们对你有用，但没有工作机会，抱歉

react better for job and also some type application, but also you become alcolyte of complexity demon whether you like or no, sorry such is front end life
对工作有更好的反应，也有一些类型的应用，但你无论如何都会成为复杂恶魔的祭司，抱歉，这就是前端生活的样子

fads  潮流

grug note lots of fads in development, especially front end development today
格鲁笔记开发中有许多潮流，尤其是今天的前端开发

back end better more boring because all bad ideas have tried at this point maybe (still retry some!)
后端更好更无聊，因为所有糟糕的想法都已经被尝试过了，也许（仍然会尝试一些！）

still trying all bad ideas in front end development so still much change and hard to know
前端开发仍然在尝试所有糟糕的想法，所以仍然有很多变化，很难知道

grug recommend taking all revolutionary new approach with grain salt: big brains have working for long time on computers now, most ideas have tried at least once
格鲁建议对革命性的新方法持谨慎态度：聪明的大脑已经在计算机上工作很长时间了，大多数想法至少都尝试过一次

grug not saying can't learn new tricks or no good new ideas, but also much of time wasted on recycled bad ideas, lots of spirit complexity demon power come from putting new idea willy nilly into code base
格鲁不是说不能学习新技巧或没有好的新想法，但很多时候浪费在重复的糟糕想法上，很多精神复杂性恶魔力量来自于随意将新想法放入代码库

fear of looking dumb 害怕看起来很笨

note! very good if senior grug willing to say publicly: "hmmm, this too complex for grug"!
注意！如果资深 grug 愿意公开说：“嗯，这个对 grug 来说太复杂了！”那就非常好！

many developers fear of looking dumb (fold), grug also at one time fold, but grug learn get over: very important senior grug say "this too complicated and confuse to me"
许多开发者害怕看起来很笨（fold），古鲁也曾经有过 fold，但古鲁学会了克服：一位非常重要的资深古鲁说“这对我来说太复杂和困惑了”

this make it ok for junior grugs to admit too complex and not understand as well, often such case! fold major source of complexity demon power over developer, especially young grugs!
这让初级 grug 可以承认太复杂且理解不够，这种情况经常发生！fold 是复杂的主要来源，恶魔般的权力对开发者，尤其是年轻的 grug 造成很大影响！

take fold power away, very good of senior grug!
剥夺 fold 权力，资深 grug 做得很好！

note: important to make thinking face and look big brained when saying though. be prepare for big brain or, worse and much more common, thinks is big brain to make snide remark of grug
注意：虽然说话时要注意做出思考的表情和大脑的样子。要准备好迎接大脑发达的人，或者更糟糕且更常见的情况，认为自己是大脑发达的人来对 grug 做尖刻的评论

be strong! no fold!
要坚强！不要屈服！

club sometimes useful here, but more often sense of humor and especially last failed project by big brain very useful, so collect and be calm
有时候俱乐部很有用，但更多时候，幽默感尤其是一个大失败项目非常有用，所以收集信息并保持冷静

impostor syndrome  冒名顶替综合症

grug note many such impostor feels in development
格鲁注意到很多开发人员都有类似的冒名顶替者感觉

always grug one of two states: grug is ruler of all survey, wield code club like thor or grug have no idea what doing
格鲁总是处于两种状态之一：要么格鲁是所有调查的统治者，像托尔一样挥舞代码俱乐部，要么格鲁完全不知道自己在做什么

grug is mostly latter state most times, hide it pretty well though
grug 大部分时候处于后期状态，不过隐藏得很好

now, grug make softwares of much work and moderate open source success , and yet grug himself often feel not any idea what doing! very often! grug still fear make mistake break everyone code and disappoint other grugs, imposter!
现在，格鲁制作了很多软件，也有一定的开源成功，但格鲁自己却常常不知道自己在做什么！经常这样！格鲁仍然害怕犯错导致所有人的代码崩溃，让其他格鲁失望，成为冒牌货！

is maybe nature of programming for most grug to feel impostor and be ok with is best: nobody imposter if everybody imposter
这也许是大多数格鲁编程的自然状态，感觉自己是冒牌货，并且对此感到可以接受：如果每个人都觉得自己是冒牌货，那么就没有真正的冒牌货了。

any young grug read this far probably do fine in program career even if frustrations and worry is always to be there, sorry
任何读到这里的年轻格鲁，即使有挫折和担忧，在编程生涯中也会做得很好，对此我表示歉意

reads  阅读

grug like these:  喜欢这些 grug：

• worse is better  更糟就是更好
• worse is better is worse
  更糟就是更糟
• is worse really better?
  更糟真的更好吗？
• a philosophy of software design
  软件设计哲学

conclusion  结论

you say: complexity very, very bad
你说：复杂度非常非常糟糕