程序员接私活经验

转载地址:http://hi.baidu.com/zengjl/blog/item/abc4f01118545f19b8127b29.html

题外话:To 程序人生版

人气依旧旺,内容已全非,皆为匆匆客,徒洒洋洋言。


正文:(一)项目确立

一年前,CSDN的外包频道,一家贸易公司寻求开发业务系统。我注意到这家公司和我正好在一个城市,索性就跟了一帖,写了点简要的个人开发情况,当然最重要的是附上了自己的手机号码(当时CSDN外包频道还不限制这个信息的)。第二天就接到那家公司总经理的电话,这让我多少有点意外,电话中,双方客套两句后,约定好周末面谈。

和以往面试一样,我带上个笔记本(上面有以往开发的项目演示版)按照约定好的时间,准时去洽谈。地点是在对方的办公室,一进会客室,给我第一感觉整齐、清新、优雅、绿色;窗外则是宁静的半岛和微澜的海浪,心情顿时感觉非常畅快。

电话中那位非常绅士的总经理,年纪大概45岁左右,我们的谈话直奔主题。我先简单介绍了一下自己的情况(工作和开发经历),用笔记本演示自己以前开发过的两个类似项目情况,他则不时地提几个关心的问题。然后,他简单地将自己公司的需求告诉我,并把现行的系统的主要功能演示给我看了看。

整个谈话过程中,我印象最深刻的是他最后时刻说的话:“我看了你以前开发的系统演示,认为你完全有能力开发我们的系统;我也不打算再寻找其他人来面试,因为我的时间不允许我这样做。你如果觉得刚才我们谈到需求内容和开发价格都合适,那么我们就此开始合作。”

我是个程序员,他是个商人,我们的合作就此开始。
正文:(二)需求确定1

有了第一次的面谈,我对这家公司的整体印象不错。说起来,我以前去过不少公司(自己工作过的公司或谈项目去过的公司),尤其是从事贸易的公司,还是第一次见到办公室这样让人感觉如此舒服的。

简单说一下我需要开发的系统,其实并不复杂,就是一个典型的贸易系统,主要功能是管理公司的产品、客户信息,然后给客户报价、生成合同、给厂家下生产单等等。当然,这每一个模块中都会有很多特定的需求,例如,产品的价格组成,当某些价格组成发生变化时,系统需要自动更新到所有可能产生影响的部分去。

(那位非常绅士的总经理,为了叙事方便,给他取个名字吧,就叫Gentleman吧)

Gentleman把他们现在使用的系统,发了一份给我,在我看来这个系统简直就是一个学生的实习作业。无论从系统的性能上,还是操作的界面上,逻辑的条理性上,都存在很多的问题。但就是这样的系统,Gentleman居然使用了近7年的时间,这让我感到很惊讶,甚至于难以理解。而Gentleman经常在需求的沟通过程中,提到他们原先的系统如何如何实现,我心中总是会非常不舒服,觉得拿这样原始而粗糙的系统来与即将开发的系统相提并论,我认为是对我的轻视或者说低估。

对了,需求中有个重要的部分,那就是数据同步。因为Gentleman长期定居在国外,每年只回国两次,每次大概一个半月,平时他都是通过IM和Email来管理他的公司。

正文:(三)需求确定2

我用2天时间,把他们原先的老系统的所有功能,都'学习'了一遍,在自己大脑中已经有了一个比较清晰的轮廓。其实行业软件,大家只要熟悉其业务流程,就会感觉非常简单。因为从程序实现上来看,主要工作就是数据库的表结构设计,以及相关前台界面的操作合理性。

Gentleman在他回CA国之前,约我再见一次面,并给我发来一份他自己整理的需求文档(20页左右)。因为我白天要正常上班,而他的返程机票已经订好,所以我们只能约定好晚上见面。这次,他约我的地点是一家五星级酒店的自助餐厅。用他的话说,他不知道该去哪合适,只知道这个地方吃饭还比较自在,他喜欢这的环境。这家自助餐厅给我留下的印象,就是用餐的外国人比中国人多,当然Gentleman给我的感觉也有点像个外国人,只是和我说话的时候还是用中文而已。

我们边吃边谈系统的需求,他把自己需求文件中描述的内容,再给我讲述一遍。而且讲得非常仔细,生怕我有不明白地方。其实他说的大部分内容,对于一个有8年开发经验的程序员来说,完全没必说得这么细致。当然,我也不打断他的思路,只是默默地听着,因为我不想让他以为我很狂妄。我看着他认真的神情,思想反倒有点走神,脑子里寻思这一个问题:我什么时候能像他这样工作和生活?

就系统的需求,我们聊了大概有3-4个小时,从自助餐厅到酒店大厅的会客区。Gentleman想把他所有能想到的想法和问题都告诉我,因为他明天就要飞回CA国,这半年内,再也没有这样好的沟通机会了,毕竟Email中的描述只能停留在字面上。

那夜,我回去后,脑子里并没想任何系统需求,只是一直在想:我什么时候能像他这样工作和生活?

正文:(四)系统整体设计1

需求大致上了解以后,我开始着手系统的整体设计工作。

首先,从应用角度上来看,这个系统是准备在一家30人左右的公司运行,而且Gentleman需要在自己的笔记本上安装一套系统,并与国内公司这边进行数据同步。另外,他们公司在每年的春秋广交会期间,都会带产品去参展,期间有5-6台笔记本需要使用系统,以便随时给客户报价。所以说,各个数据库之间的同步,是这个系统的一个非常重要内容。

其次,我开发系统有个习惯,即在完成系统功能的同时,比较注重界面的设计。这个习惯,也让我在这个系统上多花了30-40%的时间(Gentleman对于界面并未做任何要求)。但我认为是必要的,我们程序员在写程序的时候,都使用IDE工具,我个人的感觉,如果这个开发工具非常丑陋或看起来别扭,在开发系统的时候,是会非常不舒服的。同理,业务人员每天都是使用这套系统来工作,如果系统的界面非常差,操作起来很别扭,那工作简直就是遭罪。

