互联网创业项目该如何选择技术语言?

2013.10.19 94 Comments 13,800 次阅读

我曾经在博客里转载过「移动互联网创业公司该如何选择服务器」、「如何拿下简单的域名」等适合互联网创业项目团队深读研究的文章。而今天我决定再次发表一篇关于互联网项目创业初期问题的文章。但是你不必深入研究,甚至你只需要明白这么一「伟大的想法可由几乎任何技术构建」你就可以略过周良的这篇文章。

项目成功与否取决于你是否有一个坚定的愿景。如果你能将你的愿景转化成一组衡量你每个决定的值,你前进的道路会更清晰,也更容易找到合适加入你团队的人。

除了愿景,许多初创公司专注于文化。人们都说文化是由创始人、最初的几个员工及产品本身确立的,然而,技术抉择对公司文化有直接影响这个说法却没怎么被提到。

你的项目初创可能基于J2EE、Oracle、Perl、PHP、Rails、Node.js或.NET,随之而来你团队的工程师将有不同的期望,不同的价值观,和不同的关注点。这些技术本质上是没有好与坏的区别。伟大的事情都有各自不凡的所在。但是它们伴随而来的是一种文化,明白我的意思不?选择项目的技术语言是可以影响公司文化的。几年前,我遇到一位负责人选择使用Node.js来搭建自己的应用。出于好奇,我问他为什么选择Node。他的回答很简单:基础的工程师对 Node.js 很兴奋,所以我可以很容易的招募到愿意为团队做贡献的人,甚至是免费劳动力的程序员,因为他们希望积累相关经验。

这个决定既定了他工程师文化的团队和团队成员——那些能够在这个项目中工作或对这个项目感兴趣的人。

问一个不一样的问题

选择技术之前,我认为我们不应该问什么技术是我们需要使用的, 我们应该问我们自己:

选择这个技术符合我们公司的核心价值观吗?

这显然是个非常难回答的问题,因为我们需要切切实实地了解自己公司的核心价值观。我个人认为这一点是创建一个成功项目的关键所在。

你不能盲目地套用技术就像你不用能套用别人的商业计划那样。这是公司很重要的一部分(当然,是互联网创业项目,本文也仅限于讨论互联网创业公司选择什么技术语言)你的核心价值观,你的目标,你的团队,你的期望都是跟别人不一样的,既然不一样,为什么要套用别人的技术语言?

关于“这技术在某某公司用得非常适合”这样的论据是很少有效的。例如Facebook使用PHP,它“在Facebook公司用得很适合”,但是这意味着我们选都应该使用PHP?显然不是!

废话说多了,下面我们进入正题,讨论一下现在主流的一些程序语言。

 

PHP

理念:

  • 功能都实现出来,这一点很重要
  • 差不多算是互联网基础语言了
  • 只要有一个方法去实现它,那么就不会被破坏
  • 运行起来速度很快
  • 语言非常通熟易懂,任何人花一小段时间就能上手了。你也可以用java去写个同样的程序试试...
  • 面向对象是种落后的想法...

常见的使用例子: 

  • 你的第一个web app(基本大多数人的第一个网站不是php就是asp)
  • WordPress/Drupal的扩展

个人观点:

PHP出生至今,真的是风靡全球。它让web开发更加简单,容易上手。但是, 因为大量新的程序员开始使用PHP,并且每个人遵守的规范都不怎么相同,所以只有少数人能写出漂亮的PHP代码。

很难找到标准遵守PHP规范的代码,而且我一直纳闷PHP到底有没有自己的规范标准。这导致了PHP社区经常出现糟糕的质量低下的代码质。PHP程序缺乏测试,安全问题也是一个很头痛的地方!

 

Java

理念:

  • 可移植性
  • 像C/C++那般的能力,但却能够自动管理内存
  • 更多地关注面向对象
  • IDE是必须有的
  • 消耗所有内存...
  • 线程处理
  • Java applets
  • JVM(Java Virtual Machine)
  • 开源(实际上现在的时代就是开源互联网)
  • 缓慢但更为安全的开发流程

个人观点:

Java是非常有趣的语言。在几年前很多开发者已经厌倦了Java,他们找到了其他新的语言。开始转向一些脚本语言,像PHP,Pyhton,Ruby或者一些更加难懂小众的语言,比如Erlang。

尽管如此,Google通过Android展示了Java并不像我们脑海里的那么糟糕(只要你并不是使用J2EE或者Swing)。现在有一种”赶时髦“的趋势视乎暗示着Java再次变得酷起来了。这些大多建立在两件事情上:

  • JVM
  • 高质量的代码库

即便如此,对于我们来说,花一整天来编写Java程序看起来并不是一件吸引人的事(枯燥、枯燥、枯燥!)。另外还有一系列的其他JVM语言供你选择,他们成熟而且兼容Java扩展库(例如:Scala, Groovy, JRuby, Clojure),你也是可以搭配来使用它们的。

自从大量理科生和毕业大学生学习Java后,聘请Java程序员并非一件难事,但是请注意对于前期创业公司来说,要找到高水准的工程师并且对写Java程序感兴趣是一件极具挑战性的事情。

