IT人必读:写给浮躁的IT同仁(请不要做浮躁的人)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/naive1010/article/details/368064

 1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想出来再参考别人的提示,你就知道自己和别人思路的差异。
  2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久都是只对部分功能熟悉而已,不系统还是不够的。

  3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,虽然帮助的文字有时候很难看懂,总觉得不够直观。

  4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。

  5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸出很多知识点;不会举一反三你就永远学不会。

  6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。

  7.学脚本并不难,JSP、ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览群书。

  8.看再多的书是学不全脚本的,要多实践。

  9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里。

  10.学习脚本最好的方法之一就是多练习。

  11.在任何时刻都不要认为自己手中的书已经足够了。

  12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看。

  13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;

  14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件;

  15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中。

  16.不要漏掉书中任何一个练习——请全部做完并记录下思路;

17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工作。

  18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的;

  19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能讲清楚才说明你真的理解了。

  20.记录下在和别人交流时发现的自己忽视或不理解的知识点。

  21.保存好你做过的所有的源文件----那是你最好的积累之一。

  22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒!

  23.到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己的帖子没人回的。

  24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你讨论呢。

展开阅读全文

问题解决之道—请不要做浮躁的人

04-01

问题解决之道 rn出自http://www.linuxsir.org北南南北 rnrnrn一、发帖子时,先在论坛里搜索一下有没有相关的帖子。 rnrn这样我们就提高了解决问题的效率,以免重复发帖。我常在国外网站发帖,因为原来不懂这个规矩,我收到了好几个警告,有的是网站管理人员的,大多的是网站的会员。但网站的管理员还是把的帖子重新编辑,放在相应的位置上,并发一封信告诉帖子的位置,以及发帖子的方法和技巧等。在这方面,我们还要多学习一下。 rnrn二、我们发帖子时,要写好主题标题,简洁明了,切重要点;标题过长容易显示出错,切记! rnrn最好不用[紧急、请帮助、求助、特急之类的词语],因为我们的帖子是给答复我们的弟兄看的,也是给有此问题的朋友看的。如果你用这些词语,可能有不会此问题的朋友也要看,这样就浪费了这些弟兄的时间,另外如果他们也有此问题,他们也搜索不到你的主题。有此经验的弟兄也能立即答复你的问题。我们应该用与我们问题相关的词语。如果你的SAMBA有问题,那就在主题上写[SAMBA问题] 。 rnrn三、硬件问题,你就得把相关硬件的参数、品牌、芯片组等,以及你设置相关的参数出现的错误信息等。同时也得把系统说上,因为每个系统的配制方法都有不同的地方,这个极重要,否则弟兄们真的不知道怎么回答。 rnrn四、软件及系统的问题,也要注明系统版本及错误的详细信息。 rnrn五、为了便于以后查找,不得重复发帖;不得一帖多问,只能一帖一问; rnrn六、请不要在不相关的主题后面回帖,或在不相关的主题后面提出新问题; rnrn七、跟帖技巧; rnrn如果你原来已经发过你所要问的问题,如果弟兄们给你的答复,你仍没有解决了,那你最好还接着原来的问题再发帖子。如果别人也有相似的问题,你也可以跟帖子,因为类似的问题一集中,我们就容易解决。 rnrn八、发帖时要讲究说话方式; rnrn因为在咱们的论坛里,弟兄们能不能帮助你,不是弟兄们的义务,是弟兄们自愿的。所以我们提问时尽可能的客气一点。用语讲究客气,能为我们营造了一个良好的互助氛围。这对我们每个弟兄都一样,因为我们不是什么都会的。 rnrn九、要有爱心,有奉献精神。 rnrn因为我们面对的是大多的从WINDOWS转过来的弟兄,他们习惯于点鼠标,可能暂时不太习惯LINUX的操作方式。这就要我们给他以信心,让他有勇气敢于挑战LINUX给他带来的不便。我们要学会怎样倾听发帖提问的弟兄们的心理感受。我们都知道,我们学WINDOWS时也是一样的,点几下鼠标,有时也问好几个人,读好多书,其实真正有问题要问的还是LINUX,而不是WINDOWS。如果我们认真的彼此关注,我们就会感受到“互帮助给予我们的快乐和感动”。我们每个人都需要帮助,我们每个人都要尽可能的为别人做点什么,没有付出就没有收获。 rnrn十、发帖时想一下你的主题应该发到哪个版块。 rnrn把问题发到适合的版块,这样才能让兄弟们在最短的时间内,给予帮助; rnrn十一、归纳总结,如果问题解决了; rnrn我们最好写个总结,把你的心得和成果发布出来,这样也便于我们帮助有此问题的兄弟,因为互帮是多方的,而非我们只需要别人帮助,而不去帮助别人;rn 论坛

要做浮躁的人(推荐大家看看)

06-17

“不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境,而我们要学的是一门语言;rn不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单,或者可以引伸出很多知识点;rn会用Visual C++,并不说明你会C++;rn学class并不难,template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书;rn如果不是天才的话,想学编程就不要想玩游戏——你以为你做到了,其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住:学C++是为了编游戏的;rn看Visual C++的书,是学不了C++语言的;rn把时髦的技术挂在嘴边,还不如把过时的技术记在心里;rn看得懂的书,请仔细看;看不懂的书,请硬着头皮看;rn别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;rn不要停留在集成开发环境的摇篮上,要学会控制集成开发环境,还要学会用命令行方式处理程序;rn和别人一起讨论有意义的C++知识点,而不是争吵XX行不行或者YY与ZZ哪个好;rn请看《程序设计实践》,并严格的按照其要求去做;rn不要因为C和C++中有一些语法和关键字看上去相同,就认为它们的意义和作用完全一样;rn学习编程的秘诀是:编程,编程,再编程;rn记住:面向对象技术不只是C++专有的;rn请把书上的程序例子亲手输入到电脑上实践,即使配套光盘中有源代码;rnrn把在书中看到的有意义的例子扩充;rn请重视C++中的异常处理技术,并将其切实的运用到自己的程序中;rn经常回顾自己以前写过的程序,并尝试重写,把自己学到的新知识运用进去;rn不要漏掉书中任何一个练习题——请全部做完并记录下解题思路;rnC++语言和C++的集成开发环境要同时学习和掌握;rn就让C++语言的各种平台和开发环境去激烈的竞争吧,我们要以学习C++语言本身为主rn当你写C++程序写到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余下的部分粗略的完成以保证这个设计的完整性,然后分析自己的错误并重新设计和编写rn别心急,设计C++的class确实不容易;自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的;rn每学到一个C++难点的时候,尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了;rn请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100. XX;rn保存好你写过的所有的程序——那是你最好的积累之一;rn浮躁的人容易说:XX语言不行了,应该学YY;——是你自己不行了吧!?rn浮躁的人容易问:我到底该学什么;——别问,学就对了;rn浮躁的人容易问:XX有钱途吗;——建议你去抢银行;rn浮躁的人容易说:我要中文版!我英文不行!——不行?学呀!rn浮躁的人容易问:XX和YY哪个好;——告诉你吧,都好——只要你学就行;rn浮躁的人分两种:a)只观望而不学的人;b)只学而不坚持的人;rn请不要做浮躁的人;”rnrn 论坛

浮躁的软件业同仁

03-15