还有,系统的整体框架。我没有采用以前开发过度系统框架,虽然这样能节省我很多时间。但我仔细考虑了一下,由于这个系统对于时间要求并不紧迫,而我也想积累更多的系统框架,所以最终决定在原框架的基础上做许多升级改良,以便更试用于这套系统。

(不少程序员开发系统,是一套框架多处使用。我认为如果时间不是很紧张的情况下,完全可以设计更好的方案。这样在接下一单项目的时候,就可以有更多更好的系统演示给客户看)


系统的功能就像人的五脏六腑,界面则是人的长相和外衣;长相虽然不影响身体健康,但绝对影响找对象,呵呵,所以说,界面是个不大不小的问题。

正文:(五)系统整体设计2

Gentleman回CA国后的一个月内,他仍然每周都给我发过来最新的系统需求,其中有专题性质的(例如:某处的价格算法,以及价格调整的系列影响),也有系统整体性的需求调整。我则有条不紊地地分析着每份需求文件,从这些需求文件中,我能感觉到Gentleman对这个系统的期望值很高,因为他不仅是在提需求,甚至是在做程序设计工作,哪些部分需要加按钮,这些按钮完成什么功能,具体某个字段是下拉列表显示,还是弹出窗口等等。

在此期间,我并未急于做实质性的业务程序开发工作。我从Gentleman的众多需求文件,逐步整理和设计出系统的几个核心表结构,在这几个核心表结构还没有相对稳定之前,我是不会写一行业务程序代码的,这是原则。当然,我的程序框架的改进工作是一直在同步进行的,因为程序框架部分和业务程序部分几乎是平行的,只需要在框架中考虑到几处重要的StatusBar和ProgressBar,以及系统的整体显示风格即可。

(即便如此,在后续的开发过程中,还是出现了需要调整核心表结构的情况,当然这是后话,暂且不提)

随着核心表结构的设计过程,我的脑海中正在一步步地形成整套系统的数据脉络(主业务数据流和辅助数据流)。与此同时,Gentleman经常在发送新需求文件的同时,询问系统的进度情况。而此时的系统进度只是在我脑海中,在一份数据库表结构文件中(我没去写非常详尽的设计资料,因为一个人的系统没必要把过多的时间放在文档上,文档工作是对于协同开发小组比较重要的),我无法让Gentleman感知进度的情况。我只是告诉他正在做系统的设计工作,我也没发送改进好的程序框架给他看,我认为把一个半成品给对方看,还不如不给对方看。

Gentleman很理解我的工作,虽然我的当前的工作汇报只是停留在口头上。噢,又忘交代了,Gentleman在成为商人以前是学计算机专业的,不过,我至今还不知道他是否当过程序员。

中间插一讨论篇《程序风格》,本篇与这个项目开发有些关系,但并不纳入到正文中。
欢迎各位程序开发高手积极讨论一下。

讨论篇1:程序风格

程序是什么?不同的角度有不同的看法,比较经典的论断是 程序=数据+算法。数据是一套系统的核心,他的地位是不可动摇的,好比人民的温饱问题。算法是什么,算法是系统的引擎,算法的好坏优劣决定了程序执行的效率。但随着现在硬件技术的提高,很多程序员已经淡化了算法的重要性,以完成功能为标准,这是可悲的事情。

依我的看法,程序不光是数据+算法,那只是程序的行体部分;程序还需要有风格,这才是程序的神态部分。只有形神兼备的程序,才是一个优秀的程序。程序风格又包涵哪些内容呢?在解释这个问题之前,我们先设想一下,如果一个闭月羞花的美女,出口就是脏字;如果一篇行文洒脱的文章,字确写得东倒西歪;如果一座雄伟的山峰,上面确寸草不生。那样是不是很煞风景?

程序风格是什么?程序风格就是一个程序中,在数据内容以外所体现出来的内涵,它表现在程序的各个方面。从使用者的角度:主要体现在程序的整体显示风格(颜色基调、图标风格、字体大小)和交互风格(数据组合方式、功能区划分、操作流程);从程序开发者的角度,它包括项目的管理、源文件的组织、代码的风格、注释的写法。

对于一个人的项目,程序的风格就取决于你的个人风格。程序员在锻炼开发技术水平的同时,应该同时培养你的程序风格。

恭候拍砖!
正文:(六)Coding 1

程序的风格和核心数据库表基本确定后,我开始了系统的模块设计和编码工作。我的基本思路是,按照程序模块的重要性,逐个模块实现。单个模块的设计和编码同时进行的,完成好一个模块,就发送给Gentleman审核,以模块程序为交流载体,方便双方沟通。

夜晚22:00后,静夜孤灯下,一杯水,一个人。时而低头沉思,时而握笔绘图,时而指走键盘,这就是我平时工作的画面。一行行代码,一个个画面就这样跃然屏幕上。

系统中最先做到是产品管理模块,大家可能会认为这样的模块应该是比较简单的。是的,如果只是实现新建、编辑、删除功能的话,肯定很简单,但我确故意要将简单的东西复杂化。厨师的水平高低,不在菜上,而在于做菜的功夫上。

我在实现产品管理模块时,考虑到很多问题。如何将主货号和详细货号关联?主货号中的哪些字段应该与详细货号中的相同,两者之间应该怎么显示和编辑最合理?程序实现的过程中,哪些模块可以共用,哪些字段需要冗余?编辑某个货号的时候,应该怎么显示其他货号的详细内容作为参考?怎么让业务员输入最少的信息即可完成操作?

上面这些问题,有Gentleman提到的,更有Gentleman没提到的。我认为系统的开发过程,就像一段外语的翻译过程,有人是直译,有人是意译,孰高孰低,明眼人一看就知道。至于其中多付出的劳动,虽然只有自己知道,但同样可以体现在你的劳动成果中。

在我的观念中,开发系统不仅仅是为了开发而开发,应该再提升一个高度,至少要让自己满意。后来证实我的思路是正确的,Gentleman对于我的程序实现方式,很满意,或者说赞赏。以至于他总是说我聪明,能准确地理解他的意图,并恰当地实现出来。具体体现在他的需求文档中,以往那些琐碎的、近似设计的描述少了,他只提他想要的结果,具体实现他已经不用操心了 - 这正是我的目的。

