职业生涯回顾移动平台的衍变

这篇文章是微创的老一辈,随着微创成立而长大的一位程序员的自述。
揭示了许多我进入微创之前的不知道的所谓内幕。现在,我也离开了微创,淡淡地看这篇文章,淡淡地思考微创未练的地方,反省很多事情。


今天再来说一下那个“微创移动平台”吧。

前面的章节提到过,刚开始的时候,这个产品是有一个非常大的远景的,参与这个产品开发和设计的人也很多。团队至少有10个人,Albert是PM的头,而我则主管开发。

经过一段时间的开发,这个团队中的人慢慢的都被撤走,最后只留下了我和Albert。这是人员上的变动。

下面再来看看软件架构上的变动。

按照Patrick的要求,这个平台需要支持短消息和WIP访问的,并且各个层次之间传递信息都必须使用XML,平台和下面的逻辑层的交互需要通过WEB SERVICE来进行。刚开始我们的确是这么做的,可是后来却变了很多。

首先是WIP访问功能被去掉了。这是因为我们的功能设计太过于复杂,连使用短消息来访问都很困难,别说让用户去使用WIP了。当然了,写WIP代码也比较难。

其次,关于各个层次之间用XML传递数据的问题。那个时候XML出来没多久,很红,人人都想用它。不过我觉得,无论用什么技术,不管这个技术是多么的先进,我们总是需要分析一下实际情况的。我们这个所谓的平台,其实根本上就是一个小程序,主EXE文件调用几个DLL而已,所谓的层,其实它们的耦合性都很高。换句话说,这次层次之间传递的数据的结构是死的,没什么灵活性。改变结构就必须改变程序本身。那请问,为什么我们还需要使用XML?为此还必须付出组织XML、解析XML、分析XML TAG、解决XML中不能包含某些特殊符号等代价呢?为什么我们为了使用这种先进技术而不得不带来这么多问题?所以,在后面,当我完全一个人负责整个移动平台开发的时候,我就尽量去掉这些麻烦的XML,取代它的是传统的结构体。一下子程序简化了好多,也更加容易理解。当然,程序的运行速度也有一点提高。

最后是WEB SERVICE。也是当时新出来很火的一种技术。很高兴Patrick能要求我们在程序中去使用它,这样,我这个懒人总算学会了怎么写WEB SERVICE、怎么调用WEB SERVICE。不过,还是老问题,我们真的需要它吗?首先,我们的移动平台和业务逻辑是安装在一台机器上的,它们之间的调用,其实根本不需要用WEB SERVICE,直接调用就行了;其次,调用WEB SERVICE是很慢的,至少需要花1-2秒,而且如果服务器比较差的话,这种需要通过IIS的调用就会更慢,甚至可能超时。而我们的平台,其实对性能,也就是响应率,是有要求的。没什么用户能忍受发送一条短消息后,很久以后才有回复,或者根本就没有回复;最后,WEB SERVICE的调试也很麻烦,一不小心就超时了。所以,后来我干脆就把WEB SERVICE去掉了,改成直接调用。系统的性能当然又提高了很多。

本来移动平台只能支持读取EXCHANGE服务器上的邮件,后来为了支持更多的客户。Albert要求我开发增加对POP3协议的支持。于是我不得不痛苦的去研究POP3协议,写了两个类专门用来封装POP3协议。其中解析邮件内容和附件是最痛苦的。

从这个移动平台的逐步衍变的过程中,我觉得,开发任何软件,都最好在一个良好远景的下,从最简单的做起。先让一个核心功能或者模块做成功了,然后根据用户和市场的反馈,根据远景的设想,慢慢扩大功能。原先架构不理想的,那就重写或者重构。如果一开始就盲目追求大而全,反而抓不住重点。对技术的把握也是,不是说新技术、很炫的技术就是最好的,就一定要在我们的产品中使用;而是要根据自己软件的实际情况,采用最恰当的技术,要实事求是。绝大多数用户都是因为功能可以满足他们的需要,才购买和使用产品的,而不是说这个产品用到了哪些花哨的技术(另类的追“新”族除外)。

不过在当时的微创R&D,雷声大、雨点小的事情也不是一次两次了。


上一篇: 职业生涯回顾非典
下一篇: 职业生涯回顾毕业答辩会
文章来自: 清新绿茶
引用通告: 查看所有引用 | 我要引用此文章
Tags:
相关日志:
评论: 0 | 引用: 0 | 查看次数: 844
发表评论
昵 称:
密 码: 游客发言不需要密码.
邮 箱: 邮件地址支持Gravatar头像,邮箱地址不会公开.
网 址: 输入网址便于回访.
内 容:
验证码:
选 项:
虽然发表评论不用注册,但是为了保护您的发言权,建议您注册帐号.
字数限制 1000 字 | UBB代码 开启 | [img]标签 关闭