web应用 是大趋势啊

[hui zhang]

越来越发现 web 才是前端 最大的入口

以前的native 软件 好多都 web 了

qq  music 迅雷  云播 云盘 微信 美图秀秀 google doc

包括一些行业软件。

之前学的 cpp  搞了 好多年

发现 搞web  cpp 力不从心啊。

可以 cpp 搞的web server 开发框架？

[Zhang Cheng]

对于一个较大型的网站，web server并不仅仅是一个小东西。可以把后端的任务分为两类，一类是处理数据和业务逻辑的，一类是拼接字符串生成网页的。处理数据和业务逻辑又可以分，有离线的和在线的。

拿一个简单的例子来说，比如一个图书馆查询系统，如何在数据库里存储图书信息，​如何判断一本书是否有库存，这属于业务逻辑，一般可以在线做（也就是每次用户发出请求时进行处理），这个系统可能会有兴趣模型，可以为每个用户推荐他可能感兴趣的书目，这需要一些建模和计算的工作，一般会在线下进行。当用户发起访问时，后台根据用户请求的内容，决定要返回什么样的数据，并通过json、自定义的数据结构或者直接生成网页返回给前端浏览器渲染。

一般来说，现在很少有人会用cpp来做网页渲染的工作，开发效率太低。但是可能许多离线的数据处理仍然会用cpp、java等语言来做（其实cpp用的也很少，说到大数据，最近hadoop比较流行，主要是因为其提供的并行框架比较容易上手使用，并不是因为性能）。

一般大家说到web框架，主要是用来进行简单的在线的业务逻辑处理工作以及拼接网页的。常见的模型主要都是mvc型的，model定义数据结构，一般会跟数据库挂钩（框架本身可能会负责与数据库通信），view一般是网页模板，由前端的人开发，后端只需要提供数据即可，controler负责一些比较简单的在线业务逻辑，处理用户的输入、查询数据库、决定吐什么样的数据。这部分工作一般不会用cpp来做，都是脏活，特别是字符串拼接，用cpp做就是噩梦。

--

Cheng,

Best Regards

[Bojie Li]

2014-05-28 14:57 GMT+08:00 hui zhang <fastf...@gmail.com>:

越来越发现 web 才是前端 最大的入口

以前的native 软件 好多都 web 了

qq  music 迅雷  云播 云盘 微信 美图秀秀 google doc

包括一些行业软件。

Web 技术不如 Native 技术成熟，但 Web 仍然在快速抢占桌面软件的市场，不过我觉得这件事并不是技术决定的，而是商业模式决定的，而商业模式又是互联网的发展带来的。

在有网络的情况下，没有人喜欢从光盘上装软件。早期的网络由于技术原因并不普及而且价格昂贵，所以软件开发者只好把软件通过光盘的方式分发，由于分发渠道受限，一次性收费只好比较贵。软件出了 bug 不能随时修复，因此软件开发要经过漫长的测试流程。互联网普及之后，软件的分发方便多了，就可以采用薄利多销的模式，软件的价格下降甚至免费，靠广告和增值服务盈利。由于可以通过网络推送更新，软件出 bug 的成本也降低了，软件的迭代速度由此加快。现在基于 Web 的应用是软件快速分发和自动更新的极致，任何人只需打开网站就能使用软件，而且每次打开软件都会强制更新。

中国的网络运营商如果出现一位刘志军式的人物，国内整个互联网行业都能进一大步。现在这种网络状况导致互联网公司（包括 LUG 网络服务）的大把精力花费在 hacking 上。所谓 hacking 就是别人没做好的事情，我们要想办法适应。早先我以为做了网络研究就能知道这些 hacking 的办法，事实上国际上很少有人折腾这些人造的问题。