我和Gentleman的关系,开始有点像Partner了。

正文:(六)Coding 2

自从编码开始后,项目开发工作似乎进入了正轨。

这套系统的编码过程中,有一个十分麻烦的地方,那就是货号价格的变化,需要更新多非常多的地方。这些都是Gentleman在常年的工作中总结出来的,他心中非常清楚。他只要一看这些价格数字,就能知道哪些是正确更新后的,哪些是未更新的。可我在短时间内确是很难做到的这一点的,因此,我单独写了一份价格更新对照表,虽说整理着份文件花了不少时间,但磨刀不误砍柴功,这份文件在后续的工作中发挥了重要的作用。

因此,我认为在开发过程中,对于那些容易混淆或需要非常仔细的地方(例如:本系统中的各种价格组成、公式、更新对照等),应该单独写份文档作为项目参考资料(这份文档一定要准确无误),即便是一个人开发系统,也有必要。就像Windows API参考文档一样,当程序需要调用具体API函数的时候,只要查一下参考文档就可以了,完全没必要去记住那些具体参数,因为短时间内去记住那些参数,是不现实的。随着开发的过程,对于那些经常调用的部分,自然就熟悉了。

编码的过程,是对设计的逐步修正的过程。设计时理解不准确的部分,在Coding的过程中,都会逐一发现。

很多人羡慕一个人开发系统,其实一个人开发系统的优势和劣势同样明显。优势在于整个开发中,省却了所有的开发沟通时间,因为整个系统(哪怕是非常细小的环节)都了然于胸;劣势就是孤单,遇到任何技术问题都必须自己一个人去解决,解决问题后的快感也没人分享。

这个劣势在后续的开发中,给项目带来了一点问题。

正文:(六)Coding 3

编码的工作是辛苦的,远没有程序设计时的天马行空,需要的是严谨的工作态度、良好的编码习惯和相对完整的开发时间。对于Part-Time开发者来说,很多人觉得非常辛苦,主要是因为没有完整的开发时间。

项目的开始阶段,一般开发者都能保持相对高的开发热情,但一旦进入编码的中期,这种热情支撑下的开发进度就开始疲态尽显。我也是遇到了同样的问题,项目进行了3-4个月左右的时候,开发进度明显比预期的低了很多,就连大洋彼岸的Gentleman也能明显感觉得到。

Gentlman开始有些着急了,经常在Email中询问开发进度(其实就是催促开发进度),并主动提出快速开发奖励。我非常清楚Gentleman的心思,首先,他是想在下一次的广交会之前使用上这套新的系统,以便提高工作效率;其次,他是认为我当前的系统开发质量比他原先预期的要好,所以很乐意提高开发费用。面对相对优厚的额外奖励(这是Gentleman高明的地方),我也很想提高效率,但由于种种原因我很难进入快速开发状态。

多说两句当时的情况,权当为自己开脱吧。其一,项目进展到3-4个月左右的时候,我老婆正到预产期,我可爱的女儿来到了这个花花世界;其二,在去年轰轰烈烈的A股牛市中,我这新股民怀着快速发财的梦想,在5500点的高位杀入了大量的资金,结果亏损严重,致命的是这些资金有大部分不是自己的存款。这让我承受了巨大的精神压力,几次出现失眠的情况。仅此两点,大家就可想而知我当时的状态了。

心态上无法进入工作状态,时间上无法保证开发时间,一个人的战斗,孤立无援,我把项目带入到了最艰难的境地。
正文:(九)Coding 4

面对Gentleman的额外奖励,我深感惭愧,虽然内心很想加快开发进度,但当时的心思确又很难聚焦到项目开发上来。这样浑浑噩噩的状态大概延续了一个月左右,项目的开发进度比预期已经差了一大块。我几次想在Email中告诉Gentleman我的痛苦,但炒股导致的心理失衡问题,怎么能让他去承担后果。我问心有愧啊!

即便在如此情形下,程序的代码质量还是我把握的第一要素。要么不写,要写就一定要保证质量,我绝对不会做杀鸡取卵这样的事。盲目上线带来的一定是后续更大量的补救工作,同时也会影响客户的信心。这一点,应该也是Gentleman欣赏我的地方之一。

随着春季广交会时间的日益临近,Gentleman已经感觉到项目无法在此之前完成,但他表现得非常大度。不仅没有过多地责怪我,相反还继续鼓励我,额外奖励依然有效,只是要求我全力把程序开发好。Gentleman的做法,让我非常感动,我时常自己在问自己:如果我不能及时调整好心态,不能坚持把项目开发好,对得起Gentleman这样的好人吗?

我的名言:生命就是折腾与被折腾的过程。

这浑浑噩噩的一个多月,其实就是我个人心态的筑底过程,而这心态铸底成功的因素中,我清楚,有Gentleman一份功劳。伴随心态的调整成功,项目开发也重新步入正轨。当然Gentleman也从CA国飞回到本市,开始筹备公司的春季广交会的展览。

准确的说,此时此刻,系统的编码工作已经完成了80-90%

正文:(十)数据库选型

个人项目中,心理层面的问题需要自我调节,技术层面的问题同样只能独自解决,下面就写点技术问题。

在这套系统的数据库选型中,我是经过一番思考的。从我个人技术熟悉程度上来说,是对DB2和Sql Server比较熟悉。但对于30人规模的中小型公司,没必要选用过大的数据库,Oracle、DB2这类首先被PASS掉了,在Sql Server、MySql、Sybase ASA中,MySql中,到底应该选用哪个呢?

可能很多人认为Sql Server应该是首选,最初我也在重点考虑它。但是Sql Serverd数据库,部署起来有点麻烦,考虑到Gentleman是长期在国外生活,在系统开发的过程中,我时常需要对数据库的结构进行调整。因此,数据库一定要便于打包和部署。其次,考虑到数据同步问题,因为这个系统最终数据库的部署,是需要在公司本部放一个中心数据库,另外几台笔记本上各放一个远程数据库。而这些数据库之间,要能够非常方便的进行数据同步。此时Sybase的Mobilink同步技术就进入了我的视线。(在这个项目之前,我并未做过数据同步方面的工作)

