分享 The Rails Doctrine - 中文翻译
The Rails Doctrine 已经发布一段时间了，原文英文版本的由于内容有太多的复杂语言表达、形容词，以及牛逼的文风，估计很多熟练英文的人阅读起来都会显得吃力。
前一段时间由 @juanito 先翻译成了 繁体版本，然后我再基于繁体版本，以及对照英文原文（吃力啊）重新捋了一下按照简体中文的表达方式翻译了一下。
这篇呕心沥血（指原文）的长文，是 DHH 对社区内以及社区外的开发者描述 Rails 的核心价值观、教条（或者我觉得甚至可以把它看成 Rails 或 Ruby 社区的《圣经》）。里面清楚了解释了以往你会对 Rails 的某些决定的质疑。让你看清 Rails 社区的设计实现理念，目标。
以往那些忠实的 Rails 粉丝，当你遇到一些外面的质疑或挑战的时候，或许你不知道该用什么样的语言来解释 Rails 为何要这么做（哪怕你心里知道它的价值和意义，只是无法表达出来），这篇文章中的很多观点或许正是你在哪种时刻想要说的话。
强烈大家细细阅读：
GitHub 参与排错
感谢！哈哈。
Ruby 可以用 exit 和 quit，来回应程序员的需求，也就是想离开终端交互界面。另一方面 Python 则迂腐的告诉程序员如何做该做的事，即便它已经知道程序员想干嘛了（却只显示错误信息）。这是非常清晰的、小的、最惊讶原则的例子。
有几处 Typo
另一个例子只用了些许代码实现，却几乎引发了惊愕的程度。Array#second 到 #fifth（以及挑衅意味的 #forty_two）。这些 别买 的存取器，非常严重的冒犯了常发表意见的支持者，说：这简直太过度设计了（几乎是编程时代的结束），这些写成 Array#[1]、Array#[2]（以及 Array[41]）不就可以了嘛。
-
更糟糕的是，当系统过早解耦，或是过早拆成小服务，以及更糟糕的拆成 Microservices。这是现代网络应用的错误认知，你只会反复的重造系统：同样的功能在后端做一次，在端再做一次，在 Native 手机端又再次实现一次等等。这不是自然规律，你也不需要这样。
但框架要是只是厚重的教科书就不可能了，新的应用好比一张白纸。蛋蛋 是要理解从那开始，如何起步，就需要花费巨大的努力。
揪个小错误。开始还没会过来，想着 DHH 文风果然狂野……
前两天刚看的繁中版
many thanks !
有几处 Typo
纵然有好的时机，时间久了也会影响也会逐渐减少
纵然有好的时机，时间久了影响也会逐渐减少
废话不多说，一下是由我所认为
废话不多说，以下是由我所认为
用一种方法，最好只有一种方法来完成一件事就
用一种方法，最好只有一种方法来完成一件事
问问 JRuby 哪些试着要对 Ruby 逆向工程的人看看
问问 JRuby 那些试着要对 Ruby 逆向工程的人看看
以及哪些跟 Matz 一样对同样事物感到惊讶的人
以及那些跟 Matz 一样对同样事物感到惊讶的人
纠结该拉那条线才是正确的
纠结该拉哪条线才是正确的
就好比大家昨晚七点抖看了某个节目
就好比大家昨晚七点都看了某个节目
而是要把优美纳入优先考2量
而是要把优美纳入优先考量
里面通常穿插于 Ruby 本身的管用式和自定义的 DSL 威力之间
里面通常穿插于 Ruby 本身的惯用语法和自定义的 DSL 威力之间
剩下的就交给框架来处理，该去哪里，该调用那个方法
原文是：
and the framework can do all the plumbing that goes around that, and know this is the method to call
改成“框架会处理其他相关的事情，然后会调用这个方法”会不会好点？
但这有背于大部分软件工程师对其他同事的想法
但这有悖于大部分软件工程师对其他同事的想法
我们我们有足够的信心启发下一代的软件工程师，并且有勇气相信他们
我们有足够的信心启发下一代的软件工程师，并且有勇气相信他们
但凡让有点能力的人来实用 Concern
但凡让有点能力的人来使用 Concern
尚未学会实用这些实用工具的软件工程师
尚未学会使用这些实用工具的软件工程师
以及该怎么根据实际场景来实用不同的工具，有时甚至实用危险工具
以及该怎么根据实际场景来使用不同的工具，有时甚至使用危险工具
原因知道帮助任何人，让学习组一步步成为大师。
原文是：
willing to help and guide anyone to experthood
翻译成“愿意帮助和指导任何人，让他们走上大师之路”会不会好点？
Rails 可以在很多场景下实用
Rails 可以在很多场景下使用
同样的功能在后端做一次，在端再做一次
同样的功能在后端做一次，在前端再做一次
可以我们从大局来看，这件事仍然是值得的选择
可是我们从大局来看，这件事仍然是值得的选择
这些工作不知有 Rails 需要，广大的 Ruby 社区也需要
这些工作不只有 Rails 需要，广大的 Ruby 社区也需要
许多人用代码或是胜思熟虑的论证来提供意见
许多人用代码或是深思熟虑的论证来提供意见
这篇基本信条描述着一种理想形式时，不过日常生活中的实际情况却更微妙（有趣）。Rails 可以包容尊重这样庞大的社区，是因为我们几乎不实验任何的一份子。
原文是：
So while this doctrine has described an idealized form, the everyday reality is much more nuanced (and interesting). Rails is capable of supporting such a large community under one tent exactly because there are so few if any litmus tests.
不结合上下文，很难看懂翻译过后的文字。
翻译成“这篇基本信条描绘出一种理想状况，但日常生活中的实际情况却更微妙（也更有趣），正因为 Rails 几乎从来不考验每一个想法，它才能包容下这样庞大的社区”会不会好点？
谢谢，翻译
像下面那样可能有些人觉得无所谓的细节，却是正是 Rails 走心的地方。
正是像midnight beginning_of_day noon middle_of_day这样的方法的存在，让我在写代码的时候多了一份追求 
有时候优美的代码反而更玄乎。不是要追求写得多短多短，或是多厉害，而是读起来要有节奏感。
if people.include? person ... if person.in? people