10 年前如果有人推出基于 Web 的桌面软件，肯定会被质疑不能上网的时候怎么用，而现在担心不能上网的人越来越少了。现在移动互联网就像 10 年前的 PC 世界，由于无线网络的限制，随时随地上网的成本很高，因此 Native 应用仍然胜过 Web 应用。大多数人都是从程序性能、API 完备性的角度来解读的，而我认为这些都不是本质问题，按照 PC 互联网的历史推算，Web 仍然是移动互联网的未来。

[单栋]

不知道为什么，我觉得网络的未来绝对是更加有效的socket协议，感觉B/S架构有着一些不好的地方，但是具体又不知道该怎么表述……
算了，以后如果是web的天下的话，就感觉自己输了……

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bojie Li]

首先，浏览器里可以用 Web socket。
其次，你觉得 B/S 结构有什么问题？API 太少和 JS 性能不高都不是本质问题，浏览器厂商可以逐步解决。

单栋 <sd542...@gmail.com>编写：

[Bojie Li]

C++ 怎么力不从心了，瀚海星云 BBS 是用 C 语言写的，没有使用任何数据库，性能比 Discuz 之流不知道高到哪里去了。主要是程序员的时间和机器的时间谁更值钱的问题。如果你给 100 万用户的网站编程序，程序员的时间更值钱；如果你给 1 亿用户的网站编程序，机器的时间更值钱。所以在合适的地方，你的 C++ 是大有用武之地的。

hui zhang <fastf...@gmail.com>编写：

越来越发现 web 才是前端 最大的入口

以前的native 软件 好多都 web 了

qq  music 迅雷  云播 云盘 微信 美图秀秀 google doc

包括一些行业软件。

之前学的 cpp  搞了 好多年

发现 搞web  cpp 力不从心啊。

可以 cpp 搞的web server 开发框架？

[hui zhang]

c开发web成本太高了 估计 除了bat  国内 谁也玩不起来

也许我该把问题问得更具体些

我的问题是

目前web server 的那种解决方案    最好

1  LNMP    传统模式  但php 效率低，不知道 对新技术  mongodb  rabbitmq  memcahe 的支持如何。

2 nginx   +  clang fastcgi 没尝试过  

2 node.js    js写server  v8  速度很快 号称堪比java  硬伤是debug 困难

4 node.native  想法很好， 目前在开发中， 没有实践检验， （非主流）

5 c 框架   目前没有知名成熟的吧  或许 我还不知道。      （非主流）  优势是   c/c++类库多 ，方便扩展。

想听听大家意见， 不要提什么 golang dart   也许很牛逼，但是未经市场检验  离成熟 应用还有些距离。

希望大家能给个成熟的解决方案。

毕竟是做项目，不是发论文

谢谢

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/gxKJw-c8GcA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[Yan Wang]

php效率不低的说。facebook开发了一个东西叫hip-hop，把php编译成c代码以后执行。这个东西是开源的，支撑了整个fb10亿用户的前端（html+php）。​

[Guo, Jiahua]

你想做一个什么样的网站？

大概有什么功能，有多大的访问量？

[Zhang Cheng]

2014-05-28 22:36 GMT+08:00 hui zhang <fastf...@gmail.com>:

c开发web成本太高了 估计 除了bat  国内 谁也玩不起来

​看用来干啥。如果有许多离线的数据处理，用C/C++也是很正常的事。但应该不会有人用C/C++来做生成网页的工作。

 

也许我该把问题问得更具体些

我的问题是

目前web server 的那种解决方案    最好

1  LNMP    传统模式  但php 效率低，不知道 对新技术  mongodb  rabbitmq  memcahe 的支持如何。

2 nginx   +  clang fastcgi 没尝试过  

2 node.js    js写server  v8  速度很快 号称堪比java  硬伤是debug 困难

4 node.native  想法很好， 目前在开发中， 没有实践检验， （非主流）

5 c 框架   目前没有知名成熟的吧  或许 我还不知道。      （非主流）  优势是   c/c++类库多 ，方便扩展。