rn  中国有很多小朋友,他们18,9岁或21,2岁,通过自学也写了不少代码,他们有的代码写的很漂亮,一些技术细节相当出众,也很有钻研精神,但是他们被一些错误的认识和观点左右,缺乏对系统,对程序的整体理解能力,这些人,一个网上的朋友说得很好,他们实际fans,压根没有资格称为程序员,但是据我所知,不少小网络公司的Cfans,拿着吓人的工资,做着吓人的项目,项目的结局通常也很吓人。rn  程序员基本素质:rn  作一个真正合格的程序员,或者说就是可以真正合格完成一些代码工作的程序员,应该具有的素质。 rn1. 团队精神和协作能力 rn  把它作为基本素质,并不是不重要,恰恰相反,这是程序员应该具备的最基本的,也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语,任何个人的力量都是有限的,即便如linus这样的天才,也需要通过组成强大的团队来创造奇迹,那些遍布全球的为linux写核心的高手们,没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财,但是一旦进入一些大系统的研发团队,进入商业化和产品化的开发任务,缺乏这种素质的人就完全不合格了。rn2. 文档习惯 rn  说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子,良好的文档是正规研发流程中非常重要的环节,作为代码程序员,30%的工作时间写技术文档是很正常的,而作为高级程序员和系统分析员,这个比例还要高很多。缺乏文档,一个软件系统就缺乏生命力,在未来的查错,升级以及模块的复用时就都会遇到极大的麻烦。rn3. 规范化,标准化的代码编写习惯 rn  作为一些外国知名软件公司的规矩,代码的变量命名,代码内注释格式,甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定,良好的编写习惯,不但有助于代码的移植和纠错,也有助于不同技术人员之间的协作。rn  fans叫嚣高水平程序员写的代码旁人从来看不懂,这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性,是程序员基本的素质需求。rn  再看看整个linux的搭建,没有规范化和标准化的代码习惯,全球的研发协作是绝对不可想象的。rn4. 需求理解能力 rn  程序员需要理解一个模块的需求,很多小朋友写程序往往只关注一个功能需求,他们把性能指标全部归结到硬件,操作系统和开发环境上,而忽视了本身代码的性能考虑,有人曾经放言说写一个广 告交换程序很简单,这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的,对于这样的程序员,你给他深蓝那套系统,他也做不出太极链的并访能力。性能需求指标中,稳定性,并访支撑能力以及安全性都很重要,作为程序员需要评估该模块在系统运营中所处的环境,将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点,一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。rn5. 复用性,模块化思维能力 rn  经常可以听到一些程序员有这样的抱怨,写了几年程序,变成了熟练工,每天都是重复写一些没有任何新意的代码,这其实是中国软件人才最大浪费的地方,一些重复性工作变成了熟练程序员的主要工作,而这些,其实是完全可以避免的。rn  复用性设计,模块化思维就是要程序员在完成任何一个功能模块或函数的时候,要多想一些,不要局限在完成当前任务的简单思路上,想想看该模块是否可以脱离这个系统存在,是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用,这样就能极大避免重复性的开发工作,如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题,那么程序员就不会在重复性的工作中耽误太多时间,就会有更多时间和精力投入到创新的代码工作中去。rn  一些好的程序模块代码,即便是70年代写成的,拿到现在放到一些系统里面作为功能模块都能适合的很好,而现在我看到的是,很多小公司软件一升级或改进就动辄全部代码重写,大部分重复性工作无谓的浪费了时间和精力。rn6. 测试习惯 rn  作为一些商业化正规化的开发而言,专职的测试工程师是不可少的,但是并不是说有了专职的测试工程师程序员就可以不进行自测;软件研发作为一项工程而言,一个很重要的特点就是问题发现的越早,解决的代价就越低,程序员在每段代码,每个子模块完成后进行认真的测试,就可以尽量将一些潜在的问题最早的发现和解决,这样对整体系统建设的效率和可靠性就有了最大的保证。rn  测试工作实际上需要考虑两方面,一方面是正常调用的测试,也就是看程序是否能在正常调用下完成基本功能,这是最基本的测试职责,可惜在很多公司这成了唯一的测试任务,实际上还差的远那;第二方面就是异常调用的测试,比如高压力负荷下的稳定性测试,用户潜在的异常输入情况下的测试,整体系统局部故障情况下该模块受影响状况的测试,频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对自己的每段代码都需要进行这种完整测试,但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求,有针对性的进行相关测试并尽早发现和解决问题,当然这需要上面提到需求理解能力。rn7. 学习和总结的能力 rn  程序员是人才很容易被淘汰,很容易落伍的职业,因为一种技术可能仅仅在三两年内具有领先性,程序员如果想安身立命,就必须不断跟进新的技术,学习新的技能。rn  善于学习,对于任何职业而言,都是前进所必需的动力,对于程序员,这种要求就更加高了。但是学习也要找对目标,一些小coding有些codingTO就是这样的coding上只是一些Cfans们,他们也津津乐道于他们的学习能力,一会学会了asp,一会儿学会了php,一会儿学会了jsp,他们把这个作为炫耀的资本,盲目的追逐一些肤浅的,表面的东西和名词,做网络程序不懂通讯传输协议,做应用程序不懂中断向量处理,这样的技术人员,不管掌握了多少所谓的新语言,永远不会有质的提高。rn  善于总结,也是学习能力的一种体现,每次完 成一个研发任务,完成一段代码,都应当有目的的跟踪该程序的应用状况和用户反馈,随时总结,找到自己的不足,这样逐步提高,一个程序员才可能成长起来。rn  一个不具备成长性的程序员,即便眼前看是个高手,建议也不要选用,因为他落伍的时候马上就到了。具备以上全部素质的人,应当说是够格的程序员了,请注意以上的各种素质都不是由IQ决定的,也不是大学某些课本里可以学习到的,需要的仅仅是程序员对自己工作的认识,是一种意识上的问题。 rn  那么作为高级程序员,以至于系统分析员,也就是对于一个程序项目的设计者而言,除了应该具备上述全部素质之外,还需要具备以下素质:rn1. 需求分析能力 rn  对于程序员而言,理解需求就可以完成合格的代码,但是对于研发项目的组织和管理者,他们不但要理解客户需求,更多时候还要自行制定一些需求,为什么这么说呢?rn  一般而言,进行研发任务,也许是客户提出需求,也许是市场和营销部门提出的需求,这时候对于研发部门,他们看到的不是一个完整的需求,通常而言,该需求仅仅是一些功能上的要求,或者更正规些,可能获得一个完整的用户视图;但是这都不够,因为客户由于非技术因素多一些,他们可能很难提出完整和清晰,或者说专业性的性能需求,但是对于项目组织者和规划者,他必须能够清醒认识到这些需求的存在并在完成 需求分析报告的时候适当的提出,同时要完整和清晰的体现在设计说明书里面,以便于程序员编码时不会失去这些准则。rn  程序设计者必须正确理解用户需求所处的环境,并针对性做出需求的分析,举例而言,同样一个软件通过ASP租用方式发布和通过License方式发布,性能需求可能就是有区别的,前者强调的是更好的支撑能力和稳定性,而后者则可能更强调在各种平台下的普适性和安装使用的简捷性。rn2. 项目设计方法和流程处理能力 rn  程序设计者必须能够掌握不少于两到三种的项目设计方法(比如自顶至下的设计方法,比如快速原型法等等),并能够根据项目需求和资源搭配来选择合适的设计方法进行项 目的整体设计。设计方法上选择不当,就会耽误研发周期,浪费研发资源,甚至影响研发效果。rn  一个程序设计者还需要把很多功夫用在流程图的设计和处理上,他需要做数据流图以确立数据词典;他需要加工逻辑流图以形成整体的系统处理流程。一个流程有问题的系统,就算代码多漂亮,每个模块多精致,也不会成为一个好的系统。当然,做好流程分析并选择好项目设计方法,都需要在需求分析能力上具有足够的把握。rn3. 复用设计和模块化分解能力 rn  这个似乎又是老调重谈,前面基本素质上不是已经说明了这个问题吗?作为一个从事模块任务的程序员,他需要对他所面对的特定功能模块的 复用性进行考虑,而作为一个系统分析人员,他要面对的问题复杂的多,需要对整体系统按照一种模块化的分析能力分解为很多可复用的功能模块和函数,并针对每一模块形成一个独立的设计需求。举个例子,好比是汽车生产,最早每辆汽车都是独立安装的,每个部件都是量身定做的,但是后来不一样了,机器化大生产了,一个汽车厂开始通过流水线来生产汽车,独立部件开始具有一定的复用性,在后来标准化成为大趋势,不同型号,品牌甚至不同厂商的汽车部件也可以进行方便的换装和升级,这时候,汽车生产的效率达到最大化。软件工程也是同样的道理,一个成熟的软件行业,在一些相关项目和系统中,不同的部件是可以随意换装的,比如微软的许多桌面软件,在很多操作模块(如打开文件,保存文件等等)都是复用的同一套功能模块,而这些接口又通过一些类库提供给了桌面应用程序开发者方便挂接,这就是复用化的模块设计明显的一个佐证。rn  将一个大型的,错综复杂的应用系统分解成一些相对独立的,具有高度复用性的,并能仅仅依靠几个参数完成数据联系的模块组合,是作为高级程序员和系统分析员一项最重要的工作,合适的项目设计方法,清晰的流程图,是实现这一目标的重要保证。rn4. 整体项目评估能力 rn  作为系统设计人员,必须能够从全局出发,对项目又整体的清醒认识,比如公司的资源配置是否合理和到位,比如工程进度安排是否能最大化体现效率又不至于无法按期完成。评估项 目整体和各个模块的工作量,评估项目所需的资源,评估项目可能遇到的困难,都需要大量的经验积累,换言之,这是一种不断总结的累计才能达到的境界。在西方一些软件系统设计的带头人都是很年长的,比如4,50岁,甚至更老,他们在编码方面已经远远不如年轻人那样活络,但是就项目评估而言,他们几十年的经验积累就是最重要和宝贵的财富。中国缺这么一代程序员,主要还不是缺那种年纪的程序员,而是那种年纪的程序员基本上都是研究单位作出来的,都不是从专业的产品化软件研发作出来的,他们没有能积累那种产品化研发的经验,这也是没有办法的事情。rn5. 团队组织管理能力 rn  完成一个项目工程,需要团队的齐心协力,作为项目设计者或研发的主管人,就应当有能力最大化发挥团队的整体力量,技术管理由于其专业性质,不大同于一般的人事管理,因为这里面设计了一些技术性的指标和因素。rn  首先是工作的量化,没有量化就很难做到合适的绩效考核,而程序量化又不是简单的代码行数可以计算的,因此要求技术管理人员需要能真正评估一个模块的复杂性和工作量。rn  其次是对团队协作模式的调整,一般而言,程序开发的协作通常分为小组进行,小组有主程序员方式的,也有民主方式的,根据程序员之间的能力水平差距,以及根据项目研发的需求,选择合适的组队方式,并能将责权和成员的工作任务紧密结合,这样才能最大发挥组队的效率。rn  一个代码水平高的人,未必能成为一个合格的项目研发主管,这方面的能力欠缺往往是容易被忽视的。rn  综上可以看到,作为一个主管研发的负责人,一个项目设计者,所需要具备的素质和能力并不是程序代码编写的能力,当然一般情况下,一个程序员通过不断的总结提高达到了这种素质的时候,他所具有的代码编写能力也已经相当不简单了,但是请注意这里面的因果关系,一个高水平的项目设计者通常已经是代码编写相当优秀的人了,但是并不是一个代码相当优秀的程序员就可以胜任项目设计的工作,这里面存在的也不是智商和课本的问题,还是在于一个程序员在积累经验,逐步提升的时候没有意识到应当思考哪方面的东西,没有有意识的就项目的组织和复用设计进行揣摩,没有经常性的文档习惯和总结习惯, 不改变这些,我们的合格的项目设计者还是非常欠缺。rn  另外,为防止有无聊的人和我较真,补充一点,本文针对目标是作商业化的软件项目和工程,那些科研机构的编程高手,比如算法高手,比如图象处理高手,他们的工作是研究课题而非直接完成商业软件(当然最终间接成为商业产品,比如微软研究院在作的研究课题),因此他们强调的素质可能是另外的东西,这些人(专家),并不能说是程序员,不能用程序员的标准去衡量。rn  最后补充一点东西,一个软件项目研发的设计流程是怎样的呢?以通常标准的设计方法为例,(不过笔者喜欢快速原型法)。rn• 第一个步骤是市场调研,技术和市场要结合才能体现最大价值。 rn• 第二个步骤是需求分析,这个阶段需要出三样东西,用户视图,数据词典和用户操作手册。用户视图是该软件用户(包括终端用户和管理用户)所能看到的页面样式,这里面包含了很多操作方面的流程和条件。数据词典是指明数据逻辑关系并加以整理的东东,完成了数据词典,数据库的设计就完成了一半多。用户操作手册是指明了操作流程的说明书。 rn  注意,用户操作流程和用户视图是由需求决定的,因此应该在软件设计之前完成,完成这些,就为程序研发提供了约束和准绳,很遗憾太多公司都不是这样做的,因果颠倒,顺序不分,开发工作和实际需求往往因此 产生隔阂脱节的现象。rn  需求分析,除了以上工作,笔者以为作为项目设计者应当完整的做出项目的性能需求说明书,因为往往性能需求只有懂技术的人才可能理解,这就需要技术专家和需求方(客户或公司市场部门)能够有真正的沟通和了解。rn• 第三个步骤是概要设计,将系统功能模块初步划分,并给出合理的研发流程和资源要求。作为快速原型设计方法,完成概要设计就可以进入编码阶段了,通常采用这种方法是因为涉及的研发任务属于新领域,技术主管人员一上来无法给出明确的详细设计说明书,但是并不是说详细设计说明书不重要,事实上快速原型法在完成原型代码后,根据评测结果和经验教训的总结,还要重新进行详细设计的步骤。 rn• 第四个步骤是详细设计,这是考验技术专家设计思维的重 要关卡,详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱结构)提供给编码者,使得系统整体模块化达到最大;一份好的详细设计说明书,可以使编码的复杂性减低到最低,实际上,严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来,从需求分析到概要设计到完成详细设计说明书,一个软件项目就应当说完成了一半了。换言之,一个大型软件系统在完成了一半的时候,其实还没有开始一行代码工作。那些把作软件的程序员简单理解为写代码的,就从根子上犯了错误了。 rn• 第五个步骤是编码,在规范化的研发流程中,编码工作在整个项目流程里最多不会超过1/2,通常在1/3的时间,所谓磨刀不误砍柴功,设计过程完成的好,编码效率就会极大提高,编码时不同模块之间的进度协调和协作是最需要小心的,也许一个小模块的问题就可能影响了整体进度,让很多程序员因此被迫停下工作等待,这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的,对于程序员而言,bug永远存在,你必须永远面对这个问题,大名鼎鼎的微软,可曾有连续三个月不发补丁的时候吗?从来没有! rn• 第六个步骤是测试 rn  测试有很多种:按照测试执行方,可以分为内部测试和外部测试;按照测试范围,可以分为模块测试和整体联调;按照测试条 件,可以分为正常操作情况测试和异常情况测试;按照测试的输入范围,可以分为全覆盖测试和抽样测试。以上都很好理解,不再解释。rn  总之,测试同样是项目研发中一个相当重要的步骤,对于一个大型软件,3个月到1年的外部测试都是正常的,因为永远都会又不可预料的问题存在。rn  完成测试后,完成验收并完成最后的一些帮助文档,整体项目才算告一段落,当然日后少不了升级,修补等等工作,只要不是想通过一锤子买卖骗钱,就要不停的跟踪软件的运营状况并持续修补升级,知道这个软件被彻底淘汰为止。rn  写这些步骤算不上卖弄什么,因为实话讲我手边是一本《软件工程》,在大学里这是计算机专业的必修课程,但是我知道很多程序员似乎从来都只是热衷于什么《30天精通VC》之类的,他们有些和我一样游击队出身,没有正规学过这个专业,还有一些则早就在混够学分后就把这些真正有用的东西还给了老师。rn  fans乱嚷嚷,混淆视听,实际上真正的技术专家很少在网上乱发帖子的,如笔者这样不知天高地厚的,其实实在是算不上什么高手,只不过看不惯这种对技术,对程序员的误解和胡说,只好挺身而出,做拨乱反正之言,也希望那些还fans们能认真想想,走到正途上,毕竟那些聪明的头脑还远远没有发挥应有的价值。沉迷于一些错误人士的codingrn  *****************************rn  从程序员升级到工程师大多数象我这样对软件有浓厚兴趣的人,毕业后义无反顾地走进了企业,开始了程序员的生涯。那时,我们迷恋“大全”、“秘籍”一类的书籍,心中只有代码。当我看到一行行枯燥的代码变成了能够打电话的设备,变成了屏幕上漂亮的表格,变成了动听的音乐,成就感油然而生。我觉得自己也是一个出色的程序员了。在用户的机房中苦熬三昼夜解决软件的bug,也成了一种可以夸耀的资历。五年前的某一天,我把曾经让我兴奋自豪的大量代码和少得可怜的文档移交之后,来到了华为。这里有更多的年轻人,我如鱼得水,可以充分发挥自己的想象力。依然是代码,依然是匆匆地在纸上记下稍纵即逝的灵感(我们把它称作文档),依然是无休止地和bug作斗争。当有一天,一个新来 的同事拿着署着我的大名的文档,小心翼翼地来问我时,我发现自己好象有点不认识它了。我心里有点沮丧,再看看代码,发现文档上记录的一些灵感已面目全非。我当时不知道那位新来的同事感受如何,但我从那时起,好象意识到什么。现在来看,那时的很多事情都是事倍功半。rn  去年年底,公司派我到印度从事项目开发,学习印度的软件开发管理方法。一种久违的冲动在心底升起。印度,我已去过两次,虽说是走马观花,但是,印象还是比较深刻。我在访问过程中和印度的工程师交流过,他们言谈中透着自信。他们给我讲解正在做的软件的测试环境,给我看他们写的单元测试文档。当我看到一个软件模块的单元测试用例有三百多页时,我觉得心里很是沉重。当我第三次踏上这片土地时,我又见到了熟悉的人们,明亮的眼睛,温和的笑容,随意的穿着,风驰电掣的摩托,还有大学校园中穿着拖鞋,手抱书本的年轻人。rn  我也见到了我的项目经理,一个个子较高,瘦瘦的年轻人,据说刚从美国回来,已工作了五、六年。我听了心里很高兴,这回要一招一式地学两手。需求分析的时间是一个月,项目经理和我们(实际上代表客户 )讨论了proposal中的内容,确定每一项都是需要的。然后他把模块大致划分了一下,开始进入计划中的学习阶段。每个人在学习阶段要写出功能描述的胶片,给其他人讲解,不知不觉中,项目组的所有人对项目有了整体的了解。rn  他还安排了一些培训,如他们公司的软件开发模型、项目组中各角色的定义,以后及时的培训不断,只要项目组中有需求,他总是把qa或相关的人请来,培训很专业。需求分析完成后提交了一份四十多页的文档,当我看到这份英文文档中我写的部分整整齐齐地列在其中时,我的感觉很复杂,有些喜悦,但更多的是苦涩,我以前怎么就从来没有这样做过需求分析呢。rn  在我写文档的过程中,qa给我们培训过srs的写作模板,后来我还是不放心,让他们一个有经验的工程师写了一段,我们再琢磨着照着写。这份srs虽然是多个人合写,但风格一致,内容详实。更为可贵的是,一直到最后,这份需求分析的内容都没有改过,以至于我们没有机会走一下他们的需求更改流程。rn  需求分析是项目的第一阶段,第二阶段的开发时间要根据需求分析的结果来确定。当对方的首席技术官(相当于我们业务部的总体组长)来和我们讨论计划时,他们已列出了对每个 模块的代码行数的预测,可能存在的风险。根据他们公司的生产率--300行/人月,他得出了项目第二阶段需要多少周。rn  我们当时就提出了异议:1)公司对该项目需求很急;2)每月300行是否太少;3)我们还有下载的源代码参考。他解释说,300行/人月是使得项目能达到他们质量标准的经验数据,考虑到有源代码参考,生产率最多不能超过350行/人月。rn  当他问我们公司的生产率时,我脑袋里转了三个圈,没敢多说,大概六、七百行吧。他沉默了一会儿,然后坚定地说,我们这个计划是建立在确保质量的基础上的,我想你们到印度来开发软件,首先看中的应该是我们印度公司的质量保证。我知道你们不缺乏软件开发人员,你们为什么不选择下载的软件呢。几句话说到了我的痛处,现在国内的弟兄们还在为使用下载软件移植的产品四处奔波呢!rn  随后的开发活动有条不紊,我们老老实实地跟着做。系统测试计划、用例,概要设计,集成测试计划、用例,详细设计,单元测试计划、用例,编码,单元测试,集成测试,系统测试。一个完整的v模型开发过程,其中每个过程都有review。当我们对一些设计的方法不太明白时,项目经理给我们发来了相关的资料,我不知道他当时是怎么想的,一些基本的分析、设计方法是十年,甚至二十年前的软件工程书中就讲到的,印度每个计算机专业的人员都是必修这些内容的。而我们除了对一些具体协议的代码很熟之外,对这些常用的方法似乎一无所知。我感到一些羞愧,进城直奔书店,把他给我开列的书找了出来,晚上躺在床上,仔细研读,我仿佛突然又遇到了能给我指点迷津的良师益友。现在印度所已形成了强烈的学习风气。我回来后也推销了700多本书,这些书教我们如何用工程化的方法开发软件,是成为一个软件工程师必读的资料。rn  我们的项目经理的计划控制能力很强,当有什么影响到项目计划的事情发生时,如人员辞职、实验室搬家、某一模块预测不准(该模块是我们预测的),他总是采取必要的措施,减少延期,调整计划。刚开始,我们对他们每天上午11点,下午4点下楼喝咖啡还有点意见,后来也跟着喝去了,原来,喝咖啡时的交流非常丰富,从项目管理到设计方法,从技术发展到风土人情,无所不包,对我们互相之间的理解,对团队的气氛很有帮助。我们项目的qa也在适当的时候出现在我们的面前,我们对她的工作只有一些感性认识。她每次参加会议时,手里时常拿着一个check list,项目经理准备相应的资料,回答一些问题,她打着勾,或写着项目经理的解释。她给我们做培训时也很耐心,体现出很好的职业素养,我至今还在怀念她给我们的帮助。rn  我从事软件开发已有九个年头了,可我现在仍然不能说自己是个合格的软件工程师,更不用谈什么合格的管理者。我看到一份报道说,瑞士洛桑一权威机构把中国的科技综合竞争力从原来的第十三位调到二十多位,原因是他们调整了一些评估标准,其中有一条是中国合格工程师的可获得性非常低。想着弟兄们熬红的双眼,四处奔波升级的疲惫身影,我有一个强烈的愿望:快把我们自己升级成合格的工程师吧!rn 论坛

