本文是为那些英语专业的学生、书虫、文学爱好者以及那些拥有人文背景的人准备的，他们有时会纠结于这样一个问题：“你的英语学位有什么用？” 它也是为那些曾问过非 STEM 背景同事这个问题的人准备的，他们对一个人如何从心理学开始最终进入 Python 感到困惑。
事实是，技术和人文学科并非遥不可及； 事实上，我们英语专业学生在论文中完善的许多概念，在我们的日常生活中都被开发者使用。 本文不是关于程序员可以从人文学科专业学习什么，反之亦然。 它展示了这两个学科之间的重叠之处； 对它们的兼容性以及它们如何相互补充的研究。
在成为奥斯汀德克萨斯大学的开发者之前，我想成为一名英语教授。 我于 2007 年在奥本大学获得了英语学士学位，在那里我做了很多技术方面的事情。 我是一位教授的专业网站的网站管理员，该网站使用 Dreamweaver 维护并存储在 Zip 驱动器上。 我还在技术中心工作，在那里我录制视频来教教授如何使用 Blackboard，并帮助他们以我认为很酷的方式将技术融入到他们的课堂中。
当我开始在德克萨斯 A&M 大学攻读英语硕士学位时，我仍然想成为 Lacey 教授，撰写关于文学的学术文章。 但同样，我将自己引向了技术角色。 我在英语技术中心工作，而不是担任助教，并且我帮助教员录制视频、制作视频、使用 Moodle（Blackboard 的开源版本），并找到将 Google Docs 集成到课堂中的方法。 我还为 World Shakespeare Bibliography 工作，在那里我研究了关于莎士比亚的学术文章，然后写了关于它们的摘要。 我必须使用一些 markup，以便管理员可以将我的摘要复制并粘贴到网站中，但我不知道的是，我有点像在编码。
2009 年，我参加了一个关于 TEI：文本编码倡议 的研讨会。 TEI 是一种特定于手稿的 XML 标记语言。 它具有许多很棒的、针对出版商和有关书籍的其他信息的特定标签，但它也提供了一种讨论正在为网络转录的手写手稿的方式； 例如，您可以在标记中表示某些文本已被划掉并替换为不同的措辞。 我想使用 TEI 创建一个网站，讨论简·奥斯汀的粉丝小说。
但我觉得我不知道怎么做。 我对技术非常感兴趣，但技术不是很精通。 我不知道如何注册 URL，我不明白 CSS 是什么，如果我可以获得教程，我也不知道如何找到它们。 我还认为这太难了。 我甚至在开始之前就患上了 冒名顶替综合症。 所以我写了一篇关于简·奥斯汀粉丝小说的论文。
猜猜来源
让我们玩一个名为猜猜来源的游戏。 我会放一段风格指南的引用，你可以猜猜它来自哪里
句尾句点后应使用两个空格。
这来自 PEP8，还是 Strunk & White？
我讨厌 PEP8 中的这一特定行，因为在您的常规写作中，您永远、永远、永远不应该在句点后放置两个空格。 不要这样做。 这是来自等宽字体和排版的时代，我们不再在互联网或印刷材料中使用等宽字体。
除了在代码中。 所以在编写代码时请遵守此规则，但在其他任何地方都违反它。 编写代码与撰写研究论文或文章有任何关系的第一个线索就在 PEP8 中，Python 代码的风格指南：“在编写英语时，请遵循 Strunk & White。” PEP8 甚至没有引用 Strunk & White。 它假定您知道这意味着什么。 （对于那些不知道的人，Strunk & White 指的是 The Elements of Style，一本美国英语风格指南，于 1959 年首次出版。）
关于 Strunk & White 更广泛的观点是，这是一本旨在帮助人们编写更清晰、更简洁、更一致、更易读的英语的指南。 PEP8 也是一本旨在帮助人们编写更清晰、更简洁、更一致和更易读的代码的指南。
情节驱动开发
让我们谈谈测试，因为测试是文学课上的一些概念可能会派上用场的完美例子。 也许您还记得 故事弧 的基础知识
- 在exposition 中，您会了解角色是谁、他们在哪里以及正在发生的基本情况。
- 上升行动是问题被引入的地方，我们开始体验将我们引向高潮的事件。
- 高潮是情节中最激动人心的部分。 这是改变主角命运的事情发生的地方。 在 傲慢与偏见 中，这将是达西先生最终向伊丽莎白求婚的场景，然后她告诉他，即使他是地球上最后一个人，她也不会嫁给他，然后她开始质疑自己。
- 下降行动是事情开始解开并就位的地方。
- 结局将一切都系上了一个整洁的小蝴蝶结。 结束。
我们也可以在测试中使用这个弧线，它被称为 Freytag 的金字塔。 事实上，这就是我第一次在 DjangoCon Austin 上发表的演讲的想法，本文就是基于此。 我参加了 Harry Percival 的 PyCon 测试研讨会，并意识到他给出的功能测试示例是 Freytag 的金字塔应用于测试的完美示例。 功能测试有
- Exposition：Harry 向我们介绍了 Edith，她听说过一个待办事项应用程序。
- Rising action：Edith 进入应用程序，找到她的方式，并决定在她待办事项列表中输入一个项目。
- Climax：Edith 的命运永远改变了。 她执行了关键的、至关重要的操作，即向她的待办事项列表中添加一个项目。
- Falling action：她输入了她的项目，她看到它已经被输入并为她保存了。
- Denouement：Edith 很高兴，并且要回去睡觉。
在 Harry 编写任何单个功能测试之前，他会写出这个完全遵循 Freytag 金字塔的用户故事。 这样，他就知道用户需要通过他的网站采取什么路径，他们会遇到什么，他们会做什么，以及一切将如何解决。 他可以编写测试来测试所有这些步骤是否发生，然后他可以编写代码来通过这些测试。
Edith 通过应用程序所采用的路径是她的用户故事； Edith 本身就是一个角色。 在另一个世界中，Edith 可能是小说中的主角，而这段特殊的旅程可能是我希望是一个更惊险故事中的一个章节。 学习过角色发展和情节发展有助于编写完整且令人信服的用户故事的能力。 程序员需要对他们的代码应该做什么以及应该以什么顺序发生有信心，才能有效地测试它。
用户故事和功能测试并不是终点。 我们希望 Edith 在应用程序崩溃时做出什么反应？ 我们是否希望她像在希腊悲剧中一样，撕扯头发，撕裂衣服？ 我不希望这样。 我们可能想为她提供纠正错误所需的工具（如果可能），或者让她放心，我们知道出了问题，并且我们已经在处理它了。 以下哪个是更令人放心的错误消息？
需要创造性思维来确定我们的代码可能在哪里崩溃、构建检查以及返回有用的数据。 任何程序员都可以返回错误消息，但是要编写一个有用的（而不是令人望而生畏的）错误消息，需要一位也是创造性思考者并且具有出色的书面和口头沟通技巧的程序员。
当您编写好的测试时，您正在进行世界构建：可访问性需要同情心，而同情心需要想象力。 您可以利用当您迷失在一本书中并认同主角时所获得的奇妙感觉，方法是将自己置于使用您的代码的人的角度。 想象他们的挣扎和挫折。 为他们创建一个角色。 修复阻碍或惹恼他们的应用程序的那些东西。
但回到功能测试。 你知道这还像什么吗？ 大纲。
你知道还有什么看起来像大纲吗？ 基本上，所有 Python 代码。 Python 比英语专业更喜欢空格和缩进以及漂亮的格式。
Python 代码实际上使用了许多与其他书面作品相同的格式，例如新闻报道、博客文章、小说、研究论文，甚至 艾米莉·狄金森的手写椰子蛋糕食谱。 您的函数定义就像标题。 您的 docstring 就像研究论文的摘要，或者最喜欢的小说新版的序言。 docstring 会告诉您一些关于即将发生的事情的信息，并让您一窥作者或程序员的想法。 然后是中间的一切：函数的主体，文章或故事的段落。 最后，您得出结论。 您返回一些东西，您通过此特定函数的旅程就结束了。
可读性很重要
一段写得好的代码应该是可读的，但我们到底是什么意思呢？ 机器不需要代码是可读的，但在 PEP20：Python 之禅 中，Tim Peters 非常明确地表示可读性很重要。 计算机或编译器（或其他任何东西）根本不在乎您的代码是否一团糟，只要它可以工作即可。 但您的同事很在意。 后来者会在意。 与您分享工作的人需要您的代码是可读的。
编写可读的代码需要同情心，意味着您关心您的程序员同事。 可读且认真注释的代码还有助于未来的程序员了解您的困惑之处，或者您为什么以这种方式做出决定。 注释甚至可以帮助您在自己的代码中重新定位自己。 我的一个朋友曾经说过：“注释就像给自己的情书。” 一位同事喜欢说，当您在凌晨 3:00 接到电话，得知发生了灾难性错误时，注释可以让您保持理智。
这里有一个很棒的例子，来自《异乡人》系列，这基本上是一个完美的系列书籍。《异乡人》系列讲述的是一位二战时期的护士意外穿越回了18世纪的苏格兰。故事包含了战争、爱情和美好（现在它也是一部很棒的电视剧，但这并不是重点）。在第五本书《燃情十字》的结尾——我保证这不是剧透——我们的女主人公克莱尔身处18世纪，是方圆数英里内最有知识的医务人员。她治疗了一个最终去世的人，她很确定是因为她给这位病人服用了他们过敏的药物。她纠结于是否要在日记中写下发生的事情。在该系列的前一本书中，克莱尔被镇上的人们误认为她的高超医术是魔法，而被当成女巫审判，所以她变得犹豫，不敢写下任何可能后来被用来对付她的东西。
克莱尔说：“未来这里的医生也会面临同样的困境；是进行可能危险的治疗，还是让一位本可能被拯救的病人死去。那会是谁呢？我擦拭着笔，思考着……”然后她思考了一会儿自己是多么孤立无援，医生是多么稀少，医学院是多么匮乏，她得出结论：“我坐直了身子，打开书。我蘸了蘸笔，开始写下那些必须存在的文字，为了追随我的不知名的医生。”
这就是我们为什么要编写可读代码：为了追随我们的不知名的程序员。
结局
我上大学的时候，有一个室友是新闻专业的。尼基和我互相编辑对方的论文，我会尝试让她使用更多的形容词来使她的写作更精彩。她会让我删掉我华丽的描述，直奔主题。大多数写作风格指南以及 PEP 8 和 20 都同意尼基的观点。
“省略不必要的词语。”
“简洁胜于复杂。”
“有力的写作是简洁的。”
“稀疏胜于稠密。”
这些是来自 PEP20 和 Strunk & White 的训诫。我不会具体指出哪一行来自哪部作品，因为这并不重要（而且《Python之禅》的爱好者无论如何都能挑出来）。但重点是它们非常相似。好的写作是简洁、清晰和简单的，并能直奔主题，无论你是在编写一段代码还是一篇文章。我可以从《Python之禅》中提取出那些非代码特定的句子，并将它们通过电子邮件发送给我的作文教师朋友，他们会立即打印出来并分发给他们的学生。事实上，我应该这样做。
我们被称为编码员、程序员或开发者。我们整天都在做什么？我们编写代码。我们阅读拉取请求。我们编写测试。我们阅读别人的代码。我们编写注释。我们是读者和作者。在文学阅读和写作课程中学到的经验对于我们作为代码的读者和作者来说极其重要。
“你有没有机会用到你的英语学位？”我经常被问到。是的，我每天都在使用我的英语学位。
月
一系列文章，重点介绍了首次为 Opensource.com 做出贡献的人。
4 条评论