使用Meteor开发真实生活体验

时间:2015-02-18 10:00:55

标签: meteor

我正在开展一个项目,我们必须尽快决定是否投资我们当前的技术堆栈以改进它并使其更灵活地支持我们的上市时间(基于LAMP的堆栈)或是否改变到不同的堆栈,希望它能使我们的开发更快,更有效,也可能更有趣。

我们正在关注的一个框架是Meteor。所以我想知道:有没有人有过将中型项目启动或转移到Meteor的真实生活经验(3个开发人员,几百个活跃用户,大多数短暂的小块用户生成的内容,由所有用户,需要立即更新)?您是否有关于可以分享的生产力,代码质量和代码效率的指标?或者只是总体感觉如何去?使用Meteor超过一周或两周时,你对Meteor有多高兴?如何在较长时间内保持可维护性?它的扩展程度如何?

非常感谢任何见解!

1 个答案:

答案 0 :(得分:7)

我会尽可能地保持这个目标: 我从Django切换到Meteor,PostGreSQL切换到MongoDB。

切换堆栈的成本很高。一种新的语言,语法,模式,甚至可能是IDE。在线课程,坚实的node.js基础,对io.js,ES6和Mongo 3.0的好奇心。回顾一下JavaScript如何处理日期和数字,以及如何使用JavaScript查询mongo。 最重要的是,您希望您的开发人员在引擎盖下达到顶峰,以便了解Meteor魔法,以便他们了解纤维,反应性,DDP和最小化。所有这些事情将花费每个开发人员至少160小时,但有必要成为一个称职的开发人员。跳过这些步骤,你就会有一群猴子拉动杠杆。

回答你的问题: 生产率?随着代码质量的下降,它将触底。然后慢慢爬,并可能超过以前的标记(如果它是开发人员喜欢的东西)。这是因为客户&服务器使用相同的语言和只是一个档案。调试消息&堆栈痕迹非常好&热门代码重新加载,虽然仍然不是很好,但是很好。

代码质量与框架完全无关。

代码效率很好,因为大多数时候在幕后处理的反应性和光纤使得以同步方式编写服务器代码成为可能。这增加了代码的可读性。

可维护性是代码质量的另一个词。

可扩展性更像是一个关于node.js的问题,但是适用于VAST的大多数项目。对节点缺点的诚实批评是:https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b