[推荐]请不要做浮躁的人 ---------- 来自于matrix

08-24

[推荐]请不要做浮躁的人 rn请不要做浮躁的人rn1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想rn出来再参考别人的提示,你就知道自己和别人思路的差异。rn2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久rn都是只对部分功能熟悉而已,不系统还是不够的。rn3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,rn虽然帮助的文字有时候很难看懂,总觉得不够直观。rn4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。rn5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸rn出很多知识点;不会举一反三你就永远学不会。rn6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。rn7.学脚本并不难,JSP、ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览rn群书;rn8.看再多的书是学不全脚本的,要多实践rn9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里;rn10.学习脚本最好的方法之一就是多练习;rn11.在任何时刻都不要认为自己手中的书已经足够了;rn12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看;rnrnrn13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;rn14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件;rn15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中;rn16.不要漏掉书中任何一个练习——请全部做完并记录下思路;rn17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余rn下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工rn作。rn18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的;rn19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能rn讲清楚才说明你真的理解了;rn20.记录下在和别人交流时发现的自己忽视或不理解的知识点;rn21.保存好你做过的所有的源文件----那是你最好的积累之一;rn22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先rn你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就rn能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒!rn23,到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问rn题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己rn的帖子没人回的。rn24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,rn如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的rn才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你rn讨论呢。rnrnrn浮躁的人容易问:我到底该学什么;----别问,学就对了;rn浮躁的人容易问:Js有钱途吗;----建议你去抢银行;rn浮躁的人容易说:我要中文版!我英文不行!----不行?学呀!rn浮躁的人分两种:只观望而不学的人;只学而不坚持的人;rn浮躁的人永远不是一个高手。 rnrnrn原文地址 http://www.matrix.org.cn/forum_view.asp?forum_id=19&view_id=900 论坛

