超越语法

虽然不可避免的要与任何编程语言的语法作斗争，但这是学习如何充分利用该语言的最平常的一个方面。一个语言的语法往往是静态的，并且如果你搞错了编译器会报错。更深入的教训是一个语言最适合解决什么样的问题（”用正确的工具做正确的事“），并且用该语言写出更好的代码使其更高效以及可维护。

有很多方法可以选择一门新的语言，课程、教程、导师、书籍以及更多。当我学习一门新的语言时通常会使用这些选项的组合。有一点我注意到，当涉及到非语法元素时，它们通常非常相似，显然会遵照推荐的做法。

当你阅读到他人实际部署的代码时，你会得到更多。超越正常安排的学习之外还会学到模式和实践。在一个语言中做一件事的“正确”方法通常不是让其更好地工作。你会观察边界场景、一次性的以及非预期的集成。你会发现解决这些问题的方案，好的和坏的，但是当你真正地思考它的时候，就会产生“建议实践”，今天的模式就是明天的反模式。

你可能对于比如“总要注释”、"逗号放在末尾"、“缩进x个空格”这样的事有很深的感情，当然你是“对的”，反正我对这些以及编程的其他方面都有很深的感情。

当我读到他人的代码时，我会生气于“他们做错了”。当我读更多的时候，我开始理解了在他人的代码中常有，而我没有遇到过以及在我的方式中没有必要更难做，这样的情况是存在的。我不仅改变了我的一些想法，而且还学得更灵活。

开源无处不在

因为开放源代码运动的发展，可供阅读和学习的源代码量也在增加。从Gitlab、GitHub以及BitBucket这样的站点上我们可以拉取全功能的应用，不仅可以阅读而且可以捣鼓它。我很少遇到那些我想学习而至少是可用的开源代码中却没有的情况。

我记得刚开始一个新的语言时，会强调一些比如目录结构以及命名约定等一些简单的事情。现在我去看一些不同的开源项目并且会开始将一些共同的方法拼凑在一起。我很少会再强调这些类型的事情。

今天，有这么多的代码可用，有好的也有不好的。当你学习时，你不会真正地知道哪个是哪个。只要保持阅读你就会说出他们的不同。阅读“不好”的代码可以帮助你理解他为什么“不好”，关键是不要害怕去尝试任何你认为是正确的事，出错的时候承认错误，然后修正它继续前进。

不好的代码就是不好的, 好的就是好的?

有人会说“’不好的‘代码比’好的‘代码多。”，这个sub-reddit 就致力于不好的代码。

过去的几年中，我写了很多好的和不好的代码。当我看我的旧代码时，我经常会佩服我自己怎么会写出如此垃圾的代码。这实际上意味着我还在学习，如果我看我的旧代码而且感觉很好，这就意味着我已不再成长。

那么我们如何从不好的代码中学习呢？

不好的代码读得越多，你会发现它越好

当你学习以及检索示例时，你会发现并使用了大量的无法完全工作的代码，记住，只是因为它无法适用你的场景，而不是因为它不好，学习如何让它正常工作可以使你变得更好。

如何判断它的好坏？

人们热衷于批判。如果在评论区你看到很多“这什么玩意儿”说明你看到的可能就是烂代码，但请找出它烂在哪里。不要成为只会评论“代码真烂”的喷子。不要自认为你了解这段代码的所有细节，代码写成这样也有可能是由于其他特殊原因。如果你找出了它的“烂”点，还是留下个有建设性的评论吧，或者...

试着完善下

提交一个有所改善的PR(pull request)。修正错误的语法，提出一个较好的方法，添加注释或修正代码的缩进；这些方法都会有所帮助。在提交时顺便为做出的变动添加适当的解释。

在帮助其他人的同时我也学到了很多。如果自认为理解了某个东西我仍要找其他人解释下，这会使我加深对它的认识，并且能及时发现是否有所误用。

回到主题

记住，开源的作用只有在参与中才能体现。大部分项目都欢迎对代码的改动，但做出贡献有很多方式。

参与测试并提交bug；帮助完善项目文档；编写教程与how-to示例；加入项目讨论——或者简单地帮其推广。这些都会有所帮助，参与越多效果越好。

其他资源

这里有一些链接能帮你入门。一些是我参与过的，还有一些是我没研究过的。如果你在本文中发现有用或不当之处，请不吝赐教。

• DinoDate

• LiveSQL

• Open Source Society University

• Free Code Camp

• opensource.com

• Getting Started With GitLab

• GitHub Guides

• moodle.org

• PL/SQL Challenge