Added chinese version

LANGS.md

@@ -2,3 +2,4 @@
 * [русский язык](ru)
 * [Türkçe](tr)
 * [Persian(فارسی)](fa)
+* [Chinese(中文)](cn)

cn/README.md

@@ -0,0 +1,11 @@
+每个程序员都应该知道的97件事
+======
+
+*从顶级专家那里收集到的程序员智慧的结晶。*
+
+
+这是['97 Things Every Programmer Should Know' project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know)的GitBook版本。
+
+所有内容均根据[Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/)获得许可。本书的印刷版可在[Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484)上找到。
+
+如果您发现任何错误或有任何建议，可以[创建问题](https://github.com/97-things/97-things-every-programmer-should-know/issues)或者[提交拉取请求](https://github.com/97-things/97-things-every-programmer-should-know/pulls)到[仓库](https://github.com/97-things/97-things-every-programmer-should-know).

cn/SUMMARY.md

@@ -0,0 +1,101 @@
+# 摘要
+
+* [简介](README.md)
+
+1. [谨慎行事](thing_01/README.md)
+2. [应用函数式编程原则](thing_02/README.md)
+3. [问“用户会做什么？”（您不是用户）](thing_03/README.md)
+4. [自动化您的编码规范](thing_04/README.md)
+5. [简约中蕴含美感](thing_05/README.md)
+6. [在你重构代码之前](thing_06/README.md)
+7. [警惕代码共享](thing_07/README.md)
+8. [男童军规则](thing_08/README.md)
+9. [在责怪他人之前先检查自己的代码](thing_09/README.md)
+10. [谨慎选择工具](thing_10/README.md)
+11. [用领域语言编写代码](thing_11/README.md)
+12. [代码即设计](thing_12/README.md)
+13. [代码布局的重要性](thing_13/README.md)
+14. [代码评审](thing_14/README.md)
+15. [使用理性进行编码](thing_15/README.md)
+16. [对注释的评论](thing_16/README.md)
+17. [只注释代码无法表达的内容](thing_17/README.md)
+18. [持续学习](thing_18/README.md)
+19. [便利不是一种特性](thing_19/README.md)
+20. [提早且经常部署](thing_20/README.md)
+21. [将业务异常与技术异常区分开来](thing_21/README.md)
+22. [进行大量的刻意练习](thing_22/README.md)
+23. [领域特定语言](thing_23/README.md)
+24. [不要害怕打破事物](thing_24/README.md)
+25. [不要在测试数据中搞怪](thing_25/README.md)
+26. [不要忽略那个错误！](thing_26/README.md)
+27. [不仅学习语言，还要理解其文化](thing_27/README.md)
+28. [不要将你的程序固定在直立位置](thing_28/README.md)
+29. [不要依赖于“这里发生了魔法”](thing_29/README.md)
+30. [不要重复自己](thing_30/README.md)
+31. [不要碰那段代码！](thing_31/README.md)
+32. [封装行为，而不仅仅是状态](thing_32/README.md)
+33. [浮点数不是实数](thing_33/README.md)
+34. [用开源实现你的抱负](thing_34/README.md)
+35. [API设计的黄金法则](thing_35/README.md)
+36. [偶像迷思](thing_36/README.md)
+37. [努力工作并不能带来好结果](thing_37/README.md)
+38. [如何使用错误跟踪器](thing_38/README.md)
+39. [通过删除代码来改善代码](thing_39/README.md)
+40. [安装我](thing_40/README.md)
+41. [进程间通信对应用响应时间的影响](thing_41/README.md)
+42. [保持构建的清洁](thing_42/README.md)
+43. [Know How to Use Command-line Tools](thing_43/README.md)
+44. [Know Well More than Two Programming Languages](thing_44/README.md)
+45. [Know Your IDE](thing_45/README.md)
+46. [Know Your Limits](thing_46/README.md)
+47. [Know Your Next Commit](thing_47/README.md)
+48. [Large Interconnected Data Belongs to a Database](thing_48/README.md)
+49. [Learn Foreign Languages](thing_49/README.md)
+50. [Learn to Estimate](thing_50/README.md)
+51. [Learn to Say "Hello, World"](thing_51/README.md)
+52. [Let Your Project Speak for Itself](thing_52/README.md)
+53. [The Linker Is not a Magical Program](thing_53/README.md)
+54. [The Longevity of Interim Solutions](thing_54/README.md)
+55. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md)
+56. [Make the Invisible More Visible](thing_56/README.md)
+57. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md)
+58. [A Message to the Future](thing_58/README.md)
+59. [Missing Opportunities for Polymorphism](thing_59/README.md)
+60. [News of the Weird: Testers Are Your Friends](thing_60/README.md)
+61. [One Binary](thing_61/README.md)
+62. [Only the Code Tells the Truth](thing_62/README.md)
+63. [Own (and Refactor) the Build](thing_63/README.md)
+64. [Pair Program and Feel the Flow](thing_64/README.md)
+65. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md)
+66. [Prevent Errors](thing_66/README.md)
+67. [The Professional Programmer](thing_67/README.md)
+68. [Put Everything Under Version Control](thing_68/README.md)
+69. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md)
+70. [Read Code](thing_70/README.md)
+71. [Read the Humanities](thing_71/README.md)
+72. [Reinvent the Wheel Often](thing_72/README.md)
+73. [Resist the Temptation of the Singleton Pattern](thing_73/README.md)
+74. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md)
+75. [Simplicity Comes from Reduction](thing_75/README.md)
+76. [The Single Responsibility Principle](thing_76/README.md)
+77. [Start from Yes](thing_77/README.md)
+78. [Step Back and Automate, Automate, Automate](thing_78/README.md)
+79. [Take Advantage of Code Analysis Tools](thing_79/README.md)
+80. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md)
+81. [Test Precisely and Concretely](thing_81/README.md)
+82. [Test While You Sleep (and over Weekends)](thing_82/README.md)
+83. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md)
+84. [Thinking in States](thing_84/README.md)
+85. [Two Heads Are Often Better than One](thing_85/README.md)
+86. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md)
+87. [Ubuntu Coding for Your Friends](thing_87/README.md)
+88. [The Unix Tools Are Your Friends](thing_88/README.md)
+89. [Use the Right Algorithm and Data Structure](thing_89/README.md)
+90. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md)
+91. [WET Dilutes Performance Bottlenecks](thing_91/README.md)
+92. [When Programmers and Testers Collaborate](thing_92/README.md)
+93. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md)
+94. [Write Small Functions Using Examples](thing_94/README.md)
+95. [Write Tests for People](thing_95/README.md)
+96. [You Gotta Care about the Code](thing_96/README.md)
+97. [Your Customers Do not Mean What They Say](thing_97/README.md)

