如何提高团队编程水平？
过去一年半里，我在为Mendicant大学（Ruby开发者在线大学）工作。我与同学和员工一起建立了优秀的在线学习社区。美中不足的是，由于一开始我们对Mendicant的定位是逐步发展，所以短时间内没有达到我们预期数量的学员。
本文总结了一些Mendicant大学深受好评的方法。希望这些经验能帮助更多本地团队和在线团队，这样会有更多优秀的场所供程序员学习和成长。
强调个人目标与团队兴趣
在小团队里，只讨论眼下全球流行的IT技术，却忽略小组内部正在做的工作，这是对精力和潜力的极大浪费。而将关注的内容与团队成员正在参与的项目或日常工作中面临的问题联系起来，这样则会更加有效。
与其对一般性的问题进行讨论和学习，不如找出团队需要解决的一些具体问题。可以自己克服这些障碍，通过整合手头的资源可以更加有效地找到相关学习资料，或者组织相关人员进行讨论。
实践的方法有很多，其中有一种方法很有意思：在每次会议一开始，让大家谈一谈自己正在做什么、对什么比较感兴趣，这样大家可以依据兴趣进行组合。对于在线讨论组，可以使用wiki或者定期的邮件列表摘要来达到类似的效果。
实行正式的代码审查
不要空谈想法或策略，最好办法是坐下来、打开编辑器并准备好代码进行审查。通过向别人讲解自己的代码，你能从中学到很多东西。可以毫不夸张地讲，任何向他人教授知识的过程都能产生价值，哪怕仅仅是讲解编程习语或者命名规范这样的小知识也是如此。
如果代码太过粗糙不能进行有效的审查，可以通过编写一个简单的例子来展示你正在学习的核心概念。讨论的内容越具体，在与别人的交流中获得有价值信息的可能性越大。
倾向有理有据的争论
在编程社区里，依据权威（“某某说过……，因此……”）和流行观点（“大家都是这么做……”）的争论非常普遍，但最终都会偏离想要表达的观点。幸运的是，讨论代码有一种更为有效的方法。
对于给定问题讨论解决方法，明确问题背景是最重要的。不了解问题背景，就不清楚解决这个问题是使用锤子还是推土机更合适。明确问题背景后，对于给出的解决方案就有了可讨论的依据。
至此，剩下的事情就是比较不同解决方案权衡利弊。打个比方，你可能会说：“Sqlite易于使用，因为它不需要数据库服务器。但如果要处理GIS数据，你可能会选择PostgreSQL，因为PostGIS提供了很多有用功能”。这个说法虽然不是无懈可击，但比“Sqlite很烂，一定要使用PostSQL”要好一些。
有时候，你只是想表达一些纯粹的个人偏好，这没有问题。但在这个时候，如果能有一些理性讨论而不只是抒发个人感情，会更好地表达你的观点。在某些情况下，这能让你避开宗教般的争论。
寻找有效的练习和学习方法
每天都会涌现很多学习编程的新方法，它们被视作下一代革命性方法并受到推崇。同样你也会发现，通常人们现在学习和讨论的都是一些新技术。当然，这会让你错误地认为很重要并且迫切想要学习。如果追随他们，你会事倍功半因而不能踏实地做出有用的东西，到头来你会发现这些技术不过是过往云烟。
无论何时，尽可能地在学习新技术时为自己设定目标并动手实践。如果可能的话，可以用较低风险的项目试验新想法和新技术，这样会对自己以后大有裨益。如果你确实要花一些时间进行刻意练习而不是边工作边练习，请确保练习的目标是为了实际需要或是为了解决实际问题。例如：采用代码套路学习一门新语言或者文本编辑器新特性是一个好主意，但如果想要通过代码套路来获得意外收获就是一个糟糕的想法。虽然有时候方法不对也能碰巧解决问题，但在你进步的过程中不应该只是碰运气。
译注：代码套路(code kata)：由Dave Thomas 发明该词，源自日本空手道中的套路(kata)概念。代码套路是用来帮助程序员通过练习和重复来提高自己的编程技巧。
虽然上面提到的内容更多的是针对个人而不是在团队练习，但同样的目标也应当出现在你参与的任何团队活动中。无论何时，尽可能根据需要分成专注不同技术的小组，这样可以避免出现强迫一些成员练习或学习与其不相关或不感兴趣的内容。我们可支配的时间和精力是宝贵的，应当小心分配。
值得注意的是，这个建议并不意味着只关注狭窄的和现实的目标。对于理论研究或经典课题的深入学习同样适用，并且可以在团队活动中开展。不要为了模糊不清的兴趣去组织活动，将这些活动在某种程度上与个人内在目标联系起来是非常必要的。
在技术与社交之间建立良好的平衡
在任何组织里，没有交流很难建立起共同的文化，成员之间也不会分享自己的兴趣。然而，迄今为止我见到过太多的用户小组从像HackFest一样的盛会变得平淡无奇。如果团队的社交准则鼓励这种行为，就不会有深入的讨论和研究开始并延续下去。
译注：HackFest：每年一度的Apple II编程比赛，对所有参加KansasFest课程的成员开放。
以我个人的经验，可以在工作结束之后开展一些交流活动，或者将交流与工作安排在不同时间。在线社区也可以采取类似的方式，为工作和非正式交流分别设计一些活动。你不必像法西斯那样刻意强调之间的区别，但在未来前进的道路上一定要始终持有清晰的目标。
建立参与和分享的团队文化
了解你的团队，不仅要看团队成员在说什么，更要看他们在做什么。所以，尽可能地去突出团队成员的贡献，支持那些由积极协作完成的工作。不提倡由一个人完成主要工作，而其他人只是被动地接受信息。
就个人而言，我更喜欢能够碰撞出火花的讨论以及类似Hackfest的活动。只要能够专注于团队成员正在做什么，而不仅仅是重复别人说过或做过的事情都可以。同样地，我认为只要结构合理并且举止得体，组内讨论也同样可以非常有效。
在线团队也可以通过代码审查、文章讨论和问答的形式取得同样效果。
无论是与网络团队一起或是独自一人，在提高编程水平的过程中都可以参与开源软件开发和讨论。尽可能地鼓励你团队的成员公开并分享他们的成果，这会产生巨大的不同效果，会形成一个积极鼓励分享的氛围。当然，并非每个人都有时间经营他们自己的项目，或者为其他项目做出可观的贡献（比如提交一个很大的补丁程序）。但是，只要你听说某人提出一个bug或者报告了一个从未被发现过的问题，你就可以适时地坐下来，并且告诉他们如何编写最小的示例重现问题并提交一个bug。有的时候，几分钟的指导就可以让一些只会在推特上抱怨的人转变成为开源项目的积极贡献者。
了解社交习惯，切记不要排斥边缘团体
许多技术团队（在线团队和本地团队）都没有做到断绝一些相当令人尴尬的行为。虽然作为个体我们无法感受到这一点，作为团队我们一直觉得容忍这种排斥行为是一种犯罪，而这种排斥在大多数其他社会场合都是不能被容忍的。请记住，尽管参加技术会议的程序员主体是异性恋的、中产以上、20到30岁之间的男性白种人，但这个世界上还有很多同样热情、能够在技术上有建树的人并不属于这一类型。
这并不意味着需要过度地保持正确的政治方向或者放弃你的幽默感。这只意味着，如果你不能在各种其他群体面前开一些玩笑或发表一些言论，你同样要避免在程序员同伴面前说类似的话。还意味着，你同样需要在沟通之前检查一下自己对别人的文化假设。专注于别人能做什么，而不是他们与你有多大差别。
我在这篇文章里的大多数建议会自然地建立一种环境，这种环境能够吸引比我们目前服务的社区更为广泛的人群。但是我想在这里呼吁重视这个问题，它的重要性实在不容忽视。社区的组织者需要特别记住这些问题，因为它们是针对团队成员期望设置目标的绝佳机会。
在感到安全、受到欢迎和得到感激的氛围中，人们能工作和学习得最好。如果你团队中的每个成员都认同这种氛围，你最终会比那些令人感到被边缘化或没有感激的团队收获更多。