2.1　相关开发资源

开发水平的高低取决于我们手中所掌握的资源。人类文明历经近万年，计算机历经近百年，云计算火热了十几年，即使OpenStack也已经存在了近10年，相关知识早已浩瀚无边，我们所能接触到的不过沧海一粟，我们所能理解、掌握并谨记于心的更不过是这“一粟”中很微小的一部分，我们每日所做的也不过是为了使这“一粟”更大，使那一部分更多而已。

如果把这“一粟”比作我们所掌握的资源，那么我们在平时开发时应该不求下笔千行，而应力求迅速地从各种资源中找到解决的方案。举个通俗的例子，我们要开发一个视频监控系统，那么我们可以从sourceforge上的项目MPEG4IP中得到很多的灵感。

下面列举一些其他OpenStack开发中常用的资源以供参考。

2.1.1　OpenStack社区

如第1章所述，OpenStack有一个紧密团结了众多使用者和开发者的OpenStack社区，那里是“大牛”们的战场，“小牛”们的天堂，任何一个OpenStack开发者都可以从中获益。

不同于Linux内核社区中LKML（Linux Kernel Mailing List）对问题讨论、代码Review等的大包大揽，邮件列表的核心地位在OpenStack社区中被一定程度地弱化：代码的Review工作会通过Gerrit系统来完成，同时，答疑功能也由一个专门的问答网站Ask OpenStack来分担。

这个问答网站的风格类似于Stack Overflow，能够让用户对自己认为正确的解答投票，而且有中文和英文两个分站点可以选择。和所有的开源社区一样，用户在询问问题时都应该保持一个良好的习惯，即先在邮件列表的存档中搜索并查看一下自己的问题是否已经被讨论、回答过了。

2.1.2　OpenStack文档

评估软件质量的重要标准之一是软件的可维护性，而是否有完善的文档、文档是否同步则是影响软件可维护性的一个重要因素。

软件的开发者无外乎两种人。第一种人会维护自己的代码，但是随着时间的流逝，以前的理解和记忆已经模糊了，在每次修改Bug或增加新功能时，需要通过查看文档和代码来帮助自己回忆当时的开发场景。

第二种人的代码不是自己写的，需要阅读相关的文档中的代码。为了弄明白某处代码的意图，他们需要了解整个模块的逻辑流程，还要查看相关的需求及设计文档，但是很遗憾，这些文档都和实际代码不同步。

无论我们属于哪一种，文档的重要性都是不言而喻的。每一个项目，每一个模块，甚至每一行代码都有自己的故事，这些故事都应该被留存在它们的历史档案里，而我们对于它们而言只是过客而已。

但软件开发的现实是：几乎没有任何一个软件，在其生命周期中，均由最初的开发人员维护；几乎没有任何一个软件，在其生命周期中，它的文档与代码是保持同步的。

对于开源项目来说，文档的缺乏与滞后问题更为突出，但即使是最为挑剔的批判者，也不得不承认OpenStack在这方面有着较为突出的改进，它甚至创建了专门的项目来维护OpenStack相关的各类文档。

为了有针对性地满足不同参与者的需求，OpenStack将自己的文档进行了相应的分类，如针对开发者的，针对维护人员的，针对各行各业的使用者的。虽说表面看起来比较分散，甚至有些凌乱，但自有其内在规律。

OpenStack的文档主要位于3个地方。

· wiki.OpenStack.org，主要包含了项目文档及会议记录等信息，在这里可以清楚地了解如何向OpenStack做贡献、OpenStack代码如何进行管理等。

· docs.OpenStack.org/developer/<projectname>，针对开发者的文档，由位于各个项目源码目录中doc/source/子目录下的rst文件生成。

· docs.OpenStack.org，主要包含了针对维护人员、使用者等其他参与者的官方文档，如安装指南（Installation Guides）、终端用户指南（End User Guide）等，内容由OpenStack Manuals项目生成。

2.1.3　OpenStack书籍

在本质上，学习OpenStack开发，就是学习OpenStack的源码，任何与OpenStack有关的书籍都是基于源码而又不高于源码的。

因此，在阅读本节内容之前，我们必须端正自己的认识：源码才是中心，书籍只能起到促进或辅助我们理解源码的作用。

待到山花烂漫时，还是那些经典在“微笑”。Linux成长了近30年，才给我们留下了那些经典的LKD/ULK/LDD/……而OpenStack满打满算也不过刚走过自己的第一个10年，虽然涌现了一些书籍，但是否经典尚未可知。

这些有限的OpenStack书籍，可以归纳为两类：一类是针对部署与操作的，如O’REILLY的OpenStack Operations Guide和Deploying OpenStack；另一类是侧重框架与原理的，即针对开发者的，在目前已有的书籍里，除本书之外只有部分涉及而已。

按照本书的预期及主张的OpenStack开发学习过程，针对OpenStack开发的书籍也应该分为两类。第一类是介绍OpenStack及各组成部分的框架与实现原理的，可以帮助读者了解OpenStack的设计实现特点，对其有一个整体的认识和理解。第二类是专注于Open某个组成部分或项目的，如果我们希望对OpenStack不是泛泛而谈而是有更深入的理解，则可以选择一个自己感兴趣的项目，然后仔细分析它的代码，不懂的地方就通过社区、邮件列表等途径弄懂，切勿得过且过。这样一来，我们对OpenStack的很多通用机制就会非常了解，俗话说的“一通则百通”就是这个道理。

如果用一个城市来类比，则第一类书（如本书）只是帮助读者形成这个城市有多少个区，每个区的大概形状和范围，哪个地方有哪些标志性建筑等比较泛化的地图，而如果读者希望生活在某个区，从而需要深入了解这个区的人文地貌，就可以在之前那个泛化的地图基础上，聚焦在这个区的位置去细化，而第二类书就起到辅助细化的作用。