十年总结（七）：学习JAVA，爱上JAVA

houzeal

－－－－
本周末要回南京参加毕业十年聚会，下周二之前估计没有更新
－－－－

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

原创  十年总结(八.2):插曲，毕业十年聚会，我的思考  收藏

该系列其它文章请看这里。
我爱思考，请看这里。

---

参加这次聚会，我的心情很复杂，有兴奋，也有忐忑。
在开篇总结中，我就说过对自己最近两年的颓废不太满意，对自己职业道路的被动选择也不满意，
人都有自尊心，谁都愿意过得比别人好，也许这次聚会的安排也在潜意识里让我警醒、反思，
于是才有了这一系列的文章。

---

每个人用三分钟总结自己十年的经历，这是聚会中最精彩的一环。

何某某：
他以“我其实是一名程序员”作为开场白。
他应该是我们班技术最好的，在毕业前就很厉害了，绝对的技术狂人
毕业后创业，最多时候开过四家公司，后来别人说“公司要越开越大，而不是越开越多”，
他就关闭了两家。

曾经在2003-2004年与迅雷竞争，和迅雷获得了同一家风投的投资，
不过迅雷拿到的是他们的20倍，所以迅雷赢了。
昨天看到一篇文章，迅雷的创始人来自百度，也许就是这人脉因素影响了成败？

他现在的公司每月的运营成本还在20多万，不过也说明他至少有钱可烧，
无论自己挣多挣少，这充满挑战的拼搏之路，就值得人尊敬和羡慕。


张某某：
他将自己的十年归结为一个“混”字。

从他调侃的叙述中，让我看到了他“混”的精彩，
毕业进入电信运营商，后来离开进入小公司，
感觉没前途，而且觉得不能荒废英语，于是跳入小外企，
后来再经跳槽进入HP。

他在“混”的同时，并没有忘记规划自己的每一步。


曹某某：
09年毕业后考取本校研究生，2000年，尚未毕业就去华为打工，
毕业后直接进入华为，如今是一个超过百人的部门的经理，而且发展势头良好。

他调侃说：“在做技术的人里，我管理最好；在做管理的人里，我技术最牛”，
综合而平衡，就是企业最需要的复合型人才。

他说感觉自己的研究生白上了（我觉得有些夸张），
如果本科毕业能够进入一个合适的单位，绝对比读研好。


刘某：
已经走上仕途的人，而且他绝对适合走这条路。
他是本次聚会唯一有专车接送的，他目前在行政级别上最高（副处，某地区联通公司副总），

在学校的时候，他跟我都属于经常补考的，但他绝对具有亲和力、野心，属于精神领袖类型的，
也许他在学校的行事有些愤青的感觉，但他绝对知道自己的路该怎么走。

在总结中，他提到“形势不对，拨马就走”，
不随波逐流，是他数次审时度势，规划自己前途的具体行动。

---（如果我说得不对，也请我的各位同学们多多谅解）

关于考不考研的问题。

计算机科学与技术，实际上科学占三，技术占七，实践远远重于书本知识。
所以，我的建议：
1、本科毕业能找到合适单位的，最好不要考研
2、一定要拼命找工作失败后，再决定考研
3、因为害怕进入社会而考研，读研只会害了你
4、考研期间，不要再傻傻的学习，或者傻傻的玩儿，尽你所能，去找个单位做点事儿，纯研究生真的太轻松了
5、本科已经找到工作的，过几年，读一个在职研究生，还是很有必要的
6、除非致力于留校教书、或者有特殊要求，否则不建议再考博士

---

关于学习成绩和个人发展

从我们班的情况来看，学习成绩和个人成就之间没有绝对的联系。
当然，学习成绩好，有助于在毕业的时候进一个好单位，但接下来三年改变自己命运的机会多的是。

能考上大学的（尤其是这种录取分数很高的大学）人，智商都不差，
大家拼的实际上是情商。
我觉得：智商决定你能不能做成一件事儿，但情商决定你有没有机会做一件事儿。

---

对尚未毕业学生的建议

大学本科，基本上是最后一次交到真心朋友的机会（会很难），
十年之后，他们会使你的人生更加丰富多彩。

houzeal

－－－－

参加一次聚会，发了两篇感慨以后，还是继续总结我的十年。

看我这总结写的，没控制住需求和进度，本来想写四篇完毕，没想到写了9篇才到2003年。
一开始也没想到有多少人会看，但第一篇就被斑竹推荐了，写着写着压力就来了。
（感谢ptwhite、koko等，尤其koko，不仅推荐我的贴子，今天还转分给我）。
我是个追求完美的人，既然这一系列前面的都被认可了，自然会努力写后续的每一篇。

－－－

