研发部中的其他三位同事,搞硬件的其中一位同事,姓钟,一般被大家称为小钟,其年龄与我相仿,长得有几分英俊,人有几分风趣和潇洒。搞硬件的另一位同事,单名一个良字,一般被立经理昵称为良子。良子比我小三岁,个子不算高,脸圆圆的,有点娃娃脸的感觉,虽然其心智很成熟,但从其脸上似乎看不出他经历过很多的事情。另一位做机箱结构设计的同事,姓林,部门里外的同事一致称其为林工。林工比我小两岁,个子也不算高,微胖,人有点直爽,说话声音很大,很能侃,人缘也似乎很好。良子和林工虽然都来自同一个省份安徽省,但两人在性情和行为方式上却有着很大的不同,在林工身上很容易就找到北方人的影子,但良子却似乎更偏向于南方人的内敛。
小钟是广东人,已在广州的远郊买房并结婚生子,而且他和宗一样,是有车一族,虽然都不是很贵的车,但毕竟已跻身有车人士的行列了。大概正因为小钟各方面都比较稳定了,没有了这个年龄阶段的各种压力,所以人就比较潇洒。
我将有关资料整理后,便真正开始做需要分析了。按照我自己的工作习惯,做需求分析的过程中,第一步要做的工作就是设计数据库,根据实际业务情况建立数据库的表。数据库是一个系统的根基,只有先把根基打好了,才能去做程序架构的搭建、网页的设计和制作、程序的编写等其他的工作(当然数据库的设计和程序架构的搭建可以同时进行)。
视频管理系统采用的数据库自然就是我所熟悉的SQL Server 2000,而不是MySQL。就在我准备设计数据库的时候,宗跟我说,我做需求分析,要先将数据库设计的情况等用DOC文档写下来。于是我跟他说,我想先在SQL Server 2000中将数据库建好后,再用DOC文档将有关情况写下来。但宗却说,不行,要先用DOC文档写下来。于是我再跟他说,因为我习惯了先在SQL Server 2000中建数据库,我建好数据库后再写也一样。但宗却大手一挥说,“现在就是要你这样做,先用DOC文档写下来!我们不会看你在SQL Server 2000中的设计,我们要的是文档!”
宗的语气很坚决,态度很强硬,毫无商量的余地,于是我便不好再跟他多说什么,只好有点勉强地一边点头一边说,“好好,那我就先写DOC文档!”
这些对话都是当着部门中各人的面进行的,虽然不算很激烈,但宗的语气并不友好,态度强硬,中间我的语气也提高了,所以整个对话过程已或多或少地隐含着矛盾。
在公司里,服从上司的命令是没错,但在不影响工作开展和实际结果的前提下,我觉得上司也应该尊重一下下属的工作方式和工作习惯。我之所以想先在SQL Server 2000中建数据库,是因为在SQL Server 2000中进行实际的建表操作可以做到所见即所得,如果先写DOC文档,难免会“纸上谈兵”,有时还是要借助SQL Server 2000来解决一些实际的问题,所以我才有这样的想法,这也是我在以往工作中所形成的习惯。但宗却没有给我一点这样的自由度,所以虽然表面上我服从了他的命令,但在心里我对他还是有些抗拒。我心中的芥蒂也由此埋下。
虽然心里不情愿,但我还是按照宗的要求,在做需求分析的时候先写DOC文档。这其实主要就是将在SQL Server 2000中要建的表在DOC文档中用表格的形式表示出来,包括表的列名(字段名)、数据类型、说明(字段说明)、备注等信息,实际上就等于是在DOC文档中“建表”,只不过以后还要照着这个信息在SQL Server 2000中再进行一次真正的建表操作。
虽然是在DOC文档中“建表”,但这其实就是在做需求分析,这也是真实建表的反映,所以其信息也必须准确,因此我还是不能有半点马虎,否则如果其信息不准确,到真正建表后,系统的根基就会有问题。因此这就是一项重要的工作。
经过对祝老师所讲解到的内容和他发给我的那个DOC文档以及我整理出来的资料进行分析,去繁取简,去伪存真,并经过多日的脑力激荡后,在DOC文档中“建表”的工作也渐渐完成。此时的我已不是当年的吴下阿蒙,凭着我在网站程序开发和数据库设计方面所积累起来的经验,我还是顺利地完成了这个很重要的需求分析的过程,将那些繁杂的需求用数据库的表初步地表现出来了。不但顺利地完成了,而且我自认为这个需求分析还做得相对准确,我能将那些繁杂的需求用程序的元素相对准确的表现出来。而表的命名、字段的命名等都按规范来做,自不在话下。
这项工作可以说是有别于以往的工作,虽然没开始前对我来说是一个挑战,但经过这个过程后,我却更能从总体上去分析和把握一个系统的最底层的结构,将繁杂的需求变成系统和程序开发所需要的元素。这对我来说却未必不是一件好事。
我认为一个系统,最初的数据库设计很重要(在这里特指表的设计),这无关乎后面的程序用什么语言去开发,也无关乎语言版本的新旧,数据库设计得好与不好,将成为一个系统是否能成为好系统的先决条件。任你用再牛的语言,用再新的语言版本,你的程序算法再牛,但如果你的数据库设计得不准确,不符合实际业务情况和实际业务逻辑,那么你开发出来的系统也只能是一个不合格的系统。而这一点此时我认为我做到了。
文档写好后,我便将其交给宗过目,征求其意见。宗看后提出,表的主键不能用uniqueidentifier数据类型(GUID,全局唯一标识符),就用属性为IDENTITY的int数据类型,以方便日后数据库可以由SQL Server 2000迁移到MySQL或其他类型的数据库。
我之所以用uniqueidentifier数据类型,是因为在邮购公司时,兑换系统数据库的表的主键都是用uniqueidentifier数据类型的,我从中借鉴过来。表的主键用uniqueidentifier数据类型的好处是不能猜到主键的值,这对于商用系统很有好处,可以防止猜主键值(即防止猜ID),当然还有其他好处;不好之处是uniqueidentifier数据类型在实际应用中处理起来会比较麻烦,而且占用存储空间相对大一些,可能影响到程序执行的效率。本来我是从商用和安全的角度去考虑的,但既然宗这么提出来了,我也不想搞得那么复杂,于是去繁从简,表的主健全改为用属性为IDENTITY的int数据类型,IDENTITY的种子值和增量值自然就均设为1了(初始值为1,并自增1)。
改完后再给宗看,宗说我还要将各表所代表的各部分主要功能用流程图的形式画出来。虽然表是设计出来了,但是对于系统的功能要怎么更好地呈现出来,我也不可能一下子就有一个清晰的概念,我认为这需要在正式编写程序的过程中逐步去完成构思,最重要的是,表设计出来了,系统的功能就可以按照这个最底层的结构去展开。我这样跟宗解释后,问他能不能不画这样的流程图,但他还是要我先将这样的流程图画出来。
也许从正规化开发的角度来看,宗的要求没错,但是你不能跟我说正规化,这只是小作坊的开发而已,没必要上升到正规化的高度,你让我都按正规化来,那正规化本身所用的时间,我可能已可以将系统开发出来了。更何况我在文档中“建”的表,都是用具有实际意义的英文表名和字段名,并配上中文说明和备注,表的外键和关联表的主键的字段名均相同,各表的关系已清清楚楚,只要是做这方面工作的人都能看得明白,无需再多作说明。
但是我不能跟宗说这些,我还是要画所谓的流程图。但是我实在不善于画这样的流程图,无法按宗所要求的画出来,所以只将模拟程序执行时各表可能访问到的先后顺序用方图的形式画出来,并将各个表的用途和作用用文字简要地描述出来。
宗看后说,这都不是他想要的样子,我说我只能做到这样了,他也只好说那就算了,就这样吧。我不明白,你为什么一定要我做这些形式上的东西呢?我最终能将系统开发出来不就行了吗?
但是后来我明白了宗为什么要我这样做,因为他一开始就想到我可能做不下去,所以他要我写这么多东西,好在我不做的时候,他可以将这些文档资料交给下一个接手的人,方便下一个人接手开发。虽然他们把我招了进来,但宗并没有从心里真正接受和认可我。难道你为了方便下一个人接手开发,就先让我做这么多形式上的东西吗?你考虑到了方便一个假想出来的人接手开发,但偏偏就不考虑先方便我这个已成为事实的同事开展工作。
实际上宗并没有具体看各表的设计,因为他并不想了解这些细节。于是在宗点头认可了的情况下,我再按之前与祝老师讨论时的约定,把这个清楚地记录了各表的设计的DOC文档发给祝老师确认。因为实际业务情况是祝老师提出来的,而且祝老师就是计算机专业硕士毕业的,我所做的需求分析准不准确,他应该最能提出意见。
最后祝老师给我的意见就是表的设计没有问题,就这样就可以了,以后有新的业务需求再补充或修改。
得到祝老师的确认后,我便开始真正在SQL Server 2000中创建数据库和建表了。在这里,我还是参考了在邮购公司时的做法,表、视图、存储过程、函数的命名均分别以“T”、“V”、“SP”、“F”打头。
数据库建好后,接着搭建程序架构。在VS2005中先创建VS解决方案,再在其中创建各程序项目和有关的类库项目后,视频管理系统的程序架构就算搭建起来了。根据祝老师提出的实际业务情况,视频管理系统分为管理员、教师、学生等三个不同的后台,考虑到三个后台的独立性和安全性,以及参考在邮购公司时兑换系统的做法,我将三个台后分别作为三个独立的网站项目来建立了。当然将三个后台放在同一个网站项目下也是可以的,但是如果日后系统使用方要求管理员后台或教师后台不能对外公开,那到时再分拆开来就很麻烦了,所以我何不在一开始就将三者分别独立开来?如果要将三者都对外公开,那也很简单,只要到时在IIS(Internet信息服务)上多建两个虚拟目录就搞定了。此外文件传输程序则作为一个WinForm程序项目来建立。
准备就绪后,我也可以正式开始网页设计制作和程序开发的工作了。公司并没有招专职的美工来做网页设计,所以这些工作都要由我来包办。
宗让我参考的那套网站程序,其页面效果我觉得设计得还不错,于是我直接将其搬过来,并经过我的美化后,作为视频管理系统的网页界面模板。由于管理员后台的内容是最多的,也处于比较关键的位置,所以我便先着手开发管理员后台的程序。于是我按照网页界面模板先搭建好管理员后台的页面框架。程序架构搭建好了,管理员后台的页面框架也搭建好了,数据库就更加设计好了,编码的工作就可以按部就班地进行。当然编码的过程中还需要同步进行页面的设计和制作,因为在开始一个新页面的编码工作时,就要先做好这个页面。
完成了最初的也是最关键的系统的构建后,后面的工作做起来就轻松多了。于是我也开始了上班时间内不停地敲代码并不时设计和制作网页的日子。从这个过程中,也可以看到,我是可以从零开始、完全由我一个人去设计一个相对复杂的系统的。
就在我真正开始编码还没多久的时候,一天宗告诉我,祝老师将再到公司来了解系统开发的情况,让我做一些单独的静态网页将教室的预约、预约的审批、成生相应的教学单元、上传相关课件等功能和流程表现出来,以在祝老师到来时演示给祝老师看。
事实上这样的演示网页对我的开发并没有任何有意义的帮助,而只会让我多做一些无谓的工作,而且那些功能和流程我也是需要在开发的过程中一步一步去构思和具体化的,所以我心里很不想去做这些无谓的工作,并因此而改变我的工作思路。但是表面上和事实上我还是要按宗的要求去做。
于是我先放下手上的编码工作,费了一番功夫,特地将演示网页做出来,并在祝老师到来后,在宗和敖总的参与下,在那个小会议室里给祝老师演示和讲解了一番。祝老师看后表示可以照演示效果的那样来做,并提出了一些意见,其中他特别提到希望视频的展示页面和展示效果可以按照目前几大主流视频网站的展示页面和展示效果来做。虽然从表面上看这是一个小小的意见,但实际上真正做起来却很考验功夫。但是在这个时候我也不能当面就说我做不了。
为什么祝老师这么乐意和积极为我们讲解这么多东西和提出这么多意见呢?是因为祝老师在发扬教师乐于教人的精神吗?当然不是!真正的原因是华师正需要这样的一套系统,而祝老师又是负责相关工作的,祝老师给我们讲解实际业务情况,而我们开发系统,然后系统免费提供给华师试用和使用,华师可以以最低的成本得到系统,祝老师也可以因此而提升自己的资历,为自己带来好处,而我们公司则可以通过华师的使用实例造势,将这套系统继续卖给其他同样需要这样的系统的大学学校客户使用,华师与我们公司可谓双方受惠。所以往好的说就是互惠互利,往坏的说就是互相利用,当然华师始终还是处于相对强势位置的一方。当然一个祝老师并不敢擅自做这些私下里的事情,他的行动肯定是得到了上面领导的点头的,这当中自然也是因为敖总与华师的渊源很深的关系。
所以在这当中,祝老师还是有一定分量的,也正因为如此,祝老师在和我们讨论问题时,或多或少地流露出一种优越感,有种俯视着和我们──或者说是我──说话的感觉,而敖总也总是对其客客气气的。所以在整个关系中,处于最低位置的人就是我,我完全要看敖总、宗和祝老师的意思行事,虽然整个系统都要由我去开发,但看上去我更多的只是一个施工者的角色,没有话语权。虽然我不想这样认为,但事实上我就是一个只负责做好这套系统的棋子和工具。
由于演示的结果还算满意,宗也没再有异议。但是事实上后来系统成型后,实际的功能效果和操作流程跟演示的还是有很大的不同,所以做这些演示网页对我来说实际上是毫无意义的。但是这些“上面的人”就是喜欢这样,总是想要提前看还未开发出来的东西。如果真要了解系统开发的情况,直接看我开发到什么程度不就可以了吗?
就在我继续开始写代码的时候,一天宗又跟我说,再将之前做的演示网页重新做一下,做得更全面和更美观一些,因为敖总说要给客户演示。
又是演示,程序还没怎么写就不停地演示,究意是要我来开发系统的,还是要我来做演示网页的?系统还没开发出来,你演示再多又有什么用呢?如果你一定要先看整个系统的功能效果和操作流程,那么干脆你不要让我写程序,而让我先将全部网页设计出来好了。
于是我又费了更大的一番功夫,几乎将管理员后台可能出现的页面都用静态网页的形式做了出来,但是宗看后还是不满意,觉得操作流程不应该是这样,于是我便跟他解释了一番,最后他也只好说,那就这样吧。
最后宗还跟我说,他这个人性格比较直,说话有点急,不懂得赞美和表扬别人,如果之前他说话的语气重了,希望我不要放在心上。我一听还是觉得很意外,没想到宗还会这样跟我说,这等于是他在为之前那次写DOC文档的事情间接向我道歉了。既然他这么说了,我自然也附和着他说,大家都是为了工作,对事不对人,我不会放在心上的。但是我放不放在心上并不是关键,关键的是他是不是对所有人都这样,还是只对我这样。
这些演示网页,实际上也只是为了所谓的演示而做的,因为是临时做的静态网页,当中的很多HTML元素并不能用于真正的动态网页中,尤其不能用于ASP.NET程序网页中,所以等于是我又做了很多无用功。
早在面试之初,立经理就告诉过我,公司想要做的系统是录播系统的配套系统,即此时的视频管理系统是录播系统的配套系统。也就是说,视频管理系统不是公司的主要产品,录播系统才是公司的主要产品,这也就决定了视频管理系统还未“出生”就是“二奶仔”(二奶生的儿子)的身份,说不上不重要,但又说不上有多重要。虽然对我来说,是完全由我一个人开始了一个新项目的开发,但对部门中其他同事来说,我所做的系统又似乎可以被忽略,因为我所做的只是一套配套系统,一个附属产品,跟部门中其他同事完全没有关系,他们根本无需关心。所以这也就相应地决定了我的位置很尴尬,似乎从一进入公司就注定了我是一个可有可无的角色,部门中其他同事才是“大奶仔”名下的重要角色。
所以到此时,进入公司虽然只有短短一个月左右的时间,但是我还是从表面的各种情况和背后的各种关系中感受到了我的无足轻重,我在公司只是一个毫不起眼的ASP.NET程序员,是一个卑微的角色。
- 前言
- 序
- (一)毕业后的徘徊
- (二)走上不归路
- (三)无数个熬夜的日子
- (四)喘过气来了
- (五)工作中,工作外
- (六)继续熬夜学习的日子
- (七)悄悄改变的人和事
- (八)床上等你
- (九)秋与冬
- (十)编译与反编译
- (十一)独过春节
- (十二)公司里的靓丽风景
- (十三)重组程序
- (十四)酒入愁肠
- (十五)首次接单
- (十六)告别
- (十七)短暂的混乱
- (十八)转移阵地
- (十九)新的天空下
- (二十)远景与画饼
- (二十一)加班,加班
- (二十二)代码民工
- (二十三)死在了今天的晚上
- (二十四)程序员与小姐
- (二十五)迷途中的抉择
- (二十六)再下决心
- (二十七)大项目
- (二十八)开展新工作
- (二十九)人来人往
- (三十)挑战能力极限
- (三十一)特殊任务
- (三十二)可怜的忧患意识
- (三十三)昙花一现
- (三十四)人事变动
- (三十五)欲去还留
- (三十六)无名的配角
- (三十七)黯然离去
- (三十八)仓促中的选择
- (三十九)痛苦的开始
- (四十)繁杂的需求
- (四十一)卑微的角色
- (四十二)内心的挣扎
- (四十三)绝缘空间
- (四十五)越发觉得自己像条狗
- (四十六)午夜浪叫与噩梦
- (四十七)躁动的空气
- (四十八)No money no talk
- (四十九)倾注心血而成的系统
- (五十)无限愧疚
- (五十一)太不给力的年终奖
- (五十二)同学情与差距
- (五十三)破局(上)
- (五十三)破局(中)
- (五十三)破局(下)
- (五十四)转折
- (五十五)另一种生存之道
- (五十六)步入正轨
- (五十七)迟来的爱恋
- (五十八)盼望已久的收获
- (五十九)凤凰涅磐
- (六十)大海作证
- (六十一)美丽的天际
- 后记