Web应用开发工具及语言需要具备的功能探索

1 前言

最近一个多月在做Web项目，用到的技术有(也不算泄漏公司机密吧)：

后台：Struts 2(with JSP/FreeMarker)、Spring、Hibernate、MySQL、Web Service(only dubbo interface)；

前台：jQuery series；

Web服务器：tomcat。

虽然比较厌恶被别人称为做Java Web的，但没有做过的事情还是有挑战性的，一周内几乎天天加班足可以我的态度。

好像有成就感的计算机硕士应该觉得这些活儿是些"平凡"的凑工分的活儿，"纯"技术活儿怎么的也得是云计算、并行/分布式计算、数据分析/大数据等等高大上的。

为什么又是partial？

原计划是准备第一遍看完Python Django再回过头来写的，但是现在有更重要的事情，而作为结构化拖延症患者，自然就选择了这个不是很费脑细胞和时间的活儿，看能不能写完。

废话流太多了，该入正题了！

2  HTTP

每个Web开发者都应该感谢Fielding等人关于HTTP的工作，喜欢看飞机结构、功能说明书的学究可以去看RFC，想零基础起步学习开飞机的可以看[1]。

简单的Web应用中用的最多的MIME类型是text/html、application/json，暂时还用不到REST。

HTTP 2的一些新特性，在处理TCP连接、客户端和服务端交互方式等有了质量属性(*ities)方面的支持。这既是机遇，也是挑战。

3 Web应用开发工具需要具备的功能

想跳出Java Web这个小框框，但发现对其他的开发工具没有足够的发言权，还是主要是Java Web开发工具吧。

IDE/编辑器是必需的！有语法高亮错误提示、自动补全？多多益善。

一个足够轻量而有不是太轻量的Web服务器，tomcat够了吧？不！没有热部署功能，改个Action或DAO接口Java类实现，都得重启一遍，想想人家PHP，多开心啊（LAMP不予评价），好像我们也有JSP啊，把业务/数据访问逻辑堆到JSP页面上是石器时代过来的吧。我目前没有看到很好的解决办法，只是尽量让启动的速度稍微快一点，保证等待的时间不超过一根烟的时间。

Web服务器支持静态资源是必须的，动态内容呢？每次重新生成？这应该是开发语言实现本身需要考虑的事情。Web服务器应该提供足够多的配置项，虚拟根路径、应用模块页面路径切分什么的，但也不要太多，毕竟它的职责只是收发HTTP请求/响应，过多的话就越权了啊。

4 Web应用开发语言需要具备的功能

好像应该是语言族，产品经理大多会把Web浏览器当前Web"富"客户端。

还是动态内容！

数据从哪儿来？数据库，甭管内存/进程、集中式/分布式、开源/商业的数据库，该开发语言的Bridge/Connector/Adapter模块/库总得有一套。

根据什么条件生成动态内容？应用逻辑一般很好实现，开发语言应该很方便的接收前台传过来的参数，不就是GET/POST嘛，稍微成熟稳定的框架足可以保证程序员手头很干净，至于multipart传个文件/视频，车到山前自有路嘛。话外，切分请求URL对应应用逻辑处理在当前项目中有使用，玩的真嗨，由衷的击节赞叹。

如果是恶意请求怎么办？诸如DoS攻击就不是语言本身能够解决的事情了，加些过滤器/拦截器切面基本上可以解决权限判断、SQL注入攻击了。

动态内容响应怎么生成？最“省力”的方法是对每个请求在线生成唯一的响应，够快、但不便于应付产品经理鬼魅似的变更。模板！又引入了个DSL语言，这年头不懂个几门编程语言都不好意思叫自己程序员，为了应对随时到来的polyglot language时代，多会门手艺多条出路嘛。模板语言又该有些什么功能？命令式的条件判断、循环是必须的，便利的数据格式转换等也是多多益善的。

数据流是怎么处理的？在哪里接收请求参数？业务处理前端还是响应页面上，不考虑性能的话随便。又怎么把响应数据堆到或传给响应页面上呢？推/拉随便啦。

至于富页面，糟糕的JavaScript规范、军阀混战式的浏览器实现，有人认为这是机遇，我认为是遭遇。还好项目组里用的是jQuery(core, UI, Widget)、有专业的前端工程师，他每次用CSS都让我一愣一愣的，还是让专业的人做专业的事情吧。至于ajax请求，每次面对产品经理不合理的页面逻辑，我很乐得用。

5 高级特性

这部分内容不是工具和语言本身能够处理的问题，需要融合包括业务逻辑、实施方案、用户行为等作出决策，没有提供解决方法。

我十分愿意相信业务主管总是唱着这首歌在指派任务的：Harder Better Faster Stronger.

性能调优

这是一个综合性的问题，尽管已有大量成功的实践经验被共享，但仍属于百家争鸣、深受应用架构师/开发者经验和taste影响的问题。

业务流整合，页面端、服务器端的优化，一起为了快速响应的用户体验。

优化思路包括从网络模型堆栈挖掘(长连接等)、页面端优化(CDN、压缩等)、服务端(业务流程梳理、数据拆分存储等)。

缓存

响应越来越慢了！慢的令人发齿啊！

局部性原理用的好，你好，我也好。

再听听缓存的声音：凭什么大家活得时间一样长啊，我明显比你用的多啊；为什么只能存这么多，还有大部分屁股露在外面呢？

rps/tps

程序员的那句“这个功能实现不了”被列为跟“您的菜马上好”、“钱我先帮你存着”、“往里走，里边还有空位”等一样的真实的谎言时，我很震惊。

需求很简单：页面从这里跳到这里、这里要显示这些，再跳到这里、要显示这些。你知道浏览器跟Web服务器交互了几次、Web服务器又跟数据库交互了多少次啊，把这个很炫的功能拿掉我能少写很多代码啊。

至于页面脚本放置位置等页面端优化可以参考成熟的团队总结出来的经验。

关键的还是得有个profile，数据足够说明你的怀疑是否正确。

用户行为跟踪、分析、个性化

恩，高级话题。还用不着扯上NoSQL，能保证每个页面被访问次数一样吗？哪些页面流会被用户经常的连续性访问？

还个性化，个性化什么？消息提醒啊？推啊拉啊！推荐内容？我的职位是什么来着。

参考资料

[1]Gourley D., Totty B., Sayer M. et al.HTTP权威指南[M]. 北京: 人民邮电出版社. 2012.