当我知道我会弄错的时候我该如何建立一些东西?

时间:2010-02-19 21:33:44

标签: ruby web-services api architecture

背景

我有一个个人项目,我一直试图建立大约5年。从本质上讲,它是一个在线游戏 - 一个Web应用程序。它不是一个“赚钱的人”,只是我真正想要建立的东西,因此寻找资金来雇用一支熟练的团队是不太可能的。

多年来,我已经构建了两个功能齐全的原型,从概念/用户测试的角度来看都是成功的,但从架构的角度来看,这两个原型都是成功的。代码很乱,无法维护或进一步开发,不得不被抛弃。

需要花费几年的时间才能获得构建客户所需的技能 - 这是丰富/有状态且相当复杂的。我将我的职业和学习与发展鸿沟的这一方面联系起来。我终于可以建立一个体面的架构,复杂的客户端,可以成长,不需要在6个月后抛出。在这方面还有很多工作要做,但至少我知道我能做到,并且做得相当好。后端是另一个故事。

到目前为止,我已经使用PHP,SQL,Ruby,CouchDB,MongoDB,FriendlyORM,NodeJS等各种组合重建了至少11次后端。在发现一些巨大的东西之前我通常不会走得太远我的方法的缺陷并重新开始:RPC到REST,与文档驱动的关系。我很清楚过早优化是万恶之源,但应用程序非常依赖快速移动的高动态数据。 RESTful API设计,扩展,分片,缓存,身份验证,复制 - 我对这些都没有太多经验,我不能指望它很快就会变得非常体面。这些事情需要多年的学习和经验。

找到这方面的专家更有意义,但没有资金,我觉得我需要成功部署另一个原型才能吸引合适的人选。所以,我必须尽可能地建立它。

问题

假设我构建它,后端架构将是错误的并且需要重建,继续构建“足够”以继续开发客户端应用程序的最佳方法是什么?即使它很讨厌,有没有办法“拼凑”一个JSON Web服务? Ruby与Sinatra和MongoDB? Django的?是否有一些开箱即用的Web服务构建器?不需要全栈Web框架,因为没有表示层 - 只有数据。任何建议都将不胜感激。

7 个答案:

答案 0 :(得分:7)

首先使用干净的模块化代码使其工作缓慢。

如果它是模块化的,你可以更换一两层而不必废弃整个东西。

虽然它们提供模块化,但要小心Web服务,甚至是REST,因为它们往往很慢;例如,每个连接都有很多开销。

答案 1 :(得分:5)

构建这种大型,复杂的应用程序,尤其是具有大量相互依赖性,特定于状态的条件以及可能需要使用不兼容语言的客户端 - 服务器部门的应用程序,无论您如何处理它,都是令人生畏的。根据我对这类其他项目的经验,无论你多么小心,你注定要在第一次尝试时失败。诀窍是将失败视为成功之路上不可避免的一步,而不是在构建应用程序时对所有小事进行大惊小怪。

第一个任务应该是让它尽可能少地编程“工作”,简单地获得你正在寻找的效果,即使非常粗略,所以你可以看到它们如何组合在一起。如果你可以将这个大问题分解为一系列较小的问题来解决,你可能会发现一个元素的成功,这可能会激发解决更大或更多的问题。

采用的有用策略是保持应用程序的元素松散耦合,以避免相互依赖,除非严格要求,因此您可以交换或改进整体的部分而不需要一连串的后续更改。例如,您的网络代码可以在客户端和服务器之间传输状态更改,而无需关心状态本身的性质,但您的状态管理代码不必关心状态如何传输,只需要关注状态。< / p>

掌握应用程序的整体架构也很有用,这样您就不会迷失在杂草中。从高级别的角度来看,您可能希望熟悉基本的Design Patterns,它可以帮助您将一些难以理解的代码组合成简单,模块化且易于构建的内容。

关于框架和语言的主题,我会说避免频繁切换。虽然探索一种新语言以了解哪些功能可能对您的特定问题有所帮助,但是如果您坚持使用一种语言可能会更有效率,即使可能难以实现某些功能,因为您可以更有效地使用它,改进你的方法,以更好地适应语言。虽然Haskell可能更适合某些问题,但即使是普通的旧PHP也可以通过足够的决心来完成同样的事情。

有尝试新事物的尝试,扩大工作范围以使其“正确”,构建新功能,但为了保持项目的控制,你必须保持纪律,以避免这些昂贵和分散注意力的活动,这些活动通常是客观的,只考虑到项目的总体状态而只是花哨或过早的飞行。

要专门回答您的问题,请在您最熟悉的框架中构建它,您的优势所在,并以较小的增量进行,以产生有用的结果。也许这是客户端显示引擎,网络组件或后端状态转换,但不管它是什么,你应该让它处于“足够好”状态,以开始将其他组件附加到它。

解决十个小问题既繁琐又费时,但要比解决一个巨大的问题容易得多。

答案 2 :(得分:3)

您无需构建任何类型的Web后端即可继续使用客户端应用程序进行原型设计。只需使客户端应用程序调用返回虚拟数据的存根函数。

答案 3 :(得分:2)

我的观点:过分强调技术,而不是坐下来做正确的设计。

  1. 从高级设计开始。
  2. 确定所涉及的不同主要内容。为第1步和第1步花费一些时间2。
  3. 了解您可以使用哪些现成的组件来帮助快速实现不同的部分。考虑到您以后可能会删除这些组件(包括您自己的解决方案)。
  4. 重访#1&amp; #2
  5. 挑选一两件,然后开始编写相关部件的工作原型。
  6. 完成练习后,从第1步开始,看看有什么变化,以便你可以相应地进行补偿。

答案 4 :(得分:2)

Johnny G几乎把他对你原来问题的评论钉在了一起。你描述的情况甚至发生在财富500强的信念与否。在选择并每三个月推出最新最酷的技术之前,您需要彻底规划您正在尝试构建/完成项目的内容。

我认为这篇文章来自有线,“学会放手”关于公爵永远最终被运送的失败,将比我能更好地解释这一点。

http://www.wired.com/magazine/2009/12/fail_duke_nukem/

(无论如何,这也是一个非常有趣/内容丰富的阅读)

答案 5 :(得分:0)

如果您的项目很糟糕且没有人使用它,那么优化它的重要性是什么? 结束最终版本的工作,我相信您会发现许多其他尚未考虑的问题,这些问题可能更为重要。

答案 6 :(得分:0)

我发现只有一种方法可以完成个人项目。

首先编码智能,稍后再计划。开发该原型,但设计它可以拆卸任何单件并由另一件替换。

例如,如果您的语言选择是ruby,那么构建您的类以拥有一个您永远不会破坏的定义良好的接口。担心每个功能“做”正确的事情,而不是真正关心它是如何做的。

然后,回到模块化构建的原型,并一次修复一个。