51Testing软件测试论坛
标题:
十年总结(七):学习JAVA,爱上JAVA
[打印本页]
作者:
houzeal
时间:
2009-7-13 11:32
标题:
十年总结(七):学习JAVA,爱上JAVA
----
本周末要回南京参加毕业十年聚会,下周二之前估计没有更新
----
2003年以前,我是一只大大的菜鸟,凭着加倍的努力来做好跟软件相关的工作。
虽然我毕业于计算机系,却一度对计算机“不太信任”,对于编程,更是没有任何的驾驭感。
有一阵子学C,语法好掌握,但总是搞不清楚有哪些函数可用,
而一旦涉及到和资源交互,比如Socket通信,数据库连接,
跟着书本一步步的做,更是经常得不到想要的结果。
大家设身处地想一想,我是通信学院毕业的,对TCP/IP协议的原理都门清,
却愣是写不出来一个稳定的C/S网络通信程序,那个WinSock让我郁闷的要死,
你说我能不抓狂吗?
所以,当我碰到Java,并逐渐了解Java的时候,很快就被它征服了。
这就好像你在一群悍妇中寻寻觅觅,正备受打击时,
暮然回首,却见到温文尔雅,小鸟依人的她,
除了一见钟情,你还有别的选择吗?
像我这个年龄的人,刚上大学那阵子接触的都是286,编程从basic学起,数据结构都是Pascal版的,
毕业以后这三年,用过ASP,用过SQL,用过VB,
一直受的都是面向过程的教育,已经先入为主了,要理解面向对象,还是有那么一点障碍,
现在的学生们就幸福了,直接都是面向对象的思想。
不过,困难是用来克服的,况且这点理念上的差异,比起过去遭受的自信心打击,那是小菜一碟。
我之所以选择Java做了这么多年的编程语言,是因为:
1、javadoc。
我觉得Javadoc这种创新的API文档组织方式,大大缓解了学习压力。
它让我在还不熟悉Java的时候,不会充满对未知的恐慌,
因为所有可用的类、方法及其解释,都在这一份文档中。
2、异常处理及StackTrace
出错了,能够知道完整的调用路径,大大方便了代码的调试。
3、对Socket、数据库链接、IO、线程的良好封装。
4、有丰富的基础API,而且引入第三方API的方式很简单。
2002年秋天,公司没有什么具体活,内蒙项目在现场招了一个人做维护,偶尔会传一些日志过来让我们查错。
日志很大,一开始都是用UltraEdit手工找关键字,后来我就想做一个简单的日志分析工具,顺便学点东西。
为什么选择学习java已经忘记了,不过学了就喜欢上了。
我花一个月左右的时间,看了一遍Thinking In Java(实体书),这是我看过的唯一一本Java书,
以后使用过程中,主要靠翻Javadoc和上网搜。
相对轻松的工作环境,也为我提供了验证学校知识的条件,我从老师那里知道了设计模式,并在项目中实践。
当时我带着两个人开发一个“业务建模”工具,可以在界面上拖拽节点、画线什么的,就像流程图,用Swing做的,
我清楚的记得自己在这个工程中用了Composite模式,还有Template模式。
初试牛刀,看着三个人的代码最终整合起来,能够正常运行,心里也有小小的成就感。
不过第一个项目,对java面向对象的特性理解真的十分有限,
所以程序中充满了用于全局调用的静态属性和方法,
整个系统是紧密耦合,分不出模块的。
02年似乎还没有Eclipse,我们编写代码用Ultraedit,手工编译,
这虽然很麻烦,但对java的理解的更透彻,比如你必须真正明白Classpath的作用和设置才能编译通过,
也能养成比较良好的编程习惯,因为没有IDE帮你做格式化和缩进。
现在Eclipse,尤其是MyEclipse,隐藏了太多的真相,
让比较懒惰的使用者越来越“傻瓜“,遇到问题肯定抓瞎。
总结:
学习的过程是一重重的境界,火候不够,就无法体验,
我偶尔回答问题也相当粗放,仔细想想,对于新手也许等于越帮越忙,
因为我也经历过弱弱的阶段,一层薄薄的窗户纸,要捅破有时候也相当困难。
现在的JAVA技术体系太过于庞大,远不像我当初所接触的那么简单,
也许不仅仅JAVA,每一个技术阵营都有越来越复杂的趋势,
但枝繁叶茂、盘根错节的大树,毕竟也只能有一个树干,
越是基本的东西,随时间的波动越小,学习要注意去芜存菁,避虚就实,
掌握了原理,才能触类旁通,用起来得心应手。
PS:我至今都觉得,C比JAVA难学!因为我没学会。
作者:
houzeal
时间:
2009-7-13 11:33
标题:
十年总结(八.2):插曲,毕业十年聚会,我的思考
原创 十年总结(八.2):插曲,毕业十年聚会,我的思考 收藏
该系列其它文章请看这里。
我爱思考,请看这里。
---
参加这次聚会,我的心情很复杂,有兴奋,也有忐忑。
在开篇总结中,我就说过对自己最近两年的颓废不太满意,对自己职业道路的被动选择也不满意,
人都有自尊心,谁都愿意过得比别人好,也许这次聚会的安排也在潜意识里让我警醒、反思,
于是才有了这一系列的文章。
---
每个人用三分钟总结自己十年的经历,这是聚会中最精彩的一环。
何某某:
他以“我其实是一名程序员”作为开场白。
他应该是我们班技术最好的,在毕业前就很厉害了,绝对的技术狂人
毕业后创业,最多时候开过四家公司,后来别人说“公司要越开越大,而不是越开越多”,
他就关闭了两家。
曾经在2003-2004年与迅雷竞争,和迅雷获得了同一家风投的投资,
不过迅雷拿到的是他们的20倍,所以迅雷赢了。
昨天看到一篇文章,迅雷的创始人来自百度,也许就是这人脉因素影响了成败?
他现在的公司每月的运营成本还在20多万,不过也说明他至少有钱可烧,
无论自己挣多挣少,这充满挑战的拼搏之路,就值得人尊敬和羡慕。
张某某:
他将自己的十年归结为一个“混”字。
从他调侃的叙述中,让我看到了他“混”的精彩,
毕业进入电信运营商,后来离开进入小公司,
感觉没前途,而且觉得不能荒废英语,于是跳入小外企,
后来再经跳槽进入HP。
他在“混”的同时,并没有忘记规划自己的每一步。
曹某某:
09年毕业后考取本校研究生,2000年,尚未毕业就去华为打工,
毕业后直接进入华为,如今是一个超过百人的部门的经理,而且发展势头良好。
他调侃说:“在做技术的人里,我管理最好;在做管理的人里,我技术最牛”,
综合而平衡,就是企业最需要的复合型人才。
他说感觉自己的研究生白上了(我觉得有些夸张),
如果本科毕业能够进入一个合适的单位,绝对比读研好。
刘某:
已经走上仕途的人,而且他绝对适合走这条路。
他是本次聚会唯一有专车接送的,他目前在行政级别上最高(副处,某地区联通公司副总),
在学校的时候,他跟我都属于经常补考的,但他绝对具有亲和力、野心,属于精神领袖类型的,
也许他在学校的行事有些愤青的感觉,但他绝对知道自己的路该怎么走。
在总结中,他提到“形势不对,拨马就走”,
不随波逐流,是他数次审时度势,规划自己前途的具体行动。
---(如果我说得不对,也请我的各位同学们多多谅解)
关于考不考研的问题。
计算机科学与技术,实际上科学占三,技术占七,实践远远重于书本知识。
所以,我的建议:
1、本科毕业能找到合适单位的,最好不要考研
2、一定要拼命找工作失败后,再决定考研
3、因为害怕进入社会而考研,读研只会害了你
4、考研期间,不要再傻傻的学习,或者傻傻的玩儿,尽你所能,去找个单位做点事儿,纯研究生真的太轻松了
5、本科已经找到工作的,过几年,读一个在职研究生,还是很有必要的
6、除非致力于留校教书、或者有特殊要求,否则不建议再考博士
---
关于学习成绩和个人发展
从我们班的情况来看,学习成绩和个人成就之间没有绝对的联系。
当然,学习成绩好,有助于在毕业的时候进一个好单位,但接下来三年改变自己命运的机会多的是。
能考上大学的(尤其是这种录取分数很高的大学)人,智商都不差,
大家拼的实际上是情商。
我觉得:智商决定你能不能做成一件事儿,但情商决定你有没有机会做一件事儿。
---
对尚未毕业学生的建议
大学本科,基本上是最后一次交到真心朋友的机会(会很难),
十年之后,他们会使你的人生更加丰富多彩。
作者:
houzeal
时间:
2009-7-13 11:34
标题:
十年总结(九):与“非典”在一起的那些日子
----
参加一次聚会,发了两篇感慨以后,还是继续总结我的十年。
看我这总结写的,没控制住需求和进度,本来想写四篇完毕,没想到写了9篇才到2003年。
一开始也没想到有多少人会看,但第一篇就被斑竹推荐了,写着写着压力就来了。
(感谢ptwhite、koko等,尤其koko,不仅推荐我的贴子,今天还转分给我)。
我是个追求完美的人,既然这一系列前面的都被认可了,自然会努力写后续的每一篇。
---
2002年底的时候,老板拿到了一份《移动BOSS网管规范》文档,说公司要转型,转向业务监控。
我当时很纳闷,觉得公司BI做的好好的,为什么要转型,现在看来,老板的眼光还是很独到的。
大家可能知道,国内电信行业,移动信息化走在最前面,2002年移动提出的BOSS网管规范,
大大影响了后来电信、联通、网通相关系统的建设思路,形成了一个很大的市场,
只可惜作为一个小公司,想从这里面分一杯羹,是非常困难的。
春节前,我们一起讨论了这份规范,现在回想起来,我感觉当时的会议几方有些自说自话,
我那个时候懵懂的很,我看到规范的第一反应就是以公司的技术实力,能够做什么?
因为这份规范,在当时的我看来,是大而空,说了很多要求,又感觉没说什么具体要求,
实际上是因为不懂移动的业务,不懂这份规范产生的背景。
而老板考虑的是,以小公司参与这种大项目的竞争,该做哪些部分才有参与的机会。
不过大家有一个共识就是:以公司这些人,想全做那是不可能的。
也许是受公司做BI思路的影响,讨论来讨论区,最后决定开发一个通用的数据采集平台。
也就是从被管的业务系统中采集数据,或者提供各种接口接收数据,最终处理成一个标准格式,供后续处理和展示使用。
这真的很像BI中的ETL。
但在做了N年监控之后,我才明白,不了解业务系统,想做这样的通用采集平台是多么的难,
就算做出来了,推广又会遇到多大的障碍。
转眼春节,假期回来后,我就带着两个人开始按照节前讨论的计划做,
我在公司工作满一年了,老板又给涨了一次工资。
但很快非典就来了,大家人心惶惶,虽然都还在上班,但已经干不出实质性的工作了,
这期间,公司搬了一次家,我们三个人中有一个人还被隔离了一段时间,于是这个项目又没有“结果”,
在非典结束后,因为来了真正卖出去的项目而被遗忘,夭折了。
说到非典,除了精神上的巨大压力(感觉死亡如此之近),还有一件让人非常郁闷的事情。
非典刚开始的时候,政府好像制作了一批中药汤剂,封装成袋卖给/发给企业进行预防,
这药是否有效不得而知,但把我整惨了。
第一次拿到药水,我在下班前喝了一袋,回家路上买了个烧饼,想边走边吃,
这个药水的一大作用是让人的嗓子干的像沙漠,我一口烧饼咽下去,竟然没有任何分泌液的润滑,
死死的卡在了喉咙,吐不出来咽不下去,就像一块石头在那里,
有一阵子我都觉得我要窒息了,心里还在想,如果没染上非典被噎死,那可倒霉透顶了。
在03年的第一个学期,学校安排实习,我选择了去微软,由于非典,第一轮面试都是通过电话做的,
微软的Mentor会先跟你联系确定电话面试的时间,在等电话的一段时间里相当难熬。
说实话还是蛮紧张的,因为那时候感觉将来如果能够去外企还是很好的一条路,
因此也希望通过实习能够对将来求职有所帮助。
其实担心的主要是英语,口语,还好后来的面试基本上都是中文的。
在非典之后,我们三个人终于完成了一个赚钱的项目,但开发语言不是JAVA,
而我在去微软实习后,收入降低一半,却在这个时候买了房。
----
不知道现在《大学英语》课本中是否还有那篇关于医生成长的课文,
其实每一行的从业者都有一个成长的过程,
我觉得成长的一个重要判断依据就是:
不再思考自己是不是应该这样思考,不再怀疑自己是不是应该这样决策。
作者:
houzeal
时间:
2009-7-13 11:35
标题:
十年总结(十):成为房奴,实习并兼职中
2003年夏天以前这一年多的时间里,我们租的房子是我女朋友的朋友的朋友的,
租金不贵,所以我们觉得生活很安逸,更不可能预测到今后房价的飙升,因此压根没有想过买房。
可为什么在2003年突然买了房子呢?这一切源于房**然变卦要收回房子。
也许他自己要用,也许是有人出更高的价格来租房,
总之,2003年夏天,非典过后,房东希望我们尽快把房子腾出来。
于是我们开始忙于租房子。
当时我在北京还没有什么朋友,而且对中介又极度不信任(2000年女朋友曾经上过当),
又不愿意老让女朋友出面在他的圈子里打听,于是选择了贴小广告(城管同志,我也是被逼无奈啊)。
找来找去,在同一个小区里,找到一个半地下的两居室,房子看着倒也整洁,只是住进去以后才发现原来是地狱。
原来的住户不知道是不是养了很多宠物,屋子里跳蚤成群,蟑螂成窝,
忍受不了的是跳蚤,让人恶心的是蟑螂。
于是有一段时间,我从超市买来灭蚊的药,每天上班走之前,在地面上、旮旯里喷一个遍,
坚持了一周左右,跳蚤基本死光光,可是蟑螂依旧逍遥自在,
因此蟑螂是世界上生命力最顽强的生物,可不是盖的。
在半地下居住的这三个月时间,感觉是生活中最痛苦的经历之一。
不在沉默中爆发,就在沉默中死亡。
经过了如此非人的经历,我们再也不愿意忍受飘泊不定的烦恼,于是决定去看看房子。
没啥钱,一开始看的都是小户型。
后来觉得太小,以后还要换太麻烦,于是去通州看大房子,体验了一下,感觉上班时间太长,
分别在两个地方交过定金,又都退了。
过了几天,一次朋友聚会,回来的时候路过我们租房附近的一个新开盘小区,
于是周末跟女朋友一起看了看,因为在一个地方住的多了就会有感情,觉得挺满意,
就是户型比较大,总价比较高。
当时马上要去微软实习,到时候收入只有1000/月的饭补,于是在大户型、小户型、远、进几个目标之间犹豫不决,
后来公司的老板希望我在微软实习期间再兼职这边的工作,这让我至少能有以前50%的收入,
于是,咬咬牙,买了现在的房子,从而进入赤贫+房奴的时代。
现在有了孩子,觉得两室一厅还是小,就后悔当时没有买个更大的,
可是,要知道,那时每月多出几百块钱的月供都感觉压力很大,此一时彼一时,永远没有后悔药可卖啊。
去微软之后,每天下班我还要去原来的公司上两个小时的班,周末也要抽出一天上班,于是又开始了一段辛苦的日子,
在走之前,我是公司的项目经理,走了之后,一时没有合适的人员,于是剩下的人开始试行轮班制,
就是每人当两周的临时主管,主持下一步的工作,我每周末去参加例会看一下开发的情况。
几个月以后,公司又招了两个高手,开始负责新版本的开发,我就慢慢淡出,只负责一些具体的代码编写了。
为此,原来我手下的一个小伙子(就是那个工作非常有激情的同志)还非常不满意,
他有很强的表现欲,只是火候还有些欠缺,有关他的故事,我可能会单写一篇介绍,也挺有意思的。
在微软的工作内容,引不起我的兴趣,但外企的工作环境确实很好。
我实习所在的部门负责的是服务器软件的测试,当时2003年,他们内部在测试yukon,也就是后来的sql server 2005,
刚进去的时候,他们给了我们几个人十几台机器,让我们搭建一个网络环境,但也没派上什么用场。
后来我的Mentor给我安排了一个任务,对比Sql Server和Oracle对GB18030字符集支持情况,
在做这件事情的过程中,我对字符集相关的知识有了比较深入的了解,但更重要的是,
做这件事儿教会了我一个更重要的职场道理:一个及时反馈的人。
我做事一向很认真,属于自己的工作,一定会努力做到最好,
手头这件事儿,虽然以前没有干过,但查阅了各种资料,设计了很多的对比测试用例,
搞了两周以后,已经形成了初步的结果,但我还在精雕细琢写出来的测试报告,
有一天Mentor问我工作的进展情况,我把自己认为“尚未完成”的文档发给他,
他看了以后首先表示肯定,但同时告诉我:及时反馈,让别人了解你的进度,是职业化的重要体现。
此后,我就每两天向他汇报一次进度,最终这份报告经过他的润色,提交到了总部对口的部门。
此后,在那里搞的工作更加没有挑战性,做了一段时间的资料录入(录入TechEd上收集的调查表),
又研究了一段时间的Reorting Service,感觉自己还是更喜欢开发一些。
在03年底的酒会上,我所在部门的头头说,大家干的都不错,希望继续努力,将来都有机会留在微软,
可是,很快,原来公司的老板也来找我,开出条件希望我回去。
于是,我面临了人生路上的一次艰难抉择。
-----------------
性格,到底会不会成为发展的瓶颈,还是说不同的性格都能活出不同的精彩?
这是我一直苦苦思索,却无法找到答案的问题。
所谓的“成功”,有一定的规律可循吗?
如果说努力不一定可以成功,那么改变性格就一定可以改变命运吗?
你是一个很好的人,但你同时是一个很失败的人,这是可悲还是可笑?
作者:
houzeal
时间:
2009-7-13 11:35
标题:
十年总结(11):2004年春,揣着一颗创业的心去打工
对我过去感兴趣的朋友们,请看十年总结系列文章,我基本上坦白交代了。
---
上一篇的末尾之所以提到性格,是因为在面临决策的时候,性格起到相当大的作用。
话说2003-04之交,我在微软实习,而原来公司老板,也是我正在兼职的公司老板找我,
说他想开始一项产品研发计划,希望我能立刻回去。
他跟我分析说,如果现在回去,那你就是项目经理,将来就是元老,以后公司有发展肯定亏待不了你,
而如果等你毕业以后再回去,到时候人招的差不多了,你位置就不好安排了。
说到这个产品研发计划,还是跟02年底我们看到的移动BOSS网管规范有关,
有电信从业经验的人都知道,电信的核心业务,像计费、营帐、客服、结算等系统(BSS,OSS系列),
都已经被列强瓜分完毕,形成了比较固定的势力范围,小厂商要想杀进去,基本不可能。
而网管和监控这一块,虽然不是核心业务,却是一个新兴市场,
随着核心业务系统越建越多,越来越复杂,保证系统的运行稳定,也是很艰巨的任务,必须也上系统来解决,
而且,只要核心业务系统的建设和升级不停止,对网管和监控的需求就不会枯竭。
所以说,这位老板在看市场的眼光方面,还是很让我佩服的。
其实当时做出决策真的很难,是去一个小公司开始挣钱,还是抓住将来留在微软的可能,
最后我做出了回去的选择,基于如下几个因素:
1、被老板描述的美好前景所迷惑。
2、老板三番五次很诚恳的跟我说这个事儿,让我感到不回去很内疚,
我很感激他当初给我工作机会,因此回去也有一些感恩的因素,这就是性格方面的因素。
3、收入有很大的改善,可以大大缓解我们房贷的压力,很有诱惑力。
4、微软这边的工作内容,确实不太吸引人,虽然环境很吸引人。
但回去怎么跟学校说?怎么跟微软的Mentor说呢?
我当时没有通知学校,只跟微软的导师发了封邮件,说我家有事儿,下半年不能过来了。
然后就消失了,后来写论文的时候,去找老师,老师还说:你去哪里了,怎么都不说一声。
唉,我觉得这件事儿我处理的很没水平,到现在还常常自责。
其实现在想想,坦白说出来就好,没必要藏着掖着,
可我就是这样,为情面所累,
实习这半年来,微软的员工对我也很好,工作氛围很融洽,所以我不好意思当面跟人家说:我不愿意在你们这儿了。
还记得我有一篇(
http://blog.csdn.net/jinxfei/archive/2009/05/31/4228469.aspx
)文章提到的那个数学系毕业的小伙子吗(以后叫他军军)?
在我实习这半年里,他多次争取当项目经理未果,而公司新招了一个工作经验也有8年左右的来主持开发,
军军不服,正嚷着要走,听说我答应回去,又说不走了,让我着实感动了一把。
我离开半年,但形势跟当初离开时已经有很大的改变,
公司的报表业务从Brio转向MSTR,做的有声有色,当年利润不少,也是老板能够挺起腰板做研发的后盾。
研发队伍人多了不少,走的时候三个人,现在已经有7个人了,加上我,还有老板请来的他一个朋友,一共九个人。
这个团队加上我有三个工作时间较长的,一个是数学系小伙子不服的那个高手(乐乐),一个是老板请来的那个朋友(田田),
乐乐致力于要在2004年底移民澳洲,因此老板觉得靠不住,他自己也是申请的灵活工作制,经常在家照看孩子,
田田工作经验丰富,但不懂具体开发,属于老板拉来做管理的,说白了还是害怕我这个毛头小子把事情搞砸。
于是,2004年初,我以一种参与创业的心态,开始了一段产品研发的历程,
这条路走下来真是艰辛,我犯了多少错误,遇到多少困难,也获得了相应的成长,
第一个要克服的问题,是开发理念上的冲突,RUP还是XP,或者干脆什么都不要?
为此有过多少次的讨论和摩擦,并在冲撞中,互相妥协。
---
感觉老板们都是蛮会忽悠的,但老板们往往是寂寞的,他们比普通员工更渴望成功,
虽然很多老板的事业失败了,但我们不能因此而认为它们当初的承诺是骗人的。
在多数企业,市场和技术永远是矛盾体,老板都希望自己的公司有核心竞争力(技术),
眼睛紧盯的却是市场,其实在这一点上,老板也痛苦。
并不是说中国的老板不重视技术,因为每个公司都面临生存问题,挣钱生存下去才是第一位的,
人不是也一样吗,温饱问题解决不了,讲什么思想境界。
我没有当过真正的公司老板,所以认识粗浅的很,
这些是多年来站在老板身边,跟他做技术与市场斗争的过程中领悟的。
我说这些,是想得到如下一个结论:
老板的梦想,需要一个优秀的团队+机遇+努力才可能实现,
老板的上市计划失败了,并不一定是他故意忽悠人,他只是像我们一样,在鲤鱼跃龙门的时候,没有进入清华、北大而已。
作者:
houzeal
时间:
2009-7-13 11:37
标题:
十年总结(12):软件开发思想之争 - RUP VS XP
---
正式回到原来公司就职后,开发这边的管理团队形成了一个三足鼎立的局面,
田田,十几年工作经验,不怎么懂具体技术,负责纯管理,以及协调开发与市场,
乐乐,8-10年工作经验,03下半年,他牵头做了一个2.0版本的框架,java c/s架构,年底要移民澳洲,
我和乐乐各带了几个开发人员一起主持开发工作。
虽然多头领导并不是一件好事儿,但对我来讲并不是一件坏事儿,
因为来北京这几年,开发方面都是以我为主,很多时候我也不知道自己的决定是不是对,
我相信大家都有这种感受,自己做出的决策,虽然内心相信是正确的,但还是希望通过其它途径得到证实,
这就是常说的“他山之石,可以攻玉”,“外来的和尚会念经”。
我现在觉得,需要别人来证明自己的时候,正是自己还不成熟的时候,不过从青涩变得成熟,不都要经历这个阶段嘛!
04年,我的课程学分拿的差不多了,因为专业是软件工程,所以课程包括:过程改进、软件度量、算法设计、面向对象设计等等,
我当时的感觉就像一个熟读了武功秘籍的人,迫切的希望通过修炼来印证功法所说的种种妙用,
田田和乐乐都比我有经验,我自然乐得好好学习。
我有几年的软件开发经验,也切身体会到不少的问题,我也经常思考如何更合理的组织开发,
我的目标有些理想化,在我看来:
1、管理应该实现“无为而治”,也就是说管理者的精力应该不在管,而在于看,看结果,看未来
2、软件开发过程应该是可视、可控的。
3、软件开发的结果是可预期的。
我所学的各种管理课程都信誓旦旦的保证,规范的流程可以满足我的要求(除了第一条),
所以当乐乐提出开发团队要采用RUP的时候,我积极响应,表示大力支持。
于是,我们剪裁文档、安装Rational Rose、招聘测试人员和配置管理人员,制定版本管理规范等等。
我也在这一时期,阅读了《人月神话》、《IT项目管理》、《UML》等很多相关书籍。
然而,问题很快就出现了。
在小公司,我们虽然是产品研发团队,但我们无法做到和项目的完全隔离,我们发布出去的版本还不能稳定的像Window,office一样out of the box,
在流程的作用下,实施人员开始抱怨对问题的响应太慢(因为大家都习惯了有问题直接找开发,而现在我们要评审、修改文档然后改代码发布),
用户的“紧急”需求被我们安排到下一版本,但市场通过老板来改变我们的版本发布计划,插入更加急迫的需求。
由于规范的实施,导致开发与实施+市场产生了一定的对立(我不清楚这是我们公司的特例还是普遍情况),
因为中国公司的客户总是很急,市场压力很大,于是每隔一段时间,当矛盾激化的时候,田田就召集我们和负责市场和实施的人开会,
讨论的结果往往是如下几种:
1、这个问题,需进一步“优化流程”,还是寄希望流程解决问题。
2、我们开发力量不够,需要继续加人(但公司的实力是有限的啊)
3、实施方面保证目前面临的是一个特殊情况,开发方面暂时妥协,尽快解决问题(一个项目总有足够多的“特殊”理由)
3、要么没有结论,保持问题依旧(实际上是实施方面妥协)
在一次次的摩擦中,虽然乐乐一直坚定不移的倡导他的“RUP”,并将很多问题归结为“流程不够优化”和“人员不足”时,
我却在疑惑和反思。
在一家小公司,什么样的开发过程才是合理的?
产品化之路在小公司行的通吗?
RUP实施的越彻底,所带来的管理消耗越大,到底有多少小公司可以承受?
正当我为此郁闷不已的时候,听到了“XP”一词。
那是04年第一学期结束的时候,回学校给导师汇报毕业论文的计划,
她提到最近参加一次国际会议,会上有人讲解国外方兴未艾的软件开发思路:极限编程(eXtreme Programming,简称XP)。
老师描绘的由XP带来的快速交付能力和代码质量的巨大提升,让我觉得心动不已,但又将信将疑。
回家后,我立刻上网搜索相关信息,阅读XP的最佳实践,
从XP又找到了敏捷建模、敏捷思想,并熟知了一些大师们的名字。
这些先进的思想,当时给我的感觉就是“天上掉下个林妹妹,似一朵轻云刚出岫”,让人眼前一亮,
我隐约觉得我所追寻的东西,就蕴含在这些大师们的思想之中。
经过初步分析,我觉得XP对开发团队来讲过于激进,而“敏捷”这个宗旨是比较有现实价值的,
于是毫不犹豫的买下了大师们写的几本书,包括:
《敏捷建模》,《测试驱动开发》等。
以最快的速度看完这些书后(要知道,解决问题式的学习和无目标的纯学习那是太不一样了),
我在一次团队会议上提出尝试让开发团队变得“敏捷一点”的想法。
在我介绍了XP以及敏捷的核心思路后,乐乐表示不相信这样做会有效,而田田则不置可否,认为需要证实,
于是,我建议讲相关资料分发给大家去学习,然后再开会讨论此事。
大家经过学习后(我其实很怀疑有些开发人员是不是真的在意过这些事情),只有军军这个小伙子表现出跟我一样的兴趣,
在后来安排的会议上,我就像诸葛亮舌战群儒一样,跟大家辩论敏捷和RUP哪个更适合我们。
经过辛苦的辩论(这可比我论文答辩辛苦多了),我们终于达成一致,在开发团队试行“敏捷”的开发方式。
真正实施起来,敏捷建模或者XP编程远没有想象的那么简单,以我的经验来看,敏捷的成败取决于如下几点:
1、成员对这种思想的认知和认同
2、对参与者的水平普遍要求较高
3、要防止XP演变成自由主义
我们团队中试行的“敏捷”虽然没有达到老外们“宣称”的效果,但在改善代码质量,提升团队的响应速度方面,有比较明显的作用,
因此,在以后的日子里,RUP也慢慢不再被人提及。
以后几年里,我经历了几家有CMM资质的公司,但发现一个现象,那就是“资质是公司的,而不是团队的”,
也就是说,虽然公司过了认证,但团队在做开发的时候,风格更多的取决于团队的领导。
我在实际的软件项目管理过程中逐渐形成了如下信念:
1、无法执行的规定还不如没有规定。
2、代码质量应该在一切可能的情况下成为开发人员的第一目标。
而我从关注方法过渡到关注结果(代码质量),是04年下半年的事情。
---
我并不否认RUP的伟大意义,但以我目前的经验来看,不是每家公司都适合,至少以项目为本的公司,不适合。
然而敏捷或者XP也有较高的实施门槛,所以,实施起来也并不容易。
但对于个人来讲,提升自己提交物(无论是代码还是文档)的质量,是经营个人品牌的重要举措。
以前也讨论过读不读研的问题。学校的课程不是没有价值,但如果不考虑学历文凭,我们不上学一样可以学到,
但有一点,学校是一个思想交汇的地方,借助你的导师和同学,能够发现一些有价值的知识或者机会,这一点自己不容易成就。
就像我接触到XP一样。
在工作中,不要让流程或者制度成为推卸责任的借口。
我觉得刚开始接触XP的时候,其思想比现在要极端的多(也许是我当年的感觉比较极端),而今天我看到RUP for XP之类的字眼,实在感觉有些哭笑不得,
以RUP为代表的“工程化”软件开发管理思想,很重要的一个思路就是拿软件开发和建筑开发做比较,希望能够像盖房子一样来做软件。
但盖房子和做软件最大的差异在于,软件质量的度量比建筑质量的度量要复杂太多。
传统软件工程思想是希望稳定需求,通过关注过程而保证结果,
而以XP为代表的敏捷阵营,关注的是参与开发的人,以及提交物的质量,强调沟通、协作,主张拥抱变化。
我个人觉得,这两者真的蛮难融合的。
很多人说我写的慢,每篇写的太少。
呵呵,没办法啊,我有我的家庭,我有我的工作,
写点东西,都是在业余时间中抽时间,我的每一篇文章,通常都要花2-3个晚上,大家没法发现我经常凌晨发贴子吗?
我要回忆,我要有取舍,我还要注意行文的流畅,最重要的,我还要从中思考与总结。
我也不可能把所有的精力都来写这一个系列,我还得随时捕捉思想中的灵感,因为我目前的人生课题是“思考”。
这不是在写小说,各位担待啊。
作者:
houzeal
时间:
2009-7-13 11:38
标题:
十年总结(13):开发不息,重构不止
在经过RUP和XP两种思想的冲撞之后,我发现想要借助一个什么理论来获得工作绩效的提升,基本上是不可能的,
RUP也好,XP也罢,都不是看看书,照猫画虎就可以解决软件开发过程中的问题的。
还是应了那句话:软件行业没有银弹。
从宏观方面来看,项目在开发方面面临的问题是类似的:延期交付,质量不易控制,需求反复等等,
但每个项目又有其独特的人员构成、技术架构以及用户环境。
因此,只能说:软件开发的管理,没有放之四海皆准的规范,我们可以定目标,但实现目标的手段应该多样化。
实施XP一段时间,除了我和军军,还有军军介绍过来的一个同学一起做过结对编程,做过测试驱动开发以外,
但推动团队中的其他人参与XP的最佳实践难度非常大。
这些难度主要来自于人,人的配合度,以及人的能力。
在配合度方面,XP需要所有参与者都对这种思想有高度的认同感,然而不是每个人都对软件开发充满激情,
也并非每个人都追求完美,很多人只是将工作当成养家糊口的手段,按部就班的做事儿,甚至有些被动的承担任务,
这就已经与XP对质量不懈追求的基本目标背道而驰。
从能力角度来看,XP中没有严格的岗位划分,设计与开发是紧密融合的,
每个人都要会做需求分析,会设计,会编码,会测试,
你不能只了解自己负责的一小部分功能,而是必须随时做好接下新的任务准备。
就拿TDD(测试驱动开发)来说,没有很强的软件开发经验,是很难先行写出测试代码的,
写出了测试代码再去写功能代码,就意味着你已经对模块的输入、输出、处理逻辑、边界、异常等了然于胸了。
所以XP团队需要一个导师,不停的统一大家的思想,我就是这个导师,但后来XP的最重要支持者军军离开了公司,
一个人传承一种思想很孤单,也很无力,搞得我也没有太大的兴趣再深入推动XP了。
但不管怎么样,做这些事情的过程,让我学到不少技术以外的东西。
随着时间的推移,我逐渐把XP和敏捷建模的具体实践抛弃了,保留了我认为最核心的两条:
1、积极参与和有效沟通
2、对代码质量的不懈追求
这是我日后工作中的基本信念,也是对我的团队成员不断强调的原则,这就是我的团队文化。
正是对质量的不断探索,让我接触到“重构”理念,其实我觉得重构是实践敏捷的必然结果和必由之路,
为了增强软件的可扩展能力,传统的软件研发思路是尽量加强设计,越详细越好,最好把编码这块的人都当成傻子,
设计出来了,负责写代码的人严格按照设计规格来编码就OK。
设计中要预先设想未来可能出现的各种情况,这一方面容易造成浪费,另一方面可能会导致过度设计。
而敏捷思想则希望代码本身是容易改变的,每一次设计过程都不做过多的预测,看似有些“鼠目寸光”,
实际上却从另外一个层面对代码的可扩展能力提出了要求:
1、代码可读性。要让别人很容易搞懂代码的意图,以方便修改。
2、低耦合。以便修改的时候尽量缩减影响范围。
以上两点讲起来,可以有非常多的内容,不过这一篇已经有些跑题了,不多说了。
以上内容是基于上一篇延续出来的感慨,就此打住了。
总之我在软件开发管理方面现在属于无门无派,非正亦非邪,真的是很“草根”。
---
重构,就是在不改变代码原有功能的基础上,提高代码质量。
2004年的下半年,徜徉在大师们的思想中,真的感觉很惬意,
《敏捷建模》和《重构-改善既有代码的设计》这两本书,都是翻了几页就毫不犹豫买下来的,再加上《Thinking In Java》,
这三本书是到04年为止,我在技术方面看的最认真,也最有收获的几本。
我一直觉得,书不贵在多而在于精。
《敏捷建模》让我知道做软件开发还可以有一种更加灵活的方式,给了我一个可以去追寻的境界,
而《重构》给了我工具和指示,让我可以向大师的境界攀登。
《重构》这本书分成两部分,前面讲原则,后面讲手段,
作者将需要改造的代码成为Bed smell,真的是很形象,不好的代码,有点像“一块臭肉毁了一锅汤”的意思。
这本书蛮厚的,其实真正能够记下的都是原则性的东西,从后来的工作中体会到,最常见的Bed smell有:
1、重复代码。
我觉得这是优质代码的头号公敌,通常是大量复制、粘贴的结果。
这厮带来的最大问题:相同的逻辑分散在多处,导致修改困难,容易遗漏
2、过大的类或者方法
一个方法如果很长(通常超过两屏),则要理解其逻辑将非常困难,
重构时通常要将处理步骤梳理出来,每步一个子方法,主函数变成一个很清晰函数调用序列。
如有必要,可以对子方法进一步重构,直到每个方法只解决一个问题。
3、不合理的类封装
一个设计最初一般是合理的,但随着后续的修改,会不断的向已有类上增加方法,导致本来健康的类变得臃肿,
因此,每隔一段时间,应该重新规划方法的分布,比如在类之间迁移,或者抽象出新的类来。
4、魔鬼数字
int i=0;
int j=1;
如果不加额外的注释,谁能明白0和1的意义?
魔鬼数字的说法早已有之,是影响代码可读性的一大毒瘤,处理方法为:用常量替换之
出了魔鬼数字,还有一种魔鬼逻辑,比如:
if ((status==RUNNING || status==STARING) && (freeSlot.size()>RESERVED)){
//Do Something!
}
以上的if条件虽然没有出现魔鬼数字,但这个逻辑有些复杂,也是需要读代码的人费些心思去算计的,
通常条件判断式如果包含两项以上的表达式,这样的条件建议重构成一个方法:
if (canAcceptMore()){
//Do Something!
}
private boolean canAcceptMore(){
return (status==RUNNING || status==STARING) && (freeSlot.size()>RESERVED);
}
5、不合理的命名
不合理的变量名也会大大影响代码的阅读,变量名、方法名、类名、包名都要认真考虑,一般遵循如下原则
意义准确,且不随便将一个变量转作它用
风格统一(Java官方的约定就挺好的)
用词统一(同样代表缓冲,不要一会儿Buf,一会儿Cache,要么都缩写,要么都全拼)
6、冗长的参数列
函数拥有超长的参数列,通常也是增量修改的结果,这时候要考虑
要么,将参数抽象成一个独立的对象进行传递
要么,考虑一下这个方法是否有更合适的归宿
要么,可以看一下这个方法是不是完成了太多的逻辑而需要进行拆分
以上只是一些皮毛和最常见的情况,重构是一门艺术,需要在实践中慢慢体会,但最重要的,是要有这个心。
---
总结:
工作这么多年,学了很多东西,一直最怕的是把简单的问题复杂化,技术领域这样的例子数不胜数。
我觉得学习需要一种境界,张无忌学太极是最经典的例子,一开始还能记得招数,回忆几遍,就忘得差不多了,
学习进入这种境界,才能在如今技术、名词、思想满天飞的时代,不被乱花迷人眼。
比如Spring,刚出来的时候扛着轻量级框架的大旗,可大家看看现在的SSH,哪里还有“轻量”的影子?
上手就有很大的难度,更别说精通了,到底是简单了,还是复杂了?
敏捷建模也是,其核心思想就是敏捷,而基于此构建的种种思想和框架,岂不是给自由的灵魂套上了枷锁?
设计模式也是,最初只有24种经典模式,我们尚且不能运用自如,
现在恨不得模式满天飞,大脑不是计算机,不擅长背诵,
当信息量超出我们的记忆能力的时候,这些信息是否有价值,甚至说是否有害?
重构其实也一样,你只需要记住这本书名《重构-改善既有代码的设计》和它改善代码的原则即可,
至于其中的上百种重构手段,没有天才的记忆力,就不必背诵了吧?
最后,说一句,养成良好的编程习惯很重要,不要因为你是在做试验而不注意代码的质量。
作者:
shanxi
时间:
2009-7-13 12:00
看过C#后
我觉得Java真恶心。
Java这门语言未来不会再有什么大的变化了,可能以后会被Scala取代。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2