[转帖] 请不要做浮躁的人(希望你我共勉)

08-31

请不要做浮躁的人rn1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想rn出来再参考别人的提示,你就知道自己和别人思路的差异。rn2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久rn都是只对部分功能熟悉而已,不系统还是不够的。rn3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,rn虽然帮助的文字有时候很难看懂,总觉得不够直观。rn4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。rn5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸rn出很多知识点;不会举一反三你就永远学不会。rn6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。rn7.学脚本并不难,JSP、ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览rn群书;rn8.看再多的书是学不全脚本的,要多实践rn9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里;rn10.学习脚本最好的方法之一就是多练习;rn11.在任何时刻都不要认为自己手中的书已经足够了;rn12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看;rn13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;rn14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件;rn15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中;rn16.不要漏掉书中任何一个练习——请全部做完并记录下思路;rn17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余rn下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工rn作。rn18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的;rn19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能rn讲清楚才说明你真的理解了;rn20.记录下在和别人交流时发现的自己忽视或不理解的知识点;rn21.保存好你做过的所有的源文件----那是你最好的积累之一;rn22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先rn你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就rn能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒!rn23,到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问rn题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己rn的帖子没人回的。rn24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,rn如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的rn才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你rn讨论呢。rnrn浮躁的人容易问:我到底该学什么;----别问,学就对了;rn浮躁的人容易问:JS有钱途吗;----建议你去抢银行;rn浮躁的人容易说:我要中文版!我英文不行!----不行?学呀!rn浮躁的人分两种:只观望而不学的人;只学而不坚持的人;rn浮躁的人永远不是一个高手。 论坛

《给浮躁的软件业同仁(3)》--李学凌

06-13

rnrnrn  他还安排了一些培训,如他们公司的软件开发模型、项目组中各角色的定义,以后及时的培训不断,只要项目组中有需求,他总是把qa或相关的人请来,培训很专业。需求分析完成后提交了一份四十多页的文档,当我看到这份英文文档中我写的部分整整齐齐地列在其中时,我的感觉很复杂,有些喜悦,但更多的是苦涩,我以前怎么就从来没有这样做过需求分析呢。 rnrn在我写文档的过程中,qa给我们培训过srs的写作模板,后来我还是不放心,让他们一个有经验的工程师写了一段,我们再琢磨着照着写。这份srs虽然是多个人合写,但风格一致,内容详实。更为可贵的是,一直到最后,这份需求分析的内容都没有改过,以至于我们没有机会走一下他们的需求更改流程。 rnrn需求分析是项目的第一阶段,第二阶段的开发时间要根据需求分析的结果来确定。当对方的首席技术官(相当于我们业务部的总体组长)来和我们讨论计划时,他们已列出了对每个 模块的代码行数的预测,可能存在的风险。根据他们公司的生产率--300行/人月,他得出了项目第二阶段需要多少周。 rnrn我们当时就提出了异议:1)公司对该项目需求很急;2)每月300行是否太少;3)我们还有下载的源代码参考。他解释说,300行/人月是使得项目能达到他们质量标准的经验数据,考虑到有源代码参考,生产率最多不能超过350行/人月。 rnrn当他问我们公司的生产率时,我脑袋里转了三个圈,没敢多说,大概六、七百行吧。他沉默了一会儿,然后坚定地说,我们这个计划是建立在确保质量的基础上的,我想你们到印度来开发软件,首先看中的应该是我们印度公司的质量保证。我知道你们不缺乏软件开发人员,你们为什么不选择下载的软件呢。几句话说到了我的痛处,现在国内的弟兄们还在为使用下载软件移植的产品四处奔波呢! rnrn  随后的开发活动有条不紊,我们老老实实地跟着做。系统测试计划、用例,概要设计,集成测试计划、用例,详细设计,单元测试计划、用例,编码,单元测试,集成测试,系统测试。一个完整的v模型开发过程,其中每个过程都有review。当我们对一些设计的方法不太明白时,项目经理给我们发来了相关的资料,我不知道他当时是怎么想的,一些基本的分析、设计方法是十年,甚至二十年前的软件工程书中就讲到的,印度每个计算机专业的人员都是必修这些内容的。而我们除了对一些具体协议的代码很熟之外,对这些常用的方法似乎一无所知。我感到一些羞愧,进城直奔书店,把他给我开列的书找了出来,晚上躺在床上,仔细研读,我仿佛突然又遇到了能给我指点迷津的良师益友。现在印度所已形成了强烈的学习风气。我回来后也推销了700多本书,这些书教我们如何用工程化的方法开发软件,是成为一个软件工程师必读的资料。 rnrn  我们的项目经理的计划控制能力很强,当有什么影响到项目计划的事情发生时,如人员辞职、实验室搬家、某一模块预测不准(该模块是我们预测的),他总是采取必要的措施,减少延期,调整计划。刚开始,我们对他们每天上午11点,下午4点下楼喝咖啡还有点意见,后来也跟着喝去了,原来,喝咖啡时的交流非常丰富,从项目管理到设计方法,从技术发展到风土人情,无所不包,对我们互相之间的理解,对团队的气氛很有帮助。我们项目的qa也在适当的时候出现在我们的面前,我们对她的工作只有一些感性认识。她每次参加会议时,手里时常拿着一个check list,项目经理准备相应的资料,回答一些问题,她打着勾,或写着项目经理的解释。她给我们做培训时也很耐心,体现出很好的职业素养,我至今还在怀念她给我们的帮助。 rnrn  我从事软件开发已有九个年头了,可我现在仍然不能说自己是个合格的软件工程师,更不用谈什么合格的管理者。我看到一份报道说,瑞士洛桑一权威机构把中国的科技综合竞争力从原来的第十三位调到二十多位,原因是他们调整了一些评估标准,其中有一条是中国合格工程师的可获得性非常低。想着弟兄们熬红的双眼,四处奔波升级的疲惫身影,我有一个强烈的愿望:快把我们自己升级成合格的工程师吧 论坛

《给浮躁的软件业同仁(1)》--李学凌

05-29

