﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-mulinka-文章分类-感　　悟</title><link>http://www.blogjava.net/mulinka/category/2072.html</link><description>踏实肯干，不可眼高手低</description><language>zh-cn</language><lastBuildDate>Thu, 01 Mar 2007 11:18:40 GMT</lastBuildDate><pubDate>Thu, 01 Mar 2007 11:18:40 GMT</pubDate><ttl>60</ttl><item><title>从Coding Fan到真正的技术专家（转载）</title><link>http://www.blogjava.net/mulinka/articles/7758.html</link><dc:creator>魔之卡卡</dc:creator><author>魔之卡卡</author><pubDate>Fri, 15 Jul 2005 03:15:00 GMT</pubDate><guid>http://www.blogjava.net/mulinka/articles/7758.html</guid><wfw:comment>http://www.blogjava.net/mulinka/comments/7758.html</wfw:comment><comments>http://www.blogjava.net/mulinka/articles/7758.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/mulinka/comments/commentRss/7758.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/mulinka/services/trackbacks/7758.html</trackback:ping><description><![CDATA[此文转载自cjsdn,不过没有著名原作者-_-b<BR><BR>以下文章都是经典，看不看随你的便，我只希望知识掌握在更多中国人的手里！<BR><BR>中国有很多小朋友，他们18,9岁或21,2岁，通过自学也写了不少代码，他们有的代码写的很漂亮，一些技术细节相当出众，也很有钻研精神，但是他们被一些错误的认识和观点左右，缺乏对系统，对程序的整体理解能力，这些人，一个网上的朋友说得很好，他们实际上只是一些Coding fans，压根没有资格称为程序员，但是据我所知，不少小网络公司的CTO就是这样的coding fans,拿着吓人的工资，做着吓人的项目，项目的结局通常也很吓人。 <BR>程序员基本素质： <BR><BR>作一个真正合格的程序员，或者说就是可以真正合格完成一些代码工作的程序员，应该具有的素质。 <BR><BR>1：团队精神和协作能力 <BR>把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人就完全不合格了。 <BR><BR>2：文档习惯 <BR>说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。 <BR><BR>3：规范化，标准化的代码编写习惯 <BR>作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。 <BR>有些coding fans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。 <BR>再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可想象的。 <BR>4：需求理解能力 <BR>程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑，有人曾经放言说写一个广告交换程序很简单，这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也做不出太极链的并访能力。性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。 <BR><BR>5：复用性，模块化思维能力 <BR>经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成了熟练程序员的主要工作，而这些，其实是完全可以避免的。 <BR>复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投入到创新的代码工作中去。 <BR>一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部代码重写，大部分重复性工作无谓的浪费了时间和精力。 <BR><BR>6：测试习惯 <BR>作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。 <BR>测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试并尽早发现和解决问题，当然这需要上面提到的需求理解能力。 <BR><BR>7：学习和总结的能力 <BR>程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。 <BR>善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。但是学习也要找对目标，一些小coding fans们，他们也津津乐道于他们的学习能力，一会学会了asp，一会儿学会了php，一会儿学会了jsp，他们把这个作为炫耀的资本，盲目的追逐一些肤浅的，表面的东西和名词，做网络程序不懂通讯传输协议，做应用程序不懂中断向量处理，这样的技术人员，不管掌握了多少所谓的新语言，永远不会有质的提高。 <BR>善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，这样逐步提高，一个程序员才可能成长起来。 <BR>一个不具备成长性的程序员，即便眼前看是个高手，建议也不要选用，因为他落伍的时候马上就到了。 <BR>具备以上全部素质的人，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决定的，也不是大学某些课本里可以学习到的，需要的仅仅是程序员对自己工作的认识，是一种意识上的问题。<BR><BR>那么作为高级程序员，以至于系统分析员，也就是对于一个程序项目的设计者而言，除了应该具备上述全部素质之外，还需要具备以下素质： <BR><BR>第一，需求分析能力 <BR>对于程序员而言，理解需求就可以完成合格的代码，但是对于研发项目的组织和管理者，他们不但要理解客户需求，更多时候还要自行制定一些需求，为什么这么说呢？ <BR>一般而言，进行研发任务，也许是客户提出需求，也许是市场和营销部门提出的需求，这时候对于研发部门，他们看到的不是一个完整的需求，通常而言，该需求仅仅是一些功能上的要求，或者更正规些，可能获得一个完整的用户视图；但是这都不够，因为客户由于非技术因素多一些，他们可能很难提出完整和清晰，或者说专业性的性能需求，但是对于项目组织者和规划者，他必须能够清醒认识到这些需求的存在并在完成需求分析报告的时候适当的提出，同时要完整和清晰的体现在设计说明书里面，以便于程序员编码时不会失去这些准则。 <BR>程序设计者必须正确理解用户需求所处的环境，并针对性做出需求的分析，举例而言，同样一个软件通过ASP租用方式发布和通过License方式发布，性能需求可能就是有区别的，前者强调的是更好的支撑能力和稳定性，而后者则可能更强调在各种平台下的普适性和安装使用的简捷性。 <BR><BR>第二，项目设计方法和流程处理能力 <BR>程序设计者必须能够掌握不少于两到三种的项目设计方法（比如自顶至下的设计方法，比如快速原型法等等），并能够根据项目需求和资源搭配来选择合适的设计方法进行项目的整体设计。设计方法上选择不当，就会耽误研发周期，浪费研发资源，甚至影响研发效果。 <BR>一个程序设计者还需要把很多功夫用在流程图的设计和处理上，他需要做数据流图以确立数据词典；他需要加工逻辑流图以形成整体的系统处理流程。一个流程有问题的系统，就算代码多漂亮，每个模块多精致，也不会成为一个好的系统。当然，做好流程分析并选择好项目设计方法，都需要在需求分析能力上具有足够的把握。 <BR><BR>第三，复用设计和模块化分解能力 <BR>这个似乎又是老调重谈，前面基本素质上不是已经说明了这个问题吗？ <BR>作为一个从事模块任务的程序员，他需要对他所面对的特定功能模块的复用性进行考虑，而作为一个系统分析人员，他要面对的问题复杂的多，需要对整体系统按照一种模块化的分析能力分解为很多可复用的功能模块和函数，并针对每一模块形成一个独立的设计需求。举个例子，好比是汽车生产，最早每辆汽车都是独立安装的，每个部件都是量身定做的，但是后来不一样了，机器化大生产了，一个汽车厂开始通过流水线来生产汽车，独立部件开始具有一定的复用性，在后来标准化成为大趋势，不同型号，品牌甚至不同厂商的汽车部件也可以进行方便的换装和升级，这时候，汽车生产的效率达到最大化。软件工程也是同样的道理，一个成熟的软件行业，在一些相关项目和系统中，不同的部件是可以随意换装的，比如微软的许多桌面软件，在很多操作模块（如打开文件，保存文件等等）都是复用的同一套功能模块，而这些接口又通过一些类库提供给了桌面应用程序开发者方便挂接，这就是复用化的模块设计明显的一个佐证。 <BR>将一个大型的，错综复杂的应用系统分解成一些相对独立的，具有高度复用性的，并能仅仅依靠几个参数完成数据联系的模块组合，是作为高级程序员和系统分析员一项最重要的工作，合适的项目设计方法，清晰的流程图，是实现这一目标的重要保证。 <BR><BR>第四，整体项目评估能力 <BR>作为系统设计人员，必须能够从全局出发，对项目又整体的清醒认识，比如公司的资源配置是否合理和到位，比如工程进度安排是否能最大化体现效率又不至于无法按期完成。评估项目整体和各个模块的工作量，评估项目所需的资源，评估项目可能遇到的困难，都需要大量的经验积累，换言之，这是一种不断总结的累计才能达到的境界。在西方一些软件系统设计的带头人都是很年长的，比如4，50岁，甚至更老，他们在编码方面已经远远不如年轻人那样活络，但是就项目评估而言，他们几十年的经验积累就是最重要和宝贵的财富。中国缺这么一代程序员，主要还不是缺那种年纪的程序员，而是那种年纪的程序员基本上都是研究单位作出来的，都不是从专业的产品化软件研发作出来的，他们没有能积累那种产品化研发的经验，这也是没有办法的事情。 <BR>第五，团队组织管理能力 <BR>完成一个项目工程，需要团队的齐心协力，作为项目设计者或研发的主管人，就应当有能力最大化发挥团队的整体力量，技术管理由于其专业性质，不大同于一般的人事管理，因为这里面设计了一些技术性的指标和因素。 <BR>首先是工作的量化，没有量化就很难做到合适的绩效考核，而程序量化又不是简单的代码行数可以计算的，因此要求技术管理人员需要能真正评估一个模块的复杂性和工作量。 <BR>其次是对团队协作模式的调整，一般而言，程序开发的协作通常分为小组进行，小组有主程序员方式的，也有民主方式的，根据程序员之间的能力水平差距，以及根据项目研发的需求，选择合适的组队方式，并能将责权和成员的工作任务紧密结合，这样才能最大发挥组队的效率。 <BR>一个代码水平高的人，未必能成为一个合格的项目研发主管，这方面的能力欠缺往往是容易被忽视的。 <BR><BR>综上可以看到，作为一个主管研发的负责人，一个项目设计者，所需要具备的素质和能力并不是程序代码编写的能力，当然一般情况下，一个程序员通过不断的总结提高达到了这种素质的时候，他所具有的代码编写能力也已经相当不简单了，但是请注意这里面的因果关系，一个高水平的项目设计者通常已经是代码编写相当优秀的人了，但是并不是一个代码相当优秀的程序员就可以胜任项目设计的工作，这里面存在的也不是智商和课本的问题，还是在于一个程序员在积累经验，逐步提升的时候没有意识到应当思考哪方面的东西，没有有意识的就项目的组织和复用设计进行揣摩，没有经常性的文档习惯和总结习惯，不改变这些，我们的合格的项目设计者还是非常欠缺。 <BR><BR>另外，为防止有无聊的人和我较真，补充一点，本文针对目标是作商业化的软件项目和工程，那些科研机构的编程高手，比如算法高手，比如图象处理高手，他们的工作是研究课题而非直接完成商业软件（当然最终间接成为商业产品，比如微软研究院在作的研究课题），因此他们强调的素质可能是另外的东西，这些人（专家），并不能说是程序员，不能用程序员的标准去衡量。 <BR><BR>最后补充一点东西，一个软件项目研发的设计流程是怎样的呢？以通常标准的设计方法为例，（不过笔者喜欢快速原型法）。 <BR><BR>第一个步骤是市场调研，技术和市场要结合才能体现最大价值。 <BR><BR>第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了很多操作方面的流程和条件。数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。用户操作手册是指明了操作流程的说明书。请注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。 <BR>需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有真正的沟通和了解。 <BR><BR>第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要重新进行详细设计的步骤。 <BR>第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软件系统在完成了一半的时候，其实还没有开始一行代码工作。那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。 <BR><BR>第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！ <BR><BR>第六个步骤是测试 <BR>测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。 <BR>总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。 <BR>完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，知道这个软件被彻底淘汰为止。 <BR><BR>写这些步骤算不上卖弄什么，因为实话讲我手边是一本《软件工程》，在大学里这是计算机专业的必修课程，但是我知道很多程序员似乎从来都只是热衷于什么《30天精通VC》之类的，他们有些和我一样游击队出身，没有正规学过这个专业，还有一些则早就在混够学分后就把这些真正有用的东西还给了老师。 <BR><BR>网上现在也很浮躁，一些coding fans乱嚷嚷，混淆视听，实际上真正的技术专家很少在网上乱发帖子的，如笔者这样不知天高地厚的，其实实在是算不上什么高手，只不过看不惯这种对技术，对程序员的误解和胡说，只好挺身而出，做拨乱反正之言，也希望那些还沉迷于一些错误人士的coding fans们能认真想想，走到正途上，毕竟那些聪明的头脑还远远没有发挥应有的价值。<img src ="http://www.blogjava.net/mulinka/aggbug/7758.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/mulinka/" target="_blank">魔之卡卡</a> 2005-07-15 11:15 <a href="http://www.blogjava.net/mulinka/articles/7758.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>怎样成为优秀的软件模型设计者？（转栽）</title><link>http://www.blogjava.net/mulinka/articles/7751.html</link><dc:creator>魔之卡卡</dc:creator><author>魔之卡卡</author><pubDate>Fri, 15 Jul 2005 03:01:00 GMT</pubDate><guid>http://www.blogjava.net/mulinka/articles/7751.html</guid><wfw:comment>http://www.blogjava.net/mulinka/comments/7751.html</wfw:comment><comments>http://www.blogjava.net/mulinka/articles/7751.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/mulinka/comments/commentRss/7751.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/mulinka/services/trackbacks/7751.html</trackback:ping><description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;原作者:Scott Ambler <BR>&nbsp;&nbsp;&nbsp; 我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？&nbsp; <BR><BR>将下列原则应用到你的软件工程中，你会获得立杆见影的成果。&nbsp; <BR><BR>1. 人远比技术重要&nbsp; <BR><BR>你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。&nbsp; <BR><BR>2. 理解你要实现的东西&nbsp; <BR><BR>好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。&nbsp; <BR><BR>3. 谦虚是必须的品格&nbsp; <BR><BR>你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件 开发的人来说，每天可以学习很多新东西（如果愿意的话）。&nbsp; <BR><BR>4. 需求就是需求&nbsp; <BR><BR>如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。&nbsp; <BR><BR>5. 需求其实很少改变，改变的是你对需求的理解&nbsp; <BR><BR>Object ToolSmiths 公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的 “正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想 象力 - 译者注）。&nbsp; <BR><BR>如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。&nbsp; <BR><BR>你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。&nbsp; <BR><BR>你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。&nbsp; <BR><BR>如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。&nbsp; <BR><BR>你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。&nbsp; <BR><BR>你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？&nbsp; <BR><BR>需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。&nbsp; <BR><BR>6. 经常阅读&nbsp; <BR><BR>在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。&nbsp; <BR><BR>每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。&nbsp; <BR><BR>7. 降低软件模块间的耦合度&nbsp; <BR><BR>高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。&nbsp; <BR><BR>你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。&nbsp; <BR><BR>耦合度低的软件可以很容易被重用、维护和扩充。&nbsp; <BR><BR>8. 提高软件的内聚性&nbsp; <BR><BR>如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。&nbsp; <BR><BR>判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。&nbsp; <BR><BR>只有高内聚性的模块才可能被重用。&nbsp; <BR><BR>9. 考虑软件的移植性&nbsp; <BR><BR>移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many ? 译者注）。&nbsp; <BR><BR>即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。&nbsp; <BR><BR>记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。&nbsp; <BR><BR>好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。&nbsp; <BR><BR>10. 接受变化&nbsp; <BR><BR>这是一句老话了：唯一不变的只有变化。&nbsp; <BR><BR>你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999）&nbsp; <BR><BR>通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。&nbsp; <BR><BR>11. 不要低估对软件规模的需求&nbsp; <BR><BR>Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。&nbsp; <BR><BR>今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。&nbsp; <BR><BR>在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。&nbsp; <BR><BR>在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。&nbsp; <BR><BR>12. 性能仅仅是很多设计因素之一&nbsp; <BR><BR>关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。&nbsp; <BR><BR>但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。&nbsp; <BR><BR>13. 管理接口&nbsp; <BR><BR>“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。&nbsp; <BR><BR>这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。&nbsp; <BR><BR>从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。&nbsp; <BR><BR>14. 走近路需要更长的时间&nbsp; <BR><BR>在软件开发中没有捷径可以走。&nbsp; <BR><BR>缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。&nbsp; <BR><BR>在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。&nbsp; <BR><BR>你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。&nbsp; <BR><BR>避免走捷径，只做一次但要做对（do it once by doing it right）。&nbsp; <BR><BR>15. 别信赖任何人&nbsp; <BR><BR>产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。&nbsp; <BR><BR>大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。&nbsp; <BR><BR>大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。&nbsp; <BR><BR>大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。&nbsp; <BR><BR>只有良好的沟通才能解决这些问题。&nbsp; <BR><BR>要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。&nbsp; <BR><BR>16. 证明你的设计在实践中可行&nbsp; <BR><BR>在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。&nbsp; <BR><BR>你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。&nbsp; <BR><BR>17. 应用已知的模式&nbsp; <BR><BR>目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。&nbsp; <BR><BR>一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。&nbsp; <BR><A class=embed_link href="http://www.ambysoft.com/processPatternsPage.html" target=_blank>http://www.ambysoft.com/processPatternsPage.html</A> 收藏了许多开发模式的信息。&nbsp; <BR><BR>18. 研究每个模型的长处和弱点&nbsp; <BR><BR>目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建 模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。&nbsp; <BR><BR>19. 在现有任务中应用多个模型&nbsp; <BR><BR>当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。&nbsp; <BR><BR>当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。&nbsp; <BR><BR>程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。&nbsp; <BR><BR>20. 教育你的听众&nbsp; <BR><BR>你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。&nbsp; <BR><BR>教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。&nbsp; <BR><BR>另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。&nbsp; <BR><BR>21. 带工具的傻瓜还是傻瓜&nbsp; <BR><BR>你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。&nbsp; <BR><BR>使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用 它设计它支持的模型。&nbsp; <BR><BR>22. 理解完整的过程&nbsp; <BR><BR>好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。&nbsp; <BR><BR>软件开发是一个很复杂的过程，还记得《object-oriented software process》第36页的内容吗？除了编程、建模、测试等你擅长工作外，还有很多工作要做。&nbsp; <BR><BR>好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。&nbsp; <BR><BR>23. 常做测试，早做测试&nbsp; <BR><BR>如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。&nbsp; <BR><BR>建立一个技术原型供技术评审使用，以检验你的软件模型。&nbsp; <BR><BR>在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。&nbsp; <BR><BR>24. 把你的工作归档&nbsp; <BR><BR>不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。&nbsp; <BR><BR>25. 技术会变，基本原理不会&nbsp; <BR><BR>如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测 试，配置，面对风险，发布产品，管理工作人员等等。&nbsp; <BR><BR>软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。&nbsp; <BR><BR>以鸡汤开始，加入自己的蔬菜。然后，开始享受你自己的丰盛晚餐吧。<img src ="http://www.blogjava.net/mulinka/aggbug/7751.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/mulinka/" target="_blank">魔之卡卡</a> 2005-07-15 11:01 <a href="http://www.blogjava.net/mulinka/articles/7751.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>[转载]开发工程师人生之路</title><link>http://www.blogjava.net/mulinka/articles/7506.html</link><dc:creator>魔之卡卡</dc:creator><author>魔之卡卡</author><pubDate>Mon, 11 Jul 2005 07:04:00 GMT</pubDate><guid>http://www.blogjava.net/mulinka/articles/7506.html</guid><wfw:comment>http://www.blogjava.net/mulinka/comments/7506.html</wfw:comment><comments>http://www.blogjava.net/mulinka/articles/7506.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/mulinka/comments/commentRss/7506.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/mulinka/services/trackbacks/7506.html</trackback:ping><description><![CDATA[<DIV class=postText>转载自<A href="http://blog.csdn.net/whoopee/archive/2005/06/27/404172.aspx">http://blog.csdn.net/whoopee/archive/2005/06/27/404172.aspx</A><BR><BR>　　恭喜，你选择开发工程师做为自已的职业<BR>　　悲哀，你选择开发工程师做为自已的职业 
<P>　　本文所指的开发工程师，仅指程序开发人员和以数字电路开发为主的电子工程师。<BR>　　当你选择计算机或者电子、自控等专业进入大学时，你本来还是有机会从事其它行业的，可你毕业时执迷不悟，仍然选择了开发做为你的职业，真是自做孽不可活。不过，欢迎你和我一样加入这个被其它人认为是风光无限的“白领”吧。<BR>　　如果你不是特别的与人世隔绝，我想你一定看过金老先生的名著《笑傲江湖》吧，里面有一门十分奇特的武功叫做"辟邪剑法"，你看这个小说第一次看到这种功夫的练法时，我想你当时一定笑歪了牙“呵呵，真好玩！”，可是现在我很痛心的告诉你：你选择的开发工作就是你人生路上的"辟邪剑法"，而你现在已经练了，并且无法再回头。<BR>　　相对同时刚出校门同学从事其它行业而言优厚的薪水，以及不断学习更新的专业知识不仅仅让你感到生活的充实，更满足了你那不让外人知的虚荣心。在刚出校门的几年中，你经常回头看看被你落在后面的同学们，在内心怜悯他们的同时，你也会对自已天天加班的努力工作感到</P>
<P>心里平衡：“有付出才会有回报”这句话在那几年中你说的最多，不管是对自已的朋友们还是自已的爱人。第二句最常说的话是对公司的领导：“不行我就走人！”，实际上你也真的走过几回。对了，在这几年中，因为你的经济条件不错，你开始买房、开始谈恋爱、结婚、开始有了自已的小孩。有时候你会对自已说再过两年就去买车。当然其中可能有许多大件是需要分期付款的，但你对前途充满了信心，你确信认为这种日子会永远的持续下去，即使不是变得更好的话。<BR>　　日子总是在这种平淡中一天天的过去，就在那么不经意间，你突然发现自已已经快30岁了，或者已经30了，莫名的，你心里会漫延着一种说不清楚的不安情绪，你好像觉得前途并非像前几年那样变得越来越好，你也忽然发现你以前所瞧不起的同学里好像已经有不少开着车的了，也有几个人住着比你还大的房子，好像房款还是一次付清的，你突然明白你现在的生活比起你的同学来最多是中游偏上了。工作中最让你感到心里不舒服的是，你越来越不敢对你的领导说不了，即使比你来的晚的同事升职或提薪，你也只是在私下与朋友们一起喝酒时才敢发发牢骚，在头的面前你的声间越来越小、笑脸是越来越温柔。<BR>　　你终于开始迷茫“再过几年我会是在干什么呢？”，这句话常常出现在你的心里。<BR>　　计算机开发工作，是一种以年轻为资本的工作，说句通俗点的话是“吃青春饭的”，嗯，这句话好像在一种特别的行业也听到过。</P>
<P>其标志就是一：工作的时间性非常强，一个开发项目被定的时限通常是很紧张的，更有甚者，有些号称开发管理的书里面还非常卑鄙的号召将一个项目切成多个小片，每个小片都定一个叫“里程碑”的东东来严格跟踪开发进度，加班加点在其它行业是需要加班工资的，而在开发行业，加班工资好像还没见到几个公司发过，是啊，反正有时间限制着，你干不完我再找你算账.所以开发工作通常有着其它工作所没有的精神上的压力。</P>
<P>一旦一个人步入而立之年，因为家庭和孩子的负担，加上精力上面的衰退，加班工作时间变得越来越少，这点让很多老板们感到：这些人已经老了，不好用了。指示人事部门：“以后招开发人员限制在30岁以下！”，相对而言硬件开发会年龄方面限制会稍好一点点，但也是五十步笑百步。还有一个很重要的一点就是：计算机这个烂东东实在是进步的太快了，前两年买的顶级配置电脑，现在怎么看怎么像废品，这还是小事，更可气的是好像每天都需要学习新的知识，刚毕业时只会书本上的PASCAL，学会了用腐蚀的办法来做电路板，一上班就开始学习TURBOC和TANGER2.0，刚刚学会，还没来得及高兴，马上开始学Borland C＋＋和Protel3.0，好不容易学会了，却发现需要学习VC和Protel98了。单片机也是啊：Z80的指令背的很熟，工作中没来得及用就要学8031，好好学吧，本来想着这辈子就吃它了，又发现又出来什么PIC、DSP、CPLD、FPGA、ARM等等....这还不包括中间要学一大堆74系列、4000系列、XX系列...IC卡居然里面还有CPU卡..如果学习的知识里每个字都能变成一分钱，我想所有的开发工程师都是腰缠万贯的富翁。<BR>　　一眼看去，这种日子好像见不到头，年轻时乐此不彼，但现在你一定对自已能坚持到什么时候感到怀疑了。我们都玩过像仙剑奇侠传这样的RPG游戏，刚开始时你只是一个一名不文的少年，随着你去打怪物、捡宝贝、学秘芨，最后终于有一天你会变成一个大英雄！那么你在实际生活中过得比那些小侠们还辛苦，为什么成不了一个生活中的大侠呢？呵呵，原因在这里：因为开发工作是邪门功夫，它虽然可以让你速成的变成小资，但它最大的特点是经验不积累！日新月异的知识更新，让你总是感到自已在退步，你就像在RPG中的主人公，开始时就给了你一把好剑和好盔甲，而且让你的级别很高，但让你的经验不累积，虽然刚开始打小怪物时你觉得自已很爽，但越到后来，你会发现你会死的很惨！比较一下你与其它非开发行业的同学你就可以知道了，例如和你学医的同学比起来。套用岳不群他老人家说华山剑宗和气宗的区别那段话：前十年你比你那些学医的同学收入和地位要好的多，但十年以后你和他基本上各方面都会持平，而二十年以后你的各方面远远不能与你学医的同学相提并论！嗯，你已经开始不笑辟邪剑法了吧。<BR>　　“敢问路在何方？路在脚下...”，不过猴兄和八戒兄这么认为是可以的，你呢？<BR>总结了许多开发朋友在30岁以后的生活之路，让我们一起看看开发人员“路在何方？”那么开发人员在30岁以后都干些什么呢？<BR>其路一：继续做你这个很有“前途”的职业吧！<BR>　　偶掰着脚指头仔细数了数，发现还真的有很多朋友在30岁以后还在从事开发工作，我这里说的从事，是指你还需要天天在电脑边上编程序和画电路板，与你手下是否有几个小兵无关，也与你是否头上顶着什么项目经理、主任工程师的帽子无关，只要你还需要亲自开发，你就属于这一类。其中有个年龄最大的朋友是63年的，从事医疗仪器的开发工作，35岁左右还在从事软硬件开发工作的仍有一大堆，分析这些仍然从事开发的朋友，基本上都有以下特点：<BR>1　痴迷工作或者痴迷电脑，晚上八点到十二点的这段时间，基本上是在电脑桌或工作台前渡过的。<BR>2　不喜欢与人交住，朋友很少，常联系的人不超过五个。<BR>3　与朋友交往时谈工作多，但一般不主动谈钱。<BR>4　体型偏胖或偏廋，不在正常区间。<BR>5　无未来计划，对五年后自已生活怎么样、从事什么工作说不清楚。<BR>6　俭省，从不乱花钱。<BR>即使你是还不到30岁的开发人员，你也可以看看自己对以上几条是否符合，是否会在30岁后还从事开发职业，四条疑似，五条以上基本确诊你也是这类型的人。<BR>　 这些朋友们通常报着过一天是一天的态度生活，到了这个年龄，也不敢再轻易的换工作了，年轻时的锐气慢慢的也消退了。唯一不变的希望是有一天从天上掉下来一大堆钱把自己砸伤。说实在话因为他们的性格所限，基本上可以确定他们以后不可能在职场上获得更好的发展，当个小头头，带几个人开发已经是他们发展的顶点。至于以后的人生之路，不仅他们自己迷茫，可能上帝也正在头痛。<BR>&nbsp;&nbsp; 不过像这类朋友，偶很奇怪的发现：他们的小孩都是儿子！不知是偶然还是有什么其它说法。<BR>简单建议：要改变命运，先改变性格：坚持半年晚上不从事工作、游戏及电视，用此时间与人交往，你的人生会有改变。</P>
<P><BR>其路二：转行从事技术支持、行政或生产等工作还有一些朋友，从事了几年的开发工作，因为自已并非特别的爱好，或者领导上面的强制工作安排，他们转到了技术支持、服务或行政等工作，至少当时从表面上看起来，他们的薪水较开发要少一些，但真正的统计这些人，发现他们之中有半数的人获得了更好的发展，升职为服务部经理或行政经理等职，最历害的一个朋友已升职为总经理助理，进入高层。<BR>　　这类朋友当时转行通常并非自已志愿，属被逼无奈或者其它原因，但显然，拥有专业知识技术的他们显然在非技术部门中鹤立鸡群，遇到什么事情他们均可从专业的角度提出建言，久而久之，他们获得更多的升职和加薪机会也就不足为奇。<BR>　　因为不从事开发，所以经验开始积累，这类的职业通常会给你一个很安定的感觉，你到30多岁后会发现这类职业反而比开发工作更容易获得新的工作机会。<BR><BR>　　简单建议：你如果确定在开发部无法获得很好的发展机会，不妨转到其它几个部门试试，换个活法，钱少点就少点吧，机会多。<BR>其路三：开发管理<BR>　　如果你现在已经是总工或开发部经理，或者你眼看就有机会被提升为这类职务，那么恭喜你，你走的是从“弼马温”到“斗战胜佛”这条金光大路，你不仅拥有很高的专业技能，而且很显然，你也有着很强的人际交往能力，你这类人根本不需要对未来有着任何的担心，你在即使一无所有的时候也很容易白手起家。<BR>　　你这种人算是练辟邪剑法练成了仙，嗯，我无话可说。<BR>　　你是不是这类人也很容易区别，就像围棋二十岁不称国手终身无望一样，你应该在工作三、四年以后，也就是说二十七岁左右就会发现自已工作中指手划脚的时间比亲自开发的时间要多了，而且大多数这类人在这个年龄手下应该有“兵”了，相反的，如果你快30岁了还天天埋头于电脑前编程序和画板子，或者30多岁了你还没升到部门经理（虽然你总是觉得自已很有希望），基本上可以确定你不是这类人。好了，如果你确定你是这类人，那么你唯一的想法就是尽快爬上中层和高层，因为有时候人生偶然性太大，不占住坑的萝卜很有可能被人拔出来！<BR><BR>　　简单建议：天天去你的老板家里面拖地和擦桌子！</P>
<P><BR>其路四：出国或考研<BR>　　有两个搞开发后出国的朋友，其中一个甚至打工打到了一个小公司总工的位置，数据库和软件方面水平巨牛，但仍感觉心里不踏实，于是将自己工作多年的钱忍痛掏出来，出国费加上机票大概将自已辛苦所攒的银子花完，然后又借了一些钱，在02年身上揣着一万美元跑去了加拿大，在加拿大不停的重复找工作，换工作，然后再找工作的循环，找的工作基本上与计算机无关，不过工资总是在1500加元左右，呵呵，折成人民币与他在国内打工拿的基本上差不多，不过租个地下室就花了300加元，然后吃吃喝喝，再买个电脑上上网这类的，基本每月平均还要倒贴一点。前段时间给我的邮件里说，现在身上花的差不多只有5、6000美元了，准备开个小公司，看看能不能往国内倒腾点东东，做最后一搏。另外一个朋友去澳州，时间稍早一些，先是大概摘了一年多的葡萄，后来总算找了个技术工作，每天的工作是画机械图纸，收入还算不错</P>
<P>将近3000澳元，买了个旧车，也算是过上了资本主义生活。不过前年回来一趟，唯一的感叹就是：在国外拿2000美元的生活，绝对不如在国内拿5000人民币的生活舒服。<BR>　　也有两个考研的朋友，不过其中一个严格的说不是做开发的出身，偏重于市场方面的工作性质，不过我的朋友里面考研的不多，只好凑两个人说说，一个考研后在北京找了个工作，每个月5、6000元钱，但还是做开发，生活仍然与没考研之前没有任何的改变，前途仍然没见到什么大亮的光，还是搞不清楚以后再干些什么，标准的过一天算一天了。另外一个考研后在大学里面找了个工作，工资虽然比他原来打工少了不少，但毕竟终身有靠，稳定了下来，也算修成了正果，这位哥们心情一放松下来，也开始有时间琢磨着业余时间自已做点什么，好像现在慢慢的也开始有了点眉目。<BR>　　简单建议：这两条路，对开发人员来说都不算是很好，出国十年前是好事，现在难说，考研能成功转行的概率恐怕也不是很大，多半仍然去搞开发，只不过研究生可以多干几年罢了。</P>
<P><BR>其路五：转行到市场<BR>　　绞尽脑汁的想想，我所知道的人之中只有两个开发人员去了市场，这两个人都不能说是朋友，认识而已。他们都是主动要求去了市场，结果是这两个人均在市场都是干到一年左右，然后都自已开公司了。呵呵，很奇怪，极高的转行成功率！不过仔细想想，我对这两个人的思路佩服的五体投地。能下决心仍掉每月5、6000元的开发职位，从事一个自已并不熟悉的岗位，每月拿个2000多元＋提成，但提成那是说不清楚的事情，这个决定，只能让人感觉到他们对自已前途清晰的把握和老谋深算的心机。而且他们不去服务不去生产，挖空心思说服领导去市场（市场部门与开发部门通常是一个公司的核心部门，进入其实并不容易），可以说是有着长远的考虑的。有技术了，再与客户交成朋友，马上就会产生很大的机遇应该是正常的事情。<BR>　　有实力，有心机，也有着很强的决心力，这种人恐怕早在大学毕业时或更早的时候就已经决定了自已的人生之路，他们的每一步路在若干年前早就计划周全，现在看起来：学会技术－＞进入市场－＞寻找商机－＞开公司，一条多么清楚的人生之路。但就像我们上小学中学时，所有人都知道上大学是我们最清楚的人生路一样，最后只有少数人才能真正达到目标（当然，现在扩招的历害是另外一回事，我是说我们那个时候，也就是：“很久很久以前，当我像你那么大的时候”）。<BR><BR>　　简单建议：你若是这类人，我的建议是：...嗯?....那个你.你，你别走啊，我还有个事想请你赞助一下啊.....</P>
<P><BR>其路六：开公司自已干</P>
<P>　　呵呵，看到这一条，发现你的眼睛已经圆了，你肯定千百次的想过这个事情吧，咳咳，其实我从事开发的时候也是天天梦想着这种事情。总想着过两年找个机会就自已干，这个梦想一年又一年的折磨着你也给着你希望。看看吧，开发后来开公司的还真的不少，里面有成功的也有很多失败的，通常开公司都是几个人合伙开始的，有做技术的，有做市场的，几个人一拍即合、狼狈为奸，共同策划了这一个大活动。一般说来能让这几个人下决心走出这一步，产品肯定是先进的，甚至是国内独一无二的，市场也是很大的，负责市场的那个哥们通常会拍着胸保证可以卖出去，并悄悄地告诉你他在某主管领导是他小舅子的同学的二叔，肯定没问题。于是你们几个人找地点、注册执照、买了几个破桌子，再攒了两台电脑，每个人又凑了几万银子，公司开张了！<BR>　　产品很快出来了，市场的哥们也不负重望，有几个客户表示要试用了，一切看起来都是如此的正常，“.......你坐在老板桌前，不停的有人来汇报工作或者找你签字...人进人出中...你又想起公司再穷也不能只有一把椅子的故事.....”你在梦中笑出声来。<BR>&nbsp;&nbsp;&nbsp; 是如此的顺利，你们很快就有单子了，很快的单子让你们凑的那点钱不够了，你们很高兴的每个人又增加了投入，拿出钱时你眼泪汪汪的数着钱说：“这就是我那生蛋的母鸡啊”。你们的产品确实不错，市场也经营的很好，客户慢慢的多了起来，单子来的时候一笔接着一笔，你每天都处于兴奋之中，唯一美中不足的是好像客户回款总是会拖一些日子，不过客户给你保证说：过几天，过几天就付给你们，因为回款总是在计划外，所以你们为了资金的流畅运行又凑了一些钱，这个时候你有一些心事了，因为你的存款折上面的数字已经快趋向于零了。“没事，过两个月等回款了一切都OK了，谁干事业不吃点苦呢？”你这么安慰着自已又投入到工作中去，资金总是在回款和生产经营费用之间走着一个窄窄的小木桥，你的账上总是没有太多的钱，扩大了的公司规模和许多意外情况，使你又一次、二次、三次的与合作者们再次投入了自已的资金，当然，后来的钱你可能已经是借的了.....<BR>　　终于有一天，你的会计再一次告诉你，老板啊，账上又没现金了，吃过多次苦头的你终于下决心开始重视资金的运行了，你裁掉了一些不必要的人手，减少了开发的投入，要求市场人员签单的时候必须予付XX%的款，回扣也必须等收过款后再付，同时也开始对产品的生产成本开始进行控制。<BR>　　时间一天一天的过去，因为竟争对手的产品也对你的产品进行了仿造，你的产品慢慢变得不再先进，市场人员开始埋怨公司的合同资金方面规定太严格，不好签单，生产成本的下降通常也导至产品毛病的增多，客户也开始埋怨你的服务人员不能及时进行服务。<BR>　　终于有一天，你重新走进了人才交流中心，以前你是来招人的，现在你拿着自已的简历开始寻找一个工作<BR>......<BR>&nbsp;&nbsp;&nbsp; 公司的成功与否，与产品有关，与市场有关，但更重要的是与资金有关，产品与市场都可以通过资金来弥补，而却没有任何东西可以代替</P>
<P>资金，凡是倒下的公司，99%与资金链的断裂有关。在你决定要开公司以前，先估计一下你公司支持一年所需要的资金数额，包括人工费，生产，场地，广告宣传、市场费用、甚至电、水费等等等等，把你所想到的一切加在一起，得出的值就是..慢..如果你没有实际的开过公司的经验，你需要将此数字乘3，然后就是你开公司一年最少需要的费用，呵呵，公司的实际运营所需要的钱是你想像的3倍以上，你要是不信我也没办法。<BR><BR>&nbsp;&nbsp;&nbsp; 简单建议：开公司前最重要的是先确立你后续的资金来源！也就是说钱不够了怎么办？－－－因为你投入的钱肯定会不够的。</P>
<P><BR>其路七:第二职业<BR>&nbsp;&nbsp;&nbsp; 这类的朋友有不少,他们没有脱离开发工作,但是在业余时间又不停的接项目或者在卖产品,在单位里面他们显得并不出众,比起其它人来说他们属于最不愿意加班的一类.为此他们白天通常工作很勤奋.这类人也许不一定可以挣很多钱,但平均下来他们一年之中通常都可以比同事们多挣个几万元.有时候比上班拿得还多.但令人疑惑的是,这类人在生活中更加注重稳定,基本上没见到他们跳过蹧,即使私下里面已经开了个小公司,他们通常也不会辞职.<BR>&nbsp;&nbsp;&nbsp; 你的旁边有没有这类人呢?分辨他们很容易:<BR>--电话很多,而且更愿意来电话时离开办公室找个没人的旮旯通话.神秘兮兮给人一种"这家伙是不是有二奶啊?"的感觉的人，通常是这类人。这类人是女性最佳的选择对象：很顾家，不象那些富人容易花心，而比起一般人来说，他们收入相对要高得多。但总结了一下几位这类的开发朋友：也得出了一个令人沮丧的结论：这种人通常个子不高，体形类似桶状.....<BR><BR>&nbsp;&nbsp; 简单建议：这好像是开发人员最佳的出路了，但比较丰厚的收入通常让这类人不愿意去冒风险....到现在为止我所认识的这类人还没有一个真正算是成功的。<BR>&nbsp;&nbsp; 好了，虽然偶的经历远远说不上丰富，也没有什么成功之处可以自满的，但或许因为比其它朋友痴长了几岁，见过的人可能会稍多一些，所</P>
<P>以斗胆写出了以上的一些文字，让您掉牙了。<BR>&nbsp;&nbsp; 下面是偶走过开发这条路上总结出来的一点心得，你可以不看，但看了就千万别把嘴咧的太大：<BR>&nbsp;&nbsp; 一、不管是给别人打工还是自已干，都要全心全意的工作，因为你所做的任何一点工作都会让自已的人生多一点筹码，这一点最最重要!这样的例子我至少可以举出两起，优秀的开发人员被其它新公司挖走，并给一定的股份，成为新公司的股东的例子。当时与这样的开发人员一个部门同时工作或更早工作的有许多人，他们平时经常偷点懒，能少干点工作就少干点，有时候还笑话那个平时努力工作的人傻，几年过去了，究竟谁比谁傻？<BR>&nbsp;&nbsp; 二、多与市场人员交朋友，你接触他们时可能总会觉得他们知识比你少，甚至素质比你低，可能比你还有点黄。但实际上他们比你更懂这个社会！参加到他们这个圈子中去，和他们一起赌赌钱、一起聊聊天、一起洗洗桑拿、一起.....你会通过他们接触到另外一个世界。<BR>&nbsp;&nbsp; 三、机会远比钱重要，挣不挣钱在年轻时并不是特别重要！不论是在实际生活中还是在网上或其它地方，如果有机会参与到除本职工作外的一些项目或产品的开发中（包括你的朋友拉你去做点小生意之类的非开发性质的工作），那怕是帮忙的性质，也要积极介入，至少你会交到很多的朋友，这样你的人生会多出很多的机会。</P></DIV><img src ="http://www.blogjava.net/mulinka/aggbug/7506.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/mulinka/" target="_blank">魔之卡卡</a> 2005-07-11 15:04 <a href="http://www.blogjava.net/mulinka/articles/7506.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>对市场人员的一点点理解</title><link>http://www.blogjava.net/mulinka/articles/7403.html</link><dc:creator>魔之卡卡</dc:creator><author>魔之卡卡</author><pubDate>Sat, 09 Jul 2005 04:42:00 GMT</pubDate><guid>http://www.blogjava.net/mulinka/articles/7403.html</guid><wfw:comment>http://www.blogjava.net/mulinka/comments/7403.html</wfw:comment><comments>http://www.blogjava.net/mulinka/articles/7403.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/mulinka/comments/commentRss/7403.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/mulinka/services/trackbacks/7403.html</trackback:ping><description><![CDATA[<P>&nbsp;</P><img src ="http://www.blogjava.net/mulinka/aggbug/7403.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/mulinka/" target="_blank">魔之卡卡</a> 2005-07-09 12:42 <a href="http://www.blogjava.net/mulinka/articles/7403.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>