cn/thing_01/README.md

@@ -0,0 +1,15 @@
+# 谨慎行事
+
+> *"不论你从事什么事情，你都要谨慎行事并考虑后果。" ——匿名*
+
+无论在迭代开始时的进度看起来有多舒适，你都无法避免在某些时候面临压力。如果你发现自己不得不在“做正确的事”和“快速完成”之间做选择，通常会倾向于“快速完成”，并理解到之后会回来修复它。当你向自己、团队和客户做出这个承诺时，你是认真的。但往往下一个迭代会带来新的问题，你会专注于解决它们。这种推迟工作的现象被称为技术债务，它并不是你的朋友。特别是，在马丁·福勒（Martin Fowler）的[技术债务分类法](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html)中，这被称为有意的技术债务，不应与无意的技术债务混淆。
+
+技术债务就像一笔贷款：在短期内你从中获益，但你必须支付利息直到它完全偿还。代码中的捷径使得添加功能或重构代码更加困难。它们是缺陷和脆弱测试用例的滋生地。你拖延修复的时间越长，问题就会变得越糟。当你开始着手解决最初的问题时，可能已经有一堆不太正确的设计选择堆叠在原始问题之上，使得代码更难以重构和修正。事实上，通常只有当情况变得非常糟糕，你必须去修复它时，你才会真正回去修复它。而到那时，修复它通常非常困难，你真的无法承担时间或风险。
+
+有时为了满足截止日期或实现一个功能的核心部分，你必须承担技术债务。尽量不要陷入这种境地，但如果情况绝对需要，那就继续前进吧。但是（这是一个重要的但是），你必须跟踪技术债务并迅速偿还，否则情况会迅速恶化。一旦你做出妥协的决定，写下一个任务卡片或在问题追踪系统中记录下来，以确保它不会被遗忘。
+
+如果你在下一个迭代中安排了偿还技术债务，成本将是最低的。如果不偿还债务，利息将累积，而这些利息应该被跟踪，以使成本可见。这将强调项目技术债务对业务价值的影响，并使得偿还得以适当地优先考虑。如何计算和跟踪利息的选择将取决于具体的项目，但你必须进行跟踪。
+
+尽快偿还技术债务是明智的选择，不偿还将是不明智的。
+
+由 [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose)撰写