综合上面两个主要问题,我最终选择了 Sybase Asa 数据库,这款数据库,非常方便部署。更新数据库的时候,只需要直接替换数据库文件和日志文件就可以。而且我从Mobilink的资料中了解到,它是基于偶连接的同步技术,专用于中心数据库与多个移动数据库的数据同步的解决方案。我心想:Mobilink技术简直就是为我们这种应用而设计的。

同为Sybase的产品,ASA数据库理应与Mobilink无缝衔接。

讨论篇2:技术与应用

很多在校的学生和入行的新人,总是最关心开发技术,而且最关注流行技术。就好像流行时装一样,看哪些语言或工具流行,就学哪样,有甚者把市场主流的应用开发语言都学了个遍。其实大家会发现一个问题,即便学习了所有的开发语言,仍然不可能就此成为开发高手,因为他们学到的只是外在功夫,而非内功。

关于技术的内功和外功问题,大家只需要在开发的过程中,稍微用心体会一下,就可以找到练内功的方法。写代码的时候是不是频繁 Ctrl+C 和 Ctrl+V ,而不去琢磨复制过来这段代码或算法的基本原理?函数中的参数设置,是否仅仅满足功能就可以,还是需要预留下某个扩展?哪些功能代码可以抽象成一个类来实现,而非在程序中到处Copy同样的代码?等等!

(书法作品中一笔一画即能体现深厚的功底,想成为行家,就应该在程序的每个地方有自己的心得)

同样的程序,从客户角度,他们关注的侧重点是完全不同的。依据我的开发经验,客户基本上不关注系统采用的技术架构,哪怕你说得天花乱坠,那最多只是谈价格的一点小资本而已。他们关注的是系统功能,能否设计出他们认为最快捷、最安全、最实用的系统。“落后”的技术,同样有广阔的生存空间。因为对于客户,适用的就是最好的。

一个人做项目的时候,请记住:技术不是越新越好,而是越适用于项目越好,越熟悉的技术越好。在技术上你站得越高,项目的成功率就越高。(想学习和锻炼新技术,最好请到其他的项目组中学习,因为一个人的项目,新技术意味着无数未知的问题)

恭候高手拍砖!

正文:(十一)项目中期收款

Gentleman回国后的这一个多月时间,几乎一直在忙于春季广交会的事情,很少和我联系。只是约定等他从广交会回来后,让我去他那领取部分项目款。

(在第一次面谈的时候,Gentleman就问过我项目收费方式的问题。现在一般公司的付款方式是361方式,即30%作为项目启动款,60%在项目验收后付款,10%的尾款最后在确认系统运行正常后付清。而我给Gentleman的答复是,项目开发前我不收任何款,等系统基本成型后(即客户可以认同开发质量和效果后)付60%的项目款,正式上线运行后,再付40%的项目款。

我之所以采取这样的收款方式,首先,我对自己的开发实力有信心,相信客户在见到系统后,会乐于付款;其次,我考虑对方是一家公司,而我是个人开发者,让对方提前把钱付给个人,这其中的风险明显大于付给一家公司。而我关心的是项目款的多少,并非付款时间。)

这次,我们见面的地点是Gentleman在本市的House,我按照约定好的时间准时到达。他的房子位于本市一段黄金海岸线上,从室内就能看到浩瀚的大海,总面积约有160平米,价值至少两百多万。屋子以浅色调为主,家具并不多,显得非常整洁。用Gentleman的话说,他常年定居在CA国,这房子基本是空着,只是回来的时候住这,所以陈设简单了些。

我们的话题,始终围绕着房子,而并没有说太多关于项目的事情。那天,我才了解到,Gentleman在做生意之前,也是工薪族,居住在一套30平左右的老房子中。后来公司逐步地发展壮大,他家的房子也随之换了三次,地段一次比一次好,面积一次比一次大,而他现在在CA国的家,是一栋独门独院的木房子。

从Gentleman家出来的时候,我已怀揣着刚收到的项目款,心中虽说有几分成功的喜悦,但同样有几分抹不去的惆怅。

正文:(十二)意译的烦恼

在整套系统开发的过程中,我一直采用‘意译’的模式,对Gentleman所提出的需求进行改进设计,但也有例外的情况。系统中有一个模块是给工厂下生产通知单,在这个模块的处理上,就出现了问题。

公司当前的做法是依据合同中的产品数量,给工厂下达生产。一份合同由多种货物组成,每种货物的订购数量和外销价是不同的。实际工作中都是将一种货物中所有的订购数量都制定一家工厂生产,当时,我从逻辑角度上分析,认为存在这种可能,即一种货物分交给两家以上的工厂生产。

所以我在设计中提出了改进模块的设计思路,并汇报给Gentleman,他当时的反应显得有些犹豫。因为现在的实际工作中是不存在这样的情况的,如果系统能实现到这种程度,肯定是更灵活,因此他就准许了我的设计思路。

这个模块的设计和实现过程中,由于要实现到同一种产品分配给多家工厂,并且订购数量要动态分配和回收。所以需要考虑到情况就复杂了很多,时间自然也多花了N倍。最终实现出来的效果是非常不错的,操作员可以清楚地看出每份合同下达的生产通知单,以及每种产品的生产数量。

但以上所认为到的程序最佳实现效果,都仅仅是我个人认为的状态。当把这个模块拿到具体业务员那测试操作的时候,问题就显现出来了。他们都反映麻烦,第一,从思路上和现状有点差别,感觉别扭;第二,在操作步骤上又多了一步操作,耽误时间。最后,Gentleman在考虑再三后,让我把这个改进模块功能去掉,依旧实现最原始的需求。

后来我总结此次教训,虽然模块的功能更灵活、更强大,但客户只需要他想要的,改进模块一定不能成为画蛇添足。

正文:(十三)测试之痛1

程序编码工作逐步接近尾声,接踵而来的就是功能测试、模块测试、集成测试、系统测试等。对于系统测试,开发人员大都不愿意去做的,因为这是一项既繁琐、又无成就感的工作。