给浮躁的软件业同仁(1)rnrn[ 作者: 李学凌 添加时间: 2002-2-4 16:11:18 ]rnrnrn rnrn来源:bbs.ustc.edu.cn zhuan csdnrnrn给浮躁的软件业同仁(zhuan csdn) rnrn以下文章都是经典,看不看随你的便,我只希望知识掌握在更多中国人的手里! rnrn中国有很多小朋友,他们18,9岁或21,2岁,通过自学也写了不少代码,他们有的代码写的很漂亮,一些技术细节相当出众,也很有钻研精神,但是他们被一些错误的认识和观点左右,缺乏对系统,对程序的整体理解能力,这些人,一个网上的朋友说得很好,他们实际fans,压根没有资格称为程序员,但是据我所知,不少小网络公司的Cfans,拿着吓人的工资,做着吓人的项目,项目的结局通常也很吓人。 rnrn程序员基本素质: rnrn作一个真正合格的程序员,或者说就是可以真正合格完成一些代码工作的程序员,应该 rn具有的素质。 rnrn1:团队精神和协作能力 rnrn把它作为基本素质,并不是不重要,恰恰相反,这是程序员应该具备的最基本的,也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语,任何个人的力量都是有限的,即便如linus这样的天才,也需要通过组成强大的团队来创造奇迹,那些遍布全球的为linux写核心的高手们,没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财,但是一旦进入一些大系统的研发团队,进入商业化和产品化的开发任务,缺乏这种素质的人就完全不合格了。 rnrn2:文档习惯 rnrn说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子,良好的文档是正规研发流程中非常重要的环节,作为代码程序员,30%的工作时间写技术文档是很正常的,而作为高级程序员和系统分析员,这个比例还要高很多。缺乏文档,一个软件系统就缺乏生命力,在未来的查错,升级以及模块的复用时就都会遇到极大的麻烦。 rnrn3:规范化,标准化的代码编写习惯 rnrn作为一些外国知名软件公司的规矩,代码的变量命名,代码内注释格式,甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定,良好的编写习惯,不但有助于代码的移植和纠错,也有助于不同技术人员之间的协作。 rnrnfans叫嚣高水平程序员写的代码旁人从来看不懂,这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性,是程序员基本的素质需求。 rnrn再看看整个linux的搭建,没有规范化和标准化的代码习惯,全球的研发协作是绝对不可想象的。 rnrn4:需求理解能力 rnrn程序员需要理解一个模块的需求,很多小朋友写程序往往只关注一个功能需求,他们把性能指标全部归结到硬件,操作系统和开发环境上,而忽视了本身代码的性能考虑,有人曾经放言说写一个广 告交换程序很简单,这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的,对于这样的程序员,你给他深蓝那套系统,他也做不出太极链的并访能力。性能需求指标中,稳定性,并访支撑能力以及安全性都很重要,作为程序员需要评估该模块在系统运营中所处的环境,将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点,一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。 rnrn5:复用性,模块化思维能力 rnrn经常可以听到一些程序员有这样的抱怨,写了几年程序,变成了熟练工,每天都是重复写一些没有任何新意的代码,这其实是中国软件人才最大浪费的地方,一些重复性工作变成了熟练程序员的主要工作,而这些,其实是完全可以避免的。 rnrn复用性设计,模块化思维就是要程序员在完成任何一个功能模块或函数的时候,要多想一些,不要局限在完成当前任务的简单思路上,想想看该模块是否可以脱离这个系统存在,是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用,这样就能极大避免重复性的开发工作,如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题,那么程序员就不会在重复性的工作中耽误太多时间,就会有更多时间和精力投入到创新的代码工作中去。 rnrn一些好的程序模块代码,即便是70年代写成的,拿到现在放到一些系统里面作为功能模块都能适合的很好,而现在我看到的是,很多小公司软件一升级或改进就动辄全部代码重写,大部分重复性工作无谓的浪费了时间和精力。 rnrn6:测试习惯 rnrn作为一些商业化正规化的开发而言,专职的测试工程师是不可少的,但是并不是说有了专职的测试工程师程序员就可以不进行自测;软件研发作为一项工程而言,一个很重要的特点就是问题发现的越早,解决的代价就越低,程序员在每段代码,每个子模块完成后进行认真的测试,就可以尽量将一些潜在的问题最早的发现和解决,这样对整体系统建设的效率和可靠性就有了最大的保证。 rnrn测试工作实际上需要考虑两方面,一方面是正常调用的测试,也就是看程序是否能在正常调用下完成基本功能,这是最基本的测试职责,可惜在很多公司这成了唯一的测试任务,实际上还差的远那;第二方面就是异常调用的测试,比如高压力负荷下的稳定性测试,用户潜在的异常输入情况下的测试,整体系统局部故障情况下该模块受影响状况的测试,频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对自己的每段代码都需要进行这种完整测试,但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求,有针对性的进行相关测试并尽早发现和解决问题,当然这需要上面提到需求理解能力。 rnrn7:学习和总结的能力 rnrn程序员是人才很容易被淘汰,很容易落伍的职业,因为一种技术可能仅仅在三两年内具有领先性,程序员如果想安身立命,就必须不断跟进新的技术,学习新的技能。 rnrn善于学习,对于任何职业而言,都是前进所必需的动力,对于程序员,这种要求就更加高了。但是学习也要找对目标,一些小coding有些codingTO就是这样的coding上只是一些Cfans们,他们也津津乐道于他们的学习能力,一会学会了asp,一会儿学会了php,一会儿学会了jsp,他们把这个作为炫耀的资本,盲目的追逐一些肤浅的,表面的东西和名词,做网络程序不懂通讯传输协议,做应用程序不懂中断向量处理,这样的技术人员,不管掌握了多少所谓的新语言,永远不会有质的提高。 rnrn善于总结,也是学习能力的一种体现,每次完 成一个研发任务,完成一段代码,都应当有目的的跟踪该程序的应用状况和用户反馈,随时总结,找到自己的不足,这样逐步提高,一个程序员才可能成长起来。 rnrn一个不具备成长性的程序员,即便眼前看是个高手,建议也不要选用,因为他落伍的时候马上就到了。具备以上全部素质的人,应当说是够格的程序员了,请注意以上的各种素质都不是由IQ决定的,也不是大学某些课本里可以学习到的,需要的仅仅是程序员对自己工作的认识, rn是一种意识上的问题。 rnrnrn那么作为高级程序员,以至于系统分析员,也就是对于一个程序项目的设计者而言,除了应该具备上述全部素质之外,还需要具备以下素质: rnrn第一,需求分析能力 rnrn对于程序员而言,理解需求就可以完成合格的代码,但是对于研发项目的组织和管理者,他们不但要理解客户需求,更多时候还要自行制定一些需求,为什么这么说呢? rnrn一般而言,进行研发任务,也许是客户提出需求,也许是市场和营销部门提出的需求,这时候对于研发部门,他们看到的不是一个完整的需求,通常而言,该需求仅仅是一些功能上的要求,或者更正规些,可能获得一个完整的用户视图;但是这都不够,因为客户由于非技术因素多一些,他们可能很难提出完整和清晰,或者说专业性的性能需求,但是对于项目组织者和规划者,他必须能够清醒认识到这些需求的存在并在完成 需求分析报告的时候适当的提出,同时要完整和清晰的体现在设计说明书里面,以便于程序员编码时不会失去这些准则。 rnrn程序设计者必须正确理解用户需求所处的环境,并针对性做出需求的分析,举例而言,同样一个软件通过ASP租用方式发布和通过License方式发布,性能需求可能就是有区别的,前者强调的是更好的支撑能力和稳定性,而后者则可能更强调在各种平台下的普适性和安装使用的简捷性。 rnrn第二,项目设计方法和流程处理能力 rnrn程序设计者必须能够掌握不少于两到三种的项目设计方法(比如自顶至下的设计方法,比如快速原型法等等),并能够根据项目需求和资源搭配来选择合适的设计方法进行项 目的整体设计。设计方法上选择不当,就会耽误研发周期,浪费研发资源,甚至影响研发效果。 rnrn一个程序设计者还需要把很多功夫用在流程图的设计和处理上,他需要做数据流图以确立数据词典;他需要加工逻辑流图以形成整体的系统处理流程。一个流程有问题的系统,就算代码多漂亮,每个模块多精致,也不会成为一个好的系统。当然,做好流程分析并选择好项目设计方法,都需要在需求分析能力上具有足够的把握。 rnrn第三,复用设计和模块化分解能力 rnrn这个似乎又是老调重谈,前面基本素质上不是已经说明了这个问题吗?作为一个从事模块任务的程序员,他需要对他所面对的特定功能模块的 复用性进行考虑,而作为一个系统分析人员,他要面对的问题复杂的多,需要对整体系统按照一种模块化的分析能力分解为很多可复用的功能模块和函数,并针对每一模块形成一个独立的设计需求。举个例子,好比是汽车生产,最早每辆汽车都是独立安装的,每个部件都是量身定做的,但是后来不一样了,机器化大生产了,一个汽车厂开始通过流水线来生产汽车,独立部件开始具有一定的复用性,在后来标准化成为大趋势,不同型号,品牌甚至不同厂商的汽车部件也可以进行方便的换装和升级,这时候,汽车生产的效率达到最大化。软件工程也是同样的道理,一个成熟的软件行业,在一些相关项目和系统中,不同的部件是可以随意换装的,比如微软的许多桌面软件,在很多操作模块(如打开文件,保存文件等等)都是复用的同一套功能模块,而这些接口又通过一些类库提供给了桌面应用程序开发者方便挂接,这就是复用化的模块设计明显的一个佐证。 rnrn rn rnrn rn 论坛

浮躁的社会中,浮躁的我又想换工作了……

03-29