​web开发几乎从来不会过分的考虑性能问题，大多数的web应用，在达到硬件性能瓶颈之前很久就已经死掉了。一个应用即使会很火，也是慢慢成长的，不可能一夜之间爆红（当然也有这样的例子，但这样的概率太小了）。

web开发讲究的就是开发速度，一个应用要能够非常快速的开发迭代，今天想到一个新点子，可以快速实现上线，这样应用才有可能活下去。

对于做项目来说，一般的原则就是，你熟悉什么工具用什么工具，不要去挑。如果你什么工具都不熟，那么你并不适合做startup的coder，你需要找一个做过web开发的人来带，否则你会很艰难，而且有时候会过于沉浸于技术上的追求（通俗的话说就是钻牛角尖）。

想听听大家意见， 不要提什么 golang dart   也许很牛逼，但是未经市场检验  离成熟 应用还有些距离。

希望大家能给个成熟的解决方案。

​​php算是最成熟（但已不流行）的方案，网上的教程最多，对新的工具（mongodb、memcache等）的支持也都不错。

python（django）和ruby(ror)是现在非常流行的方案，运行效率听起来不行，但实际上对大多数网站全都够了，也不伐一些大网站。有名的比如dropbox、豆瓣都是python开发的。

node.js我不熟，但也是现在非常流行的技术。

golang其实也算是比较成熟了，google内部也用的比较多了（比如dl.google.com现在已经是用golang重写了），但是golang直接用于web应用开发的似乎不多，有一个web框架beego。

dart是在浏览器里运行的，不是后端的东西。目前不建议用dart，可能浏览器支持不够广。

​如果是startup的项目，个人建议用python(django)或者ruby(ror)。框架很流行，网上的资料多，有问题到社区提问也能很快的得到回答。不用考虑性能的问题。

如果你或者你的团队里有做过web开发的，那么你（他）熟悉什么工具就用什么工具。

另外，做web开发，请一定要搞清楚有前端和后端之分，前端远比后端重要。美工、前端直接决定了产品的用户体验，现在的web早已过了拼后端的年代了，现在都是比的用户体验和玩法。后端的东西，快也快不到哪里去，满也慢不到哪里去，数据你有的别人也有，你能做的分析别人也都能做。对于做产品的团队来说，一般前端的人数会比后端更多。

--

Cheng,

Best Regards

[Bojie Li]

On May 28, 2014, at 22:36, hui zhang <fastf...@gmail.com> wrote:

c开发web成本太高了 估计 除了bat  国内 谁也玩不起来

也许我该把问题问得更具体些

我的问题是

目前web server 的那种解决方案    最好

1  LNMP    传统模式  但php 效率低，不知道 对新技术  mongodb  rabbitmq  memcahe 的支持如何。

2 nginx   +  clang fastcgi 没尝试过  

2 node.js    js写server  v8  速度很快 号称堪比java  硬伤是debug 困难

不仅是 node.js，php 怎么 debug？Ruby on Rails 怎么 debug？这些脚本语言似乎没有像 gdb 那样强大的调试器吧。当然可能是我不知道，求推荐。

我觉得用哪种框架都差不多吧，熟悉的就好，PHP 再过时，这么多网站不还在用嘛。Node.js 火，并不是因为它快，而是因为前端都会 JavaScript，容易上手 node.js。我见过好几个创业团队的人希望我加入之后能解决性能问题，我都会说性能问题不是创始阶段需要考虑的，因此我的技能并不能派上用场；相反我缺少很多做产品的感觉，这是初创团队最需要的。做产品很忌讳玩弄自己不熟悉的炫酷技术，玩着玩着就把自己玩进坑里了。

[单栋]

首先是B/S架构注定客户端一定要有一定的大小，如果你觉得以后物联状态下所有节点都能够实现B/S那我就觉得还成，再者，对网络占用太多了，特别是大量的请求，但数据量很小。
然后对于WebSocket就更加明显了，客户端会进一步变大
还有就是从并发上考虑了，如果真的希望做很大的并发，为何要中间套用一层web呢？app明显能够获得更加大的并发。

