十年总结（七）：学习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难学！因为我没学会。
十年总结(八.2):插曲，毕业十年聚会，我的思考
原创十年总结(八.2):插曲，毕业十年聚会，我的思考收藏该系列其它文章请看这里。
我爱思考，请看这里。
---
参加这次聚会，我的心情很复杂，有兴奋，也有忐忑。
在开篇总结中，我就说过对自己最近两年的颓废不太满意，对自己职业道路的被动选择也不满意，
人都有自尊心，谁都愿意过得比别人好，也许这次聚会的安排也在潜意识里让我警醒、反思，
于是才有了这一系列的文章。
---
每个人用三分钟总结自己十年的经历，这是聚会中最精彩的一环。
何某某：
他以“我其实是一名程序员”作为开场白。
他应该是我们班技术最好的，在毕业前就很厉害了，绝对的技术狂人
毕业后创业，最多时候开过四家公司，后来别人说“公司要越开越大，而不是越开越多”，
他就关闭了两家。
曾经在2003-2004年与迅雷竞争，和迅雷获得了同一家风投的投资，
不过迅雷拿到的是他们的20倍，所以迅雷赢了。
昨天看到一篇文章，迅雷的创始人来自百度，也许就是这人脉因素影响了成败？
他现在的公司每月的运营成本还在20多万，不过也说明他至少有钱可烧，
无论自己挣多挣少，这充满挑战的拼搏之路，就值得人尊敬和羡慕。
张某某：
他将自己的十年归结为一个“混”字。
从他调侃的叙述中，让我看到了他“混”的精彩，
毕业进入电信运营商，后来离开进入小公司，
感觉没前途，而且觉得不能荒废英语，于是跳入小外企，
后来再经跳槽进入HP。
他在“混”的同时，并没有忘记规划自己的每一步。
曹某某：
09年毕业后考取本校研究生，2000年，尚未毕业就去华为打工，
毕业后直接进入华为，如今是一个超过百人的部门的经理，而且发展势头良好。
他调侃说：“在做技术的人里，我管理最好；在做管理的人里，我技术最牛”，
综合而平衡，就是企业最需要的复合型人才。
他说感觉自己的研究生白上了（我觉得有些夸张），
如果本科毕业能够进入一个合适的单位，绝对比读研好。
刘某：
已经走上仕途的人，而且他绝对适合走这条路。
他是本次聚会唯一有专车接送的，他目前在行政级别上最高（副处，某地区联通公司副总），
在学校的时候，他跟我都属于经常补考的，但他绝对具有亲和力、野心，属于精神领袖类型的，
也许他在学校的行事有些愤青的感觉，但他绝对知道自己的路该怎么走。
在总结中，他提到“形势不对，拨马就走”，
不随波逐流，是他数次审时度势，规划自己前途的具体行动。
---（如果我说得不对，也请我的各位同学们多多谅解）
关于考不考研的问题。
计算机科学与技术，实际上科学占三，技术占七，实践远远重于书本知识。
所以，我的建议：
1、本科毕业能找到合适单位的，最好不要考研
2、一定要拼命找工作失败后，再决定考研
3、因为害怕进入社会而考研，读研只会害了你
4、考研期间，不要再傻傻的学习，或者傻傻的玩儿，尽你所能，去找个单位做点事儿，纯研究生真的太轻松了
5、本科已经找到工作的，过几年，读一个在职研究生，还是很有必要的
6、除非致力于留校教书、或者有特殊要求，否则不建议再考博士
---
关于学习成绩和个人发展
从我们班的情况来看，学习成绩和个人成就之间没有绝对的联系。
当然，学习成绩好，有助于在毕业的时候进一个好单位，但接下来三年改变自己命运的机会多的是。
能考上大学的（尤其是这种录取分数很高的大学）人，智商都不差，
大家拼的实际上是情商。
我觉得：智商决定你能不能做成一件事儿，但情商决定你有没有机会做一件事儿。
---
对尚未毕业学生的建议
大学本科，基本上是最后一次交到真心朋友的机会（会很难），
十年之后，他们会使你的人生更加丰富多彩。
十年总结（九）：与“非典”在一起的那些日子
－－－－参加一次聚会，发了两篇感慨以后，还是继续总结我的十年。
看我这总结写的，没控制住需求和进度，本来想写四篇完毕，没想到写了9篇才到2003年。
一开始也没想到有多少人会看，但第一篇就被斑竹推荐了，写着写着压力就来了。
（感谢ptwhite、koko等，尤其koko，不仅推荐我的贴子，今天还转分给我）。
我是个追求完美的人，既然这一系列前面的都被认可了，自然会努力写后续的每一篇。
－－－
2002年底的时候，老板拿到了一份《移动BOSS网管规范》文档，说公司要转型，转向业务监控。
我当时很纳闷，觉得公司BI做的好好的，为什么要转型，现在看来，老板的眼光还是很独到的。
大家可能知道，国内电信行业，移动信息化走在最前面，2002年移动提出的BOSS网管规范，
大大影响了后来电信、联通、网通相关系统的建设思路，形成了一个很大的市场，
只可惜作为一个小公司，想从这里面分一杯羹，是非常困难的。
春节前，我们一起讨论了这份规范，现在回想起来，我感觉当时的会议几方有些自说自话，
我那个时候懵懂的很，我看到规范的第一反应就是以公司的技术实力，能够做什么？
因为这份规范，在当时的我看来，是大而空，说了很多要求，又感觉没说什么具体要求，
实际上是因为不懂移动的业务，不懂这份规范产生的背景。
而老板考虑的是，以小公司参与这种大项目的竞争，该做哪些部分才有参与的机会。
不过大家有一个共识就是：以公司这些人，想全做那是不可能的。
也许是受公司做BI思路的影响，讨论来讨论区，最后决定开发一个通用的数据采集平台。
也就是从被管的业务系统中采集数据，或者提供各种接口接收数据，最终处理成一个标准格式，供后续处理和展示使用。
这真的很像BI中的ETL。
但在做了N年监控之后，我才明白，不了解业务系统，想做这样的通用采集平台是多么的难，
就算做出来了，推广又会遇到多大的障碍。
转眼春节，假期回来后，我就带着两个人开始按照节前讨论的计划做，
我在公司工作满一年了，老板又给涨了一次工资。
但很快非典就来了，大家人心惶惶，虽然都还在上班，但已经干不出实质性的工作了，
这期间，公司搬了一次家，我们三个人中有一个人还被隔离了一段时间，于是这个项目又没有“结果”，
在非典结束后，因为来了真正卖出去的项目而被遗忘，夭折了。
说到非典，除了精神上的巨大压力（感觉死亡如此之近），还有一件让人非常郁闷的事情。
非典刚开始的时候，政府好像制作了一批中药汤剂，封装成袋卖给/发给企业进行预防，
这药是否有效不得而知，但把我整惨了。
第一次拿到药水，我在下班前喝了一袋，回家路上买了个烧饼，想边走边吃，
这个药水的一大作用是让人的嗓子干的像沙漠，我一口烧饼咽下去，竟然没有任何分泌液的润滑，
死死的卡在了喉咙，吐不出来咽不下去，就像一块石头在那里，
有一阵子我都觉得我要窒息了，心里还在想，如果没染上非典被噎死，那可倒霉透顶了。
在03年的第一个学期，学校安排实习，我选择了去微软，由于非典，第一轮面试都是通过电话做的，
微软的Mentor会先跟你联系确定电话面试的时间，在等电话的一段时间里相当难熬。
说实话还是蛮紧张的，因为那时候感觉将来如果能够去外企还是很好的一条路，
因此也希望通过实习能够对将来求职有所帮助。
其实担心的主要是英语，口语，还好后来的面试基本上都是中文的。
在非典之后，我们三个人终于完成了一个赚钱的项目，但开发语言不是JAVA，
而我在去微软实习后，收入降低一半，却在这个时候买了房。
－－－－
不知道现在《大学英语》课本中是否还有那篇关于医生成长的课文，
其实每一行的从业者都有一个成长的过程，
我觉得成长的一个重要判断依据就是：
不再思考自己是不是应该这样思考，不再怀疑自己是不是应该这样决策。
十年总结（十）：成为房奴，实习并兼职中
2003年夏天以前这一年多的时间里，我们租的房子是我女朋友的朋友的朋友的，租金不贵，所以我们觉得生活很安逸，更不可能预测到今后房价的飙升，因此压根没有想过买房。
可为什么在2003年突然买了房子呢？这一切源于房**然变卦要收回房子。
也许他自己要用，也许是有人出更高的价格来租房，
总之，2003年夏天，非典过后，房东希望我们尽快把房子腾出来。
于是我们开始忙于租房子。
当时我在北京还没有什么朋友，而且对中介又极度不信任（2000年女朋友曾经上过当），
又不愿意老让女朋友出面在他的圈子里打听，于是选择了贴小广告（城管同志，我也是被逼无奈啊）。
找来找去，在同一个小区里，找到一个半地下的两居室，房子看着倒也整洁，只是住进去以后才发现原来是地狱。
原来的住户不知道是不是养了很多宠物，屋子里跳蚤成群，蟑螂成窝，
忍受不了的是跳蚤，让人恶心的是蟑螂。
于是有一段时间，我从超市买来灭蚊的药，每天上班走之前，在地面上、旮旯里喷一个遍，
坚持了一周左右，跳蚤基本死光光，可是蟑螂依旧逍遥自在，
因此蟑螂是世界上生命力最顽强的生物，可不是盖的。
在半地下居住的这三个月时间，感觉是生活中最痛苦的经历之一。
不在沉默中爆发，就在沉默中死亡。
经过了如此非人的经历，我们再也不愿意忍受飘泊不定的烦恼，于是决定去看看房子。
没啥钱，一开始看的都是小户型。
后来觉得太小，以后还要换太麻烦，于是去通州看大房子，体验了一下，感觉上班时间太长，
分别在两个地方交过定金，又都退了。
过了几天，一次朋友聚会，回来的时候路过我们租房附近的一个新开盘小区，
于是周末跟女朋友一起看了看，因为在一个地方住的多了就会有感情，觉得挺满意，
就是户型比较大，总价比较高。
当时马上要去微软实习，到时候收入只有1000/月的饭补，于是在大户型、小户型、远、进几个目标之间犹豫不决，
后来公司的老板希望我在微软实习期间再兼职这边的工作，这让我至少能有以前50％的收入，
于是，咬咬牙，买了现在的房子，从而进入赤贫+房奴的时代。
现在有了孩子，觉得两室一厅还是小，就后悔当时没有买个更大的，
可是，要知道，那时每月多出几百块钱的月供都感觉压力很大，此一时彼一时，永远没有后悔药可卖啊。
去微软之后，每天下班我还要去原来的公司上两个小时的班，周末也要抽出一天上班，于是又开始了一段辛苦的日子，
在走之前，我是公司的项目经理，走了之后，一时没有合适的人员，于是剩下的人开始试行轮班制，
就是每人当两周的临时主管，主持下一步的工作，我每周末去参加例会看一下开发的情况。
几个月以后，公司又招了两个高手，开始负责新版本的开发，我就慢慢淡出，只负责一些具体的代码编写了。
为此，原来我手下的一个小伙子（就是那个工作非常有激情的同志）还非常不满意，
他有很强的表现欲，只是火候还有些欠缺，有关他的故事，我可能会单写一篇介绍，也挺有意思的。
在微软的工作内容，引不起我的兴趣，但外企的工作环境确实很好。
我实习所在的部门负责的是服务器软件的测试，当时2003年，他们内部在测试yukon，也就是后来的sql server 2005，
刚进去的时候，他们给了我们几个人十几台机器，让我们搭建一个网络环境，但也没派上什么用场。
后来我的Mentor给我安排了一个任务，对比Sql Server和Oracle对GB18030字符集支持情况，
在做这件事情的过程中，我对字符集相关的知识有了比较深入的了解，但更重要的是，
做这件事儿教会了我一个更重要的职场道理：一个及时反馈的人。
我做事一向很认真，属于自己的工作，一定会努力做到最好，
手头这件事儿，虽然以前没有干过，但查阅了各种资料，设计了很多的对比测试用例，
搞了两周以后，已经形成了初步的结果，但我还在精雕细琢写出来的测试报告，
有一天Mentor问我工作的进展情况，我把自己认为“尚未完成”的文档发给他，
他看了以后首先表示肯定，但同时告诉我：及时反馈，让别人了解你的进度，是职业化的重要体现。
此后，我就每两天向他汇报一次进度，最终这份报告经过他的润色，提交到了总部对口的部门。
此后，在那里搞的工作更加没有挑战性，做了一段时间的资料录入（录入TechEd上收集的调查表），
又研究了一段时间的Reorting Service，感觉自己还是更喜欢开发一些。
在03年底的酒会上，我所在部门的头头说，大家干的都不错，希望继续努力，将来都有机会留在微软，
可是，很快，原来公司的老板也来找我，开出条件希望我回去。
于是，我面临了人生路上的一次艰难抉择。
－－－－－－－－－－－－－－－－－
性格，到底会不会成为发展的瓶颈，还是说不同的性格都能活出不同的精彩？
这是我一直苦苦思索，却无法找到答案的问题。
所谓的“成功”，有一定的规律可循吗？
如果说努力不一定可以成功，那么改变性格就一定可以改变命运吗？
你是一个很好的人，但你同时是一个很失败的人，这是可悲还是可笑？
十年总结（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，或者干脆什么都不要？
为此有过多少次的讨论和摩擦，并在冲撞中，互相妥协。
－－－
感觉老板们都是蛮会忽悠的，但老板们往往是寂寞的，他们比普通员工更渴望成功，
虽然很多老板的事业失败了，但我们不能因此而认为它们当初的承诺是骗人的。
在多数企业，市场和技术永远是矛盾体，老板都希望自己的公司有核心竞争力（技术），
眼睛紧盯的却是市场，其实在这一点上，老板也痛苦。
并不是说中国的老板不重视技术，因为每个公司都面临生存问题，挣钱生存下去才是第一位的，
人不是也一样吗，温饱问题解决不了，讲什么思想境界。
我没有当过真正的公司老板，所以认识粗浅的很，
这些是多年来站在老板身边，跟他做技术与市场斗争的过程中领悟的。
我说这些，是想得到如下一个结论：
老板的梦想，需要一个优秀的团队＋机遇＋努力才可能实现，
老板的上市计划失败了，并不一定是他故意忽悠人，他只是像我们一样，在鲤鱼跃龙门的时候，没有进入清华、北大而已。
十年总结（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个晚上，大家没法发现我经常凌晨发贴子吗？
我要回忆，我要有取舍，我还要注意行文的流畅，最重要的，我还要从中思考与总结。
我也不可能把所有的精力都来写这一个系列，我还得随时捕捉思想中的灵感，因为我目前的人生课题是“思考”。
这不是在写小说，各位担待啊。
十年总结（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种经典模式，我们尚且不能运用自如，
现在恨不得模式满天飞，大脑不是计算机，不擅长背诵，
当信息量超出我们的记忆能力的时候，这些信息是否有价值，甚至说是否有害？
重构其实也一样，你只需要记住这本书名《重构－改善既有代码的设计》和它改善代码的原则即可，
至于其中的上百种重构手段，没有天才的记忆力，就不必背诵了吧？
最后，说一句，养成良好的编程习惯很重要，不要因为你是在做试验而不注意代码的质量。 看过C#后
我觉得Java真恶心。
Java这门语言未来不会再有什么大的变化了，可能以后会被Scala取代。
页:
[1]