其实我本来只想发个关于换岗的咨询帖的,结果不小心写成了一篇个人经验分享、新手就业指导的四不像,就当成故事来发吧,大家随便看个热闹,新手可以留意一下相关建议,高手直接看最后一段里的问题吧,也别光看热闹,好歹回复一下,呵呵。rnrnrn[b]恍若隔世的第一份工作[/b]rn 先介绍一下背景吧,在下本科科班出身,出自著名的北京四大染缸之首的北工大,说起来,尽管学校不怎么样,但好歹也混进了211工程,而且貌似工大的计算机专业还有点名气(也可能是大家自我安慰谣传出来的)。不过不管学校如何,在下的大学生涯跟绝大部分人一样,是在睡觉、网游、泡MM(只泡过一个,现在是我媳妇儿了)中度过的,到毕业时除了文凭几乎什么收获都没有。但是纠结于要不要上大学的兄弟们可千万别以为上大学没用,撇开个人素质修养,上过大学的还是跟没上过的差距很大,关于这点后面还会提到。rnrn 大四时由于WOW开始公测,于是毕设、实习都是糊弄过去的,更别提自己找工作了,临近毕业,有位师兄帮忙推荐了一家公司,因为面子太大,连面试、试用都没有,直接就进去了。做的是当时最火的OA,不过用的是lotus开发,由于语法类似VB,所以上手很容易,很快就参与开发了一个项目中的几个模块。不过公司规模比较小,很快就没新项目了,于是被派到用户现场做了半年维护,其实现在想起来能有机会跟用户打交道,真是一个很好的机会,可惜当时还是抱着技术至上的心理,再加上天生内向,所以没把握住这个机会。维护了小半年,每天都在熬时间的痛苦中度过——用户现场不能上网,而且部门经理也在现场,又不能玩游戏,有时一星期才有1、2个咨询的电话,那真是度日如年啊……但话又说回来,用户现场是纯国企,能够闲得蛋疼,可见为什么关于就业咨询的贴都会将国企列为优势资源。rnrn 当时的IT业竞争还没这么大,再加上我们这种半国企几乎不会受到外来的竞争,所以当时根本没考虑过职业规划的问题,不过在工作一年期满时,我还是决定离职,因为lotus这东西技术含量太低了,又不是主流,说不定哪天就被淘汰了。不过很遗憾的是我职业生涯的第一次判断就错了一半,虽然lotus现在仍然半死不活,几乎只有IBM内部邮件在用,但是这方面的工作还是很好找,而且由于从业人员少,4、5年经验很容易就能当上项目经理。而对于中国的程序员来说,码工——项目经理——中层管理这条路几乎是必走的,现在在做java,很明显没那么容易升任项目经理了。rnrnrn[b]就业培训那点事[/b]rn 就当年的形势来说,java是性价比最高的语言,入门比C简单得多,又比VB技术含量高,所以在做维护的期间我报了北大青鸟的培训。虽然很多高手对培训不屑一顾,而且很多技术经理招聘时直接pass掉培训机构出来的,但是我觉得这个事还是要分析一下再下定论。rnrn 可能青鸟教的东西不怎么样,而且就业班也是以忽悠为主,但毕竟是以实训为主,比起大学的纯理论,或者只有C、VB的实训来说,能直接编一些中小型的java、.net项目,还是很锻炼人的。另外像在下这种懒散的人,如果没人领着,工作又稳定,断然不会努力地去自学。而自己做项目练习,也不会像学校布置的这种,有一个明确的思路,并且为了获奖,在遇到一些困难时不会绕路而是查资料想办法解决,这种查资料的能力其实也很重要,最明显的例子就是班里人人都能上网,但是有些问题只有我想到了正确的关键字从而查到了解决方法。rnrn 综上所述,培训这种事比较适合这样一类人:一是有学历的,这个是入职的门槛,培训机构是搞不定的,再者,科班出身的人对于数据库、软件工程等相关理论确实比纯培训的人强,即使我这种上学不好好听的,在做项目的数据库设计时,也不自觉地就按照三范式去设计了;二是没有项目经验的,虽然培训机构出来的人简历都一样,但是这种方向明确的项目练习还是比自己随便找个题材设计要严谨,而且像我之前说的,在做的时候也会努力实现所有要求,而不会随便放弃;最后是就业班至少是个后备,实在找不到工作了,还可以靠它推荐,不管工作如何,至少能凑合上一个,有了后备压力会小很多的。rn当然,这一段的基础是我参加了这个培训,当然会说些好听的,要不自己的2W多块就白扔了……所以诸位看看就好,别太当真。rnrnrn[b]好马不吃回头草[/b]rn 上面说到就业班可以推荐,可惜当时没用上,在我开始学三期时,原来的公司开始将lotus平台的OA系统向java平台迁移。由于三期课很少,一周只上两天,所以当时厚着脸皮跑回原来公司兼职,既能做真实项目锻炼又能赚点钱,不过后来证明,这个决定虽然也不能算错,但是对于职业发展几乎没有帮助,而我居然在三年之后才发现……rn rn 兼职期间是处于平台研发期,虽然是老大一个人搞定,至少周边的零碎研究还能接触一些,所以在临近毕业时,我很慎重地思考了一下未来,如果通过青鸟推荐,运气好的话能找到4、5K的工作,最高的人据说能到8K,我是不太相信,但找工作本来就有运气的成分,也可能是真的,而继续在原公司做的话,只有不到3K,差距有点大。所以最初我是通过推荐面试了几家,不过都是相当小的公司,甚至有一家就是居民楼的普通3居……我强烈怀疑去了这种公司后可能今天做java明天做.net,再过两天就去做销售了,而我原来的公司至少是比较稳定的,所以为了所谓的技术积累,我还是决定留在原公司。rnrn 现在看来,技术积累真是一件很扯淡的事,当时幻想着做上几年的java,工资就能水涨船高——事实确实如此,后来的几年工资都是按每年1K增加,但是,跟那些一开始就进那种业务不专的公司的同学比,薪资水平还是在一条线上,甚至仍比别人低。诚然,那些人今天java明天php的,似乎很不稳定,但我也没在java方面有更深的造诣,还只是码工而已;那些人进公司时4、5K,甚至8K,现在仍在原地踏步,但我还是没追上他们……rnrn 所以还在纠结于选择高薪还是发展的同学们,不要用“有前途”来自欺欺人了,抓紧年轻的优势吧,在我国码代码是码不了一辈子的,你将来必然会走上别的岗位,技术迟早会成为衡量你价值的次要因素甚至都不再是因素。当然真能静下心做研究的人不在此列,毕竟还是有很多专门的研究机构的,不过除了国企研究院外,大部分研究机构的工资应该也不会低。rnrn 至于本段的标题,纯粹是个人问题,在之前一年的工作里,已经对国企这种不思进取的做法很不满了,结果隔了半年多居然又回来了,想想可能还是自己懒吧,习惯了这种无压力的生活,有点离不开了,就像飞蛾总围着灯转、苍蝇总能找到厕所一样……rnrnrn[b]做小项目的出路在哪?[/b]rn 我们公司的主营是OA,这个玩意大家都应该知道,流程引擎定下来之后,所有项目都要定制开发的,这就跟人们经常批判外包接触不到核心技术一样,回公司后基本就开始拼命做项目,由于底层一样,所以每次就是那点代码来回粘贴,真是毫无技术含量。rnrn 这又验证了一个观点,所谓进大公司当炮灰,进小公司练技术,很遗憾,还是扯淡……做OA的厂商不少,像普元这种,我猜肯定不是依靠定制开发项目赚钱,人家卖的是产品,对技术人员来说,应该有底层升级或者咨询实施这类工作可以做,远比二次开发技术含量高。小公司用户层比较窄,面对的业务领域也单一,从需求到编码到实施都是同一套东西,你做过10个项目又能怎样?跟1个项目没有区别啊。rnrn 但是那3年公司发展较快,领域虽然单一,可是项目不少,在不停地加班中渐渐忘记了思考职业规划,等到想跳槽时才发现简历里的项目内容都是可以互相粘贴的,而简历中最值钱的部分竟然是兼职那几个月里搞的一些研究……真是欲哭无泪啊。rnrnrn[b]抱大腿重要?先看你站在哪队里……[/b]rn 其实在下混职场不过5年,要总结出点门道来很难,更何况对于技术人员来说,职场相对来说还不算是很复杂的。就分享一下经历当做抛砖引玉吧。rnrn 在下天性比较严谨,心很重,想事情也想得比较多,而且不太合群,按说职场上那些事应该跟我没什么关系,但是经历了才知道“常在河边走哪能不湿鞋”有多正确。本来第二次辞职的直接原因是上一段提到的,对技术积累的又一次审视,但不得不说,以我辞职时的人际关系来看,也很难在这公司继续混下去了。rnrn 如果是1年前的我,写到这个话题时可能会抱怨至少5千字,不过现在我只想说自己的问题。在离职前的半年,当时有一本书很火,被誉为修身养性必备——《不抱怨的世界》,我看的是它的跟风作品《做不抱怨的员工》,前者有更多职场外的东西,而后者却是为中国白领定制的,显然可学习的地方更多。当时看时已经发觉自己身上的很多不足了,不过当时正在气头上,还是觉得公司对我太不公平,现在冷静下来看,这不公平也总归得有根源吧。rnrn 应该说抱大腿这件事是没错的,而我抱的也很成功,跟部门一位副经理关系不错,但关键问题是,我是隶属于另一位副经理的。由于公司较小,两个经理一个偏业务,一个偏技术,基本所有项目都是两个人共同挂名的,但让我出局的是一个没有挂名的项目。这个事是我后来在IBM做外包才深刻体会到的,就是职场上的等级制度,比如杜拉拉小说的人物介绍,直接写谁向谁汇报,以此来明确组织层级。rnrn 由于没有经理挂名,我理所当然地认为不需要向谁汇报,项目经理(我媳妇儿)知道大概就可以了,而她太忙,那自然是我全权负责了,于是从需求到编码再到测试部署,一个人忙了大半年,期间公司层面对整个项目完全不知晓,虽然我的直属领导不太计较这种事,但是大半年没跟他交流过,逐渐被边缘化也就不奇怪了。在我提辞职后,业务经理出于私交跟我长谈了一次,包括分析就业压力和公司前景等,但留下来的话还是技术经理手下,已经闹到这步,不可能再继续了。rnrn 总之,经历过这事后,我才发现自己只是比同龄人稍成熟些,跟职场上混过10年以上的人比还远不够班啊,尤其现在在外企做外包,感觉跟国企的风格又不一样,想出人头地还是要与人斗才行呐。其实这个话题还可以展开的,但是按之前说的不能抱怨的话,还真没啥能说的了,就这样吧,有关职场的混法,还是等牛人来普及吧。rnrnrn[b]技术和业务孰轻孰重?[/b]rn 又一次从原公司离职,这回是我第一次自己找工作,当时在javaeye论坛里咨询过一贴,问做了四年OA能值多少钱,虽然我在贴里写了技术不怎么样,但是很多人给出的答案都在8K左右,这让我多少有了点信心。但很明显,大家都只关注了4年的java开发经验,并没有深究开发的是什么,只有个别人从业务角度出发,认为4年经验也很不错了。可是当时我对于OA已经没什么信心了,为了提高技术,想做一些更有技术含量的东西,比如j2se方面的。rnrn 把简历挂到网上后,很快就有外包公司打来电话,并承诺工资可以到8K,于是我便认准了自己真值这个钱。结果之后的几次笔试真是让我无地自容,有一次前台的面试干脆直接交了白卷(本来不想去的,但是当时已经离职了,不去也没事干,就当出去透透气了)。其实虽然当时有点信心,但是自己水平几斤几两还是很清楚的,离职时就备好了几本j2ee的大作开始研究,毕竟这方面有经验,比找j2se的工作靠谱多了。rnrn 但是技术这玩意真得不能琢磨,越看越深,最后发现如果想把这块补补再找工作的话,可以在家待两年了……在后来的一次外企面试中,我干脆是抱着咨询的态度去的(因为英语不行肯定进不去),跑去问面试的技术经理怎么系统地学习j2ee。面试到第10家公司时,终于被录用了,想来是因为外包对技术要求不高吧,而且在进项目组之后才发现,这里的本科生比例真不高,所以估计科班出身也有少许加成作用吧。rnrn 总结这10次面试,没有一家跟业务有关,只有两家是做OA的,也只是招技术人员,但毕竟本身就是技术出身,也没那么容易就换岗吧。可是当时已经开始觉得业务的重要性了,主要是在深入了解了j2ee后,原来之前被我认为没什么技术含量的web开发也这么多讲究,这根本不是一朝一夕能吃透的,以我这种懒散的性格,不可能在技术路上一直走下去,想换岗的话,迟早有一天要更加重视业务能力。当然这是一个比较抽象的想法,对于当时的我来说,所谓的业务只是OA中流程如何设计而已。rnrnrn[b]关于外包的那些事[/b]rn 尽管在论坛里看不到外包的一点好话,但是在我信心受挫时还是决定先找个工作再说,于是就进了IBM的这个项目组。当然也不是随便就进来了,根据自身情况分析后,我觉得外包对我好像没什么影响,下面也列出来供大家参考吧。rnrn 网上诟病的外包几宗罪里,第一是累,不过据说IBM比起华为之类的来要好很多,再说,做项目有不累的吗?原来在国企做项目都整天加班呢。而且累不累要看在哪个岗位做,不一定都很累,这是已经做了一年后得出的结论。再一个是归属感,这个也无所谓,随遇而安嘛,原来公司也经常常驻客户那边开发,现在也是IBM给别人做,应该差别不大吧。第三就是所谓的接触不到核心技术,好吧,我原来的公司开发组不过6个人,底层代码都只有老大一个人掌握,我还真不信抱着这个观点的人都是各公司的核心人员。rnrn 再来是自身原因,之前在国企懒散惯了,虽然也会加班,但技术停滞不前,在跳槽前已经计划到外包公司吃一下苦了,所谓矫枉必须过正,也算是督促自己进步吧。反正不打算长干,就当体验生活了。rnrn 以上,总结一下,外包也不一定是洪水猛兽,跟培训机构一样,可以尝试一下,当然我一个人的现状肯定比不过网上那么多负面评论,毕竟有运气成分在里面,总的来说外包还是很累的,周围很多86-89的小孩头发都白了,我一个做对日外包的同学也是半年没见头发白了一片,对自己RP有信心的可以尝试一下。rnrnrn[b]业务大于技术?你确定你所谓的业务真的能称为业务?[/b]rn 为防止对号入座,项目就不特别介绍了,反正是IBM做的通信领域三巨头之一的全国级的项目。在这里的一年,真的算是长了见识,现在想想,如果当年从青鸟出来就能进这里做外包的话(就我这外语水平,不幻想能直接进IBM),现在应该能成长得很不错了,广大的年轻人啊,请谨慎选择第一份职业,真的很重要啊……rnrn 刚进来时我被分在了接口组,虽然没进流程组有点意外,但后来发现没进去真的躲了N多的加班。第一项任务是开发几个接口,当时正对j2ee无限崇拜,又有机会在这种优秀的架构上开发,真的提高了不少,很多设计模式的思想比自学时理解得快多了,甚至利用业余时间开始重构以前做的工程。rnrn 接口组,自然不会总有开发任务,之后开始处理接口问题导致的错误数据,因为之前sql水平也不高,group by这类都玩不利索,所以这一段时间也过的很愉快,至少在技术方面有提高吧,不过几个月过后,兴奋有点减弱,又开始思考职业规划问题。理由很简单,加班实在太频繁了。虽然我的工作量没有那么大,但是看几个项目经理没日没夜的加班,我觉得在这个行业里混下去代价真的很大。我是那种很顾家的人,如果我到了老大们的岁数,有了孩子,肯定不会像他们那样玩命,25岁以后我就不再幻想自己还能成什么大事,所以家庭肯定是第一位的。rnrn 在这个阶段我又开始考虑转到业务岗位上去,尤其是鼓捣了2个月的sql,编码又被放下了。这时项目组来了位技术总监Y大,IBM的等级太复杂,闹不清级别,反正感觉很牛,这个人对我的影响真的很大,我第一次开始考虑所谓的业务到底是什么。rnrn Y大进来后先是找各组人员谈话,对于接口组来说,显然技术不是第一位的,因为要跟别的系统打交道,自然不能光了解自己的业务,也要对别的项目的业务有所了解。虽然我早就体会了业务很重要,但从这种等级的人嘴里说出来,明显比自己体会要深刻的多,当然论坛里有各种大牛,会把这观点抽得体无完肤,但是对于我未来的方向来说,显然这个观点是可以成立的。rnrn 业务到底是什么呢?各位还是自己百度去吧,我是有点领悟了,但肯定说不了那么准确,反正比起当初某领域内的OA来说,整个通信行业显然更有资格称为一个业务领域,Y大自己做了N(>10)年通信,仍然觉得了解的广度不够,显然这才是真正的业务人员,而不是之前我以为的需求人员。从这个角度说,似乎本身从事通信领域的人跳槽到IT行业竞争力更大,但我肯定不能从零开始了,看运气吧。rnrnrn[b]未来的路在哪里?[/b]rn 之后的两件事让我认真开始考虑换岗了,毕竟算是有了机会。一是由于人员流动,我做了接口组的leader,虽然当时没有开发任务,只是负责支撑响应,但是好歹也是全国范围的项目,又有很多个系统集成,对于“推磨”的功夫提高了不少,这里的推磨并不是完全推卸责任,做过的人都知道,防人之心不可无,你不推磨,所有问题就都成你的问题了。rnrn 由于个性谨慎,再加上之前也算混过国企,所以本来认为自己在这方面没什么问题——也确实做的还可以,不过跟当时的直属领导L大比还是逊色不少。比如自己自认为文笔还可以,当时的主要工作就是发邮件协调各项目组,而L大的第一封邮件就让我学到很多,当时是我先出的邮件,感觉说的不甚明了,虽然很详细但重点不够突出,之后就看到L大补充说明了一分邮件,那水平确实高出一截。至于其它的沟通技巧就不多说了,毕竟这种事负面影响也很多,职场新人太早学了消化不了。rnrn 其二是支撑告一段落后,分配我去做了实施。据Y大说是比较看重我,觉得我有点内向,需要锻炼一下。这就是我在前面提过的,学历很重要,因为周围大部分不是本科学历;再者就是个人素质了,至少能让你在百十来号人中被领导发现。当然做好本职工作是必须的,只是在大家都做的不错时,你需要有一项技能让自己鹤立鸡群,哪怕这个技能跟工作完全无关。当然这一段是我猜的,毕竟我不能去问领导为什么关注我,所以新人们看看就好,有空还是去向更牛的人学习吧。rnrn 好吧,本文的主题终于出现了:经历这两件事后,我已经远离编码半年了,再加上本身也想换到非技术岗位,所以想咨询一下大大们,有什么好的建议,尤其是曾经顺利换岗的大牛们。虽然我现在的视野比1年前开阔了不少,但是仍然是管中窥豹,我觉得目前可以做的岗位就是实施顾问这一类,偏业务,但又不用很深的业务知识,好像比较有前途的是ERP方面的吧,但是不知道门槛有多高,在接口中跟它打过交道,而且最近报了会计培训(又是培训,真没长进啊……),不过感觉也不会轻松地找到工作。不知是否还有类似的岗位?虽然现在薪水只有7K5,并不算高,但是换岗位的话估计还要再降吧,按现在的通胀来看,有没有什么好的办法可以逐渐过渡?再一个就是行业领域,虽然现在做个跟通信业本身不沾边,但是Y大的思路是对的,不管有没有关系,我也是在这个圈里混了一年,总比去别的圈子从头开始强吧,而且我看几个招聘网站,不少ERP方面的实施也都在这个圈里,是否还有别的不错的领域,也恳请大大们指教。rnrn 最后,本人的技术确实很烂,这一点上大家应该都知道只做过web项目的人能会点啥,而且在下在这方面没什么上进心,看我码这么多字就知道,我是比较偏文科的,只是高中分班时不想背书,才选了理科。所以高手可以就这点随意拍砖,反正我不打算做技术了,怎么拍也不会影响信心。不过我还是希望高手多提意见而不是拍砖,O(∩_∩)O哈哈~rn 论坛

