一 生活灿烂,望君多珍重
写下这篇牢骚小文之前,先简略描述一番在下目前的生存状态:上班时间:基本没事情做,在看各种自己感兴趣的技术,理论,写一些实践的代码,每天下午4点,必到楼下溜达15分钟,顺便喝杯咖啡;晚上,读书,写程序;周末,游玩,唱K,足球.
很开心的日子,对不?
美好和悲惨通常不分家.作为我们公司的软件程序员,我体会更深.更多的时候我在出差,那时候我不可能还在这个匆忙的城市度过自己的悠闲时光.我会深入祖国大后方,老老实实的蹲在某个小城市政府部门某栋小楼的某个办公室(有时候是机房),每天像销售/商务人员一样向官员了解他们需要的软件功能,然后快速开发部署以供他们使用,然后等待他们的诘责再要求,然后蹲回机房老老实实再改程序再部署再接受审判......循环周而复始.没有周末,没有闲暇,没有阳光,没有足球.
在一个备受对方刁难的项目实施过程中,我在某地过了四个月这样的日子.连续120天啊!
所以,在没有出差的日子(不出差也意味着我在公司会无所事事),我要尽情的享受生活!
二
这两年大家对spring的赞美之声一直不绝于耳,囿于工作性质和时间,我不能太深入的实践这个框架,去年只是买那本<j2ee development without ejb>来翻翻.Johnson 的论点确实深得我心,很多时候,用户其实不需要分布式,不需要更改数据库,不需要太过笨重的事务管理...(这些对用户来说都是透明的),他们关心的只是软件如何满足他们的需要,让他们能尽快的展开工作.为此,我们设计的系统就要开发周期短,易维护,灵活易增加功能,还要足够健壮......
什么?高灵活性,高可靠性,高健壮性?不是我们一直追求的目标么?你也许会这么反驳我.
问题是我们所鼓吹的跟我们所实际做的完全两样.在下早年曾对sun的pet store模型很感兴趣,把相关文献源码基本看了几遍.并以开发人员的身份实际参与了一个应用该模型进行开发的大型项目.该项目80-100人的规模,总历时5年.我在项目快要接近成功的时候离开了这个公司,回首这段开发经历,不胜其苦.应用这类模型进行开发,根本不可能做到所谓的高灵活性,易于维护性,易于提高生产力.每测试一个ejb就要等待15-20分钟启动ejb容器的滋味,你尝过吗?
这段时间写了一些spring的代码,很为spring的简略而惊奇.但spring就是银弹吗?在我正要在公司内部写一系列小文鼓吹spring之前,我这么问自己.我悲哀的回忆起,我的悲惨经历完全和技术无关.对,spring采用ioc,程序易于测试;spring包装了rmi,很方便的完成ejb的功能;spring提供了各著名持久框架的胶水,让ibatis,hibernate,jdo都能轻易集成到其中...
但是,我们原来的框架也不算太差啊?虽然由于前期规划不好,代码风格混乱不堪,水平参差不齐,但从架构组成,开发周期和运行性能而言,足以满足用户的实际需求了(系统的实际运行也证明了这点).那么,问题究竟在哪里?
三
我问自己.问题在于技术吗?也许是,销售和市场人员是这么抱怨的.但如果按照经典的软件工程过程来分析,是谁在获取需求?谁在编写需求说明书?回答:可能是销售人员和项目经理进行调研进而编写需求.谁在编写概要设计说明书?回答:没有,时间很紧,来不及写.谁在编写详细设计说明书?回答:没有...谁在写测试报告?回答:来不及写...谁负责部署,反馈信息?回答:具体到每个程序员......
别笑我.你也许认为,像我目前公司的这种情况,是很极端的例子,不可能公司不写任何文档,不进行任何测试的.好的,我告诉你,我们也有文档.我从公司服务器杂乱无章的文档中翻出了最初的需求文档,它的内容证明了它是不折不扣的垃圾.我也翻出了某一两个功能模块的文档(这还是我坚持要他们写的),内容和实际程序设计不止差了十万八千里.我找不到测试报告,也许这个系统真的没有测试.就这么拿出去部署应用了.程序员又怎能不辛苦?
一句老生常谈的话概括:管理问题.这是小公司屡见不鲜的毛病.
四
如果说这个例子过于极端,那么看看管理良好的公司所开发的项目?前文所述应用pet store进行开发的公司,是某大公司在本地的子公司(简称S).S的项目开发流程非常规范.专门的需求分析员,专门的系统设计师,专门的开发人员,专门的测试小组,测试人员,测试流程.....可以说一切资源人员配置都按照大软件工程的标准进行配置.结果呢?在开发那个80 * 5 * 12 人月的项目中,众人一样累得死去活来,晚上加班到12点是常有的事.
<人月神话>强调了一个问题:开发人员之间的交流成本非常昂贵.<人件>旗帜鲜明的论证(或憧憬):在软件开发中,人是最重要的.然而这两本书我认为理论性过强了,似乎也不符合我国的现实.我更喜欢这本小书:<软件工艺> 它说:做软件如打铁,就是手艺.将系统交给好的程序员,他自然能做出好的软件.好的程序员,应该需求分析,架构设计,编码各方面都有很深的造诣.... 这本小书真让我爱不释手.
我想,即使有银弹,枪法不同的人使用,恐怕效果也不一样.最好的小说,通常都反映了人本性最深邃的一面.同样,要设计最好的程序,必须要由最好的程序员来进行.这里程序员的范畴很广,在我的概念里,是把需求分析师,架构师,开发人员,测试人员都包含进去的.
一个好的程序员应该善于与人沟通交流,逻辑思维能力要强.有一定的文史哲基础,能将枯燥的事物用形象的比喻介绍给用户.有一定的文笔,能简洁流畅的编写需求分析书.
一个好的程序员应该精通系统架构.在了解需求之后能迅速将抽象的需求实际转换为相对具体的东西(如程序原型,uml用例图,甚至一些能说明情况的草图),以充当需求和程序架构的桥梁.用户根据这些成果表达/修改他们的需求,设计师根据这些成果进行框架的设计.
一个好的程序员应该精通各种框架技术,熟悉相应数据库(指应用开发而言),这样他才能有选择,有比较的确定用户的功能如何做,如何做得好.
一个好的程序员应该有一定的编码水平.起码不能写出太离谱的代码.
一个好的程序员还要懂得如何去测试,如何发现系统漏洞,甚至如何去攻击之.
......
我的水平也就到这里了,其他的我写不出.虽然不能孤立的撇开管理谈技术,但我觉得,假如一群好的程序员能够做到了自己的最好,最后却在公司窝囊的领导下搞砸了一个项目,那他们也足以问心无愧.
五
以下一系列小文是我在公司的无聊之作.刚开始我为了实际应用spring做了个小小的源码缺陷跟踪系统(Bug Tracking System),后来我发现这个程序虽然写出来了,但我根本无从评估它是否易用,是否易维护,是否符合别人的使用准则.我不得不启动界面让别人实际的看程序,最后获得"哦,这东西不适合我使用"的评价.老实说花了这么多时间获得这样的评价真让人沮丧.于是我想写几篇需求和设计文档,以使我和别人易于沟通,易于交流,而不用每次都要实际的启动程序.
原来,在经历整年的出差/开发/部署生涯中,我极端怀疑文档的意义.我想不可能在环境很紧迫的时候能做到一边更改代码一边更改文档.但我现在意识到,这是自己的认识偏差所导致,假如不把文档作为程序开发的约束,而作为需求沟通,设计思想交流的桥梁,恐怕它的意义会大大提高.
我很喜欢<理想国>,于是把下列小文尽量写成对话的形式.并且借用了司马相如作品的主人公,力求写得生动有趣.
我想和你交流的想法如下:
1)需求分析师如何和用户聊天以提炼需求.真实模拟国内调研时间短,需求难以明确的特点,并尽量少的在获取需求过程中使用计算机术语.
2)系统设计师如何和需求分析师分析需求,编写需求说明书.
3)系统设计师如何根据需求说明书撰写概要设计,确立程序开发所采用的框架.
4)实际开发的过程
5)测试(也许会省略,^_^)
6)其他......
希望大家不吝赐教,我正在急需反省的时期,呵呵.谢了!