《软件工程师成长之旅.doc》由会员分享，可在线阅读，更多相关《软件工程师成长之旅.doc（15页珍藏版）》请在金锄头文库上搜索。
1、软件工程师成长之旅从事软件开发已有些年头，其间经历了各种各样的团队，见识了不少开发的方式和现象，这些经历或给人以一些失败的教训或给人以一些成功的经验，平时总忙于各种锁事的处理，没有什么时间到这个空间来溜溜，新年伊始，有点闲遐，简单的写写，但愿这些教训或经验能给正从事软件开发的同行们一点启发，或是当作一个故事看看。首先，作为软件开发的热爱者，我是肯定软件开发行业的从业价值的，至少在我看来这是一个不错的行业。但这个行业毕竟是一个重脑力劳动的行业，如果没有良好的心态和良好的学习惯在这行立足是比较困难的。我个人认为要成功为一个优秀的软件开发者需要从如下几个方面考虑。一、从事软件开发必须具备三个条件硬条
2、件：（1）智力不宜太差我不敢说做软件不一定要有多聪明，但如果反应力不太好的，我认为从事这行是比较困难的，毕竟这是一个知识高速更新的行业，需要不停的学习。如果接受学习知识不能深入或是接受起来比较吃力是不太适合做软件开发的。（2）要有良好的心态和学习习惯一般来说，在绝大多公司做软件开发，都要求有相当全面的知识面，通常一个人从学校出来时所学的知识是远远不够，而且软件开发所需的知识表现为一个特点：通常熟悉或精通几个知识点是不足以体现出一个人的实力，它往往需要你日积月累掌握相当数量的知识点，最后才能表现出实力。所以，这就要求你必须不急不燥认真学习、实践相关的知识，当这种积累达到一定程度的时候你就会明显感
3、觉实力有所增强，而这种实力增强的周期通常在半年到一年半，如果一个人没有相当的毅力和良好的心态，急于求成，学习的时候东一下西一下往往不能见成效，日子一久，就会逐渐丧失对知识、对技术的追求热情，最后不知不觉在竞争中被淘汰，或是处于很平常的状态。所以良好的心态和学习习惯是从事软件开发的第二个必备条件。（3）要善于总结和分析 软件开发所涉及的知识和方面是非常广泛的，包括行业领域知识和技术知识，以及为人处世等各方面的知识。而且软件行业的思想和门派也五花八门，我们如果见风跟风见雨跟雨，通常是行不通的，其实无论软件开发涉及多广泛的知识，但它始终跳不出一个基本出发点，那就是：它都是为了做好软件，获得经济效益。
4、所以，在软件开发的过程中，只要我们认真根据具体情况，认真分析问题、积累解决问题的有效手段，一般来说在公司里生存都不会有太大的问题。而且这种积累越多，你就会发现良性循环的效益越大。如果不分析总结你可能会陷入失败再失败的恶性循环，即使你参与了一个成功开发的案例，往往也不知道之所以成功的原因，到哪天自己组织项目时还是感觉力不从心。对个人而言，无论是成功或失败的案例都是很宝贵的，失败的案例通常能提供给我们更多的教训，让我们在以后的软件开发中遇到类似问题时不再重蹈覆辙，甚至你从这些失败中提炼出了很有价值的问题，然后找到了很好的解决办法，直接就从失败中获得了经验。成功的案例直接就给你提供了很多有益的参考。
5、所以成功和失败是辩证的，关键是看我们如何吸收它所蕴含的财富。二、软件开发成长的五个阶段从我本人及身边朋友的成长经历来看，我认为成为一个优秀的软件开发人员，应该要经历以下五个阶段的发展层次，否则，即使能在竞争中左右逢源，处处钻空子生存下去，起码这种生存方式不是所有人都能做到的，而且生存起来也不会很踏实。我不否认“天生一人必有一路”的说法，但我认为既然你有意在软件开发这行做下去，就应该认认真真的去做，不要总想着拉帮结伙，去获取人际斗争的渔人之利，这对个人和这个行业都不好，甚至可以说对这个国家的软件发展都不利。我比较主张走实力之路，所以以下的观点也基于这个立足点。（1）面向技术点阶段：我认为一个初入
6、这个行业的程序员，由于知识技能与见识的不足，接受一些思想是比较困难的，如果这个时候去过多的关注一些思想，到头来可能会成为一个只能夸夸其谈而无实际用处的“吹水派”，到哪里做砸哪里的项目。而且这个时候，通常由于资历、经验的不足在团队中难以成为核心成员，即使你能做到“思想层面”，你也没有机会去实践。所以这个阶段的程序员，最好是踏踏实实把一些常用的技术点认真消化，深入理解，深入实践，为以后的发展积累良好的基础。对技术点的积累，你既要兼顾工作中的需要也要兼顾将来的发展，既不能完全被所在的环境束缚于一隅，也不能背离现实而一味追求知识面的扩张。你必须明白一个道理，只有工作相对愉快的前提下你才能有更高的学习效
7、率，所以，首先要基本能把“工作上需要的能力”解决的情况下，才进行知识技能的扩张。其次，在这个阶段的程序员，因为技能的不足，通常会认为技能是最重要的，而忽略对业务的理解。其实，做好软件“技能”与“业务”都是相当重要的，缺一不可。技术的强势有时可以降低对业务的理解要求，同样，业务的强势有时也可以降低对技术的要求，有的时候很多东西本身就很难定性它是属于“业务问题”或是“技术问题”，所以总是去争论“业务”与“技术”的优劣是比较狭隘的。虽然我深知“业务”的重要性，但我个人认为，这个阶段的程序“相对忽略”对业务的理解，这是可以理解的，因为这个时候的程序员面临的最大问题通常技能不足。技能不解决，即使熟悉了业
8、务也一样做不好，而且这个阶段的程序员，我认为还达不到会花很多精力关注业务的程度，所以对这个阶段的程序员，一些经验丰富的主力程序员，或是项目LEADER有认真指导其工作的义务（注意是义务而不是权力）。但现实中的很多LEADER或是经验丰富的程序员往往出于个人水平的不足，无法给予相应的指导，或是由于利益关系不愿意指导，这就是现实。所以这个阶段的程序员要有面对这种矛盾的心理准备，尽一切办法渡过这个难关，尽量处理好“业务”与“技术”的关系，可以通过加强对业务的理解来“适当弥补”技术上的不足，或是找到其它更好的方法来处理这些问题。其实，我不是很主张这个阶段的程序把主要精力花在业务上，还有一个很重要的因素
9、，这个因素“可能”甚至是“一定”会给公司的发展带来难以处理的“后遗症”，关于这个话题，我暂时就不再这里阐述了。 另外，知识技能的积累发展，通常也有一个过程，我把这个过程归纳为“想到(理论水平)能做到(可能水平)做到(极限实战水平)熟练做到(常态水平)”。对于很多常用的知识，只有达到“常态水平”才有实际意义，所以在学习、实践的过程中要注意体会、总结知识的应用特性，把那些需要达到常态水平的知识提炼出来，加强理解和运用，力争达到熟练状态，甚至“幻化自如”的境界。 这里，我想提醒大家一句：我们学习技术应站在表演者的角度去学习，而不是观众的角度去学习，表演者是需要真枪实弹上阵的，是要对后果负责的，而观众
10、只是听听，看看，说说，当当评论家而矣，通常不需要对后果承担责任。我个人认为这种意识相当重要，它能让你对事情负责、对公司负责、对自己负责、对过去负责、对现在负责、对未来负责。我强调这种责任心，绝不是简单的“文字游戏”，而是切身体会到：多角度、多方位去想想自己的责任，你在进行学习的时候，就会有更加明确的指导思想，知道事情的轻重缓急，更加合理的安排学习内容和进度。最后，关于学习方法，我想强调一点：俗话说“学海无涯”，特别是软件开发这行，也可以算得上“博大精深”，我个人认为，应该以“如何能更有效的掌握知识，就如何去做”为主要指导思想，这样才能加速知识的学习进度。比如说，对你所在的环境而言，你向别人请教
11、，能比你自己去研究更有效，你就应该优先考虑向别人请教，而不是放不下面子，自己花大量时间研究。如果你认为看书比看电子文档更有效，你就应该投点资买本书来看，而不是吝啬几十元钱，。如果你能认同这种“指导思想”，我可以很肯定的说，至少你能克服性格的上的缺陷，不是性格完全决定你的行为方式，而是自已主动根据需要去改变自己的行为方式，并且做事的时候也更能把握主次，懂得如何取舍(比如：你舍点“面子”取得的是“知识”，你舍点“钱”取得的是“更好的学习效率”)。（2）面向框架阶段当软件技能发展到一定阶段的时候，你会发现要做好一个项目往往不是有足够的技术点就能成功的。这个时候你会发现一个东西即使做出来了，也还有质量
12、高低之分，质量高低在维护修改时，就能明显体现出来。然后你会关注如何写代码，如何让代码结构良好工整，如果不出意外，通常你会开始进行结构研究，最后过渡到框架。在达到这个阶段后，你就已经完成了从“只管做出来”，到关注“如何做比较好”的升级。这个阶段你大致会接触设计模式、组件化编程这样一些理念，并在思想和形式上有不同程度的运用，并且这个时候你基本上够格成为一个团队的主力了。（3）面向团队阶段当你在技能上趋于成熟，框架上趋于成形的时候，你自然会想大家都按你的成果来展开工作，这个时候你会发现很多的矛盾和冲突，你会发现，原来一个东西“自己会做”和“让别人也愿意这么做”之间有如此大的差距。如果你善于分析总结，
13、你会发现，研究框架必须面向团队，它必须能易于接受，并真实的减少大家的工作量，对项目能起到实质性的推进。否则，可能你的框架仅仅是为技术而技术，不是过于做作而显复杂，就是过于简单而没有“包容变化”的能力。这个层次往往是很多程序员的瓶颈，到最后就此为止，而处于自认为“身怀绝技”却总“怀才不遇”的尴尬境地。并且这个时候的程序员在公司呆上比较长的时间后，往往会被提拔，这对公司来说是危险的，他们的技术能力通常会成为团队发展的瓶颈，之所以成为瓶颈，从根本原因来说，就是“他们的技术不具备团队特性，而他们的职位其实已经主要要求团队特性”，这样，致使他们的经验、技能无法对团队形成根本性的影响，无法满足团队建设的需
14、要，最后只能通过一些低水平的手段，比如通过“拉帮结伙，排斥异已”、“死死捏住公司的重要资源，使公司形成对个人的绝对依赖，而不敢有所动作”，通过这样一些方法来求得生存，这对公司来说当然是极其危险的。目前很多公司之所以人员频繁流动，软件产品的维护成本极高，大多属于这种情况下发展起来的“乌众之众”，称其为团队，实在是对“团队”一词的诽谤。“团队”应该是能互相影响，互相提高，个人技能能比较顺利的转化为“其它成员（即团队）”的技能。这样的环境才算得上是团队。另外，能真正证明“技能”能对“团队”形成“根本性影响”的是代码，而不是一句句空话或是一些漂亮的文档、规范之类的东西。当然这不是说文档之类的东西就是没
15、用的，而是说，只有当这些东西直接或间接的转化为代码了，才能真正说明这些东西是具有可行性，否则这种“可行性”就具有相当的不确定性，并且是难以评判其作用的。（4）面向问题阶段当你的技术在框架层面游弋一段时间后，你通常就会成一个经理、项目经理、或是技术Leader，这个时候你会发现，你手下会有很多不同种类的角色，面对项目“公说这么做，婆说那么做”争论不休。团队里人际关系也变得重要起来，对上要能交得了差，对下要能让大家认真做起来，这个时候，你不要昏了头，乱了分寸，如果让我告诉一点经验，那么我可以这样告诉你“面向问题”，把握最本质的东西，把问题找出来，找最有效的手段，解决最关键的问题，而不要为了运用技术
16、或理念而争论不休，这个时候你要看所倡导的技术和理念是不是能有效解决问题？要解决的问题是不是有价值的？一切皆从问题起，无论用什么理念或技术，它一定是有目的的，如果它的目的和我们要解决的问题不一致，也就不用争论了。所以，找到“最有效的问题，最有效的解决手段”，才经得起实践的检验。这个有效性包括“我们的问题确立是否有效？技术或理念是否和我们的目标一致？我们的团队有没这种技术或理念的驾御能力？”，无论多么先进的东西，不管出于什么样的原因，只要它不能解决问题都是“废物”。“面向问题”不仅适用于软件开发，还适用于处理生活上其它很多事。其实，它有点类似于武侠书中的“见招拆招”，即无招，但并不等价于不懂招。关于“面象问题”我想再补充一点：如果已经拥有良好的“面象团队的框架”，那么“准确发现问题”远比解决问题重要。当然，这种情况并不是绝对的，有些时候“发现问题”和“解决问题”同等重要，甚至正好相反，比如：有些问题可能很明显，但我们没这方面的经验和资
