与 Chris Maunder 的程序员访谈

欢迎来到我们持续进行的 Code Project 面试系列，在这一系列采访中，我们与开发者们探讨他们的背景、项目、兴趣和厌恶。在本期节目中，我们采访了 Code Project 的联合创始人以及“仓鼠的饲养员”——Chris Maunder。

Chris 加入 The Code Project…嗯，在最初的时候。他闪转腾挪，从不睡眠充足。他对小动物很友善。还有一些关于他的、你可能还不知道的事情……

你是谁？

Chris Maunder，加拿大，多伦多。首席清洁工、Bug 修复者、首席内部制造麻烦者、橙色（Defender of the Orange）的捍卫者、社区出气筒、偶尔的作者、助理系统管理员、支票签署人、洗碗工和行业联络员。还兼任：Code Project 联合创始人。

您做什么？

多年来，我曾从事过一些有趣的项目，包括将空间数据划分为数字高程模型，并在此类 DEM 上研究和实现降雨、径流和侵蚀模型，还开发了MFC UI 控件，以及为澳大利亚国防信号局开发了一些，嗯，数据处理应用程序，一个失败的 CE 应用（可以让你通过世界上任何交通系统进行路线规划，但失败的原因是这个想法在一年前已经被别人做过了），之后又开发了几个网站。

我还曾为Dundas Software 工作过，当时The Ultimate Toolbox 是其商业产品，还开发过一些从未面世的Windows CE 应用。

我最新的项目是CodeProject.com，它占据了我白天、夜晚和所有空闲时间。这是一份 24 小时的工作，从收发邮件开始和结束，但涵盖了社区互动的全部范围（也被称为在Lounge 闲逛浪费时间），还包括架构设计、编写代码、代码审查、部署、系统管理职责、服务器和硬件，以及数据库设计和管理。还涉及一些编辑、少量图形、法律、财务、处理员工问题、与客户沟通以及对系统和社区进行一般性监控。

我和我的团队还在开发Lake Quincy Media，这是一家媒体公司，为 CodeProject 和其名下的数百个其他网站提供服务。

基本上，我做什么都做，包括在洗碗机满了的时候清洗它。这是一份很棒的工作。我强烈推荐。

您的开发环境是什么？

我使用C# 和.NET Framework 4，ASP.NET Web Forms 和MVC，Visual Studio 2010，SQL Server 2008 R2，Notepad2，以及Expresso。用于测试的Nunit，用于样式的StyleCop，用于构建/测试的TeamCity 和Nant，以及偶尔在 Visual Studio 无法正常运行时使用Expression Web 4。我们还使用Chirpy 进行 JavaScript 压缩，以及在 Visual Studio 中使用 .less 的 CSS 和 T4 文件。对于我们的搜索服务器，我们使用了Lucene。我们的邮件服务器使用的是 Linux。

CodeProject.com 最初是用ASP 和VBScript 编写的。当前的 .NET 版本大约在 2003 年开始开发，因此有大量的遗留代码，最值得注意的是，在 Web Forms 中奠定了坚实的基础，采用了旧的洋葱架构，而不是像现在的“酷孩子”那样使用SOLID 原则和 MVC。

然而，我们正在不断重构，并转向MVP 模式，并在缺少的地方实现IoC，以便我们能够更轻松地转向 MVC，并改进我们的自动化测试和缓存。

您对哪些新工具、语言或框架感兴趣？

并行处理是我一直以来在CRAY 计算机上工作的长期兴趣所在。虽然这在一些独立应用程序（如我们的邮件发送系统）中有所涉及，但 ASP.NET 本身并不提供大量的并行处理机会。

目前最让我感兴趣的技术是任何能让我们的后端数据库系统不那么关键的技术。缓存，这很明显，但从负载均衡的角度来看，还有SQL 集群，而不是故障转移集群。我们花费了大量的资源来开发一个极其出色的系统，允许标准安装的 SQL Server 充当负载均衡集群，但最终，构建和维护该系统的成本比购买一台更大、更快的机器的成本还要高，而且这种趋势仍在继续。

我们还努力让 SQL Server 提供有用的全文索引，用于根据会员评分加权的技术内容，这些内容在文章方面产生了极好的结果，但在消息、新闻、目录项等方面的速度和灵活性不足。我们将其全部移除，迁移到了 Lucene，这不仅降低了我们的数据库要求，还提供了将一些查询（如相关文章）从 SQL Server 转移到 Lucene 的机会。这些 NoSQL 风格的技术正带来巨大的好处。

我还深刻地需要理解我们的网络拓扑，这是我曾发誓不会做的事情。直到 6 个月前，我们还在依赖Windows 负载均衡作为集群 Web 服务器的方法，但随着转向硬件负载均衡器和 VLAN，我们获得了效率和灵活性，带来了显著的改进。Windows Server 管理、DNS、SQL 设置和管理、SQL 故障转移集群，以及任何与IIS 相关的内容，现在都引起了我一定的兴趣。要么我懂这些，要么我们的监控人员会在凌晨 2 点打电话告诉我搜索服务器宕机了。

切身的利益关系能够极大地提升你掌握一项技术的能力。

您最讨厌的编码习惯是什么？

目前（因为这会随季节变化）在 int 更合适的地方使用 `var`。例如…

var value = GetIntValue();

而不是…

int value = GetIntValue();

这让我抓狂。

我的第二个大抱怨是，代码中没有解释你正在做什么。是的，我说的就是注释。我曾与Steve Smith 就这个话题进行过多次讨论，虽然我们承认对方的许多观点，但通常会归结为“视情况而定”，对此我回答“你怎么知道它视情况而定”，因此我总是要求代码需要注释。

在我看来，有四种主要情况需要注释。

1. 你在编写复杂、不易理解、高度优化、临时解决方案或代码本身无法解释的内容。

2. 你正在与一个在学校午休时没有读过词典的团队合作。

3. 你使用了参数和返回值。

4. 你在一段时间内编写了非平凡的代码。

第一种情况很明显，就是事情本身的性质。代码内的注释（即方法内的注释）应该是一个警示信号，表明有些东西不对劲，或者你需要注意一些不太显而易见的事情。代码库可能非常庞大，在审查它们时，很容易陷入一种阅读代码的昏迷状态。代码内的注释应该让你清醒过来，但不能仅仅为了有注释而写注释。在这点上我同意 Steve。

第二种情况是最危险的。用一种自描述且显而易见的方式来写你的类、属性和方法并不算太痛苦。当然，前提是你不在乎极长的名字

• GetItem
• GetItemByName
• GetItemByNameFromCacheButNonFromDatabaseIfNotExistingInCache

是的，这是一个牵强的例子，但它说明了一个问题：除非你和你的团队非常擅长想出名字，并且严格遵守定义明确的命名约定，否则名字会出错，你会发现某个人，在某个地方，对函数的作用产生了误解。也许他们认为“Create”是指“在磁盘上创建”，而作者的意思是“在内存中创建”。像这样的小错误可能会带来噩梦。理论上，通过正确的命名完全可以避免这些问题。

理论上，实践和理论没有区别。在实践中，是有区别的。

第三种情况有点牵强，但我这里的意思是，方法的名字并没有传达出参数代表什么，或者提供了无效（或无）值时会发生什么。同样，命名在大多数情况下都有帮助，但那个“大多数”是关键。

第四点是，你可能写了完美命名的类和对象，但是，如果你有一个执行非平凡操作的系统，你的代码只会告诉你一件事：它做了什么。它从不回答真正的问题，也就是：为什么。

所以，这就是为什么不注释，真的，是我的一个厌恶点。我看着代码，我能看到它做了什么，但我不知道为什么。我不知道为什么我会使用一个方法而不是另一个，也不知道那个另一个对象的作用是什么。为什么要有它？

我喜欢看到的注释是简短的XML 摘要注释，它们描述了对象的作用，能够回答“为什么”的问题，以及关于公共方法的摘要注释，供那些使用类公共 API 的人参考。总会有微不足道的注释，但我宁愿忍受微不足道注释的坏处，也不愿让一个开发者问自己“我要解释这个方法及其参数的用途，还是它足够明显，我可以早点下班回家”。

一致性是代码库中最重要的东西，我坚信，只要通过代码审查确保注释的正确性（注释仍然是代码），并且在完美命名或看似合理的假设失效的情况下带来清晰度，这些开销就得到了回报。

假设写一段代码并给它起一个名字就能使其清晰，这和假设写一段代码就能按照你预期的方式工作一样是错误的假设。对于人类的巨大解读能力，没有编译器，所以要做好一些后备方案。

咳咳。我该下讲台了。

您是如何开始编程的？

直到 27 岁开始第一份合同工作，我才有了电脑。这是一个故意的决定，因为我曾经不停地恳求我的父亲每周从工作单位带一台便携式电脑回家，这样我就可以在上面工作。我知道如果我的卧室里有一台 PC，我将有 2-3 年看不到阳光。

即便如此，我 11 岁时就开始在TRS-80 上摆弄，然后是Kaypro II。当时最常用的语言是BASIC，但直到 11 年级我接触到Pascal，我才完全沉迷。那个Turbo Technojocks Toolkit 将永远在我心中占有一席之地。

从那时起，我转向了C，然后是FORTRAN。这种奇特的转变是因为我在物理学学位期间的工作允许我使用 C，但我的第一份正式工作是作为一名地貌学家，编写DEM，而 FORTRAN 是那里唯一的一门语言。

我对 FORTRAN 的耐心很短暂，所以我开始将所有东西都迁移到 C++ 和MFC，用 133MHz 的 PC 淘汰了他们昂贵的大型机。在那之后，我回到了 CRAY 上的 FORTRAN。虽然语言相同，但能够将你的代码进行改进的自动并行化工具（对我来说）是令人难以置信的。我感到很渺小。

开发者社区是如何影响您的编码的？

我喜欢他们普遍缺乏枪支和个人恩怨。不，等等，我想到的是另一个社区。

我最喜欢的是社区无私地、大量地分享知识的愿望和能力。我常常惊叹于开发者们为社区提供的贡献，也因此感到谦卑。我也喜欢社区的智慧、机智和创造力。对话快速而无情，这让你时刻保持警惕。

我最讨厌的？对话快速而无情。

事实上，我在软件社区中最不喜欢的是那些极少数人，他们出于自我驱动的需要，在 slightest 错误或挑衅时就会侮辱他人。我们天生就是一群自负的人：我们的工作让我们觉得自己是“宇宙的主宰”——至少在你看到核心转储之前——而这可能会稍微泄露到在线生活中。

所以总会有一群人认为他们能做得更好，并且拒绝考虑其他开发者面临的实际限制。也许他们没有使用新工具的奢侈，或者他们不是母语编码者，而是一个在公司其他人无法完成大部分工作时，能够完成大部分工作的人，从这个角度看，他提供了一项关键服务。他的代码可能不完美，但他已经尽力了，他正在做最重要的事情：提供软件服务，让其他人能够完成他们的工作。我认为很多人忘记了他们代码的最终目的，这可能导致失去视角。

这又回到了我创办和持续建设 CodeProject 社区的动机。我喜欢帮助开发者在日常生活中完成工作，或者获得他们本来无法获得或完成的代码。这让我在桌子上留下的“头部凹痕”变得值得。

您会对一个新兴的程序员提供什么建议？

你无法写出 100% 完美的代码。即使你写出来了，6 个月后它也不会是完美的。停止尝试写完美的代码，专注于写能运行的代码，并且（在用户手中）尽可能快地运行。编写健壮、可维护的代码，并且能够告诉你它出了什么问题以便你快速修复，这比假设它会完美运行要好得多。它不会。

哦，还有，买一把好椅子。这真的很重要。