[Bojie Li]

On May 28, 2014, at 22:36, hui zhang <fastf...@gmail.com> wrote:

c开发web成本太高了 估计 除了bat  国内 谁也玩不起来

成本高不高要看你自己的熟悉程度，我见过某国际金牌级别的神牛 5 分钟写 100 行 C 代码无 bug，如果你熟悉 C，就算你比他慢 10 倍，5 分钟 10 行，一小时 120 行也很快了。如果代码主要是你一个人写，最熟悉的就是最好的。

[Zhang Cheng]

2014-05-28 23:40 GMT+08:00 单栋 <sd542...@gmail.com>:

首先是B/S架构注定客户端一定要有一定的大小，如果你觉得以后物联状态下所有节点都能够实现B/S那我就觉得还成，再者，对网络占用太多了，特别是大量的请求，但数据量很小。
然后对于WebSocket就更加明显了，客户端会进一步变大
还有就是从并发上考虑了，如果真的希望做很大的并发，为何要中间套用一层web呢？app明显能够获得更加大的并发。

“中间套一层web”，我猜你想表达的意思是中间使用HTTP传递信息吧？使用HTTP的最主要原因是：

* 简单，不用自定义通信协议，并且在扩展方面有很成熟的工具、解决方案。例如可以使用nginx进行load balance，对于能缓存的数据，可以方便的使用第三方提供的cdn服务。自定义协议的话，什么都得自己来。

* 可以方便的替换前后端。例如一个应用首先做了web端，后来要做移动端，运行的平台很不一样，web端可能主要是js，移动端可能是java（android），可能是objective-c（iOS），还可能是其他的语言平台。如果自定义通信协议，那么各个平台上都要用不同的语言实现一套。这样的成本太高了。但是HTTP作为一个非常成熟、已然标准化的通信协议，几乎所有的平台都支持。应用程序只需要关注自己的数据，而不必关心通信协议。后端也一样，今天用python写了，明天量大了，想用java重写，没问题，重写时也只用关注自己的数据结构和业务逻辑即可。

* B/S结构，前端大一点没关系，现在的网络已经非常好了。即使中国这么差的网络，有时候打开微软的web版office比本地都快。大不是问题，但是免去了安装繁琐，既方便了用户，更方便了开发者。

还有，你指的“并发”是什么？没有理解你说的并发是什么意思。

--

Cheng,

Best Regards

[Bojie Li]

现在 C/S 结构的客户端还不够大吗，别忘了操作系统。Windows 和 ChromeBook 哪个更轻量级，不用多说吧。

你也许考虑的是嵌入式设备，这是另外一个问题，我前面说的是用户直接交互的终端设备。

并发这个我没看懂，能详细说说吗？套一层 web，无非是用户每次启动软件时问问服务器有没有更新，如果没有更新就是 HTTP 304 Not Modified，消耗的带宽很少，对服务器也没什么负载。app 与服务器通信很多也是 http 协议，跟 web 应用有什么区别呢？

[单栋]

恩，确实http很方便，而且确实跨平台也很不错，但是为了一个统一的客户端（browser），然后要重复的获取很多的数据真的值得么？比如office的一个logo
主要还是在第3条，我觉得未来网络的发展会跟不上终端的发展速度的，然后网络需求又越来越大，同时网络的可扩展性真心不太大，
如果网络能够一直发展下去，并且一直提供足够的数据流量的话，应该就没问题。

--

[单栋]

恩……大概我也说的有点自我矛盾呢……确实也只是我自己的个人见解……没怎么仔细推敲
B/S架构和C/S架构的区别我觉得就是客户端是一个统一的客户端还是多个小的专用客户端的差异，而且我更加觉得个人终端的发展会比网络的发展速度快，还有就是，我觉得小客户端的开发，在未来应该和开发一个Web的代价差不多。

[Zhang Cheng]

