软件工程师成长之旅2.doc

软件开发经验谈软件工程师成长之旅从事软件开发已有些年头，其间经历了各种各样的团队，见识了不少开发的方式和现象，这些经历或给人以一些失败的教训或给人以一些成功的经验，平时总忙于各种锁事的处理，没有什么时间到这个空间来溜溜，新年伊始，有点闲遐，简单的写写，但愿这些教训或经验能给正从事软件开发的同行们一点启发，或是当作一个故事看看。首先，作为软件开发的热爱者，我是肯定软件开发行业的从业价值的，至少在我看来这是一个不错的行业。但这个行业毕竟是一个重脑力劳动的行业，如果没有良好的心态和良好的学习惯在这行立足是比较困难的。我个人认为要成功为一个优秀的软件开发者需要从如下几个方面考虑。一、从事软件开发必须具备三个条件硬条件：（1）智力不宜太差我不敢说做软件不一定要有多聪明，但如果反应力不太好的，我认为从事这行是比较困难的，毕竟这是一个知识高速更新的行业，需要不停的学习。如果接受学习知识不能深入或是接受起来比较吃力是不太适合做软件开发的。（2）要有良好的心态和学习习惯一般来说，在绝大多公司做软件开发，都要求有相当全面的知识面，通常一个人从学校出来时所学的知识是远远不够，而且软件开发所需的知识表现为一个特点：通常熟悉或精通几个知识点是不足以体现出一个人的实力，它往往需要你日积月累掌握相当数量的知识点，最后才能表现出实力。所以，这就要求你必须不急不燥认真学习、实践相关的知识，当这种积累达到一定程度的时候你就会明显感觉实力有所增强，而这种实力增强的周期通常在半年到一年半，如果一个人没有相当的毅力和良好的心态，急于求成，学习的时候东一下西一下往往不能见成效，日子一久，就会逐渐丧失对知识、对技术的追求热情，最后不知不觉在竞争中被淘汰，或是处于很平常的状态。所以良好的心态和学习习惯是从事软件开发的第二个必备条件。（3）要善于总结和分析 软件开发所涉及的知识和方面是非常广泛的，包括行业领域知识和技术知识，以及为人处世等各方面的知识。而且软件行业的思想和门派也五花八门，我们如果见风跟风见雨跟雨，通常是行不通的，其实无论软件开发涉及多广泛的知识，但它始终跳不出一个基本出发点，那就是：它都是为了做好软件，获得经济效益。所以，在软件开发的过程中，只要我们认真根据具体情况，认真分析问题、积累解决问题的有效手段，一般来说在公司里生存都不会有太大的问题。而且这种积累越多，你就会发现良性循环的效益越大。如果不分析总结你可能会陷入失败再失败的恶性循环，即使你参与了一个成功开发的案例，往往也不知道之所以成功的原因，到哪天自己组织项目时还是感觉力不从心。对个人而言，无论是成功或失败的案例都是很宝贵的，失败的案例通常能提供给我们更多的教训，让我们在以后的软件开发中遇到类似问题时不再重蹈覆辙，甚至你从这些失败中提炼出了很有价值的问题，然后找到了很好的解决办法，直接就从失败中获得了经验。成功的案例直接就给你提供了很多有益的参考。所以成功和失败是辩证的，关键是看我们如何吸收它所蕴含的财富。二、软件开发成长的五个阶段从我本人及身边朋友的成长经历来看，我认为成为一个优秀的软件开发人员，应该要经历以下五个阶段的发展层次，否则，即使能在竞争中左右逢源，处处钻空子生存下去，起码这种生存方式不是所有人都能做到的，而且生存起来也不会很踏实。我不否认“天生一人必有一路”的说法，但我认为既然你有意在软件开发这行做下去，就应该认认真真的去做，不要总想着拉帮结伙，去获取人际斗争的渔人之利，这对个人和这个行业都不好，甚至可以说对这个国家的软件发展都不利。我比较主张走实力之路，所以以下的观点也基于这个立足点。（1）面向技术点阶段：我认为一个初入这个行业的程序员，由于知识技能与见识的不足，接受一些思想是比较困难的，如果这个时候去过多的关注一些思想，到头来可能会成为一个只能夸夸其谈而无实际用处的“吹水派”，到哪里做砸哪里的项目。而且这个时候，通常由于资历、经验的不足在团队中难以成为核心成员，即使你能做到“思想层面”，你也没有机会去实践。所以这个阶段的程序员，最好是踏踏实实把一些常用的技术点认真消化，深入理解，深入实践，为以后的发展积累良好的基础。对技术点的积累，你既要兼顾工作中的需要也要兼顾将来的发展，既不能完全被所在的环境束缚于一隅，也不能背离现实而一味追求知识面的扩张。你必须明白一个道理，只有工作相对愉快的前提下你才能有更高的学习效率，所以，首先要基本能把“工作上需要的能力”解决的情况下，才进行知识技能的扩张。其次，在这个阶段的程序员，因为技能的不足，通常会认为技能是最重要的，而忽略对业务的理解。其实，做好软件“技能”与“业务”都是相当重要的，缺一不可。技术的强势有时可以降低对业务的理解要求，同样，业务的强势有时也可以降低对技术的要求，有的时候很多东西本身就很难定性它是属于“业务问题”或是“技术问题”，所以总是去争论“业务”与“技术”的优劣是比较狭隘的。虽然我深知“业务”的重要性，但我个人认为，这个阶段的程序“相对忽略”对业务的理解，这是可以理解的，因为这个时候的程序员面临的最大问题通常技能不足。技能不解决，即使熟悉了业务也一样做不好，而且这个阶段的程序员，我认为还达不到会花很多精力关注业务的程度，所以对这个阶段的程序员，一些经验丰富的主力程序员，或是项目LEADER有认真指导其工作的义务（注意是义务而不是权力）。但现实中的很多LEADER或是经验丰富的程序员往往出于个人水平的不足，无法给予相应的指导，或是由于利益关系不愿意指导，这就是现实。所以这个阶段的程序员要有面对这种矛盾的心理准备，尽一切办法渡过这个难关，尽量处理好“业务”与“技术”的关系，可以通过加强对业务的理解来“适当弥补”技术上的不足，或是找到其它更好的方法来处理这些问题。其实，我不是很主张这个阶段的程序把主要精力花在业务上，还有一个很重要的因素，这个因素“可能”甚至是“一定”会给公司的发展带来难以处理的“后遗症”，关于这个话题，我暂时就不再这里阐述了。 另外，知识技能的积累发展，通常也有一个过程，我把这个过程归纳为“想到(理论水平)能做到(可能水平)做到(极限实战水平)熟练做到(常态水平)”。对于很多常用的知识，只有达到“常态水平”才有实际意义，所以在学习、实践的过程中要注意体会、总结知识的应用特性，把那些需要达到常态水平的知识提炼出来，加强理解和运用，力争达到熟练状态，甚至“幻化自如”的境界。 这里，我想提醒大家一句：我们学习技术应站在表演者的角度去学习，而不是观众的角度去学习，表演者是需要真枪实弹上阵的，是要对后果负责的，而观众只是听听，看看，说说，当当评论家而矣，通常不需要对后果承担责任。我个人认为这种意识相当重要，它能让你对事情负责、对公司负责、对自己负责、对过去负责、对现在负责、对未来负责。我强调这种责任心，绝不是简单的“文字游戏”，而是切身体会到：多角度、多方位去想想自己的责任，你在进行学习的时候，就会有更加明确的指导思想，知道事情的轻重缓急，更加合理的安排学习内容和进度。最后，关于学习方法，我想强调一点：俗话说“学海无涯”，特别是软件开发这行，也可以算得上“博大精深”，我个人认为，应该以“如何能更有效的掌握知识，就如何去做”为主要指导思想，这样才能加速知识的学习进度。比如说，对你所在的环境而言，你向别人请教，能比你自己去研究更有效，你就应该优先考虑向别人请教，而不是放不下面子，自己花大量时间研究。如果你认为看书比看电子文档更有效，你就应该投点资买本书来看，而不是吝啬几十元钱，。如果你能认同这种“指导思想”，我可以很肯定的说，至少你能克服性格的上的缺陷，不是性格完全决定你的行为方式，而是自已主动根据需要去改变自己的行为方式，并且做事的时候也更能把握主次，懂得如何取舍(比如：你舍点“面子”取得的是“知识”，你舍点“钱”取得的是“更好的学习效率”)。（2）面向框架阶段当软件技能发展到一定阶段的时候，你会发现要做好一个项目往往不是有足够的技术点就能成功的。这个时候你会发现一个东西即使做出来了，也还有质量高低之分，质量高低在维护修改时，就能明显体现出来。然后你会关注如何写代码，如何让代码结构良好工整，如果不出意外，通常你会开始进行结构研究，最后过渡到框架。在达到这个阶段后，你就已经完成了从“只管做出来”，到关注“如何做比较好”的升级。这个阶段你大致会接触设计模式、组件化编程这样一些理念，并在思想和形式上有不同程度的运用，并且这个时候你基本上够格成为一个团队的主力了。（3）面向团队阶段当你在技能上趋于成熟，框架上趋于成形的时候，你自然会想大家都按你的成果来展开工作，这个时候你会发现很多的矛盾和冲突，你会发现，原来一个东西“自己会做”和“让别人也愿意这么做”之间有如此大的差距。如果你善于分析总结，你会发现，研究框架必须面向团队，它必须能易于接受，并真实的减少大家的工作量，对项目能起到实质性的推进。否则，可能你的框架仅仅是为技术而技术，不是过于做作而显复杂，就是过于简单而没有“包容变化”的能力。这个层次往往是很多程序员的瓶颈，到最后就此为止，而处于自认为“身怀绝技”却总“怀才不遇”的尴尬境地。并且这个时候的程序员在公司呆上比较长的时间后，往往会被提拔，这对公司来说是危险的，他们的技术能力通常会成为团队发展的瓶颈，之所以成为瓶颈，从根本原因来说，就是“他们的技术不具备团队特性，而他们的职位其实已经主要要求团队特性”，这样，致使他们的经验、技能无法对团队形成根本性的影响，无法满足团队建设的需要，最后只能通过一些低水平的手段，比如通过“拉帮结伙，排斥异已”、“死死捏住公司的重要资源，使公司形成对个人的绝对依赖，而不敢有所动作”，通过这样一些方法来求得生存，这对公司来说当然是极其危险的。目前很多公司之所以人员频繁流动，软件产品的维护成本极高，大多属于这种情况下发展起来的“乌众之众”，称其为团队，实在是对“团队”一词的诽谤。“团队”应该是能互相影响，互相提高，个人技能能比较顺利的转化为“其它成员（即团队）”的技能。这样的环境才算得上是团队。另外，能真正证明“技能”能对“团队”形成“根本性影响”的是代码，而不是一句句空话或是一些漂亮的文档、规范之类的东西。当然这不是说文档之类的东西就是没用的，而是说，只有当这些东西直接或间接的转化为代码了，才能真正说明这些东西是具有可行性，否则这种“可行性”就具有相当的不确定性，并且是难以评判其作用的。（4）面向问题阶段当你的技术在框架层面游弋一段时间后，你通常就会成一个经理、项目经理、或是技术Leader，这个时候你会发现，你手下会有很多不同种类的角色，面对项目“公说这么做，婆说那么做”争论不休。团队里人际关系也变得重要起来，对上要能交得了差，对下要能让大家认真做起来，这个时候，你不要昏了头，乱了分寸，如果让我告诉一点经验，那么我可以这样告诉你“面向问题”，把握最本质的东西，把问题找出来，找最有效的手段，解决最关键的问题，而不要为了运用技术或理念而争论不休，这个时候你要看所倡导的技术和理念是不是能有效解决问题？要解决的问题是不是有价值的？一切皆从问题起，无论用什么理念或技术，它一定是有目的的，如果它的目的和我们要解决的问题不一致，也就不用争论了。所以，找到“最有效的问题，最有效的解决手段”，才经得起实践的检验。这个有效性包括“我们的问题确立是否有效？技术或理念是否和我们的目标一致？我们的团队有没这种技术或理念的驾御能力？”，无论多么先进的东西，不管出于什么样的原因，只要它不能解决问题都是“废物”。“面向问题”不仅适用于软件开发，还适用于处理生活上其它很多事。其实，它有点类似于武侠书中的“见招拆招”，即无招，但并不等价于不懂招。关于“面象问题”我想再补充一点：如果已经拥有良好的“面象团队的框架”，那么“准确发现问题”远比解决问题重要。当然，这种情况并不是绝对的，有些时候“发现问题”和“解决问题”同等重要，甚至正好相反，比如：有些问题可能很明显，但我们没这方面的经验和资源来解决这些问题。不过，总的来说，我认为绝大部分时候“不能准确定位出问题”而引发的困难更多，诸如“开发人员能力不足、组织管理有问题、需求变化太大”之类的问题，以我个人经验来看，更多是问题定位不准确所致，比如说：“开发人员能力不足，究竟不足在哪里，能力不足究竟会产生什么具体的影响？组织管理有问题，究竟哪里组得有问题，哪里织得有问题，这么组这么织，究竟会具体影响到哪方面的结果? 对需求变化太快，也是一样的道理”。我认为，如果问题没找准，解决问题就是空话。（5）面向过程控制“面向过程控制”主要是分析事物发展的过程，总结事物的发展规律，并将这种规律团队化，然后又在团队的运用中，不停的发现问题，解决问题，逐步完善。从而达到“吸百家之精化，众人之睿智，数年之经验”最终凝结成一套“有形、有意”的沉淀，并成为团队的财富，甚至社会的财富。这个层次可以说是前面几个层次的扩展，对前面所积累的能力、方法的综合运用。如果说“面向问题”主要是在“面向团队所形成的积累（框架）”的基础上见招拆招，针对管理过程中的“问题点”进行“点层面”上的补充和完善，那么“面向过程”则是对事物发展过程中所产生的问题进行更全面的分析，研究更全面、更具有普遍意义的解决问题的体系结构，而不是“点层面”的问题。要达到真正的“面向过程控制”，以我个人的经验来看，至少需要具备几个条件：n 丰富的实践经验要真正分析出事物的发展过程，总结出规律，如果不是“身经百战”仅从书本上学点东西，我想是很难真正分析得出有益的“过程”的。倘若一本书或几本书，就能让你分析出真正实用的过程，那我得想想是不是应该改行了，我都会向同行疾呼“技术是无用的东西，只能做奴隶，只能被人看不起，千万不要入行，入行的赶快改行”。这里，我罗嗦了一点，我是想强调实践经验的重要性。但并不是说书上写的是错误的。其实以我这些年的经验来看，很多书上写的，特别是大师级的书，都是正确的，但是这些东西，如果没有“非常丰富的实践经验”通常你很难真正理解它的正确性，更不用说合理运用了。n 成熟的思维模式以我个人经验来看，其实要达到“过程控制”这样一个层次，不是单纯总结、分析、实践就能完成的。我感觉，在潜识里还存在着很多东西都对你能否达到这样一个层次有所影响，只是程度不同而矣，比如：一个人的品行：你是务实之人，还是附势之徒？一个人的胆识：你是敢有见解之人，还是猥缩之流？一个人的魄力：你是敢作敢为之人，还是躲避责任的奸滑小人？我感觉这些“人性”可以不同程度决定你：求知热情、改过胸怀、执着毅力等一系列与技术成就密切相关的因素。我不是分析人性学的专家，但我能比较肯定的说，它们之间还是存在着某种因果联系。不过，有一些东西还是比较明确的，比如：一个人看问题能否很自然的切换观察角度（多方位观察）、是否有灵感发现问题的突破点等等，这些只是个人体验，我也就不过多分析，以免偏了主题。我能比较明确告诉大家的是：你应该养成一个习惯，多总结做事的方法，并让之达到“常态水平”，当你做事的时候，往“哪儿一站”，你就不由自主全面、综合的运用着很多经验（特别强调不是刻意），也就是“习惯成自然”的意思。很多好的方法、经验达到“习惯成自然”运用的时候，我认为你就具有了“成熟的思维模式”。当然要“习惯成自然”肯定先是从“刻意”开始。n 强劲的技术实力我已经说过了，软件是“思想”的一种表达形式，并且最终是以代码（计算机语言）的形式来表达，这也是所有表达形式中，无可争议的“最难、最详细”的表达形式。涉及的知识之多，之广，层次之繁，如果没有相当“强劲的技术实力”以及“研究能力”来“准确、高质、恰当”的表达“思想”，我想任何“思想”都可能是纸上谈兵。所以“强劲的技术实力和研究能力”，也就意味的“强劲、实用”的表达能力，也就意味着“高效的执行力”。n 有益的技术价值观 最后，我想强调一点，如果你不认同技术的价值或是看轻技术的价值，我想这些观点对你来说，最好不要看，否则，你会笑我“呆”，我也会感觉是在“对牛弹琴”。坦白地说，我相信一个不懂技术的人“通过借他人之力”是可能管好技术团队的，但我绝对不相信一个贬低、藐视技术价值的人能管理好技术团队。中国有句俗话“知已知彼，百战胜”，如果“贬低、藐视”技术，我们怎么能有那份兴趣、那份责任感去了解“技术人员的特点”？如果我们不了解技术人员的特点，我们又凭什么，拿什么去“百战百胜”？我们怎么能“管好事，理清事，用好人”？管理的重点是“管好事、理清事、用好人”，是“决策力”，而不是“监督力”，绝对不只是看别人做事! 。如果你没有决策能力但做了相应的管理职位，而且你也确实主要行使监督职责，我真的可以理解你。但如果你理所当然地认为管理的主要职能就是“监督”，就是看别人做事，然后指手划脚 ，我认为这很现实，但很荒唐。这就象当“二奶”很现实，如果冠冕堂皇的话，那就很荒唐。的确，在现在的中国，单纯的技术不能帮你赚到很多的钱，这是个事实，但我依然热爱它。我热爱技术，完全不代表我不理解其它的不同想法，甚至可以说我非常理解。所以，我不会因为自己喜欢技术或是技术比较别人好一点，就看不起别人，看不起那些对技术不以为然的人，当然“道不同不相为谋”，我也没必要一定要说服别人对技术的认可，事实最终会说明各自观点的优劣之处。“万物有异，容之则同，事无完美，容之则美”，这就象我不认同“监督型上司”，但我理解他们、包容他们，最后我们还是能在一起共事，甚至愉快的共事。这里我以一句有点文诌诌的话来结束此节，“天地苍苍，人渺渺，尔心虽大勿自傲，海纳百川乃为容，胸怀淡然人自高”。（6）小结本人现在只是致力于开发研究，也不太想脱离技术团队，所以纯商业层面和纯人际层面的东西就不再谈了。其实上面的很多思想和方法，不仅适用软件开发技术团队的管理，对其它方面的管理都是有用的，甚至对其它行业的团队管理都有相当的参考价值。并且从上面的第三个层次开始，就应该形成：n 一个可执行的框架（即以代码来表意的框架）我已经无数次强调过“人的意思(或思想)在软件这行，最终都会以代码的形式来表达”。如果仅有一些文档，我都可以肯定的说“此事未完，此事尚无法严格证明其可行性、正确性”，它的“执行力”比较差的可能性非常大，以我的经验来判断，我基本可以这样下一个定律：“越接近代码的表达方式（如果正确的话），它的执行力越高，越远离代码的表达方式，它执行的难度越高，出问题的可能性越大，执行力也就越差”，比如“正确的伪代码”通常比“正确的其它类型文档”执行效率高，“正确的算法流程图”通常比“正确的说明性文字”执行效率高，因为前者都比后者更接近代码。这里，我并不是要排斥文档，我只是想说明，不能因为“文档表意”的“重要性”，而否定“代码表意”的“更重要性”。一些宏观结构用文档表达肯定更好，它有利于我们理解系统，但它基本不代表任何执行力。一个比较良好的可执行框架，至少应具有以下几个特征： 面向团队的，基于“使用者”的感受来研究（第三层应该达到的）。 以“面向问题的思维模式”作为重要的补充思想（第四层应该达到的）使其在针对特殊问题上更加完善。 涵盖常用、普遍的过程使其更加体系化。 涵盖常用的技术点，使团队的“代码表达技能”有一个中心，并可在这个中心的基础上，不停的积累完善，从而使“常用技术点”的积累也形成一个“可持续的体系结构”。而这个“可持续的体系结构”是由“过程”来形成结构，在这个基础上使技术点的积累体系化。当然，这只是解决“常用技术点”的一种方法，但并不是解决所有技术点的方法。n 一个合适的培训体系一个良好的经验积累（不管以代码来表达，还是以文档来表达，或是两者皆有）通常都是某个经验丰富的人创造出来，然后经历若干人的共同努力使之完善，它所包含的知识范围和经验值一般来说都有一定的复杂性和广泛性。所以，如果没相当有效的培训方法，