浮躁的职场新手,请不要再浮躁了. -- 真倒霉啊!

04-04

其实也没有什么好写的.只是今天被家里人骂了一顿.心理还是有点不愉快.很郁闷.不知道如何表达出来.只好写在blog上了.就当抒发一下自己的情感. rn   事情是这样.我是今年7月才毕业的学生,计算机专业的.在学生时代,觉的什么都没学到.只能靠自学.所以到了要毕业的时候,很想在外面闯荡一番.不管成败.刚出来的时候,因为自己的专业在当地还是比较吃香的,投了很多的企业,也有很多的叫我去面试.所以我去了一家公司。那家公司虽不是很大,但是也是能不错的企业,也能学到很多的东西.所以我面试了第二天.那家叫我去当实习生.我也就答应了.rn   很快.一个星期过去了.也培训了一个星期.对公司也有了一定的了解.对业务也渐渐名目了.公司开始外派人员到外地去实地培训.我就理所当然的被外派到1个小城市.rn   我接到这个通知.第二天稍微准备了一下,第三天就走了.到了那边.人生地不熟.所以叫当地的同事到车站接我一下(因为公司竟然不给我当地的地址,我只好叫当地同事出来接我).同事到了车站,问我要先到公司,还是先去办公地点.我就看看时间还没有到下班时间.就说先去办公地点了.到了那边.也还好.然后我问了我的工作内容.我的同事就一一给我讲解了一下.当是我问我到我是做软件开发的(因为我应聘的是开发部门的).他就觉的奇怪了.因为这边都是做维护的.我也被当时的情况急了.但是我没有马上给总公司回电话,问情况.到了第二天,我就受不了现在工作的内容.所以我就向公司询问了我的工作内容.公司明确答复是做维护.我的心一凉.难道我被骗了.而且还说,做维护能够提高对业务的熟悉度.对以后的开发也是很有帮助的。但是为什么一开始不明确的说明呢.到了办公地点才说.我真的受不了了.我认为我真的被骗了.所以后面几天.我做事越漫不经心了.上班经常迟到,有的时候就干脆没去.而且每天的工作内容实在是很无聊,就是看.看到我都心烦.所以有的时候我就偷偷的学些开发的东西.以防以后找工作不好找.  rn   也就这样做了2个星期.我真的不知道那两个星期,我是怎么过来的.实在是超级无聊.周六周日,更惨.一个人在外地.没同学.没朋友.走出去没事做.平常就干脆呆在宿舍里.每天就是2点一线的.人都快成机器人了.一想到这样,我就心烦啊!我就打电话,跟我家里人说,我不想做了.真的,不想了.在这里不能提升技能.但是家里人极力反对.说我人很浮躁.说什么事都不安心.看到别人的东蹦西跑.你也跑.看到别人找到好的工作.你也呆不住.现在很多的单位不要那种,跳来跳去的人.认为这种人不安心.做不了什么事.rn   但是我说我想做开发的时候,我家里人说现在很多的大学生,都是找不到对口的工作.找到了工作做事一定要塌实.不能三心二意.企业也是付出成本的.最好还是不要跳来跳去.最后会得不偿失的。rn   哎^怎么说呢.我现在没了头绪,什么都没有了.只能写写字.表达一下自己的想法.确实我家里的人的意见是正确.但是我心有不甘。我不想就这样活着,我想有些发展。也欢迎大家能给我些意见.rnrn 论坛

【转载】请不要做浮躁的人--我觉得很适合CSDN上一些提问者

07-26

请不要做浮躁的人rn1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想rn出来再参考别人的提示,你就知道自己和别人思路的差异。rn2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久rn都是只对部分功能熟悉而已,不系统还是不够的。rn3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,rn虽然帮助的文字有时候很难看懂,总觉得不够直观。rn4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。rn5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸rn出很多知识点;不会举一反三你就永远学不会。rn6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。rn7.学脚本并不难,JSP、ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览rn群书;rn8.看再多的书是学不全脚本的,要多实践rn9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里;rn10.学习脚本最好的方法之一就是多练习;rn11.在任何时刻都不要认为自己手中的书已经足够了;rn12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看;rn13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;rn14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件;rn15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中;rn16.不要漏掉书中任何一个练习——请全部做完并记录下思路;rn17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余rn下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工rn作。rn18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的;rn19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能rn讲清楚才说明你真的理解了;rn20.记录下在和别人交流时发现的自己忽视或不理解的知识点;rn21.保存好你做过的所有的源文件----那是你最好的积累之一;rn22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先rn你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就rn能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒!rn23,到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问rn题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己rn的帖子没人回的。rn24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,rn如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的rn才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你rn讨论呢。rnrn浮躁的人容易问:我到底该学什么;----别问,学就对了;rn浮躁的人容易问:JS有钱途吗;----建议你去抢银行;rn浮躁的人容易说:我要中文版!我英文不行!----不行?学呀!rn浮躁的人分两种:只观望而不学的人;只学而不坚持的人;rn浮躁的人永远不是一个高手。 论坛

