程序员创造力

A. 程序员需要一个创意的头脑吗

可以别人创意你编程

B. 程序员有哪些常见的恶习

• 聪明但是给人的感觉是不谦逊。

• 交流与合作能力比较强，但是又往往向往个人主义。

• 懒惰（体力劳动），大部分程序员可能都是这样，也许是因为程序员已经习惯了脑力劳动！

• 创造力非常强，但是好像又缺乏纪律性！

• 学习能力非常强，但是又往往太过于依赖个人经验。

• 程序员肚子局部胖的比较快。

• 爱电脑胜过自己爱人。

• 作为思考者的程序员，不喜欢热闹得商场，比较喜欢同一两个朋友呆在一起玩电脑的感觉！

• 抽烟。在我接触过的同事中，相对于其它部门而言，技术部的程序员抽烟的比例比较高！

• 十二点之前基本不休息。

C. 中国程序员VS美国程序员，差距在哪里

当然小编并不是在长他人志气，灭本国威风，只是想小小提醒作为程序员的你，一定不要以学编程、拿高薪作为自己唯一的人生目标。就好像创业路上的你，无论在什么时候，我们都要不断提升自己的专业度和竞争力，永远保持一颗热爱自己事业的工匠之心，坚定的走下去。互联网行业千变万化，要不断的学习，更新知识系统，才能永远不被这个社会所淘汰。

D. 如何成为有思想、创新的程序员

