程序员创业指南和企业应用程序构建 - 文章1

引言

这是我将讲述我如何创办 SplendidCRM Software, Inc. 的系列文章中的第一篇。我希望我的创业经历能激励你，因为创建一家公司可以是一次美妙的冒险。

第一篇文章

四年前，我在失业期间创办了 SplendidCRM Software（换句话说，我失业了）。我整天感到无聊，想做一些有挑战的事情。我阅读了最新的行业期刊，其中包含了一个关于 SugarCRM 的公告，SugarCRM 是一款新的开源应用程序。由于 SugarCRM 是一款企业应用程序，而我是一名企业开发人员；我立刻想到：“我能做到，而且这是一个很好的匹配”。

我处理这类项目的方式是假设我的努力不会白费。即使我的软件没有产生任何收入，我也一定会提升我的技能，成为一名更优秀的开发人员，并成为未来雇主更有价值的员工。

对于 SplendidCRM Software，最棒的是所有的应用程序设计都已经完成了。另外，只要我遵守原始开源协议的条款，我就可以在我的实现中自由使用现有的美术资源。我无需考虑产品的细节；我只需要运用我在企业软件开发生涯中学到的一切技能。

选择 CRM，我预感到仍然存在大量的软件挑战。例如，一个企业公司通常在全球各地都有办事处。它的员工生活在不同的时区，说不同的语言，使用不同的货币。最重要的是，他们都访问同一个 CRM，并且都希望获得本地化的体验。因此，企业产品需要

1. 支持多种数据库
2. 支持多种平台
3. 支持多种语言，以及
4. 支持多种货币

除了这四个针对全球企业的挑战之外，最终的系统还需要快速。

让我再说一遍。我是一名企业开发人员，所以我选择了一个现有的企业解决方案，并着手创建一个相同的解决方案。如果你是一名游戏开发人员，可以考虑创建一个游戏。你不必设计一款新游戏；相反，只需找到一款有趣、现有的游戏并尝试复制它。很有可能在创建一款完全相同的游戏的过程中，你会学到新东西。就我而言，SplendidCRM 在功能上与 SugarCRM 没有区别，但它在技术上有所不同，我相信它拥有更好的软件设计。我学到了太多新技术，我不得不在未来的文章中再分享。

我很幸运，SugarCRM 是使用 LAMP 堆栈开发的，而我的技能是并且仍然是 Microsoft 堆栈。最终，每个产品——每个产品都基于不同的堆栈——都表现相同，但专注于完全不同的受众。LAMP 堆栈的产品很可能被投资了 Linux 服务器的公司选中，而 Microsoft 堆栈的产品很可能被投资了 Windows 服务器的公司选中。

网络上充满了这类机会。例如，DotNetNuke 是一个基于 Microsoft.NET 的 Web 应用程序，它部分受到了另一个开源内容管理系统的启发。Alfresco 是一个相对较新、开源的内容管理产品，它正等待被重新实现为 .NET。这类机会肯定还有很多。

随着经济低迷，很多人——包括程序员——都失业了。如果你目前失业，我建议你利用空闲时间开始一个新项目。对于 SplendidCRM Software，我没有进行市场分析，也没有研究竞争对手。我只是开始创建一个类似的产品。（财富 500 强公司一直在这样做；例如，克莱斯勒发明了小型货车，它非常成功，以至于在短短几年内，所有主要汽车制造商都开始生产小型货车。）

当你失业时，你肯定需要花时间找工作。现实一点说，你不会每天工作 8 小时，每周工作 5 天。每天花一两个小时找工作，但然后一定要确保你把剩下的时间用于做有成效的、新的、能提升你技能的事情。

本系列文章的目标是激励程序员。为了让程序员对本系列保持兴趣，我将在每篇文章中包含一个技术部分，描述我如何在 SplendidCRM 中应用特定的设计策略，或者为什么应用。

GUID 的使用

SplendidCRM 大量依赖 GUID（全局唯一标识符）作为其主键。我在 15 年前开发 Windows 95 应用程序的 COM 接口时就接触到了 GUID，并且从那时起就一直对其着迷。GUID 是一个 16 字节的数组，通常格式化为 36 个字符的字符串。

当你开发企业应用程序一段时间后，你会很快意识到使用 GUID 作为主键的优势，而不是整数主键。虽然一个纯整数键只占用四个字节的存储空间，但对于当今的大多数应用程序来说，16 字节和 4 字节之间的差异是可以忽略不计的。（阅读 这里。）

更重要的是，一个 ID 可以被赋予全局唯一的含义，而无需重复使用该 ID。整数没有同样的优势。当整数用作主键时，很难确定该值的含义。例如，2077 是客户编号、账户编号、案例编号还是 Bug 编号？看到 SugarCRM 1.0 以整数主键开始很有意思。显然，SugarCRM 的初始开发人员和架构师没有企业应用程序开发经验；否则，他们从一开始就会使用 GUID。（阅读 这里。）

使用 GUID 作为主键的最佳理由之一是数据可以导入而无需重新输入。在您必须合并和验证两个包含 50,000 条记录的数据库之前，您不会意识到这一点有多么重要。

一旦您采用了 GUID，就必须像对待宗教一样对待它。您永远不应该犯的一个罪是，将非 GUID 值放入 ID 字段。我们在 SugarCRM 上亲眼看到了这一点。显然，他们不是这个宗教的信徒，因为他们——直到今天——仍然在 Team ID 字段中混用 GUID。异端邪说！

想象一下，两家公司正在合并，每家公司都有自己的 CRM。如果两者都使用整数主键，那么合并将是痛苦的，因为例如，每个系统都可以有一个 ID 为 12345 的账户。更糟糕的是，同一个账户 ID 可能在每个 CRM 的 1000 个位置被引用。合并过程不仅需要将 12345 的 ID 替换为 GUID，还需要搜索并替换对新 GUID 的 1000 个引用。

当一个客户要求我们将他们的 SugarCRM 数据库迁移到 SplendidCRM 时，我们亲身经历了这个问题。SplendidCRM 的设计具有几乎相同的数据库架构，以使此类迁移变得简单。然而，在 ID 字段中使用非 GUID 需要额外的工作。作为迁移过程的一部分，**我们不得不扫描数据库中每个表的每个 ID 字段，并将所有整数键转换为 GUID 键**。我们还不得不重新输入 Teams 表，因为 SugarCRM 的聪明人认为将前缀“private”放入 ID 字段是合适的。

公平地说，确保别人轻易地抢走客户并不是 SugarCRM 的职责，但我认为这并不是他们糟糕设计的初衷。我由此得出结论，SugarCRM 的开发人员并不完全相信 GUID 的“宗教”。

现在，我将结束我们对 GUID 的简要介绍。我计划了一整套文章——这是第一篇。

历史

• 2009年5月25日：初始发布