学会将代码写简单
为开源项目作出贡献的最佳方式是使它的代码得以精简。我们应当努力编写即使没有注释也能使新手程序员轻松理解的代码，让维护者无需花费太多精力也能轻松维护。
在学生时代，我们乐于使用更加复杂的技巧去解决新的难题。首先，我们学会了循环，再是函数，接着是类… 当我们得到提高，能够用更高级的技术写更长的代码时，我们得到的是称赞。我们发现有经验的程序员使用 monad，而新手使用 for 循环。
当我们出生社会，在工作中或者在开源项目中与他人合作时。我们使用在学校学到的各种玄酷技能自豪地给出解决方案的代码实现。
“啊哈！我可以扩展这个项目，并实现 X 功能！我这里用到了继承！我真TM牛逼！！” ε٩(๑> ₃ <)۶ з
我们实现了某个小功能，很有成就感，并有充分的理由相信自己很牛逼。但在实际工程中的编程却不仅仅是实现某某功能这么简单。以我个人的经验而言，写代码使我感到开心与自豪，并且我十分乐意向世界展示我所知道的一切。有例为证，这里是用另一种元编程语言构建的线性代数语言。(注意，这玩意已经很多年没人碰过了)
在自己维护过代码后，我的观点发生了变化。
-
我们不应该去刻意的追求如何构建软件。软件是我们用来解决问题的手段，而解决问题才是我们的真正目标。我们应当围绕着需要解决的问题构建出尽可能小的软件。
-
我们应当尽可能使用更简单的技术，以便于人们以更少的学习成本去使用或者扩展它。当然，在我们不知道如何使用更简单的技术去实现它时，也可以使用更高级的技术。
这不是什么新鲜的观点。我身边的每个人都或多或少的赞同这些观点，但不知道为什么，当我们为一个新的项目贡献代码时又会忘记这些原则。总是本能的想用复杂的技术去实现功能。
软件是一种付出🔗
你写的每一行代码都需要耗费时间。当然，也许你很乐意花费你的时间。但是，你的代码在被审阅时也是需要花时间的，审阅者需要花费时间来阅读并理解它们。未来的维护者也需要花费时间维护和修改你的代码。他们本可以利用这些时间来晒晒太阳陪陪家人的。
所以，当你向某个项目提交代码时，请务必心怀谦恭。多为他人着想同时也会得到他人的理解和尊重。将代码写少是很难的，但你的付出会减轻别人的负担。
{{< notice info “这段有一个吃饭的例子，我不知道怎么翻译，就稍微改写了一下。原文如下：” >}}
It should feel as though you are eating with your family and there isn’t enough food on the table. You should take only what you need and no more. The people with you will respect you for your efforts to restrict yourself.
{{< /notice >}}
越复杂的技术越难以维护🔗
作为学生，我们通过使用复杂的技术来证明自己的能力。这体现在我们有能力在开源项目中使用函数、类、高阶函数、monads 等。我们在向同行展示自己的解决方案时，并常常因为自己所用的技术高低而感到自豪或卑微。
然而，在现实的团队合作项目中，情况却正好相反。现在，我们尽可能使用简单的方法去解决问题。简单的方法能够使得即使是新手程序员也能轻松地扩展我们的代码以解决其他问题。简单的代码能够让人快速上手并让我们脱颖而出。我们通过使用简单的技术解决问题来体现我们的价值。
“看！我用 for 循环代替了原来的递归函数并且达到了我们的需求。我知道这样不够优雅，但我注意到我们新来的实习生在这里似乎会遇到麻烦，我觉得这样改应该会有所帮助吧！ ”(๑•̀ㅂ•́)و✧
真正牛逼的人是不需要证明自己有多牛逼的。你可以通过以简单的方式来解决问题来体现你的价值，这样你的团队中的每个人都会在未来受益于此。
当然，有所节制🔗
话虽这么说，但是过度坚持“使用简单的代码解决问题”的教条可能会适得其反。通常，使用递归的解决方法要比使用 for 循环的解决方法更简洁，用类或 monad 也是正确的方法。还有两种情况另当别论，为满足自己需求而写的系统 (软件)，或是软件使用者没有任何编程经验的情况 (不存在 2 次开发的可能)
学生党一枚，翻译上有任何问题还请多多指教 _(:з)∠)_
译者：Mogeko
原文作者：Matthew Rocklin
原文地址：http://matthewrocklin.com/blog/work/2018/01/27/write-dumb-code