2002年底的时候，老板拿到了一份《移动BOSS网管规范》文档，说公司要转型，转向业务监控。
我当时很纳闷，觉得公司BI做的好好的，为什么要转型，现在看来，老板的眼光还是很独到的。

大家可能知道，国内电信行业，移动信息化走在最前面，2002年移动提出的BOSS网管规范，
大大影响了后来电信、联通、网通相关系统的建设思路，形成了一个很大的市场，
只可惜作为一个小公司，想从这里面分一杯羹，是非常困难的。

春节前，我们一起讨论了这份规范，现在回想起来，我感觉当时的会议几方有些自说自话，
我那个时候懵懂的很，我看到规范的第一反应就是以公司的技术实力，能够做什么？
因为这份规范，在当时的我看来，是大而空，说了很多要求，又感觉没说什么具体要求，
实际上是因为不懂移动的业务，不懂这份规范产生的背景。

而老板考虑的是，以小公司参与这种大项目的竞争，该做哪些部分才有参与的机会。

不过大家有一个共识就是：以公司这些人，想全做那是不可能的。
也许是受公司做BI思路的影响，讨论来讨论区，最后决定开发一个通用的数据采集平台。
也就是从被管的业务系统中采集数据，或者提供各种接口接收数据，最终处理成一个标准格式，供后续处理和展示使用。
这真的很像BI中的ETL。

但在做了N年监控之后，我才明白，不了解业务系统，想做这样的通用采集平台是多么的难，
就算做出来了，推广又会遇到多大的障碍。


转眼春节，假期回来后，我就带着两个人开始按照节前讨论的计划做，
我在公司工作满一年了，老板又给涨了一次工资。
但很快非典就来了，大家人心惶惶，虽然都还在上班，但已经干不出实质性的工作了，
这期间，公司搬了一次家，我们三个人中有一个人还被隔离了一段时间，于是这个项目又没有“结果”，
在非典结束后，因为来了真正卖出去的项目而被遗忘，夭折了。

说到非典，除了精神上的巨大压力（感觉死亡如此之近），还有一件让人非常郁闷的事情。
非典刚开始的时候，政府好像制作了一批中药汤剂，封装成袋卖给/发给企业进行预防，
这药是否有效不得而知，但把我整惨了。
第一次拿到药水，我在下班前喝了一袋，回家路上买了个烧饼，想边走边吃，
这个药水的一大作用是让人的嗓子干的像沙漠，我一口烧饼咽下去，竟然没有任何分泌液的润滑，
死死的卡在了喉咙，吐不出来咽不下去，就像一块石头在那里，
有一阵子我都觉得我要窒息了，心里还在想，如果没染上非典被噎死，那可倒霉透顶了。


在03年的第一个学期，学校安排实习，我选择了去微软，由于非典，第一轮面试都是通过电话做的，
微软的Mentor会先跟你联系确定电话面试的时间，在等电话的一段时间里相当难熬。
说实话还是蛮紧张的，因为那时候感觉将来如果能够去外企还是很好的一条路，
因此也希望通过实习能够对将来求职有所帮助。
其实担心的主要是英语，口语，还好后来的面试基本上都是中文的。

在非典之后，我们三个人终于完成了一个赚钱的项目，但开发语言不是JAVA，
而我在去微软实习后，收入降低一半，却在这个时候买了房。

－－－－

不知道现在《大学英语》课本中是否还有那篇关于医生成长的课文，
其实每一行的从业者都有一个成长的过程，
我觉得成长的一个重要判断依据就是：
不再思考自己是不是应该这样思考，不再怀疑自己是不是应该这样决策。

houzeal

2003年夏天以前这一年多的时间里，我们租的房子是我女朋友的朋友的朋友的，
租金不贵，所以我们觉得生活很安逸，更不可能预测到今后房价的飙升，因此压根没有想过买房。
可为什么在2003年突然买了房子呢？这一切源于房**然变卦要收回房子。

也许他自己要用，也许是有人出更高的价格来租房，
总之，2003年夏天，非典过后，房东希望我们尽快把房子腾出来。

于是我们开始忙于租房子。
当时我在北京还没有什么朋友，而且对中介又极度不信任（2000年女朋友曾经上过当），
又不愿意老让女朋友出面在他的圈子里打听，于是选择了贴小广告（城管同志，我也是被逼无奈啊）。

找来找去，在同一个小区里，找到一个半地下的两居室，房子看着倒也整洁，只是住进去以后才发现原来是地狱。
原来的住户不知道是不是养了很多宠物，屋子里跳蚤成群，蟑螂成窝，
忍受不了的是跳蚤，让人恶心的是蟑螂。
于是有一段时间，我从超市买来灭蚊的药，每天上班走之前，在地面上、旮旯里喷一个遍，
坚持了一周左右，跳蚤基本死光光，可是蟑螂依旧逍遥自在，
因此蟑螂是世界上生命力最顽强的生物，可不是盖的。
在半地下居住的这三个月时间，感觉是生活中最痛苦的经历之一。