写这篇文章也源于我和新员工的一些谈话心得，一些基础比较薄弱的技术人员，看起来有点像没有思想和灵魂的程序员。你可能也会觉得国内有很多小企业出来的人或者刚毕业的人，会的最多也是CRUD和拖拉控件。我也接触过一些技术人员，他们告诉我他们再也不想搞技术了，因为技术是在太无聊了，特别年纪稍大一点的，想的最多的就是转行。曾经我非常惊讶于这样的状况，事实上，写程序是一件很有创造力的事情，但为何很多人都会觉得无聊呢。 随着年纪的增长，这些问题的答案慢慢变得清晰一些。在这里，我不敢说，我说的都是正确的，我只是在一直不停的探索。在探索之后，我对我的新员工说了以下的话：“进入我们公司，虽然我们也是很不起眼的刚创业的小公司，但是，你在这里需要做一些改变了。我知道你们以前的工作性质可能是上司给你交代任务，告诉你怎么做，然后你管也不管就照章办事，拉拉控件，以完成项目功能为首要任务。在我们这里，你需要成为一个有思想的程序员。有思想的程序员需要懂得如何使用聪明的脑袋瓜。事实上，很多人都不知道我们的脑袋瓜到底能做多少事情，不过，一旦你尝试了，你就会体会到‘不是做不到，而是想不到’。需要记住这些话，从思想上改变，从今天开始。首先，我们是做软件产品的公司，质量是产品生存的首要标准，产品质量的最低要求就是易用性；其次，我们要保证产品的质量，代码的质量首先要过关，标准编码方式、异常处理方式、代码的生命周期管理、编码的完整性都需要兼顾；第三，避免写一些垃圾代码和重复的代码，这需要动用你聪明的脑袋，我曾经写了10几个的CRUD产品，从而自主创新了控件关系映射、对象-对象映射、通用窗体框架，乃至我们现在的OSGi.NET产品和云计算SaaS商店平台，都是从这些重复的劳作中不断思索发明的。我看到设计模式的书时，可以骄傲的向同学们吹牛，我也设计过几个‘模式’；第四，学会发现问题，探索问题，积极询问，避免把问题遗留下来或者拖机取巧。浪费一个发现问题和解决问题的机会，相当于浪费提高自己的机会。最后，你要有信心成为一流有思想和灵魂的技术人员，别哪一天你离开尤埃时，丢我们的脸，：）。” 我不敢说，我现在多有思想，但是，我隐隐约约感觉到一些这样的有意思的东西。我崇拜“道法自然”，它告诉我违反规律就会受到惩罚，因此，我会时刻反省我是否有做错的事情，包括在平时编码、设计和架构的时候，以及平时生活上的为人处事。接下来，我介绍一下，我如何来发明我曾经的产品，希望能够给人一些启发。 1 我是如何发明了控件关系映射组件 控件关系映射的发明源自于我在参与一款MIS系统的设计，该系统是一个钢管管理系统，每一个钢管的信息有很多很多的属性，我记得钢管厂给我们的数据说明书里面，一个管子的信息有惊人的380多列。因此，我们在查询、修改、添加记录的时候，总是会有类似以下成片成片的代码。1 var add***Sql = "insert into Test(a1,a2,....aN) values(@a1,@a2,....@aN)";2 ...... 3 var para1 = new SqlParameter("@a1", SqlDbType.String, a1.Text.Trim(); 6 var paraN = new SqlParameter("@aN", SqlDbType.String, a1.Text.Trim(); (忽略中间的N-3行代码，以及查询、修改和删除的代码)我记得，我们一起做的另一个小伙拿了一个CRUD一千多个字段的表来向我们显耀说：“我他妈的把这功能实现了！”。我不知道大家是否反感这样的代码，反正我是厌倦了。当我想到这是一件很痛苦的事情的时候，我考虑了如何来解决它。经过一些思考，我惊讶的发现，所有的CRUD以及界面的流程都可以抽象为“输入-处理-输出-输入-处理-输出......”的过程，处理的过程实际上是获取输入，然后组装成SQL语句，最后在响应到界面。这个过程是以SQL语句为中心，SQL语句的参数来源于界面的控件或者界面类的其它成员，SQL语句执行的结果可能是跑到另一个页面、执行DataGrid绑定、执行下拉列表绑定、给控件赋值。因此，我想到一个方法，可以设计一个SQL映射的配置，即利用这个配置，直接将界面控件映射到数据库，并且也可以执行反向映射。以下是映射SQL的配置。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 以下是调用映射SQL语句实现CRUD中的一个操作。 1 namespace HumanDispSolution2 {3 public class login : CrmPage4 {5 private void btnLogin_Click(object sender, System.EventArgs e)6 {7 DataSet ds = this.ExecuteMapping("Login") as DataSet; 8 if(ds.Tables[0].Rows.Count > 0) //登入 9 { 10 System.Web.Security.FormsAuthentication.RedirectFromLoginPage(UID.Text,false);11 }12 else13 this.lAlert.Text = "alert('登录失败，请重新输入帐户信息！');";14 }15 }16 } 另外，我还编写了一个工具来自动生成这样的配置文件，从此以后，关于数据库的CRUD，我爽了！！ 2 我是如何发明了通用窗体框架 控件关系映射的发明也是源于上面提到的钢管系统。当超过2个人一起参与一个复杂项目时，可能他们都需要操作主界面，在主界面加上各自模块需要的菜单、需要的界面元素，此外两个人设计的东西也完全不一致。这就造成一些问题了，因为如何实现两个人的集成就有一些麻烦，而且经常出现意外。于是我就发明了一个通用窗体框架，这个框架提供了以下功能：（1）集成用户权限；（2）集成数据访问；（3）插件式支持，每一个人都可以并行开发，集成时仅需要将配置文件集成一起就形成一个组装起来的软件了。 每一个开发人员只需要编写类似以下的配置文件就可以集成了： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 3 我是如何设计了对象-对象关系映射 ORM对于一些小型应用感觉有点庞大，但是对于大型应用，我想是一个比较总要的组件了。在我们使用ORM组件时，也经常会写以下代码。1 var user = new User(); 2 user.Name = NameTextBox.Text.Trim(); 5 OrmFactory.Save(user); 6 ----------------------------------------------7 var user = OrmFactory.QueryScalar(...); 8 NameTextBox.Text = user.Name; 9 ...... 如果一个MIS系统充斥了大量这样的代码，估计你也会腻味，从而丧失对编程的兴趣了。记得我刚才说什么来了，“有问题，意味着升华”，“做一个有思想的程序员”。因此，接下来的问题就是，我们如何来解决类似这样重复的劳动。我在2006年时想到的办法就是实现一个对象-对象的映射。首先，设计如下实体类： 1 public class UserEntity2 {3 ……4 [Member]5 public int Age; 6 [Control] 7 public string Name8 {9 get { return this._Name; } 10 set { this._Name = value; }11 }12 [Control("CardNo.Text")] 13 public string CardNo14 {15 get { return this._CardNo; } 16 set { this._CardNo = value; }17 }18 ……19 }20 21 public class EmployeeEntity22 {23 ……24 [Reference(typeof(UserEntity))] 25 public UserEntity User26 {27 get { return this._User; } 28 set { this._User = value; }29 }30 [Control] 31 public float PostSalary32 {33 get { return this._PostSalary; } 34 set { this._PostSalary = value; }35 }36 ……37 } 其次，调用ObjectEngine实现OO映射。A 实现表单类与实体类映射1 private void Map_Click(object sender, System.EventArgs e)2 {3 this.o = CZB.ObjectMapper.ObjectEngine.Map(this,typeof(EmployeeEntity)) as EmployeeEntity; 4 } B 实现实体类与表单类的映射1 private void InverseMap_Click(object sender, System.EventArgs e)2 {3 this.o.User.Name = "c.z.b in"; 4 this.o.User.Age = 19; 5 this.o.CompoInsurance = 0; 6 CZB.ObjectMapper.ObjectEngine.InverseMap(this,o); 7 } 4 我是如何设计OSGi.NET和SaaS商店产品 至于OSGi.NET和SaaS商店是我在不断思索通用窗体框架以及对现有科技的趋势的把握下，由几个很有创造力的编程人员，在建立了完善的产品保障体系下，构建起来的。这两个产品我会在后面介绍如何设计的。他们的设计我用了很长的时间。 我不是什么老鸟，希望我们在如此多的技术的世界中能够多多交流，共同进步。解决这些问题，不仅增加了编程的乐趣，更是增加了自己的见识，从而避免自己成为一个没有思想的程序员！我也知道，我们可以找到很多理由来反驳文中提到的做法和观点，但是，提高自己才是最重要的，不要去着急的否定一些什么，并给自己找借口。

E. 选择程序员的十大理由

上得了厅堂，下得了厨房，写得了代码，查得出异常，杀得了木马，翻地了围墙，开得起好车，买的起好房，抓得紧女郎。不做还作甚？

F. 在大家眼中，程序员是一个怎样的职业

程序员首先是雇员、然后是工程师；比起创造力，工程能力对这个职位更为重要

为什么有人在技术造神

大家应该已经感受到，技术圈这两年已经和娱乐圈创业圈差不多的氛围了，这其实是有原因的。

最主要的原因是，创业公司和创业媒体越来越多，他们需要大量的程序员投身到创业这个高风险的行业中，而造神，正是让程序员们自动跳进火坑的绝佳办法。不是说程序员不能创业，我是说，创业媒体们故意模糊了创造和创业的界限，把程序员们的创造冲动偷换概念，鼓吹了太多不适合的人去创业。

另一个原因是，招聘成本高涨，CTO 们为了能提升影响力，不得不频频出席各种大会刷脸。文笔好的再做做自媒体和技术社群，既能强化个人品牌提高身价，又能在融资的时候提升成功率。

总之，这个行业出现了各种技术大神。

这些大神在普通人类和初级程序员眼里是无所不能的，是他们向往的目标；在中级程序员和高级程序员眼里，这些大神就是他自己，只不过他还没红起来而已…

于是攀比心理也开始泛滥，全国第三的架构师比比皆是，整个圈子渐渐就浮躁起来。

然而绝大部分程序员，依然是雇员

媒体们在包装时，最喜欢按独立开发者的路线来整。“从小就对技术有天分”、“大学时曾在某编程大赛一鸣惊人”、“写了个 APP 玩结果一个月有了千万用户”、“从公司离职自立门户三年上市”。

OK，这的确是程序员的一条职业路线图。但是媒体们不愿意告诉你的是，一：只有极少数程序员是通过这个路线成功的；二：这条线其实需要太多非程序员职位的技能，比如产品设计能力和销售能力。

程序员的价值决定

绝大部分互联网公司的程序员职位，没有技术门槛

然而不幸的是，绝大部分互联网公司都不是技术驱动的公司。真的就是鸟哥说的那样，绝大部分技术岗位，其实技术门槛都不高（门槛在工程上，后文细讲）。技术不过是这些公司的护航舰，而不是破冰船。

先别打我，冷静下来想想，到底有多少你会的那些技术，是你的同行们不会的呢？不多，对吧？

几年前亿级别的搜索还是问题，现在已经到处是通用解决方案了；几年前千万到亿级别的网站和 APP 解决方案还在大公司手里，现在各个架构大会都讲烂啦，而且其实都差不多；就连 DeepLearning，带 API 接口的框架也开始涌现，只需要把图片用 REST 传进去就能取到结果了。

很多事情，已经没有难度，只需要持续投入。是的，对绝大部分程序员来讲，他们不需要成为科学家，而需要成为工程师，成为从科学家手里接过火种，去燎原大地的人。

怎样才是一个好工程师

工程的本质不是创造，而是去风险化。

工程是关于如何低成本、高效率、按时按量完成既定任务的。所以判断一个工程师是否优秀，并不是他多有创意多有名气，而是看他有多稳，看他能多 GettingThingsDone，中文就是“靠谱”。

有时候一个好的解决方案，未必采用了最新的技术和框架，而是看上去朴实无华，功力都包涵在背后的细节里。就像顶尖高手打的斯洛克台球，每一杆都平淡无奇，只是因为上一杆的回球太到位。

有同学问，那我工程做的太好，岂不是没有机会遇到一些高难度挑战了么？放心，一般公司都雇佣了产品经理来帮你制造高危事件。

同样的，一个好的工程师，会选择最适合需求和团队的方案，考虑开发效率和系统效率的均衡，从而已达到最优效果；而不是整天和别人去争论什么语言最好、哪些框架过时了。

工程的另一个要求是进度控制和质量控制。

在项目立项之后动工之前，对要做的事项作出详尽的规划，对未来一到两周的工作给出细致的排期，这是进度控制的基础。

代码的及时入库与合并，自动化测试和每日构建，CodeReview 和文档编写，这些看似无关紧要的习惯则决定了项目质量。

不幸的是，很多程序员把这些工程上至关重要的东西当成垃圾，视为对他们“创造力”的压抑。

他们总是以创造力为借口去寻求自身的自在，比如上班不带胸牌不打卡，中午休息时间在公司看视频打游戏，最好可以远程上班，项目到期之前再来检查进度，公司不要用统一框架，只有傻逼才写文档。

对职业的理解偏差和工程能力上的荒芜，培养了大批能写代码但死活写不好代码的“码农”，反而让那些有着彪悍工程能力和良好习惯的程序员变得奇货可居。

最后，来说说程序员那无处安放的创造力

有了锤子想找钉子是很正常的原始冲动，但我们必须认识到，创造力对于程序员这个职业来讲，是锦上添花的东西。如果你没有强大的工程能力，那么创造力也不过是无本之木。所以扎扎实实的把工程基础打好，这是最根本的。

在此基础上，我比较推荐程序员采用内外两条线来培养自己。在公司内的项目上采取相对保守的策略，尽力把稳定性做到最好，培养出自己卓越的工程能力；然后在公司外的开源项目和自己的独立项目上，采用一些新的技术、实践一些新的想法、充分发挥自己的创造力，梦想还是要有的，对吧。

这样做最明显的好处是，你可以了解到新技术和激进方案的优缺点，从而在进行方案选型时，有更多的依据；还有一个职业发展上的好处：如果不是主负责人，公司的项目往往不能代表你的能力；但独立项目却可以作为一个非常好的能力证明出现在你的简历里边。

你可以是一个身怀绝技的手艺人，在自己家里你尝试各种手法各种风格的个人作品；但当你参与颐和园这种级别的工程时，好好的把自己负责的石头雕成总设计师要求的样子就好 —— 毕竟这个时代一个人已经很难负责整个项目了。这就是我所理解的程序员的工匠精神。

G. 编程需要创造力想象力吗

做独立开发者的话很需要，一般程序员只需要把上面交代的任务完成就行了

H. 程序员的必备技能有哪些

数组、字符串与哈希表
任何受过专业训练的程序员，对“数据结构”这门课程中涉及到的各种数据结构都不会陌生，但是在实际的编程工作中，大部分的数据结构都不会用到，而且也永远都不会用到。虽然如此，深入地理解基本数据结构的概念和实现细节，仍然是每个程序员的任务。这不仅仅是因为，掌握这些知识将有利于更加正确和灵活地应用它们，而且也是因为，对于语言背后的实现细节的求知欲是一个优秀程序员的素质。
正则表达式
在程序员日常工作中，数据处理占据了相当的比重。而所有的数据之中文本又占据了相当的比重。文本能够被人理解、具有良好的透明性，利于系统开发、测试和维护等就必需要有一定规律遵循一种规则，当你掌握一门正则表达式语言，就能够培养你编程的直觉本能，达到较高水平，也能够在实践中提供更高的开发和执行效率。
调试
软件调试是软件工程的一个重要部分，其过程出现在软件工程的各个阶段，从最初的可行性分析、原型验证、到开发和测试阶段、再到发布后的维护与支持，都有软件调试过程参与。学习和灵活运用软件调试技术，不仅可以提高程序员工作效率，而且有利于对代码的感知力和控制力，加深对软件和系统的理解。此外，调试技术是解决各种软件难题的一种有效武器，它直击要害、锐不可挡，相对其它间接方法具有明显的优势。软件有大美，调试见真功!
两门语言
任何一位职业化的软件技术人员都会将编程语言当成自己的利器。它们代表了开发人员对计算机本身的理解与对软件开发工作的执着。同时，建立在编程语言之上的基础也标志着程序员的职业化道路发展到了一个新的阶段，而单一语言又有一定的局限性，软件开发的本质就是处理信息以及数据。一种专门用来处理数据的脚本语言常常是走向更加职业化的必备武器之一。所以精通两种语言，对于任何一个开发人员来说，并非必须，但是对于一个专业化程度较高的开发人员来说，又常常是必要的。
一个开发环境
随着技术的进步，IDE已经越来越强大，远远超出我们心目中的最初形象，越来越多的内容被涵盖到IDE中，从需求分析、业务建摸大批软件发布，IDE已经逐渐覆盖了软件开发的整个生命周期。
SQL语言
说起SQL，绝大多数程序员对其作用都了然于胸--用来访问数据库嘛。确实，数据是信息系统的核心，没有数据的计算机应用没有任何意义。信息系统中，大量数据本质上就以实体--关系的模式存在，而RDBMS支持SQL这么简单但表达能力丰富的访问接口，同时还提供了内建的事务ACID特性保证和故障恢复能力--因此，RDBMS理所当然地成为了大部分信息系统的标准数据存储介质。于是，无论使用何种语言开发信息系统，从C、C++，Delphi到Java,从Perl、Python到Ruby，使用SQL访问RDBMS都是我们必须修炼的武功秘籍。
编写软件的思想
说起程序员的武器自然少不了技术书籍，它们就像是拳谱、剑经、虽然不能马上转化为巨大的伤害输出，但假以时日勤以研读，有朝一日成为傍身绝学也是说不定。不过虽然各类技术书籍汗牛充栋，除去入门时浅显易用的参考和复杂深奥的学术专着，能够让所有程序员常看常新的心法秘籍还是不多。

I. 做程序员前景如何

整个IT行业的核心就是软件，网络和通讯只是IT行业的信息载体。
因此IT行业收入最高，利润最大的企业就是软件公司，软件公司里相对“高，精，尖”的是项目分析师，需求分析师，及应用人员，程序设计师，他们所占总人数不过10%，其余80%都是程序员，高精尖人员也是逐步从程序员基础做起，经过一段时间积累，可以成长成为软件工程师，项目分析师直至项目经理。
IT2009年目标要求软件专业人才达到80万人，软件人才现状，软件企业从业人员50多万，软件开发人员25万人，2009年软件开发专业人才需要量更大，你觉得好不好找工作？更何况，从未来的职业发展道理来看，学软件的技术能力发展空间更大。未来职业提升空间，相对工资和收入提升空间都要更大。
所以做程序员的发展空间和前景都是不错的.

选择职业嘛,最重要的是看自己喜欢不喜欢,感不感兴趣.如果你也喜欢软件开发的话,那程序员是不错的;不喜欢的话,还是选择自己心中想要的哦~

呵呵 祝你成功~

J. 能一辈子做程序员吗

出来做程序员,一写就是好多年，发现身边的大龄程序员也多了起来，盛传的"程序员30"的这道坎是不是会落在每个人头上? 的确，快三十的人慢慢地不大愿意像以前那样加班了，得考虑身体和家庭；薪水涨到了不少，但经济压力还是那么重，估计再找工作，很多老板看到简历的薪水要求就会马上把自己否决；技术更新那么快，自己没有时间去一一追逐；想想同学都是什么经理，什么长了，自己还是一个developer, 也许顶个leader的小头衔，老爸老妈是否还能像以前那样夸儿子有出息.随着年纪继续大下去，还玩得起么？ 程序世界不是只有VC/DELPHIC这些程序语言，也不是只有MFC/GLIBC这些库，NT/Linux这些操作系统, 也许有人觉得做特种兵就是要精通各种语言, 熟悉各种LIB和SDK, 才能玩得转, 这些都是耗费巨大体力和精力的事情, 老了就完完了. 人家一个密码学的专家可以干上一辈子, 为什么程序员甚至程序特种兵30就玩不动了? 假如一个程序员把自己的价值就定位到VC JAVA DotNet上, 的确就会疲于奔命, 渐渐就玩不动了. 你看招聘, 很多公司上来就要求各种语言,各种数据库, 甚至还要你精通PS,还能算帐顶个会计, 要求多得不得了. 你看了以后要么自卑,要么鄙视: 他们自己都不知道该做什么东西, 该要什么人. 那些招聘网站的首页,那些有名的外企,绝对不会show这种招聘广告: 丢人哪. 他们只会在基本的程序和平台外语技能后面加上: 精通xxx尤佳,最好该领域有xx年经验. 这里xxx可能是内核定制,可能是语音视频技术,可能是OA系统开发, 或者...这些才是他们想要的关键技能, 才是你的价值所在. (语言是很基础很重要的技能，它们就像厨师的菜刀和锅铲，它们是一门艺术，但是一个厨师不应该仅仅了解这些。) 常常看到有人问: 我精通这个语言,那个语言,大家看看我到底值多少钱哪? 假如你干了两年还这么问,你就麻烦了, 老板看的不是你单纯的程序语言技能, 他要的是你解决问题的能力, 这些更多的和你做过什么项目, 从事哪个领域或者行业的开发有关. 举个例子: 你给一家外包公司的简历, 说你精通VC或者其他什么的那行(不是不要你说), 远远比不上你说有在外包企业从事3年工作的那行文字重要. 很多人说外企好,别人老板尊重程序员,他们的程序员干到50还乐呵呵. 这里面文化的原因当然有, 但是更加主要的原因, 是因为资本家觉得他们还有价值, 而且是比那些刚入行的青年有大得多的价值. 那么多的内部技术文献, 那么多年通过开发和维护系统换来的经验, 该领域里面那么多的细节, 系统该这么作,不该那么作, 只有这些老家伙了解, 而且几乎是直觉上的了解, 我不仅不能开掉他们, 还要让他们HAPPY, 不能让他们被别人挖走了.不可能每个人都能转成市场和管理,每个人都能做首席架构师, 但是这不妨碍我们继续在一个自己精通的领域内作我们的特种兵: 我们比客户还清楚他们要什么; 我们不仅知道系统怎么做的, 而且知道为什么必须这样做. 有些地方, 架构师设计的时候, 必须通过我们的REVIEW评审他才放心; 而且有一点很重要: 这些知识比那些易变的语言甚至稳固的硬件更难过时. ------------------- 不管大公司小公司，对于一些不管什么项目都做的公司，只想安心做事情的程序员是永远没有前途的，对于那些没有根，没有技术积淀，没有行业背景的公司，程序员假如不能转型成市场或者管理者，他不仅低人一头，而且对于公司永远只是一个可以随时炒掉的螺丝钉。 成为为资深技术人员是出路之一，但是需要合适的土壤，欧美这方面的确好很多，但是在中国找到类似的土壤并非不可能。另外做技术比不上管理风光是必然的，外国中国都一样，但是是否一直做技术，要看个人兴趣和能力。不要迷信外企的"技术管理双阶晋升"，那是糊弄人的，但是他们会给技术人员一个起码的自尊，你起码可以说：在公司我比经理级别高(虽然你没有那么大的办公室)。 这也是一个一直做技术是否现实的问题，一个如何实现更高的自我价值的问题：有人说年纪大了学习能力并没有下降，但即使保持了学习能力，给你开那么多的薪水，你比刚入行的小伙子的优势在哪里？可以说，对于新的语言的掌握甚至实战能力，很多学校出来的新人非常不错甚至可以说精通，你难道和一批批的新人反反复复的拼这些？就算你样样比他们强，性价比呢？ 改编自: