与Steven Haryanto的访谈

2014年1月24日 by David Farrell

Steven Haryanto是一位Perl程序员和多产的CPAN作者。我们最近与他交谈，讨论了他的开发方法和提高生产力的工具。（Steven告诉我们，上面的照片是他家乡万隆的代表性图片）。

根据最近的CPAN报告，你去年向CPAN发布了769个版本。你是如何变得如此高效的！？

就我而言，我在2012年发布了超过900个版本，所以2013年并没有那么高效。真正使这一切成为可能的是两个因素：一个dist构建/发布工具（我恰好使用Dist::Zilla）以及我产生了很多错误/bug的事实。

在这些版本中，有没有哪个特别突出，对你来说是一个重要的里程碑？

老实说，没有。现在事情大多是逐步进行的，这让我感到很满意。这意味着我还没有需要从头开始重写或重新设计一个模块。当然，有几个是部分重写的，但不是非常重大。

我发布到CPAN的大多数模块都是我自己或用于工作的模块。目前只有其中几个被证实至少被其他人使用过。这包括Org::Parser、Data::Sah、Gepok、Data::Dump::Color、Progress::Any、Log::Any::App和Text::ANSITable（只有最后一个是2013年创建的）。2012年我发布了166个新发行版，2013年只有71个。所以2013年更多的是关于更新和改进，而不是创造新事物。

你以前提到过“面向发行版的开发”，你现在还遵循这种方法吗？为什么？

是的，因为将软件模块化可以让我避免发疯，模块和发行版是Perl中模块化的单元。

你发现像要发布模块一样进行开发，迫使你遵循更好的编码实践吗？（比如编写测试、文档、错误检查）

当然。Perl模块和发行版的编码实践相对成熟，所以遵循它们是顺理成章的。现有的工具也很有帮助，它们减轻了我需要重新发明轮子的负担。

你使用什么文本编辑器/IDE来编写Perl代码？你为什么使用这个工具？你试过其他工具吗？你更喜欢它吗？

正如你们中的一些人所知，我是一个org-mode的粉丝，所以我目前还在使用Emacs。我对这两个都不是非常高级的用户。我也过去使用过Komodo IDE，它的正则表达式调试工具很棒。我也试过Padre，但因为我遇到安装问题，所以我还没有再次尝试。

Org-mode看起来很酷！作为一个Perl开发者，你最喜欢org-mode的哪些特性？

实际上没有与Perl相关的特性。我像大多数人一样使用org-mode（包括非Perl程序员和非程序员）：组织待办事项列表和做笔记。我还恰好编写了Org::Parser，因为当时还没有这样的模块，这帮助我创建了一些处理和总结我写的Org文档的脚本。例如，我记录了每天完成/未完成的待办事项的数量，以记录我的进度。我使用一个简单、自制的格式在Org文档上做时间账本。我也用Perl编写了从shell启动文件运行的待办事项提醒。

我还在开始使用 Org 来编写软件产品文档，并稍后将其导出为 HTML（然后是 PDF）。一旦工作流程更加明确，可能还会出现一个或两个 CPAN 模块。

我记录了每天已完成/未完成的待办事项数量，以记录我的进度。

你也提到了使用 tmux / screen。你能解释一下这些终端工具是如何帮助你的开发的吗？

我现在很少使用它们，除了在缓慢且不可靠的连接上，幸运的是，我所在的地方这种情况发生的频率越来越低。通常 Konsole 就足够了。但我确实在监视的服务器上维护 screen 会话。

尽管如此，我还是大部分时间在终端工作，因此我的许多 CPAN 模块都与命令行应用程序和终端相关。

在你的一篇博客文章（《如何管理我的分布》）中，你说你使用 Dist::Zilla 来管理你的分布。你能详细说明 Dist::Zilla 如何帮助你提高效率吗？

Dist::Zilla（或等效工具）让我们从构建/发布分布的枯燥和繁重的工作中解脱出来，让我们能够专注于编写代码，并鼓励我们进行更多发布。新的发布可以在几秒钟内完成，而不是几分钟。对于成百上千个分布来说，手动操作是根本不可能的。

你最喜欢的 Dist::Zilla 插件是什么？

没有特定的插件，可能是因为 OurPkgVersion（仅仅因为它的大哥，PkgVersion, 修改了行号）。Run 也是很方便的。但 Dist::Zilla 的好处在于，当现有的插件不能满足需求时，你可以简单地创建自己的插件来完成你需要的具体事情。我自己也编写了一些。

Dist::Zilla 的好处在于，当现有的插件不能满足需求时，你可以简单地创建自己的插件来完成你需要的具体事情。

你的框架 Rinci 是否帮助你在开发过程中？

当然。没有 Perinci 工具，我就不会编写和发布那么多的东西。它们让我避免或最小化做一些我讨厌做的事情，比如编写 POD，Getopt::Long spec，命令行使用说明等等。和 Dist::Zilla 一样，它们让我能够专注于编写实际的代码。

你使用任何静态代码分析工具，如 Perl::Critic 吗？

目前没有。我应该使用。也许需要做大量初始配置和调整的想法让我推迟了使用。

你以前曾 指出 Perl 缺乏一个好的语法高亮库。你认为现在情况还是这样吗？

我没有再检查过；我甚至忘记了最初为什么需要语法高亮库。我认为情况还是这样，我已经接受了这一点。至少还有其他工具可用，不是所有事情都需要在 Perl 中完成。《PPI::HTML》是用来高亮显示 Perl 代码的，而不是其他语言，对吗？

关于 Perl 社区或开发，你有什么想法认为人们应该知道吗？

由于Perl是一个瑞士军刀式的工具，包括作为shell脚本的替代品以及编写命令行程序，我希望作者们能够更加关注启动开销。似乎许多杰出的CPAN作者主要关注的是编写漂亮的OO代码或PSGI Web应用或长时间运行的守护进程，但事实是Perl的功能远不止于此。因此，我一定会鼓励和推广像Moose、DateTime和Log::Log4perl这样的流行库的轻量级替代品。

我希望作者们能够更加关注启动开销。

在您的开发过程中接下来是什么，您期待尝试什么？

我将继续推出CPAN模块，为Perl社区做出我的贡献。我目前的关注领域包括：与印尼相关的（语言/区域）模块、用Perl编写出色的命令行程序，以及其他工具/库以减少样板代码并强调DRY原则。

正在进行的一个项目是cpanlists.org（尚未上线），它将是一个简单的网站和服务，用于管理作者和CPAN模块的列表，并为每个作者/模块提供评论和评分。它类似于Amazon Listmania列表，我过去也博客过想要创建类似的东西。我主要是为了发布我的笔记以及Riap::HTTP的概念证明，这是一个面向开发者的API服务的协议。

人们将能够维护他们最喜欢的模块列表。这已经在MetaCPAN中通过++实现，但我在MetaCPAN中无法为每个模块添加注释或评分。要评分模块，必须使用单独的服务（CPAN Ratings）。我还想创建除单个收藏夹列表之外的多份列表，例如：推荐执行X（例如日志记录或将Markdown转换为POD）的模块列表、因X（例如，启动开销大，错误数量多）而应避免的模块列表等。

当许多人创建他们的列表时，这将帮助用户评估和选择适合他们需求的正确CPAN模块。

这篇文章最初发布在PerlTricks.com。