php需要掌握的东西 不做浮躁的人

03-14

1、语法:必须比较熟悉,在写代码的时候IDE的编辑器对某一行报错应该能够根据报错信 rn息知道是什么样的语法错误并且知道任何修正。 rn2、命令:必须熟悉PHP带的一些常用命令及其常用选项,熟悉那些命令,自己运行 rnphp.exe -h 如果这些命令你没有全部使用过,那么你对PHP实际上还很不了解。 rn3、工具:必须至少熟练使用一种IDE的开发工具,例如:Eclipse、Netbeans、zend或者 rneditplus,ultraedit,包括进行工程管理、常用选项的设置、PHP插件的安装配置以及进行 rn调试。 rn4、API:PHP的核心API是非常庞大的,但是有一些内容笔者认为是必须熟悉的,否则不可能熟练的运用PHP,包括: rnrn- 文件目录处理函数包80%以上的函数的功能的灵活运用。 rn- 日期时间函数中的80%以上的函数的功能的灵活运用 rn- 数学函数库中的100%的内容。 rn- 网络库中的60%以上的内容,对各个函数的功能比较熟悉。 rn- 字符串处理函数下的60%以上的内容,特别是各种处理函数。 rn- 正则表达式函数下的90%以上的内容,特别是各种正则处理 rn- 一些安全库下的40%以上的内容,如果对于安全没有接触的话根本就不可能掌握PHP rn- XML处理,熟悉SAX、DOM以及JDOM的优缺点并且能够使用其中的一种完成XML的解析及内容处理。 rn- 图形图像函数库下的80%以上的内容,特别是一些图像生成和处理 rn- MySQL 数据库函数下的90%以上的内容,特别是处理各种数据的函数 rn- 数组处理函数下的90%以上的内容,特别是各种操作处理函数 rn- 其它PEAR,PECL,和一些扩展类库中的80%以上的内容,特别是一些常用的类的处理 rn- 针对不同的需求,查找不同的函数库。 rn5、测试:必须熟悉使用phpunit编写测试用例完成代码的自动测试。 rn6、管理:必须熟悉使用xinc, phing等完成工程管理的常用任务,例如工程编译、生成phpdoc、生成、版本控制、自动测试。 rn7、排错:应该可以根据异常信息比较快速的定位问题的原因和大致位置。 rn8、思想:必须掌握OOP的主要要求,这样使用PHP开发的系统才能是真正的PHP系统。 rn9、规范:编写的代码必须符合流行的编码规范,这样程序的可读性才比较好。 rn10、博学:掌握OOA、OOD、MS SQL Server、Oracle 、Zendframework、cakephp、symfony、模板技术等流行技术,掌握软件架构设计思想、搜索引擎优化、缓存系统设计、网站负载均衡、系统性能调优等实用技术。rnrn综合上述,没发现PHP和java有什么不同!PHP和Java,还是.net一样要学的东西有很多! rn浮躁的人容易说:PHP语言不行,应该学Java,C#,VB.NET:--是你自己不行了吧!? rn浮躁的人容易问:PHP和Java,C#,VB.NET哪个好;--告诉你吧,都好--只要你学好就行; rn浮躁的人容易问:我到底该学什么:--别问,学就对了; rn浮躁的人容易问:PHP有钱途吗:--建议你去抢银行 论坛

[强烈推荐]--请不要做浮躁的人(转帖)可能很多朋友已看过

07-05

请不要做浮躁的人rn1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想出来再参考别人的提示,你就知道自己和别人思路的差异。rn2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久都是只对部分功能熟悉而已,不系统还是不够的。rn3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,虽然帮助的文字有时候很难看懂,总觉得不够直观。rn4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。rn5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸出很多知识点;不会举一反三你就永远学不会。rn6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。rn7.学脚本并不难,ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览群书;rn8.看再多的书是学不全脚本的,要多实践rn9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里;rn10.学习脚本最好的方法之一就是多练习;rn11.在任何时刻都不要认为自己手中的书已经足够了;rn12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看;rn13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;rn14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件;rn15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中;rn16.不要漏掉书中任何一个练习——请全部做完并记录下思路;rn17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工作。rn18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的;rn19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能讲清楚才说明你真的理解了;rn20.记录下在和别人交流时发现的自己忽视或不理解的知识点;rn21.保存好你做过的所有的源文件----那是你最好的积累之一;rn22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒!rn23,到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己的帖子没人回的。rn24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你讨论呢。rnrn浮躁的人容易问:我到底该学什么;----别问,学就对了;rn浮躁的人容易问:JS有钱途吗;----建议你去抢银行;rn浮躁的人容易说:我要中文版!我英文不行!----不行?学呀!rn浮躁的人分两种:只观望而不学的人;只学而不坚持的人;rn浮躁的人永远不是一个高手。rnrn 论坛

请不要做浮躁的人——虽是老帖,转给新手,值得一看

12-03

1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想出来再参考别人的提示,你就知道自己和别人思路的差异。rn2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久都是只对部分功能熟悉而已,不系统还是不够的。rn3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,虽然帮助的文字有时候很难看懂,总觉得不够直观。rn4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。rn5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸出很多知识点;不会举一反三你就永远学不会。rn6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。rn7.学脚本并不难,ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览群书;rn8.看再多的书是学不全脚本的,要多实践rn9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里;rn10.学习脚本最好的方法之一就是多练习;rn11.在任何时刻都不要认为自己手中的书已经足够了;rn12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看;rn13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍;rn14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件;rn15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中;rn16.不要漏掉书中任何一个练习——请全部做完并记录下思路;rn17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工作。rn18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的;rn19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能讲清楚才说明你真的理解了;rn20.记录下在和别人交流时发现的自己忽视或不理解的知识点;rn21.保存好你做过的所有的源文件----那是你最好的积累之一;rn22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒!rn23,到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己的帖子没人回的。rn24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你讨论呢。rnrn浮躁的人容易问:我到底该学什么;----别问,学就对了;rn浮躁的人容易问:学脚本有钱途吗;----建议你去抢银行;rn浮躁的人容易说:我要中文版!我英文不行!----不行?学呀!rn浮躁的人分两种:只观望而不学的人;只学而不坚持的人;rn浮躁的人永远不是一个高手。rnrnrn注:原文是说设计的,确实觉得写的不错,就改成脚本了,希望原作者勿怪 论坛

请不要做浮躁的人 - 做程序员的推荐看这篇文章(转贴至lqflsh的论坛)

12-17

呵呵,刚刚看到了,就来贴一下下。rn出处URL:http://www.py123.com/lqflsh/bbs/dispbbs.asp?boardID=37&ID=3604rnrn1.不要看到别人的回复第一句话就说:给个代码吧!你应该想想为什么。当你自己想 出来再参考别人的提示,你就知道自己和别人思路的差异。 rnrn2.初学者请不要看太多太多的书那会误人子弟的,先找本系统的学,很多人用了很久 都是只对部分功能熟悉而已,不系统还是不够的。 rnrn3.看帮助,不要因为很难而自己是初学者所以就不看;帮助永远是最好的参考手册,虽然帮助的文字有时候很难看懂,总觉得不够直观。 rnrn4.不要被对象、属性、方法等词汇所迷惑;最根本的是先了解最基础知识。 rnrn5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单,或者可以引伸 出很多知识点;不会举一反三你就永远学不会。 rnrn6.知道一点东西,并不能说明你会写脚本,脚本是需要经验积累的。 rnrn7.学脚本并不难,JSP、ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览群书。 rnrn8.看再多的书是学不全脚本的,要多实践 。 rnrn9.把时髦的技术挂在嘴边,还不如把过时的技术记在心里。 rnrn10.学习脚本最好的方法之一就是多练习。 rnrn11.在任何时刻都不要认为自己手中的书已经足够了。 rnrn12.看得懂的书,请仔细看;看不懂的书,请硬着头皮看。 rnrn13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍。 rnrn14.请把书上的例子亲手到电脑上实践,即使配套光盘中有源文件。 rnrn15.把在书中看到的有意义的例子扩充;并将其切实的运用到自己的工作中。 rnrn16.不要漏掉书中任何一个练习——请全部做完并记录下思路。 rnrn17.当你用脚本到一半却发现自己用的方法很拙劣时,请不要马上停手;请尽快将余 下的部分粗略的完成以保证这个代码的完整性,然后分析自己的错误并重新编写和工作。 rnrn18.别心急,写脚本确实不容易;水平是在不断的实践中完善和发展的。 rnrn19.每学到一个脚本难点的时候,尝试着对别人讲解这个知识点并让他理解----你能讲清楚才说明你真的理解了。 rnrn20.记录下在和别人交流时发现的自己忽视或不理解的知识点。 rnrn21.保存好你做过的所有的源文件----那是你最好的积累之一。 rnrn22.对于网络,还是希望大家能多利用一下,很多问题不是非要到论坛来问的,首先你要学会自己找答案,比如google、百度都是很好的搜索引擎,你只要输入关键字就 能找到很多相关资料,别老是等待别人给你希望,看的出你平时一定也很懒! rnrn23,到一个论坛,你学会去看以前的帖子,不要什么都不看就发帖子问,也许你的问题早就有人问过了,你再问,别人已经不想再重复了,做为初学者,谁也不希望自己的帖子没人回的。 rnrn24,虽然不是打击初学者,但是这句话还是要说:论坛论坛,就是大家讨论的地方,如果你总期望有高手总无偿指点你,除非他是你亲戚!!讨论者,起码是水平相当的才有讨论的说法,如果水平真差距太远了,连基本操作都需要别人给解答,谁还跟你讨论呢。 rnrn浮躁的人容易问:我到底该学什么;----别问,学就对了; rn浮躁的人容易问:JS有钱途吗;----建议你去抢银行; rn浮躁的人容易说:我要中文版!我英文不行!----不行?学呀! rn浮躁的人分两种:只观望而不学的人;只学而不坚持的人; rn浮躁的人永远不是一个高手。 rnrn其实,我是一个程序员 rn 论坛

没有更多推荐了,返回首页