5月份工作总结

-----

安全，性能，行为驱动开发

安全

背景：
潘把在线聊天对任务交给我对时候，我挺开心的，毕竟自己没有做过类似的东西，而且里面有几个技术环节，都是能吸引我这种新手的。

自己先拿出两天时间，查找资料，了解了3
中在线聊天的架构方式，并且读到了一篇文章《可伸缩的高性能
Rails

应用程序开发和部署实践》，借鉴了里面对memcache
的应用及消息队列对机制。

剩下开发的时间只有不到4
天了，于是采用了最保守对方法，客户端拉对方式，在后来开发对日子里，挺开心的，每天跟大家报告下进度。第四天，我放到了测试网上，潘让外面的朋友帮忙测试了下。接着问题来了。

出现了对全部用户的弹屏！

发言框里的格式全乱了！

能够发图片！

这些虽然没有对数据库造成破坏，不过对用户造成了极大的麻烦。

都是我没有对html
标记语言进行过滤，对插入表情替换对正则写对不对造成的。

记得《
rails

高级编程》一书中，写到“如果在跳舞的猪和安全问题之间选择，用户无一例外会选择跳舞对猪。”针对
rails

对一些安全导读见http://guides.rubyonrails.org/security.html

。很多时候，安全问题是我们容易忽略的，对
web

安全知识对掌握也是目前我所欠缺的。目前我觉得有下面的方法：

1

、高手指导和自我学习。

既然公司提倡构建学习型团队，我觉得目前大家大部分时间都是在忙这赶进度，改
bug

，忽略了总结，忽略了交流，这样会导致该沉淀的没有沉淀，导致为了做事而做事了，忽略很多理论和思想的基础。有时间的话，可以让潘给我们大家讲讲一些关于安全的问题，一些在程序中需要注意对事情，或者请些其他部门的高手，比如曾工，他们应该还是很乐意帮忙的吧！同时自己多关注些
web

安全相关的资料，学习。

2

、养成习惯。

性能优化可以放到后面去优化，安全不应该被放到后面，应该是随着开发的同时考虑进去，比如，我一开始写的建筑招聘中的删除简历，直接把
/destory/13,

这样就可以删除
id=13

的简历了，然而并没有验证这个简历是否属于执行删除的人，换言之，任何人只要调用这个
url

都可以删除
13

的简历了。这样的后果就是，有个人突然无聊，来到这里，获取了
session

下对
token

，然后用
js

写一段
1...10000

的循环，访问这
url

，结果，所有的简历都没有了。其他用户要哭了。所以对于非
get

的行为，要多考虑一些，养成习惯，问下自己，这个行为属于谁，需要满足什么条件才能执行。

3

、不相信客户端。

其实这一条可以放到上面去的，因为这也是一种习惯。

性能

背景：
在把前面对那些问题解决了以后，领导提醒了我要抓紧做下压力测试，看下聊天的性能。

用了一个下午的时间，先自己学习了下jmeter
测试软件，大概了解了ab
测试对方法，对服务器发起了一个完成10000
次，1000
并发量的情况，结果服务器对内存只剩了24M
了，导致服务器几近崩溃了，在贾和潘的帮助下，发现是nginx
服务器下的passenger
模块为了相应这么多请求，开启了64
个进程，而每个进程都占近1.2%
以上的内存，却没有释放，导致内存使用率居高不下。模拟下真实的环境对当前的进行测试，假设有20000
人，对服务器进行访问，每隔5
秒访问一次，那么要在5
秒内完成20000
次请求n=20000,
我们设计并发量2000,
处理器大约每秒可以执行2900
次，需要7
秒中左右。看起来很不错了。不过似乎不能满足我的需求，而且这种情况下cpu
对利用率高达95%
以上。

性能优化，这同样是我没有系统接触过的东西，都是一些道听途说，或者浅尝辄止的应用。对着课本看了些，做到这里，我越发自己欠缺的东西太多了，从底层的语言，到上层的构架，从编程的技巧，到算法的优化。然而很多东西都不是一蹴而就的，需要循序渐进，按部就班的进行。对于性能改进，我是没有什么经验。也就是刚刚看的上面的一篇文章。不过对于聊天的改进，我有了自己的想法，还有另外的一种实现方式。想对ajax
拉的方式可以很好的减轻服务器的压力。

很多时候，优化即使对程序优化到bit
级别的，也不可能让冒泡比快速排序快。所以，针对性能优化，《rails
高级编程》告诉我们注意下面几点：

1
、算法改进优于代码优化。

我想我的在线聊天程序就是比较生动的例子，构架和算法，决定了你性能的数量级。优化应该自上而下的进行

2
、可维护性，优于性能。

还是那就话，代码首先是让人读的，然后是让机器执行的。为了优化，破坏代码的易读性是得不偿失的。

3
、只优化有问题的部分

2/8
原则在这里同样使用。20%
的代码，占了80%
的资源。只优化这些就可以了。

我会尽快实现另一种构架的在线聊天，把消息队列机制引入到我的rails
程序中。

下面说点有趣的事情，下面的这件事情说是反思，其实包含总结的成分。

行为驱动开发（
BDD

）

展会的第二个迭代我已经完成了，而且第二个迭代除了视频不是采用
BDD

开发的，其他的都是我尝试着用
BDD

开发的。

还是借用潘的一句话，“虽然比较程序比较简单，但这种思想还是比较新颖的。”更好的是，他在保证我的质量的同时，让我享受到了程序开发的乐趣。

传统的开发模式是由内到外的，是计划，设计，开发，测试。而
BDD

是由外到内的，测试提前，跟页面要东西，页面需要什么，我们就开发什么，而且先写测试用例，开发的目的就是确保测试用例全部跑通过。这样开发完的程序，你就可以交付了。

感谢丁尧对我提供的帮助，在行为测试驱动的思想下，我的程序成功避免了
AB

类
bug

，虽然可以会导致开发的速度有所下降，但是我觉得还是质量应该放在首位，毕竟开发出来的应该是一个精致的，而不是残疾的，尚且不论，熟悉了他的
DSL

以后，速度是不成问题的。

简单的说下我的开发过程。

1

、编写场景：（感谢栗波提醒我中文写场景）下面是我的一个测试秒杀后台的场景

#language:
zh-CN

功能:

实现秒杀得主的数据的导出

为了实现秒杀得主的数据的导出

我作为一个管理员

我希望能够实现对订单的搜索，导出

背景:

我已经拥有300
条的秒杀数据

假如我已经拥有了如下秒杀数据

场景:

我选择产品1
和手机号为‘13910435521’
的时候，显示对应对秒杀数据

假如我进入秒杀后台界面

当我将搜索条件置为产品2
，手机号为‘13910435521’

而且我设置公司名称为广联，用户名为tongbao

那么我将得到一条相应的数据

2
、下面是实现场景对应的测试代码

3
、接着编写程序，直至所有的测试代码全部通过。

4
、重构，再测试，完成，扔到一遍，交付测试人员。

总的来说，时间过得好快阿，2010
年又要半年过去了。时不我待阿!