一套没有经过严格测试的系统,就像一匹没有缰绳的野马,谁也不知道它发飙的时候,会跑到什么地方去。再繁琐的工作也要做,初步的功能测试和模块测试工作自然是由我自己来完成。可我发现个问题,我只要输入一些数据到系统中,开始做测试工作,就会自然地进入到一种自我欣赏系统的状态中,一圈数据测试下来,只能找到少量的程序错误。

Bug大体上可以分为两类,第一类是程序错误,例如:由于数据边际校验不强而引起系统异常死机,程序显示不正确等;第二类是算法错误,即程序中某些数据的计算方法不正确,或数据更新不完整。对于第一类错误,我还好测试些,毕竟出现问题后,一目了然。但对于第二种错误,我根本无法察觉,例如一套产品的最终价格是58,我很难直接判断出这个价格是正确计算结果,还是有问题。但对于有丰富经验的业务员来说,他们是很容易做到的,因为这些价格他们太熟悉了。

考虑到我在测试过程中很难发现第二类错误,所以就和Gentleman商量,看能否找人来协助我做这部分的测试工作。(当时我以为Gentleman的日子过得很潇洒,身在国外,遥控公司,自己则周游列国,好不自在。)而他也没含糊,一口就答应下来,我真是喜出望外。

其实我的想法仅仅是,让他找个心细的业务员来做系统的测试工作,但出乎意料的是,他居然亲自上阵,自己一个人来做测试工作。
正文:(十四)测试之痛2

Gentleman是一个办事认真仔细的人,他每次测试完一个模块后,都会详细地记录下错误的具体情况(效果、他估计的原因、在什么数据输入流程下出现错误等等),然后发一份错误报告给我。有时为了描述一个错误,需要要写上百字,并配以屏幕截图。我见过他在电脑上输汉字,基本上是二指禅的功夫,输入速度非常慢。所以我可以想象,他在做完测试后,敲上一篇上千字的错误报告需要多少时间。而且,后来我从Gentleman那也证实了自己的猜测,他花在写Email的时间,远多于测试时间。

虽然我多次建议Gentleman将测试工作交由下属去做,但他一直都没有同意。他说,系统的需求和设计过程,都是他全程参与的,换了谁都没有他这么清楚。其中有很多地方都是与原系统不相同的,如果换由其他人来做测试的话,是测试不出问题来的。他坚持测试到基本可用的状态,再交由其他人来做后续测试。

我真的为他这种认真的工作态度所感动,所以他每次发送新的错误报告后,我都会尽快把这个错误修改好。我们就这样合作,他一有空就测试程序,然后把错误报告发给我,我将修改好的程序发送给他,他最后再做一次错误修正后确认测试。为了我们的测试能基于相同数据,我们之间还经常交换数据库,固定以某段数据为测试基础。初略估计,这个测试阶段他的工作量应该是我的2-3倍,因为大部分的Bug,都很容易修改,只有少量几个需要调整较多的地方。

看着系统一天比一天强壮,这种感觉真的很美妙,就像练健美的人看着自己的肌肉越来越发达,喝酒的人感觉自己酒量越来越大一样,都是很享受到事情。

同时,Gentleman也基本上切换到新系统下工作了,只是用老系统来查以前的数据。因为有了新系统的比较后,他已经无法忍受老系统的低效率了。

正文:(十五)测试之痛3

系统经过Gentleman和我的多次测试和修改后,健壮性得到了显著的提高。在测试期间Gentleman想从CA国飞回来,专程为系统上线前做最后的实战测试。我是不赞同的他这么做的,当时正好赶上万众瞩目的北京奥运会,他的签证上也遇到了些麻烦,所以也就顺利成章地取消了这一临时计划。

虽然Gentleman自己没回来,但他专门安排了他的助理(本文中称呼为MissLee)来协助我做上线前的最后测试工作。我和Gentleman协商后,制定的计划是:测试数据库放在MissLee的电脑上(以后再配备专用的数据库服务器),首先在营销部的5台电脑上安装客户端程序。即本套系统先由营销部来做实战测试,因为他们的业务中使用到的模块最多,数据所走到流程也最全。当系统测试没有问题后,再全面推广到公司的所有机器上,这个过程预计2-4周。

系统安装到营销部后的那些天,他们马上就有很多信息反馈。依据Gentleman的要求,营销部所有的反馈意见都统一发到MissLee那儿,再转交给Gentleman本人。Gentleman和MissLee会对这些信息反馈进行分析,例如:哪些意见是非常正确的,系统的确需要在某处添加数据项、添加功能或数据导出。然后他们会整理好,发送Email给我。我越来越觉得Gentleman真是个Good Partner,他的事先安排,让我的工作井然有序,而不是面对嗡嗡作响的各种嘈杂意见,这应该是很多人值得学习的地方。

当然,这期间系统也有很多'莫名其妙'的错误,例如,他们在导出一份报表文件的时候,进度条总是停在30%处就不动了。而我在自己的电脑上,和Gentleman的电脑上都测试不出这样的问题(这些问题大多是因为,产品库中缺少了某些产品的图片啊,或金山词霸的自动取词功能引起系统中特效按钮显示不正确等等)。类似于这种情况的问题大概有五六次,我都是需要及时到现场测试,然后逐一排查原因,最终找到问题所在。

解决这些疑难杂症的话说起来很轻松,但在实际找寻错误的过程中,没有交流,只有自己一个人琢磨。都是在结合程序源代码的基础上,仔细排查错误,这个过程既曲折更痛苦,需要相当的开发经验。以至于后来Gentleman开玩笑,说我无所不能,在我这所有问题都不是问题。

经历了半个多月的系统测试后,营销部人员,也由最初的对系统很不放心,到享受系统带来的高效工作。

讨论篇3:项目之上的情感

在本文前面的若干节中,我已经多次提及Gentleman身上的特点,认真仔细,善待员工。原本我以为他平时的工作很轻松,可后来才知道,他每天工作都在十小时以上。国内与CA国有八个小时的时差,这边白天上班的时候(他那就是17:00-01:00),他基本上都挂在IM上,随时与公司这边保持着联系,而且还要处理大量的客户Email。