2014-05-29 0:01 GMT+08:00 单栋 <sd542...@gmail.com>:

恩，确实http很方便，而且确实跨平台也很不错，但是为了一个统一的客户端（browser），然后要重复的获取很多的数据真的值得么？比如office的一个logo
主要还是在第3条，我觉得未来网络的发展会跟不上终端的发展速度的，然后网络需求又越来越大，同时网络的可扩展性真心不太大，

​终端的发展指什么？指终端的计算能力还是存储能力还是表现能力？能否说的更具体一些？网络的可扩展性不大，是指哪方面的可扩展性？服务端的计算能力？带宽还是什么？

如果说计算能力，终端的计算能力确实在飞速的发展，但是终端的数据少，没什么要计算的。终端的计算几乎主要都来自于图形相关的需求，比如游戏的渲染。

如果存储能力，终端的存储发展远落后于服务器的存储。硬盘这东西用了这么多年了，iops几乎没有改变，手机使用sd卡存储，速度不是一般的慢，可靠性更是很差。而服务器存储，无论是量还是吞吐率还是可靠性，在最近几年，都有着极大的发展，存储方面现在甚至开始折腾低功耗了。

​​表现力，这个似乎跟网络没有关系。跟端有关系，浏览器这个端的表现力，现在发展的也是足够的快，现在除了native的游戏渲染性能外，其他方面完全不输native端。

​网络的可扩展性，到目前为止我还没看到有什么瓶颈。不知道你具体指哪些方面。

 

如果网络能够一直发展下去，并且一直提供足够的数据流量的话，应该就没问题。

​如果你指带宽的发展的话，现在带宽的发展是非常快的。一线城市已经开始逐渐推开百兆带宽了，百兆带宽就算在线看蓝光原盘都是够了。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-29 0:07 GMT+08:00 单栋 <sd542...@gmail.com>:

B/S架构和C/S架构的区别我觉得就是客户端是一个统一的客户端还是多个小的专用客户端的差异，而且我更加觉得个人终端的发展会比网络的发展速度快，还有就是，我觉得小客户端的开发，在未来应该和开发一个Web的代价差不多。

那估计你没有做过移动客户端的开发。凡是做端开发的都很蛋疼，因为升级很慢，如果写了一个bug，一旦分发出去了，就像泼出去的水，总是有许多人是不会经常更新软件的。​

而你也说了，“小”客户端，所谓小客户端，也就是客户端只负责最后的数据呈现，而不做其他的事情了，这跟浏览器应用又有什么区别呢？区别在于浏览器应用只需要使用人人都会的html/css/js来实现，浏览器负责渲染，但是客户端的开发则需要自己去实现渲染工作。客户端的调试也远比浏览器应用要麻烦许多（虽然开发客户端的IDE看上去都很高大上）。

不要把客户端看做是一个“统一”的客户端，这根统一没有关系。随着发展，浏览器已经不再是一个客户端，而是操作系统了，chrome os就是最好的回应。而一个网站或者一个网站提供的一个应用才是一个端。标签页就是操作系统的任务栏，每个标签页里运行着一个客户端。

​​

我

​觉得可以邪恶的说，许多应用开发移动的“端”，其主要目的并真的是为了提高用户体验，而是为了采集用户的数据，比如偷偷的上传你的通讯录，你的短信，你的通话记录，还有你使用其他软件的信息。

目前在移动端，我觉得除了浏览器以外，其实也有其他人在做应用平台，微信就是一个很好的例子。比如招商银行的微信银行，已经足够我日常使用了，查余额，查账单，乃至一些其他的银行业务都可以很方便的完成。倒是他开发的那个客户端，笨重至极，运行缓慢，耗电不说，里面要找一个我需要的功能都要半天。

我觉得将来应用的发展会是什么样的，具体的“端​”不是重点，在浏览器里也好，在微信里也好，操作系统原生程序也好，都不是重点，甚至会有更多新的平台出现，哪个胜出都不重要。

