编写代码。 不会太多 主要是功能。

587布兰登·史密斯（Brandon Smith）着有作者迈克尔·波伦（Michael Pollan）的一句名言：“饮食”。不会太多主要是植物。＆＃34;我喜欢它是因为它不会试图教条化：它封装了一些基本的指导原则，可在90％的时间内使您90％地达到目标。维基百科描述了引用的书（重点是我的）：

他解释了...这样一种观念，即营养主义以及整个西方框架，通过这种框架我们可以认识到食物的价值，这更是对简单解决方案神话的一种虔诚的奉献精神，而不是令人信服且可靠的科学研究结论。

代码就像食物一样，具有价值。我认为我们中的人可以（希望）对此表示同意。但是，有些人太害怕写作/吃东西，以至于避免写作/吃应该吃的东西。

在编程的上下文中，我认为这转化为对复制的不健康恐惧（对于某些人而言也是这样）。一点重复-用完全没有使简洁性最大化的方式写东西-不是世界末日。有时，这是前进的最佳途径。有时可以在这里和那里进行复制和修改，尤其是当您仍在弄清楚您的应用程序最终将是什么样的时候。

当然，过多的代码（例如过多的食物）也可能是一件坏事。这是一个很容易理解的话题，所以我觉得在这里不必做太多讨论。

只要注意您的项目的胃口：写出需要写的东西，然后尽量不要沉迷于此。

通过＆＃34;功能＆＃34;这里我指的是“纯函数”。您可以证明纯函数不是＆＃34;植物＆quot;代码，尽管我认为它们是。以我的经验，大多数代码库都有一个纯功能子集，我相信以纯功能样式编写该子集几乎永远是项目长期健康的胜利。

当然，限定词是“大多数”：这不是教条。编写100％的功能系统（如果需要的话，可以使用纯素食）通常需要您跳过一堆额外的箍以获得所需的所有功能。仅从健康的角度来看，那些额外的并发症可能不值得。

然后不同的项目有不同的需求：就像运动员可能需要更多百分比的蛋白质，或者个人可能有某些营养不足一样，一个项目可能只包含很小的功能子集，或者可能无力承担返回新价值的机会每次都是由于数据大小或性能敏感性。这没有错。

他认为，美国人现在在超市，快餐店和餐馆购买的大多数食品实际上都不是食品，而实用的窍门是只吃那些祖母一代人会认为是食品的东西。 。

冒着扩大类比的风险，可能等效的方法是仅对初级人员会认识到的事情进行编码。用简单明了的术语编码。不要太聪明，制造人造成分。尽可能使用那里的原语。写出简单，自然，人性化的东西。