程序员的创造力

㈠ 软件工程十分需要创造性么

如果你打算自己创业有自己的品牌，产品当然少不了创造性。一般的程序员只是熟能生巧而已。

㈡ 程序员的必备技能有哪些

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

㈢ 编程需要创造力想象力吗

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

㈣ 程序员如何才能有独立开发项目能力

难！我本身是软件工程师，我从业都十多年了，就拿网站来说吧，比如你独立开发一套PHP或者是Java的网站，通常，美工+WEB前端+后端开发+需求分析，设计的能力，相当于，你一个人，顶一个团队的工作量，连项目经理都兼任，维护客户都兼任！因为你得分析需求啊。
如果Java更难了，相当于美工（1人）+WEB前端（1人）+后端开发（3-7个），如果是APP的，还得加安卓+IOS工程师+项目经理。
如果是C++，巨难，虽然我也可以独立开发。问题是，太耗费精力了。特别是嵌入式，其实C语言都有几种，Java也有几种，其他人，半桶水，不专业的。
最终，你要给客户看到的效果！如果你美工 不行，后端不得，只要有一个严重的短板，你就不胜任真实的项目独立开发的能力，自娱自乐可以。
写驱动，谈何容易，全世界，不超过1000人会写底层的驱动。
第二个，我看到你说，做嵌入式的是学c++还是java ,我java比c++好一些，说明，你基础不行，虽然是科班出生，科班难出人才，除非自学成才的天才例外！如果天才，你这个年纪的，或者大一点的，都能独立开发了。特别是美工，需要天赋的！编程也是。需要悟性的，才有创造力，如果死读书的书呆子，没什么创造力的。少数例外。

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

可以别人创意你编程

㈥ 程序员有哪些常见的恶习

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

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

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

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

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

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

• 爱电脑胜过自己爱人。

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

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

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

㈦ 选择程序员的十大理由

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

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

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

为什么有人在技术造神

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

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

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

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

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

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

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

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

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

程序员的价值决定

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

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

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

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

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

怎样才是一个好工程师

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

写这篇文章也源于我和新员工的一些谈话心得，一些基础比较薄弱的技术人员，看起来有点像没有思想和灵魂的程序员。你可能也会觉得国内有很多小企业出来的人或者刚毕业的人，会的最多也是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商店是我在不断思索通用窗体框架以及对现有科技的趋势的把握下，由几个很有创造力的编程人员，在建立了完善的产品保障体系下，构建起来的。这两个产品我会在后面介绍如何设计的。他们的设计我用了很长的时间。 我不是什么老鸟，希望我们在如此多的技术的世界中能够多多交流，共同进步。解决这些问题，不仅增加了编程的乐趣，更是增加了自己的见识，从而避免自己成为一个没有思想的程序员！我也知道，我们可以找到很多理由来反驳文中提到的做法和观点，但是，提高自己才是最重要的，不要去着急的否定一些什么，并给自己找借口。

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

程序员本身没有差距，而且中国的程序员工资更低，工作时间更长。但是组织差别是构成中美程序员行业的最主要差别，也就是体质差别。在中国努力工作的人并不能产生更强的结果，美国是是个程序员都一般努力，但是最终成果却很好。但是中国的程序员是大家都很努力，但是力气用不到一起去，内耗导致很多重复劳动，最终结果一般。权利垄断和恶性竞争是中国所有行业的最大问题。
30岁之后程序员转行的问题在于，美国没有那么多程序员可用，很多劳动离开了某个人，其他人无法顶替（技能差别，年轻人不是那么多，也没有那么努力）。而在中国不是这样的，年轻人工作更努力，工资更低，用你干几年，然后换年轻人，从技能上来说并没有什么根本差别，而且由于竞争存在，新鲜血液的工作效率更高，可以有效的降低工资成本。但是这会带来一个问题，30岁之后的程序员处于尴尬地位。于是行业内的恶性竞争就形成，权利垄断者（管理层）成为香饽饽。而且更换底层劳动力，有利于上层权利垄断。
但是问题就来了，被淘汰掉的劳动力并非无用劳动力，多年的技能积累付诸东流，形成较大的劳动力浪费。这些被淘汰的劳动力并不会就此退出，而是循环进入下一层恶性竞争，从而形成更大的重复劳动。
从宏观上讲，就是经济结构失衡。无效的生产，导致产品过剩，而真正有效的需求得不到满足。中国下一步会减少程序员供给，从人员培养上来减少程序员的产生，才是有效改善程序员待遇的最佳手段。