另外注意:如果你的项目目标是Android,那么不用想得太复杂,即使你认为其他JVM语言更好,你也要坚持使用官方的推荐语言。

如果我们用java作为创业公司的技术,那么还是会存在很多问题的。你可能会想同时使用一些的“更快,更灵活”的解决方案(比如 Ruby, Python, Node…)。但对于公司跟程序员来说,一个跨平台语言带来的价值是非常巨大的,这就是为什么Java语言看起来节奏很慢,但在实际应用上确实是非常活跃的。

 

C#/.NET

理念:

  • 更好的Java
  • 最初是为了桌面与嵌入式软件设计的
  • 比开发Java的小伙伴们拥有更好的IDE
  • 企业级般的重量了,但是提供了大部分Rails很酷的特性
  • 矛盾的开源版本
  • 缓慢但更为安全的开发流程

个人观点:

当我回顾C#在发布C#5的时候,我不得不惊叹,我真的对该语言新的特性留下了深刻的印象。单从纯粹的语言设计角度来看,C#是有一丁点的领先于Java。在Visual Studio里写Javascript时的欣悦感让我感到很舒服(自从我用VS主要为了C++后,我真的再也没有期待过什么了)。

另一件让我印象很深的是:C#可利用的文档的质量高!但是C#并不是开源的,Visual Studio + MSDN 整个环境都因为licenses跟内存损耗而变得很糟糕。

微软正在慢慢地往开源发展,所以有了更多像Azure的开源方案。.NET仍然是微软开发的中心。作为创业者,应该考虑下你对开源的看法了。

C#吸引了大部分Java群体中的变向者:这些工程师们寻求稳定性和有保障的合同远胜于追求开源。还有他们可以容忍IIS!

明确的可替代品

在过去的这些年,有两个动态语言对于新的创业项目来说变得十分受宠:Python和Ruby。这两个语言实际上有非常多相似的地方。现在Python因为后台apps而著名(因为NLP, biotech, APIs, SOA的因素 )而另一方方面,Ruby因为面向用户的apps而著名。尽管这两个语言都受到了一样的限制(主要是性能跟并发性),但是他们的核心价值和语言有着不一样的专注点。

 

Python

理念:

  • 只有一种显而易见的做事方法
  • 代码要漂亮简洁和明确
  • 文档是关键
  • 有较强的语言设计引导

个人观点:

作为一个更喜欢ruby的人来说,我常常嫉妒python项目文档的质量。同时python设计的初衷——给你一个正确的编程方式却又让我又爱又恨。通常这一初衷对于团队来说很好,但某些时候令人抓狂。

在某些领域python有很多优秀的库,并且这些库和想要解决的问题有关,这种情况下python可能是最好的选择。python开发者知道怎样去讨论交流他们的代码。但是python在互联网流行前就已经存在,如果你比较看重并发和处理能力,那么这个并发性很差的动态语言可能不是一个很好的选择。

 

Ruby/Ruby on Rails

理念:

  • 为人而不是机器而设计的(Designed for humans, not machines)
  • 极端的灵活性:如果陷入困境的话,是你的原因,那是你!
  • 一切力求简单、优雅并充满乐趣
  • DSL至上,尽DSL
  • 测试非常重要
  • 事情变化很快,保持学习
  • 激情活力

个人意见:

就我而言,Ruby是我非常喜欢的语言。你会发现GitHub上存在大量的Ruby开源代码。Rails是一个了不起的Web框架,如果你知道如何使用工具的话,它可以让大多数的Web项目容易实现。

但灵活性和过快的开发周期也有缺点。随时准备在你的代码上投入大量时间以保持其更新以及分离废弃变老的库。如果不能依靠缓存,一个成功应用的性能往往被缺乏良好的并发支持所限制。

Ruby开发者主要是用Rails开发,所以与框架特性相比基本不会去深入核心语言本身的特性。他们往往是充满好奇心且机会主义的(以一个很好的方式),有些实用主义,关心代码质量/结构和测试覆盖率。Rails开发者早期采用它的典型原因是由于该框架本身默认使用的一些新技术(coffeescript、turbolinks、CSS预处理器……)。

Ruby和Rails主要吸引了那些想把事情做得快而优雅的开发者。相比于底层计算细节,这些开发者往往是以产品导向的,他们更关心的目的和客户价值的实现。

 

Node.js (Javascript)

Node.js不是一门编程语言,但它是使JS在服务器端运行最流行的方法。和我对Ruby的大部分介绍和评论是关于Rails一样,相比JS我更关注Node。

理念:

  • 为实时驱动的应用程序而设计,高吞吐量、低延迟
  • DIY
  • 小的内核,剩余的内容由社区维护
  • 低耦合
  • 借鉴Ruby/Python

个人意见:

我觉得Node.js很有趣。在技术上Node没有太多新内容。Python有Tornado/Twisted,Ruby有EventMachine,C有 libevent。