现在应用发展的特点是，轻客户端，也就是在客户端（无论客户端是什么）做的事情越来越少，客户端越来越注重于展现信息、提供更好的用户体验和交互。客户端的用户希望的是能用最便捷的方式使用到这个应用，而不需要为使用以外的其他事情付出精力（比如安装、升级）。在目前来说，浏览器目前占领了不错的地位，因为它跨越了各种平台，这是开发者最喜欢的事情，开发者所需要投入的精力最少，他们不用去花费很大的精力去解决兼容性问题（做Android应用开发的人应该都对此很蛋疼，硬件兼容性、系统版本兼容性，一大堆问题），甚至可以节省许多推广的成本（引诱一个用户点开一个网页很容易，但是要引诱一个用户下载并安装一个软件太难了）。还有前面说的比如更新方便等好处。

​我个人觉得，当今的应用，除了离线工具以外，都依赖服务器提供数据。所以无论“端​”是什么形态的，都逃不过“web”这个概念，因为它需要从网络上获得数据输入。

其次，要从网络上获取数据，就躲不过传输协议的事。HTTP是一个非常广泛应用的协议，绝大多数与服务器的通信都使用HTTP，这是事实上的标准，只有极少数的地方，出于历史原因或者内容特点才会使用HTTP以外的协议。

在短期的将来，应该不会有协议替代HTTP，只会有HTTP的改良版（比如spdy、HTTP/2.0），这些改良的东西，很多努力都花在了改进移动端体验上，例如更省电、更节省带宽、延迟更短等等。

--

Cheng,

Best Regards

[Bojie Li]

2014-05-29 0:07 GMT+08:00 单栋 <sd542...@gmail.com>:

B/S架构和C/S架构的区别我觉得就是客户端是一个统一的客户端还是多个小的专用客户端的差异，而且我更加觉得个人终端的发展会比网络的发展速度快，还有就是，我觉得小客户端的开发，在未来应该和开发一个Web的代价差不多。

一个统一的和多个专用的永远都是一对矛盾。每个平台的开发者都希望自己的平台能一统江湖，如果有一个统一的平台，自然应用（客户端）的开发者会省很多事。在 PC 领域 Windows 一统江湖了。但移动领域 iOS 和 Android 就难分伯仲，它们不仅代码上不兼容，界面风格也很不一样，所以移动开发者为了在两个系统上都做到最佳体验，就要苦逼地开发两个客户端。如果你开发一套 Web 界面，不可能既符合 Android 又符合 iOS 的风格。即使是同一种移动操作系统，对不同的分辨率开发者说不定还要做适配，当然可以有一些工具和框架自动化这个过程，但要达到最佳体验总是需要人工干预的。

不过开发者除了选择适配系统风格，还可以选择搞一套自成体系的风格，比如 Google 各种服务的 Web 界面风格是统一的。由于所有平台都支持浏览器，因此 Web 是在不同系统中实现风格统一的最好平台。

此外，Native 和 Web 也是两种本质上不同的软件分发方式：（1）Native 不强制用户使用最新版软件，Web 强制用户使用最新版软件；（2）Native 软件有中心化的唯一分发渠道，需要先安装后使用；Web 软件的分发是自由而无序的，无需安装即可使用。

[Bojie Li]

 你觉得个人终端比网络发展快，是什么方面？

我觉得网络带宽最近一直在以摩尔定律的速度发展。2004 年 Internet 陆地极速的记录是 4.x Gbps，2012 年这个记录已经接近 400 Gbps 了，十年翻了 100 倍。而现在用户真正能用上的带宽，离10年前的陆地极速记录还差得远，因此网络带宽还远远没有到技术瓶颈，发展快慢的影响因素主要是市场需求和成本。Internet 最大的技术瓶颈是延迟，因为光速是有限的，只要爱因斯坦是对的，我们就只能在传输控制和分布式算法上做优化。