现在回想起测试阶段,我把大量的测试工作都交由他来做,真是于心不忍。系统安装到营销部的时候,MissLee和其他同事也都说Gentleman非常辛苦,希望系统能给他减少负荷。我当时心中就在想一个问题,当今社会,有几家公司的员工会这样为老板说话?大家为什么会这样向着老板说话?如果Gentleman身上没有特殊的品质,员工又是会怎么样?看到了这些,我就不难理解,为什么一家30人不到的贸易公司,每年的贸易量却能达到2000标箱以上。


今年一场金融危机几乎席卷了全球,我由于炒股的原因,所以非常关注全球各股市的走势。我能意识到这场危机对于出口型公司的冲击会有多大,所以在9月18日的时候,冒昧地给Gentleman发了一封与项目无关的Email。全文如下:

“您好!

不知您最近是否关心全球经济动向?现在能看到的情况已经非常糟糕。美国五大投资银行已经倒闭和被他人收购了三个(贝尔斯登、雷曼、美林),另外两个(高盛、摩根士丹利)也是关注的焦点,昨天高盛股价下滑23%,摩根士丹利股价大跌44%。

上周我和一个高中同学(他是耶鲁博士毕业,就职于美国雷曼兄弟公司纽约总部)MSN上聊天,他说美国遇到1929年以来最大的金融危机。上周末雷曼即宣布破产,美联储前主席格林斯潘在接受采访时也说,美国遭遇百年不遇的金融危机,经济回退很难避免。美股最近3天出现了2次4%以上的跌幅,这是美国911事件以来单日最大的跌幅。

我不清楚会对全球经济产生多大的振动,现在全球的股市(美洲、欧洲、亚洲)都是一片暴跌。波罗的海航运指数也从高点12000点,跌到现在不到6000点,这些都说明全球经济可能面临萎缩。我的一个朋友,是青岛一家4S店的总经理,他们最近2个月的汽车销售量为0,搞得他压力非常大。前天就是去他公司看套行业软件去了,和他聊了一下上面这些话题。他前期忙于生意,都不太清楚原来全球经济发生了这些事情,感觉他听后心情很沉重。您公司是做外贸,应该对这更敏感些,我也不了解这些变化会对咱们这个行业产生多大的影响,提前做有些准备总是有益的,希望我的担心是多余的。”

下面冒昧地将Gentleman的回信公布于此,希望他不会因此责怪我。

“谢谢你的关心!非常感谢,真的。我每天都在关注这些事情。一句话,冬天快要来了!
1929年美国发生了大萧条,称为GREAT DEPRESSION.最近2-3年内,极有可能会发生GREATER DEPRESSION.
格林斯潘说,美国遭遇百年不遇的金融危机,并没有夸张--虽然这是他一系列政策埋下的种子。
对于我们生意的影响有多大,现在还很难说。一种可能是:覆巢之下,焉有完卵?另一种是,沧海横流,方显出英雄本色。
(这话说的有点大了,我并没有把握。勉励自己而已。)谢谢!”

这封Email之后,我能明显感觉出我们的关系更亲近了,已经超出项目范畴了。一个人的成功不可能是偶然的,Gentleman身上有很多值得我学习的地方,在后续的Email中我直言,项目的收入对于我来说是次要的,能跟着成功男士学习优秀的品质对我来说更为宝贵。

正文:(十六)数据同步1

系统从一开始设计的时候,就有数据同步的需求,即公司局域网的电脑都访问中心服务器的数据库,而各台笔记本都访问本机上的分数据库,两者是完全同构的数据库。

由于在接这个项目之前,我没做过任何数据同步的项目。因此,一开始我还设想着自己写程序来实现数据同步功能,即设定时间点,然后通过程序导出每个数据库某段时间内的数据(新建、修改、删除),然后再将导出的数据进行比较,最终求出数据合集。可稍微考虑点详细的实现过程就觉得头大,情况太复杂了。如果要实现到应用的程度,可能单写数据同步程序所花费的精力,就远远超过了写业务程序,所以,最终放弃了这种不现实的想法。

(在校时,我的一位同学接了个进销存项目,可当时我们所掌握的技术主要集中在C++操作文件上,即所有的数据都是存储在二进制文件中。这老兄完成这个项目,楞是没有用数据库。所有的数据全用二进制文件来操作,读写删查都是自己写代码,没有用一句SQL。用他的话说,简直就是自己写了个数据库啊,累得快吐血,效果还很一般。)

同样的道理,如果我自己去写数据同步程序的话,我估计效果肯定和我那位同学当年一样。所以断然不能自己去写数据同步,即便我真有这能力写出来,那也不能这样做。因为如果业务发生变化或系统扩展,需要对数据库表进行调整(新增表或字段),那我的数据同步程序还要自己去重新完善,我想那一定是个场灾难。

数据对于任何公司来说,都是最宝贵的,所以我要选用成熟而安全的方式来实现数据同步。

正文:(十七)数据同步2

确定选用数据库同步工具来实现数据同步后,我就开始Google数据库同步工具,其中Sybase Mobilink进入了我的视线,它的主要功能介绍如下:

“MobiLink 同步允许在符合 ODBC 标准的统一数据库和 Adaptive Server Anywhere 或 UltraLite 远程数据库之间进行复制。在本教程中使用的是 Adaptive Server Anywhere 远程数据库。统一数据库能够是使用 Sybase Adaptive Server Anywhere、Sybase Adaptive Server Enterprise、Oracle、Microsoft SQL Server 或 IBM DB2 生成的数据库。

MobiLink 适用于将一个统一数据服务器和大量远程数据库进行同步(通常包含多个移动数据库)。远程站点的管理和资源需要已降到了最低限度。此系统是基于偶连接的,并且远程站点可随时进行连接。在每次进行连接之后,数据库是完全同步的。

MobiLink 的工作方式是:将远程数据库上的多个事务的结果合并成一个更改集,然后应用到统一数据库中。因为同步始终在事务边界进行的,所以保持了参照完整性。不保留在组件事务过程中所做的各个更改的顺序:因为从不复制未提交的数据,所以保留了数据完整性。”