不在沉默中爆发，就在沉默中死亡。
经过了如此非人的经历，我们再也不愿意忍受飘泊不定的烦恼，于是决定去看看房子。
没啥钱，一开始看的都是小户型。
后来觉得太小，以后还要换太麻烦，于是去通州看大房子，体验了一下，感觉上班时间太长，
分别在两个地方交过定金，又都退了。

过了几天，一次朋友聚会，回来的时候路过我们租房附近的一个新开盘小区，
于是周末跟女朋友一起看了看，因为在一个地方住的多了就会有感情，觉得挺满意，
就是户型比较大，总价比较高。

当时马上要去微软实习，到时候收入只有1000/月的饭补，于是在大户型、小户型、远、进几个目标之间犹豫不决，
后来公司的老板希望我在微软实习期间再兼职这边的工作，这让我至少能有以前50％的收入，
于是，咬咬牙，买了现在的房子，从而进入赤贫+房奴的时代。
现在有了孩子，觉得两室一厅还是小，就后悔当时没有买个更大的，
可是，要知道，那时每月多出几百块钱的月供都感觉压力很大，此一时彼一时，永远没有后悔药可卖啊。


去微软之后，每天下班我还要去原来的公司上两个小时的班，周末也要抽出一天上班，于是又开始了一段辛苦的日子，
在走之前，我是公司的项目经理，走了之后，一时没有合适的人员，于是剩下的人开始试行轮班制，
就是每人当两周的临时主管，主持下一步的工作，我每周末去参加例会看一下开发的情况。
几个月以后，公司又招了两个高手，开始负责新版本的开发，我就慢慢淡出，只负责一些具体的代码编写了。
为此，原来我手下的一个小伙子（就是那个工作非常有激情的同志）还非常不满意，
他有很强的表现欲，只是火候还有些欠缺，有关他的故事，我可能会单写一篇介绍，也挺有意思的。

在微软的工作内容，引不起我的兴趣，但外企的工作环境确实很好。
我实习所在的部门负责的是服务器软件的测试，当时2003年，他们内部在测试yukon，也就是后来的sql server 2005，
刚进去的时候，他们给了我们几个人十几台机器，让我们搭建一个网络环境，但也没派上什么用场。
后来我的Mentor给我安排了一个任务，对比Sql Server和Oracle对GB18030字符集支持情况，
在做这件事情的过程中，我对字符集相关的知识有了比较深入的了解，但更重要的是，
做这件事儿教会了我一个更重要的职场道理：一个及时反馈的人。

我做事一向很认真，属于自己的工作，一定会努力做到最好，
手头这件事儿，虽然以前没有干过，但查阅了各种资料，设计了很多的对比测试用例，
搞了两周以后，已经形成了初步的结果，但我还在精雕细琢写出来的测试报告，
有一天Mentor问我工作的进展情况，我把自己认为“尚未完成”的文档发给他，
他看了以后首先表示肯定，但同时告诉我：及时反馈，让别人了解你的进度，是职业化的重要体现。
此后，我就每两天向他汇报一次进度，最终这份报告经过他的润色，提交到了总部对口的部门。

此后，在那里搞的工作更加没有挑战性，做了一段时间的资料录入（录入TechEd上收集的调查表），
又研究了一段时间的Reorting Service，感觉自己还是更喜欢开发一些。

在03年底的酒会上，我所在部门的头头说，大家干的都不错，希望继续努力，将来都有机会留在微软，
可是，很快，原来公司的老板也来找我，开出条件希望我回去。
于是，我面临了人生路上的一次艰难抉择。

－－－－－－－－－－－－－－－－－

性格，到底会不会成为发展的瓶颈，还是说不同的性格都能活出不同的精彩？
这是我一直苦苦思索，却无法找到答案的问题。

所谓的“成功”，有一定的规律可循吗？
如果说努力不一定可以成功，那么改变性格就一定可以改变命运吗？

你是一个很好的人，但你同时是一个很失败的人，这是可悲还是可笑？

houzeal

对我过去感兴趣的朋友们，请看十年总结系列文章，我基本上坦白交代了。

－－－

上一篇的末尾之所以提到性格，是因为在面临决策的时候，性格起到相当大的作用。

话说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

－－－
正式回到原来公司就职后，开发这边的管理团队形成了一个三足鼎立的局面，
田田，十几年工作经验，不怎么懂具体技术，负责纯管理，以及协调开发与市场，
乐乐，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

在经过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

看过C#后
我觉得Java真恶心。

Java这门语言未来不会再有什么大的变化了，可能以后会被Scala取代。