cn/thing_02/README.md

@@ -0,0 +1,19 @@
+# 应用函数式编程原则
+
+函数式编程最近在主流编程社区中重新引起了关注。部分原因是因为函数式范式的*不断涌现的特性*非常适应我们行业向多核心转变的挑战。然而，尽管这是一个重要的应用领域，但本文提醒你*了解函数式编程*的原因并不仅限于此。
+
+精通函数式编程范式可以极大地提高你在其他环境中编写代码的质量。如果你深入理解并应用函数式范式，你的设计将表现出更高程度的*引用透明性*。
+
+引用透明性是一个非常理想的特性：它意味着函数在给定相同输入的情况下始终产生相同的结果，无论它们在何时何地被调用。也就是说，函数的求值不依赖于可变状态的副作用，或者理想情况下几乎不依赖于副作用。
+
+命令式代码中缺陷的主要原因之一是可归因于可变变量。阅读本文的每个人都曾经调查过为什么在特定情况下某个值不如预期。可见性语义可以帮助减轻这些隐匿的缺陷，或者至少大大缩小其位置范围，但它们的真正罪魁祸首实际上可能是采用了过多可变性的设计。
+
+在这方面，我们当然没有得到行业的太多帮助。面向对象的介绍在默默地推广这样的设计，因为它们经常展示由相对持久的对象图组成的示例，这些对象愉快地相互调用着修改器方法，这可能是危险的。然而，通过敏锐的测试驱动设计，尤其是在确保["Mock Roles, not Objects"](http://www.jmock.org/oopsla2004.pdf)的情况下，不必要的可变性可以被设计消除。
+
+最终的结果是一种设计，通常具有更好的职责分配，其中包含更多、更小的函数，这些函数作用于传递给它们的参数，而不是引用可变成员变量。缺陷将更少，而且通常更容易调试，因为在这些设计中，定位引入错误值的位置比推断导致错误赋值的特定上下文更容易。这导致了更高程度的引用透明性，没有什么比学习一个函数式编程语言更能深入理解这些思想，因为在这种计算模型中，这是常态。
+
+当然，并不是所有情况下都适用这种方法。例如，在面向对象系统中，与用户界面开发相比，这种风格通常在领域模型开发（即，协作有助于分解业务规则的复杂性）中产生更好的结果。
+
+精通函数式编程范式，以便能够审慎地将所学到的教训应用于其他领域。你的对象系统（其中之一）将与引用透明性的优点相一致，比许多人认为的更接近函数式的对应物。实际上，有些人甚至断言函数式编程和面向对象编程的巅峰实际上*只是彼此的一种反映*，一种计算上的阴阳形式。
+
+由[Edward Garson](http://programmer.97things.oreilly.com/wiki/index.php/Edward_Garson)撰写

cn/thing_03/README.md

@@ -0,0 +1,16 @@
+# 问“用户会做什么？”（您不是用户）
+
+我们往往会假设其他人与我们思考方式相同，但事实并非如此。心理学家称之为错误的共识偏差。当人们的思维或行为与我们不同的时候，我们很可能会将他们（下意识地）标记为某种缺陷。
+
+这种偏见解释了为什么程序员很难站在用户的立场上。用户的思维方式与程序员不同。首先，他们使用计算机的时间要少得多。他们既不了解也不关心计算机的工作原理。这意味着他们无法利用程序员熟悉的一系列问题解决技巧。他们无法识别程序员用来处理、通过和绕过界面的模式和线索。
+
+了解用户思维方式的最佳方法是观察用户。请用户使用类似于您正在开发的软件完成一个任务。确保该任务是真实的：“把一列数字相加”可以，而“计算上个月的开销”更好。避免任务过于具体，比如“您能够选择这些电子表格单元格并在下面输入*SUM*公式吗？”——这个问题中有一个很大的线索。让用户讲述他们的进展过程。不要打断。不要试图提供帮助。不断问自己“他为什么这样做？”和“她为什么不这样做？”。
+
+你首先会注意到的是，用户在核心任务上有相似的行为。他们尝试按照相同的顺序完成任务，而且在相同的地方犯相同的错误。您应该围绕这种核心行为进行设计。这与设计会议不同，会议上人们往往会因为说“如果用户想要……会怎样？”而被听取。这会导致复杂的功能和对用户需求的困惑。观察用户消除了这种困惑。
+
+你会看到用户陷入困境。当你陷入困境时，你会四处张望。而当用户陷入困境时，他们会将注意力集中在一个狭窄的范围内。这使得他们很难在屏幕的其他地方找到解决方案。这也是为什么帮助文本不是解决用户界面设计问题的好方法之一。如果必须提供说明或帮助文本，请确保将其放在问题区域的旁边。用户狭窄的注意力焦点是为什么工具提示比帮助菜单更有用的原因。
+
+用户往往会混淆地继续进行。他们会找到一种可行的方式，不管多么复杂，就会坚持使用。提供一种非常明显的操作方式比提供两种或三种快捷方式要好。
+您还会发现用户说他们想要什么和他们实际做的有差距。这令人担忧，因为通常获取用户需求的常规方法是询问他们。这就是为什么捕捉需求的最佳方法是观察用户。观察用户花费一个小时的时间比花费一天的时间来猜测他们想要什么要更有信息量。
+
+由[Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne)撰写

cn/thing_04/README.md

@@ -0,0 +1,20 @@
+# 自动化您的编码规范
+
+你可能也有过这样的经历。在项目开始时，每个人都有很多良好的意图 - 可以称之为“新项目的决心”。很多时候，这些决心都被写在文件中。关于代码的那些决心最终会被写入项目的编码规范中。在启动会议上，首席开发人员会浏览文件，并且在最好的情况下，每个人都同意尽量遵守这些规范。然而，一旦项目开始进行，这些良好的意图一个接一个地被抛弃。最终交付的代码看起来一团糟，似乎没有人知道它是如何变成这样的。
+
+什么时候出了问题？可能已经在启动会议上。项目成员中有些人没有注意。其他人没有理解其中的要点。更糟糕的是，有些人持不同意见，已经在计划他们的编码规范反抗。最后，有些人理解了其中的要点并同意，但是当项目压力过大时，他们不得不放弃某些规范。对于一个希望获得更多功能的客户来说，格式良好的代码并不能给你带来额外的好处。此外，如果不能自动化执行编码规范，遵循编码规范可能是一项非常乏味的任务。试着手动缩进一个混乱的类，你就会明白这一点。
+
+但是，如果这是一个问题，为什么我们一开始要有编码规范呢？统一格式化代码的一个原因是，没有人可以通过私人的格式化方式来“拥有”一段代码。我们可能希望防止开发人员使用某些反模式，以避免一些常见的错误。总之，编码规范应该使项目中的工作更容易，并从一开始就保持开发速度。因此，每个人都应该对编码规范达成一致——如果一个开发人员使用三个空格缩进代码，而另一个开发人员使用四个空格，这是没有帮助的。
+
+有许多工具可以用于生成代码质量报告，记录和维护编码规范，但这并不是全部解决方案。应该在可能的情况下自动化并强制执行。以下是一些示例：
+
+- 确保代码格式化是构建过程的一部分，以便每个人在编译代码时自动运行它。
+- 使用静态代码分析工具扫描代码以查找不希望的反模式。如果发现任何反模式，就中断构建过程。
+- 学习配置这些工具，以便可以扫描您自己的项目特定的反模式。
+- 不仅要测量测试覆盖率，还要自动检查结果。同样，如果测试覆盖率过低，就中断构建过程。
+
+尝试将您认为重要的每个方面都做到这一点。您将无法自动化您真正关心的一切。对于那些无法自动标记或修复的事情，将它们视为编码规范的补充准则，这些准则是自动化的，但是请接受您和您的同事可能不会如此认真地遵守它们。
+
+最后，编码规范应该是动态的而不是静态的。随着项目的发展，项目的需求会发生变化，一开始可能看起来很聪明的做法，在几个月后可能就不再明智了。
+
+由[Filip van Laenen](http://programmer.97things.oreilly.com/wiki/index.php/Filip_van_Laenen)撰写

cn/thing_05/README.md

@@ -0,0 +1,27 @@
+# 简约中蕴含美感
+
+有一句名言我认为对所有软件开发人员来说都很重要，值得铭记在心：
+
+> *风格的美丽、和谐、优雅和良好的节奏取决于简约。* ——柏拉图
+
+我认为这句话简洁地概括了我们作为软件开发人员应该追求的价值观。
+
+在我们的代码中，我们追求以下几个方面：
+
+- 可读性
+- 可维护性
+- 开发速度
+- 难以捉摸的美感
+
+柏拉图告诉我们，所有这些品质的实现因素都是简约。
+
+什么是美丽的代码？这可能是一个非常主观的问题。对美感的感知在很大程度上取决于个人背景，就像我们对任何事物的感知一样。艺术教育背景的人对软件的美感有着不同的感知（或至少不同的接近方式），而科学教育背景的人倾向于谈论对称性和黄金比例，试图将事物归结为公式。根据我的经验，简约是双方争论中大部分观点的基础。
+
+想想你研究过的源代码。如果你没有花时间研究别人的代码，请立即停止阅读这篇文章，找一些开源代码来学习。真的！我是认真的！去搜索一下你所选择的编程语言中一些著名的、公认的专家编写的代码。
+
+你回来了吗？很好。我们刚才在哪儿？啊对了...我发现，与我产生共鸣、我认为美丽的代码具有一些共同的特点。其中最重要的是简约。我发现，无论整个应用程序或系统有多复杂，个别部分都必须保持简单。简单的对象具有单一职责，包含类似简单、专注的方法，具有描述性的名称。有些人认为每个方法只有五到十行代码的概念过于极端，而且有些编程语言很难做到这一点，但我认为这种简洁仍然是一个值得追求的目标。
+
+最重要的是，美丽的代码是简约的代码。每个个体部分都保持简单，具有简单的职责和与系统其他部分的简单关系。这是我们保持系统随着时间推移的可维护性的方式，通过简洁、简单、可测试的代码，保持整个系统的开发速度。
+美感源于简约。
+
+由Jørn Ølmheim撰写