乍看到这些介绍的时候,我简直是喜出望外,这些同步功能简直就是为本项目需求所设计的啊。

我赶忙连夜下载了一套 Sql Anywhere 9 开发版(其中包含Mobilink同步工具),依据一些文档资料,我开始测试起数据同步功能来。先新建好一个中心数据库和两个远程数据库,然后按照文档中提供的例子,启动同步服务器和同步客户端。没想到进行得异常顺利,远程数据库和中心数据库的数据很快就实现了同步,我有点找不到北了,心想原本以为麻烦的问题,原来就是层窗户纸啊!

可高兴劲还来得及过去,就发现一个问题,其他所有的同步都正常,就是删除操作的同步出来点问题。远程数据库中的删除可以正常同步到中心数据库上,但远程数据库之间却无法同步删除操作。具体情况的描述如下:

中心服务器取名CenterDB(Server),两个远程数据库分别取名RemoteDB1(Client1)和RemoteDB2(Client2),当你在RemoteDB1(Client1)中删除某条记录后,Clinet1执行同步语句后,能同步到CenterDB(Server)上,即CenterDB中也删除了这条记录。接着在Client2上执行同步语句后,却发现这条记录依然存在于RemoteDB2(Client2)中。

这是我在MobiLink使用过程中遇到的第一个麻烦。

正文:(十八)数据同步3

为了删除无法同步的问题,我到处Google解决方法,可网上几乎没有什么讨论MobiLink的文章,仅有的几篇都是介绍性的文章,逐渐地我开始有点毛爪了。可Gentleman在得知这个问题后,确表现得非常大度,他对我说,如果实在解决不了删除同步的问题,那系统在使用的过程中,就采取行政手段来同步。即需要数据删除的时候,大家就记录下来,然后互相发Email通知。

我很难想象在系统使用过程中,大家互相发Email通知删除的时候,会顺便暗自问候我这个程序开发者多少次。我没得选择,必须找出办法来。在翻了很多资料和搜索大量网页后,终于在Sybase网站上一个英文的帮助文件上,找到了这个问题的解决方法。

原来MobiLink在实现数据同步的过程中,中心数据库的删除就是无法同步到远程数据库上,而远程数据库的删除可以同步到中心数据库上。如果想实现这种删除的数据同步,有两种解决办法。第一种方法是建立影子表,即对每个表都新建一个影子表,某条记录删除的时候,都在其对应的影子表中记录下删除行的主键;第二种方法是逻辑删除,即在每个表中建一个删除标识字段。

考虑到实现的复杂度,我最终选用了逻辑删除的方法。但紧接着另一个问题又来了,此时的程序编码工作差不多完成了70%左右,现在把程序中所有的真实删除都改成逻辑删除,源代码中需要修改很多的地方。如何以最快最全的方法实现逻辑删除?我整整思索了半天,突然灵光一闪,想到了一个最佳方法。即从数据交互的父类中修改真实删除所调用的函数,把真实删除改的SQL语句改为逻辑删除所对应的SQL语句。这样只修改一处代码,即把系统中所有的真是删除都搞定。

我暗自夸奖自己:你怎么这么聪明啊!

正文:(十九)数据同步4

在解决了MobiLink数据同步的中心数据库与远程数据库的删除同步问题后,我又开始测试数据同步的速度问题。发现局域网内和Internet网上MobiLink的数据同步速度差不多,这让我很是高兴,可接着另外一个问题又开始困扰我了。

开始做数据同步测试的时候,由于数据库中的数据量很小,每次数据同步的时间大概在2-5分钟。而随着数据库中的数据逐步增加,发现同步所需的时间越来越长。MobiLink资料上,都说数据同步的原理是依据日志文件中的数据库操作语句,对数据进行增量同步,即第二次同步的数据是第一次同步后的数据修改。这就让我很不理解了,为什么随着数据库的增大,同步的速度越来越慢,而且从同步服务器的滚屏显示上,明显是在扫描第一次同步以前的数据。

Google了N多的地方,都没有发现有讨论这个问题的地方,我又得自己摸黑前进了。凭借以往的经验初步推断,有两种可能原因,第一种是数据库的日志出来问题,第二种是数据库的MobiLink同步设置出来问题。

首先从第一种可能性考虑,我把ASA数据库的日志删除掉,重新构建日志。希望全新的日志能给我解决这个问题,可发现同步速度依然是老牛拉车。重构的新日志不行,我又遍查方法,希望能有日志整理的方法,把原先的日志重新整理。光折腾日志就花了我一个多星期,头也大了两圈,最终自认为是进来死胡同。

然后又考虑Mobilink同步设置的问题,把《Mobilink同步用户指南》《Mobilink同步参考手册》都翻了个遍,还查几乎所有能找到的资料,也都没查出所以然来。光前面两本书加起来就一千五百来页,真是郁闷得够呛。此时的Gentleman又给了我鼓励,说现在也能将就着用,无非就是速度慢些而已。可我心中明白啊,系统正式上线后,数据库会迅速加大,如果每次同步都是全扫描,那真是慢得跟头驴一样。

经过半个多月的查找,就在我几乎快绝望的时候,一次随意翻查《MobiLink Developer Resource Kit》的时候,居然发现里面有一篇“Mobilink数据分区”,详细地记载了如何设置实现数据的增量同步。这真是踏遍铁鞋无觅处,得来全不费功夫啊。我都感动得想喊出来,按照里面的设置方法,对数据库进行了相应的调整后,一测试,OK, No Problem。

那天,我感受到久违了的胜利喜悦,似乎一下子把我拉回到了读书时代。

正文:(二十)最后一次大考1

经过多次的数据库同步测试,我自认为已经大体上掌握了MobiLink的数据同步方法;同时,系统程序经过营销部的实际测试也日趋完善。与Gentleman商量后,决定系统在秋季广交会前全公司范围内上线。

由于前面的系统测试工作做得非常充分,所以系统上线后并未遇到任何技术上的问题,仅是某些部门和个人提出了一些小的功能修改意见。至此系统算是基本上线成功,但还有最后一次大考,那就是秋季广交会。