事件驱动的框架已经使用了一段时间,但Node具有两大优势:1.大多数JS库是非阻塞*大多数Web开发者不管怎样都要写一些JS。

在前端和后端使用相同编程语言的想法吸引了不少人,但值得与否还有待验证。

Node的开发者大都是它的早期接受者,他们更喜欢自定义而不是按惯例创建结构/模式,这样使他们觉得更舒服。它吸引开发者使用已知的语言(JS)去处理高层的并发。Node作为一个框架处理的水平比经典的MVC更底层一些。Node开发者们也真的喜欢这个在服务器和客户端使用相同语言的想法。

 

Clojure

理念:

  • 实用且符合现代人使用的Lisp
  • 一切皆是数据
  • 并发性,并发性,并发性
  • 让那该死的可变状态见鬼吧
  • 能够很好地与Java协作
  • 稍微靠近科研路线,但并不影响他的实用性

个人观点:

我最喜欢Clojure的一点是它的lisp。一旦你攻克了它的圆括号和操作符/参数顺序,那么Clojure将很可能让你重新思考你构建代码的方式。对于处理数据跟强迫你保持代码简短这两方面来说,它真的很棒并且高效。

让我头疼的是我没有足够的时间去编写Clojure。当我尝试去追踪那些数据时,我的大脑会出现混乱。对于该语言来说异常通常是没意义的,假如你尝试解决别人代码的bug,这将会是机具挑战的事情因为Clojure本身是复杂的语言,并且可以用宏来拓展。最后,Clojure语言并不是真的面向web开发,Clojure完成的大多数作品都是以数据作为中心的。

Clojure主要吸引了那些处于边缘,对编程语言有求知欲,面相数据的程序员。如果你寻找有编程语言怪癖的数据处理专家,那么Clojure将会是吸引他们的好方法。

 

Go

  • 更强大的C
  • 你可以自己管理内存,前提是你不能粗心大意
  • 直观的代码更好
  • 丰富的代码库
  • 效率很快...从编译到执行
  • 存在并行编程模式,并且使用简单

个人观点:

喜欢Go(亦称Golang)。Go或许对于一些人来说有些无聊,但它的简洁与效率是真材实料的。

Go强迫你更多地去思考你的代码的结构,你的数据/代码行为,因为你不能总是坚持面向对象的编程模式。我发现我的代码总算变得容易调试,结构更简洁,但有时会重复性比较大(例如:错误处理)。

没有比Go更加方便地开发并发业务的语言了。一旦需要编译,你的代码编译加上运行的时间会比Rails服务器启动的时间还快。Go支持一些鸭子类型(duck typing,动态类型的一种风格),这造就了从Ruby(举个例子)转换过来显得颇为简单。对比起一些脚本语言,它所编写产品的性能实在让人觉得惊叹,并且它占用的内存很小。

 

技术驱动理念

技术的选择会受到理念的影响。你需要清楚而谨慎地权衡你选用的技术是否与企业的价值观一致。做出正确的决定有助于你从技术细节的纠缠中摆脱出来,拥有更多投入商务运作的时间。

Related Posts:
94 Responses
Comment (24)
Trackback (0)
  • #31
    趣你的 :

    粥凉!!!

    2013.12.7 20:58 Reply
  • #32
    趣你的 :

    粥凉!!!

    2013.12.7 20:58 Reply
  • #33
    毕扬 :

    你这主题真心丑啊,而且怎么做的跟垃圾站似的

    2013.12.4 21:56 Reply
    • 周良 :

      嗯,我也在考虑要不要换一个

      2013.12.5 11:15 Reply
  • #34
    毕扬 :

    你这主题真心丑啊,而且怎么做的跟垃圾站似的

    2013.12.4 21:56 Reply
    • 周良 :

      嗯,我也在考虑要不要换一个

      2013.12.5 11:15 Reply
  • #35
    木篱笆 :

    难怪程序员这么忙,因为有太多语言要学习了~

    2013.12.4 13:00 Reply
    • 周良 :

      这个也不少,忙的是构思程序,哈哈

      2013.12.5 11:16 Reply
  • #36
    木篱笆 :

    难怪程序员这么忙,因为有太多语言要学习了~

    2013.12.4 13:00 Reply
    • 周良 :

      这个也不少,忙的是构思程序,哈哈

      2013.12.5 11:16 Reply
  • #37
    www.zuoyi123.com :

    还是要根据情况来 PHP不错

    2013.11.6 08:55 Reply
    • 周良 :

      太复杂的的东西就不适合php了。ruby不错

      2013.11.9 10:59 Reply
  • #38
    www.zuoyi123.com :

    还是要根据情况来 PHP不错

    2013.11.6 08:55 Reply
    • 周良 :

      太复杂的的东西就不适合php了。ruby不错

      2013.11.9 10:59 Reply
  • #39
    www.coomt.com :

    PHP的前景还是挺大的

    2013.11.4 16:28 Reply
  • #40
    www.coomt.com :

    PHP的前景还是挺大的

    2013.11.4 16:28 Reply
  • 还没有Trackback
Leave a Reply