而移动终端受电池的制约越来越明显，单位体积的电池容量发展缓慢，为了高性能，电池只能越做越大，物理尺度的限制很明显。CPU 也遇到了难以逾越的 heat wall，热量散不出去，主频和集成度就无法进一步提高。然而，我们用的移动终端上的 ARM 处理器比 PC 上的 Intel 处理器在性能上落后至少一代，但移动应用由于一般比较简单，我们仍然不会感觉到卡。瘦客户端、胖服务器的 B/S 架构应该更符合云和移动的趋势。

[hui zhang]

非常感谢你的 回答，  

分析得很透彻， 要是google mail group  有个像 stackoverflow  打钩的功能 就好了。

我就给你的回答 打个钩

现在有个项目 实在一个开源框架上搞的，  原框架用的nodejs ， 但是我们团队几乎没有人熟悉

大部分人都是搞 php 和  c的

特别我只对c/c++熟悉，

其实用c 开发的最大优势 是  debug   ，机器在做什么一目了然。

之前有用 脚本开发的经验，    脚本最大问题 就是 debug ，  因为没有comile   很多很小的问题得到运行时 才能发现，

这也是我担心 nodejs开发的问题。

如果有 c/cpp 框架 我首选c/cpp

目前小团队的创业项目，我感觉只有web 端 有前景了， mobile 平台 创业其实不好做，好多团队都在亏。

之前 好些朋友 也找我做web ， 可惜我不会啊。

如果能闲暇时光 搞点外快 还是不错的，  死工资 拿的真没意思。

 

--

[Bojie Li]

On Thursday, May 29, 2014, hui zhang <fastf...@gmail.com> wrote:

现在有个项目 实在一个开源框架上搞的，  原框架用的nodejs ， 但是我们团队几乎没有人熟悉

大部分人都是搞 php 和  c的

特别我只对c/c++熟悉，

如果你对基于组件（widget）的界面开发熟悉的话，建议看看 Wt（http://www.webtoolkit.eu/wt/），一个 C++ Web 框架，有点像 Qt。不过由于我没开发过桌面程序，对基于组件的不太习惯，还是老老实实用 MVC 框架去了。

另外，是不是你的输入法有问题，为什么你的句子里有很多空格？

 

--

-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/gxKJw-c8GcA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---

You received this message because you are subscribed to the Google Groups "USTC_LUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.

[Zhang Cheng]

2014-05-29 9:12 GMT+08:00 hui zhang <fastf...@gmail.com>:

现在有个项目 实在一个开源框架上搞的，  原框架用的nodejs ， 但是我们团队几乎没有人熟悉

大部分人都是搞 php 和  c的

特别我只对c/c++熟悉，

其实用c 开发的最大优势 是  debug   ，机器在做什么一目了然。

之前有用 脚本开发的经验，    脚本最大问题 就是 debug ，  因为没有comile   很多很小的问题得到运行时 才能发现，

这也是我担心 nodejs开发的问题。

如果有 c/cpp 框架 我首选c/cpp

​

如果说调试的话，​我觉得在web应用上，编译型语言甚至还不如脚本语言。

* 语法错误这种东西，编译型语言可以在编译时发现，脚本语言也同样可以在上线前发现，现在的脚本语言大多数也都带了lint工具，可以做很完整的语法甚至语义检查。

* 非语法上的错误，编译型语言也在编译时期也同样发现不了。不过动态语言（注意，这跟编译不编译没关系）会有一些潜在的问题，例如使用变量不需要声明，赋值语句中左值变量名写错了很难发现。但其实许多时候lint也会检查出来，我在vim中写python每赋值了一个新的变量，只要没写对这个变量的读语句，vim就会提示我有未使用的变量，如下图(图中另外两个叹号是警告我没写文档)：

* 逻辑上的错误，只能靠上线前测试（无论是人肉测试还是单元测试） 。我想不出有什么错误，使用编译型语言在上线前能检查出来，但是使用脚本语言检查不出来的。