Gentleman和他的同事们,非常重视广交会,他们会在此前做好最细致的准备,其中包括参展的样品、名片的准备、笔记本、业务系统、打印机的调试等等。给我感觉就像上前线打仗一样,这比喻一点都不夸张。Gentleman说他们在以往的广交会上就是神经一直紧绷,来了客户以后,需要迅速给客户报出各种产品(或依据客户的需求组合的产品)的价格。其中容不得半点差错,价格报高了,会让客户失去兴趣,价格报低了,则公司蒙受损失。所以广交会期间,只要客户一来询价,大家就处于紧张状态,需要反复核算价格。

当然Gentleman这次去参加广交会是准备好了两套方案的,他们分别在新老两套系统中都输入好了参加广交会的新货号,如果新系统在广交会期间出现问题,他们就马上切换到老系统下使用。(这些是我事后从其他员工那儿得知的)

此次广交会,Gentleman他们租用来两个展厅,所以带去的六台笔记本组成2个局域网,分别在两处使用。整个广交会参展期间(大约10天时间),新系统不负众望,运行高效稳定,报价准确迅速,极大地减轻了Gentleman他们的工作量和精神压力。看着大家回来时对系统满意的神情,我心中甚是开心,说明新系统完全达到了预期的目的。

可就在广交会回来后的数据库同步过程中,我又挨了一记‘闷棍’——其中一台笔记本上的数据库与中心服务器数据库的同步过程中,出现了只下载数据不上传数据的奇怪现象。

正文:(二十一)最后一次大考2

由于全球金融危机的原因,今年的秋季广交会市场比较清淡,珠江三角洲附近以出口为主的家具和玩具企业纷纷倒闭。但从Gentleman那了解到,今年他们公司的情况还算不错,虽然比春季广交会的成交量差一些,但已经比预期的状况好多了。加之此次广交会上,由于新系统非常好用,所以在现场感觉工作比较轻松,并未出现手忙脚乱的现象。在此次广交会临近结束的时候,他们还特意举行了一场小型的庆功宴会。

大家从广交会上回来后,纷纷说新系统非常好用。得知这些喜人的消息,我自然也是非常高兴,在他们回来的第二天,我就去Gentleman公司那,帮他们把笔记本上的数据同步到服务器上。我原本预计最多一两个小时就能搞定的事情,可没想到居然整整耗了近十个小时(16:00 - 02:00 晚饭也没吃)。

因为出现了一个奇怪的现象,即其中一台笔记本与中心数据库同步的时候,只能下载数据,却无法上传数据,这让我一头雾水。因为这台笔记本上的同步语句和其他的都是一样的,MobiLink中的确提供了单向同步的设置,可我并未加上这个参数啊。问题出在什么地方呢?

我仔细梳理着每一步环节,回想起来这台笔记本上的数据库与其他数据库不同在于,它的数据库是从另外一台笔记本上复制过来的。因为在广交会上,Gentleman是分两个展区的,而这第二个展区的开展时间比第一个展区晚两天,所以Gentleman当时在得到我的许可后,就把第一个展区用的数据库复制到了这台笔记本上。

而MobiLink数据同步的原理是,每个远程数据库都对应一个同步用户的,即每台笔记本都需要对应一个不同的同步用户。最初我认为MobiLink的数据同步过程,只要我不设置单向同步,即肯定是即上传又下载的。可那天经过我反复测试,发现对于一个新的同步用户,在初次与中心服务器做同步的时候,数据是只下载不上传的。

一开始,我以为是设置出来问题,可反复检查设置,并未查出问题。我再仔细琢磨MobiLink为什么这样处理?虽然我并未在任何MobiLink资料中印证我的猜测,但我最终认为这是MobiLink特意这样处理的。即对于一个全新同步用户,初次同步过程中,MobiLink的执行方法是只下载不上传的。其实这也很好理解,因在一个中心数据库和多个远程数据库发布的时候,只有默认这种方式才能最快完成同步,否则数据只有轮询同步两遍之后才能实现完全一致。在想明白了这一点后,我赶紧改变了方法,即采取手工SQL语句导出的方法,将那台无法上传数据的笔记本中的数据导出到文件中,然后再将这些文件数据导入到中心服务器内。

那晚,就这样琢磨后测试,测试后又琢磨,一直折腾到凌晨2点才把数据全部导入到中心服务器中。因为我清楚,如果不把数据整理好,Gentleman的公司明天就无法正常工作,所以一定要在那晚把数据整理好。

正文:(二十一)煮酒论英雄

那天为了将笔记本数据导入到中心服务器,我工作到凌晨两点,Gentleman为此深受感动。但我认为,一个值得我尊敬的合作伙伴,我就应该尽我全部的能量,将系统功能开发好,将数据同步完善好。

在这近一年的交往过程中,我深感Gentleman身上有太多值得学习的地方。所以每次Gentleman回国的时候,都是我抓紧学习的机会。为了有更好的交流时间,我迫不及待地在秋季广交会之前,就邀请Gentleman单独庆贺一翻。

Genteleman是个非常理性的人,在他的思想中,开发一套系统,无论投入多大精力和财力,只要系统能创造出更多的效益,那所有的投入都是非常值得的。而对于我来说,当前的新系统仅仅是第一步,只是简单地提升了业务的执行效率,并未给公司带来更多的利益。在我的头脑中,正在思索下一步的工作重点,如何能从繁琐的工作中解放出更多的人员?如何能让Gentleman站在全局的高度上,分析出公司的利润发展点和成本控制点?如何能有效地将营销部、海运操作部、财务部等各职能部门更有效得协同工作?我相信,心有多大,舞台就有多大。

借单独与Gentleman庆功的机会,我将自己成熟的与不成熟的想法都抛出来了。我们边饮酒边畅谈,对于新系统的下一步建设做了总体的规划,从这个规划中可见在Gentleman的心中,有更宏伟的蓝图,他希望建设的不仅仅是一个单纯的贸易公司,而是一个既有活力又有深度的集团性公司。


BEST PARTNER 全剧终




你可能感兴趣的:(others)