两天的时间不能浪费一分一秒。MVP已经定义了我们将要做的“事情”, 也就是我们的数字版滑板。现在还需要找到“如何”完成它的工具，我们有哪些选择呢？
在软件行业，你选择的一系列工具被称作“技术栈”。就好比是盖房子。首先你得决定采用什么主建材。是用砖块，木材还是钢材？采用何种地基？需要哪些建筑工具？这些选择将决定造房子需要花多长时间，造好的房子有多坚固，以及以后想增加一个房间是否容易。
对于一个周末的黑客松项目来说，只有一个最重要的因素决定着类似的选择：构建的速度。我们暂时不需要考虑那些高大上的可扩展架构，或者最先进最时髦的技术栈。我们需要的是能在最短时间内帮助我们从零打造出可用产品的技术栈。
这意味着我们需要一个熟悉的，可靠的，能帮我们完成很多“脏活”的工具箱。
深入技术细节：编程语言和框架
这是我们第一个也是最重要技术选择：选哪个编程语言以及何种编程框架？
为什么选择Python？
编程语言就是你往计算机下达任务的指令“词汇表”。我们选择Python是因为它赖以成名的简洁语法。代码读上去就像是普通的英文。当你跟时间比赛时，最好不要在调试工具上浪费时间，比如试图搞明白某个复杂的编码机制或者漏写了一个分号。Python代码写起来毫无障碍，让我们可以专注在MVP问题本身。而且Python社区相当活跃，每一种需要的功能都可以找到现成的库来调用。
为什么选择Djanjo：开箱即用的框架
编程语言仅仅是”词汇表”。好的框架就是完整的指令手册。框架提供了合理的编码结构，顶层设计，以及一系列预先构建好的组件，这些都可以让你无需从零起步。
还是以盖房子为例。你当然可以自己去砍树，自己去加工板材，甚至自己打磨钉子。或者，你也可以购买一个预制的房屋套装，包含所有的墙壁和门窗。你只需要把它们组装起来，然后根据个人喜好做些微调。
这就是Django的价值。它是构建互联网应用的预制盖房套装。它的设计哲学就是著名的开箱即用（Batteries-Included）。这意味着你直接立马可以上手开始构建。对于我们需要在48小时内完成的MVP而言，Django的两项功能绝对是大杀器：
-
Django管理员后台：这是Django的杀手锏。只需要几行代码，Django就可以生成一个完整的安全的并且看上去非常专业的管理员后台。这主要提供给我们作为创始团队登录用以查看全部业务数据。 当有新用户创建一个网店，我们就会在管理后台收到通知。我们可以查看相关商品名录，帮助修改错误的输入（仅在必要时）或者排查用户在使用过程中碰到的其它问题。但如果从零开始，弄出这样一个管理员后台可能需要花费一天的时间。Django不花我们一分钱，只需要15分钟就可以准备好。这个管理员后台就是我们的任务指挥中心。
-
ORM（对象关系映射器）：这个听上去好像有点复杂，但其实很简单。如果要从数据库读取数据，一般来说你得通过编写SQL语句完成。就是类似SELECT * FROM products WHERE store_id=123;这样。SQL很强大，但也容易出错，且跟我们主要采用的Python代码风格迥异。Django的ORM模块就扮演了翻译的角色。它允许我们用Python代码跟数据库打交道。上述SQL指令在Django中可以改写成：Product.objects.filter(store_id=123)。这让代码不仅易于编写和阅读，也能够避免很多比如SQL注入的安全隐患。采用自带ORM的Django框架让我们的代码更简洁，开发速度也更快。
深入技术细节：我们考虑过的其它语言和框架
Django当然不是唯一的选择。技术层面看，总有很多不同的方法可以达到同一个目的。关键是要根据任务性质和特点选择最合适的工具。
- Node.js以及Express框架：这也是一个非常流行的组合。Node.js允许使用JavaScript语言编写服务端代码，而JavaScript通常是运行在客户端浏览器中。这对于很多全栈型创业团队非常友好。Express框架则非常灵活，也遵循极简设计的原则。所以对于我们而言，这反而是它的不足。与其说Express是一个预制的盖房套装，不如说更像是一盒子高质量的乐高积木。它提供了很多很底层的功能，但是需要自行组装更高阶的模块。由于我们只有48小时，所以这样的自由度不是我们所需，我们需要的是Django开箱即用的丰富组件和编码结构。
- Ruby on Rails：这可能是一个更接近Django的备选。Rails与Django的设计哲学高度相似。它同样推崇“约定优先于配置”的理念，意味着它内置的很多合理决策能加速软件开发的过程。实话说，Rails也的确是个不错的选择。最终选择Django可能更多是基于我个人的喜好和熟悉程度。因为我过去更多使用过Python和Django，所以在时间紧迫的情况下，押注最熟悉的工具总没错。
深入技术细节：数据库选型
有了合适的编程框架，我们需要决定在哪持久化保存我们的业务数据，比如店铺名称，商品明细，价格等等。我们需要一个数据库。如果说编程框架是盖房套装，那数据库无疑就是房子的地基。必须得稳定，可靠并且易于查找数据。
为什么选择关系型数据库？
我们决定使用一款关系型数据库（Relational Database）。原因很简单：我们的数据将保存在数据库的表（Table）中，就像一张巨型且功能强大的Excel表格。店铺信息存储在店铺表中，产品信息存储在产品表中。更关键的是，可以在这些表之间建立关系（Relationship），比如每一款产品肯定属于某一个店铺。
这样的关系结构对于电商业务是完美的选择。数据间有了明确的联系和规则。肯定没人想看到一个不属于任何店铺的产品信息，或者一个没有顾客信息的订单。关系型数据库会强制约束数据之间的关系结构，保证数据始终一致，不多也不少。
为什么选择PostgreSQL？
在众多的关系型数据库中（比如MySQL，微软的SQL Server等等），我们最终选择了PostgreSQL（常被简称为Postgres）。
原因呢？其实对于MVP而言，Postgres及其主要竞争对手MySQL都是不错的选择。但我们出于以下几点更倾向于Postgres。Postgres在开发社区中的口碑相当不错，令人称赞地健壮，可靠并且符合通用的技术标准规范。绝对是开发中可以放心使用的主力选择。更重要的是，我知道Postgres有一些后面我们可能能用上的高级功能。比如其中一个功能是订阅通知机制（LISTEN/NOTIFY），这将是我们在第8章提到的实时缓存系统背后的秘密武器。对于我们要完成的MVP，这个特性还用不上，但即使暂时用不到全部功能，从一开始就选择一个功能强大的地基，在将来无疑也是会受益颇多。
综上，我们的盖房图纸已经就绪。技术栈选择如下：
- 编程语言：Python
- 编程框架：Django
- 数据库：PostgreSQL
万事俱备，可以开工了。现在需要开始浇筑地基，准备建造承重墙了。换句话说，我们需要开始准备服务器了。