* 与一般的应用不同，web后端的程序运行环境都具有很强的并发性和随机性，并发程序的调试无论是否编译型，其实都挺困难的。而且线下也都很难查出来。比如我们曾经在网上找了一个java版的qqwry ip库代码，线下测的好好的，线上使用了一段时间也没问题，突然有一天发现出问题了，查了半天发现是因为原代码中使用了一个全局变量做StringBuilder，在并发比较高时就挂掉了，一开始使用没出问题是因为量太小了。

* 要说调试难度不一样，我觉得不是编译不编译的区别，而是动态不动态的区别，跟脚本没关系。脚本里也有严格且高效的语言，比如lua。动态语言难调试，主要是因为缺乏一些静态的检查手段。就调试而言，在web的调试中，似乎只有打日志这一种方式最高效，很少有人或者说所有的web开发者本身都不会去搞个coredump下来慢慢分析，搞coredump的一般都属于系统架构组，怀疑使用的工具有缺陷时才使用。因为线上的环境很随机，最好的调试方法就是记录日志，然后尝试在线下复现。不带实际数据的调试都是呵呵。

* 再说为啥我觉得脚本语言比编译语言更方便，因为出现问题可以直接在线上修改，快速生效。例如发现问题了，立刻在线上临时加一些log()语句，可以很快的定位问题，而编译型语言则很麻烦，一般线上是没有编译环境的，线下编译再发布上线，这就已经很慢了。当然直接在线上修改代码是很不规范的线上运作流程，但确实是有效的定位问题的方法。大一些的公司在上线新代码时一般会先部署一些测试服务器，将一部分正常的用户请求定向到测试服务器上，以供开发者测试，这些测试服上开发者是可以随便修改程序的。

* 动态语言虽然被人吐槽，但其实只要规范使用，约定大家都不允许“炫技巧”，不允许使用太fancy的用法，违者罚工资就好了。在比较严格规范下其实不容易出问题。比如mozilla尝试做js的子集，其实就是用技术约束来替代罚工资的做法。许多使用C++的公司会做许多限制，例如不允许使用异常等等，这种约束看上去不人性化，但很有效。

​* 这个tread里面讨论过开发效率​，讨论过调试效率，但还从没谈过维护成本。我觉得在web应用开发中，开发效率第一、维护成本第二、调试是最末的。因为调试是临时的事，开发和维护是永久的事。开发效率决定了应用能否快速的占领市场，而维护成本则决定着团队能否长期存活下去。你用C/C++开发，请问以后如何维护？现在优秀的C/C++程序员已经非常少了，你准备自己一辈子维护这个程序么？程序员的职位（升官、跳槽、换项目）变动是非常频繁的，总有一天你无法继续维护你当初开发的项目，需要其他人接手。你现在招人可以找到一大把精通js的人，但几乎招不到熟练使用C/C++的人。这是一个很严肃的问题。

目前小团队的创业项目，我感觉只有web 端 有前景了， mobile 平台 创业其实不好做，好多团队都在亏。

之前 好些朋友 也找我做web ， 可惜我不会啊。

如果能闲暇时光 搞点外快 还是不错的，  死工资 拿的真没意思。

这一块我不熟，但我感觉区别还不在web/mobile这种端上，而在于内容。现在做游戏的都很赚钱，无论web还是mobile。做应用的，相信你盈利的多少最直接相关的是你的内容、你的玩法，而不是你用什么端。当然，web端比native端有一些先天性的优势，比如更容易推广，更容易更新。​

搞外快这种事，我觉得跟你会不会后端关系不大，会不会前端才是硬道理。你不会用ps，不会设计，后端做的再牛，谁找你啊？后端的技术都是死的，一学就会了，前端的东西更多的是设计，这东西不是学一下就会的（当然其实一般吊丝网站外包的设计也都很挫，都是很死板的照着教材上的几个例子改改的，都长一个样）。

--

Cheng,

Best Regards