程序员的思考

Ⅰ 什么是程序员，程序员是什么，思考

作为程序员的我来为你解惑，同时也希望可以有更多人了解我们的职业。很多人也问过我程序员是做什么的？难道修电脑的？ ！！

正解：程序员(英文Programmer)是从事程序开发、维护的专业人员。一般将程序员分为程序设计人员和程序编码人员，但两者的界限并不非常清楚，特别是在中国。软件从业人员分为初级程序员、中级程序员、高级程序员、系统分析员，系统架构师，测试工程师六大类计算机科学发展到今天（21世纪初期），程序员从事的人群很多，分工也不相同，从大的方面可以分为以下几类：asp程序员、delphi程序员、php程序员、powerbuilder程序员、C程序员、linux程序员、net程序员、vb程序员、java程序员、javascript程序员、C++程序员、Python程序员、android程序员、iOS程序员。一般的程序员都有四年的在专业领域的学习，需要一个在程序领域的学士学位获得者，不论是数学方面的还是工程方面的都是可以的。大约有20%的人在这一领域的计算机科学和工程学拥有更高的学位。还有很小一部分程序员是自学的，尽管一些专业性的学校或者综合大学可以提供，但是也需要一些别的途径来提供相关的人才。尽管学历是比较重要的，但是公司经常把重点放在应聘者的工作经验上。
==============================================
同样从事程序员职业的我，希望可以为大家解惑

Ⅱ 如何像程序员一样思考

[1]. - 如果有一堆着火了的草，旁边有一个装满水的桶，应该怎么办？
- 把桶中的水浇到草上灭火。

[2]. - 如果有一堆着火了的草，旁边有一个空的桶，应该怎么办？
- 把桶装满水，然后就得到了[1]的情况。

[3] - 如果有一堆草，旁边有一个空的桶，应该怎么办？
- 点燃那堆草，然后就得到了[2]的情况。
差不多这样

Ⅲ 程序员如何利用剩余时间思考，最大提升自己能力

1.怎样把自己所了解的技术通过文章内容传递给别人
2.如何才能把自己做的东西讲给别人听并且让他听明白我的想法，比如在这个环境下我是否可以试着去讲一下。
3.找一个学习榜样（开发或者管理），思考他们有什么好的行为、习惯、做事方法值得学习。
4.学习一些框架和方法，比如归纳法、演绎法、SMART原则、STAR法则、SWOT矩阵分析、MECE分析法、5W1H、GROW、六顶思考帽、WBS、鱼骨图、PDCA模型、麦肯锡解决问题7步法、复盘、4P法、空雨伞、FABE销售法则、AIDMA法则、费米推理、时间管理四象限、正反面决策法、决策树、卡佛矩阵等，它们能让你更有章法的思考和工作，更快的提升自己。
5.思考自己在技术上做到什么程度，是否还会有大的提高。
6.这个技术，团队里哪个人用得最好，好在哪里？我该如何做到像他那样？
7.产品预期要解决什么问题，解决了吗？如果没有，该怎样解决？如果解决了，解决得好吗？为什么这样子可以解决？
8.自己所用技术能否解决当下问题？是否还有最合适的技术？如果有，是哪些方法。
作为程序员，尤其是一名优秀的程序员，你与普通人的区别就在于你是停滞不前还是勇往直前，思考自己技术，能力等各方面是否还有提升，还可以做的更好？在产品上用心，在技术上多想方法，多跟优秀的人学习。最后你会发现，做程序员也可以这么开心，也能有如此的收获。
另外为让程序员们更好的学习，达妹特准备了一下资料供参考。
IT行业的高薪源于技术的日新月异，专业技术才是高薪的保障，无论何时都要不断的学习新的知识，这点很重要。

Ⅳ 程序员在学习新技术要思考哪些事

先看下面这样的困惑：
最近了解了几个MVC的框架，其中有两个是公司内部的。发现这些东西都是类似的，从处理逻辑到页面渲染；从service到layout；配置的实现无非就是XML，或者annotation……我有种感觉，兴许已经跳不出这个思维圈子了？
如今的时代，是一个概念翻飞的时代，oschina里的开源软件数量就已经超过了两万，五花八门的技术层出不穷，到底什么技术才是值得学习的？
有位朋友说，他想学习一些关于Android上的开发技术，兴趣驱使。几个月过去了，他说他已经能做出许多小程序了，可是他现在回想起来，掌握一门技术是好，可兴趣之外还有什么呢？他说，“如果我的工作中不使用Android平台，我学它还有何用？”。
学习技术到底是一件有意思的事，还是一件痛苦的事？读书的时候，我曾经买过侯捷翻译的《深入浅出MFC》，对那时的我来说，似乎太困难了一点，我强迫自己看完了三分之一，实在是没有毅力继续往下读了。我在其中察觉不到快乐，这本书在当时似乎充满了生涩。
如上这样的故事太多了，很多时候，程序员们（包括我在内）辛苦地学习，有的没有好的效果，有的过程充满痛苦，有的更是不知道我学它的目的是什么。
国内的教育体制，培养了这样一批人：
他们努力、奋进，热爱技术，愿意投身软件行业，愿意写出高质量的代码，他们对业界的东西很感兴趣，他们愿意学习扎实的基础知识，他们渴求火热的新技术……
几年以后，他们拥有广泛的视野，阅历宽阔、经验老到、言辞犀利，对行业动态了如指掌，显然，他们是行业的博学者。
然而……
他们却缺乏这样一种能力——思考。
欠缺思考容易导致这样的现象：
不会做设计
遇到了问题，拿见到过的、学到了的熟悉的框架、方案、模式往上套，而不仔细分析其中的利弊，只是尽可能地寻找最接近当前问题的解决途径。
有的是不会做系统设计。和少数所谓的“架构师”接触过，他们“只懂业务，不懂技术”，这样设计出来的系统只能满足功能性需求；而论坛上的一些具体问题的讨论话题，则暴露出一些跟帖讨论者“只谈技术，不提业务”，譬如“XXX大容量的解决方案”、“秒杀系统的终极架构”，企图对某一类宽泛的问题，设计出一套放之四海皆准的通用解决方案。
还有的则是不会做面向对象设计，缺少抽象和解耦的能力，这样的例子就更多了。朋友告诉我，他的单位有一位写Ruby的老员工，一个庞大的工程，代码里面居然只有一个上帝类，就搞定了所有的问题。
不能坚持自己的观点
这一点在面试中最容易观察到。应聘者有刚毕业的学生，也有工作超过10年的有丰富经验的从业者。他给出一个粗略的方案以后，在方案没有细化到一定程度以前，很难给出优劣的评论，但是，如果你轻轻地challenge一下，他就迅速放弃本来的构思，跑到你的思路上来。
例如，SNS系统中，服务端有消息要怎样通知到客户端，这样的一个问题，解决方案有很多种，比如客户端轮询、服务端hold住连接推送等，各有利弊。应聘者应当有自己的观点。
不能细化一个问题解决方案
怎样区分一个空谈家和一个实干家？给他一个具体的问题是最好的办法。在我刚工作的时候，我曾经很钦佩那些在活动中、讨论中高谈阔论的人，我觉得他们很能说。可是后来我逐渐发现，能说的人实在是太多太多了。细化设计、甚至落到编码，才是对一个程序员真实的检验。当然，如果你觉得做软件设计的人可以不熟悉编码、架构师可以不首先是一名高级程序员，那我们也没有什么可谈了 :)。
如果你会学习，你可以成长得很快；如果你不会思考，你永远只能跟在别人后面。
在新技术的学习上我认为也应当多思考，不同的人有不同的学习动机。在非外界所迫的情况下，对于新技术的学习，我的观点可以概括为：
它要解决什么问题，就是所谓的问题域，是我关心的吗？
我没有去研究操作系统底层的实现，并非这没有价值，而是我没有兴趣，这就是问题域的影响（不过现在我有兴趣了，我想做一些这方面的事情）。
和过往解决方案它的优势在哪里，是否显着？
这是competition，重复的技术是没有生存空间的（当然，你是微软的话除外 :) ），就像互联网同一个类型的网站，竞争到最后就那么两三家。就像Groovy，我很喜欢它，但是有了Scala以后，我觉得兴许有一个要死掉（Groovy创始人说，如果他早些知道Scala的话，就没有Groovy什么事了。具体的报道请去Google上搜他的blog）。
它的实现和带来的效果上看，有没有很有意思的思路，是值得借鉴和思考的？
这是最难讲的一个问题。以去年初开始接触的Node.js为例，它可以做到把后端的聚合（譬如portlet之流）放到前端来，后端只保留一种类型的页面服务——页面模板，以及若干易于管理的API接口，大大简化了后端体系的复杂度，而且还能把压力分散到前端来，这是我早些年不曾见到的。
这三个问题想过之后，觉得有价值，我才去学习。要不然，对我而言就是不想深入的东西，了解了解也就罢了。
新技术学习的方式呢，我想说这么几点：
寻找切入点
我很喜欢BlueDavy的blog上的一句话：“理论不懂就实践，实践不会就学理论！”。
最后最好是要落到动手实践上去的，但是倘若习惯从那些原理介绍的文字入手，未尝不是一种不好的选择。而且，现实情况会有一些约束，例如在了解几家互联网公司的云平台的时候（Amazon的EC2，M$的Azure等等），除非你是这几家公司的员工，否则是很难深入其中的。
寻找自己的兴趣点
学习应当是一件有意思的事情，当你的大脑排斥它的时候，我不相信可以很容易地掌握这门新技术。如果你找不到兴趣点，那么，不妨回到我前文对于新技术是否值得你学习的观点上去，既然你没有什么兴趣，你学它干嘛？
善于比较
比较是一种非常容易上手的思考方式，和什么比较？和相似技术比较，和操作系统、网络这些基础设施上面的例子比较，最后，和生活中的例子比较（譬如，Java NIO的实现是一个很好的例子）。
不断获得回馈
回馈是什么？做出一个HelloWorld的例子，就是一个极好的回馈；理解某一项实现原理，联想到其它类似的实现，产生一种恍然大悟的感觉，也是一种回馈。在学习的过程中，不断产生回馈，意味着你不断地收获成就感，这是继续下去的动力之一。

转载

Ⅳ 怎么成为一个优秀的程序员即如何思考问题，如何学习，如何写代码

在基础扎实的条件下，你可以从设计模式中体味到很多将问题解决方案和写代码进行很好结合的方式。

扎实的基础是大量的练习而来的，除了要细致地阅读你的教材，不懂就问，很多时候教材中的语句有作者的主观性，表达不准确，这个时候就要把代码实例拿出来试验下。

一定要多多做练习，各种题目的练习，跟同学等交流也是很好的方式，同时还要注意积累和总结，我的空间中有些刚刚学习javaSE时候的练习代码，你可以看看，关键是能自己做一下练习，同类考察水平的题目很多的，在代码中学习是个很好的方式。

学习编程就要习惯于看代码写代码，看别人的代码也是很有用的，不管别人的代码水平是不是一定不自己的好：好的可以拿来学习，不好的就要仔细总结，避免这些问题。

总结下：①学会阅读学习教材。
②多多练习，增强动手能力。
③试图阅读他人源代码(包括JDK)以提高自己的水平。

Ⅵ 关于程序员在30岁，35岁之后怎么办的新思考

今年一直在深度加班，最近感觉自己身体确实不如五年前了，不如20岁的时候了。那时候学习到2、3点才睡觉，第二天早上继续开工，没有问题。最近感觉熬不动了，晚上十一、二点就困的不行了，早上也起不来，起来的话，上午就有点精力不够。
我给自己的定位就是技术，我对纯的管理也不感冒，技术经理，架构师，首席架构师，技术总监，如果有机会的话，可能是这个发展路线。目前来说，就是个技术经理，正在向架构师转变，发现需要学习的东西更多了，精力还真是不太够用的。还有就是思考的角度要转变，不能以程序员的角度思考软件，要站的高一点，要全面，自己还要看过(最好是做过)很多这方面的东西。首先从整体来思考系统，然后分解，逐步分解、细化，最细的就是程序员的代码了，那个由他们来按照规范编写，要去把握整体的结构，整体的设计，整体的模式。
另外一个我认为较为重要的就是，需要对团队的开发人员做培训。最近我也发现了，虽然我们用的都是面向对象的语言。但是代码一点都不面向对象，除了写了class，因为不写class也没有办法编程啊。但是很多时候大家对于类的设计都没有认真的思考，而且大家的认识也不够深入，有必要在这方面提高大家的水平。封装、继承、多态，不是简单的类、继承、写个接口，就真的是那么回事了，很多时候我们还需要深入一点，越是基础越重要。还是那句话:出来混，迟早要还的。
公司每天都在抱怨进度为什么慢，我也在思考为什么慢呢?每天都在加班，周末也在加班，就是快不起来，都很努力了，没有人偷懒，为什么没有产出呢?我觉得就是这个面向对象的能力没有提高，写代码的时候卡住了，业务清楚了，流程清楚了，觉得代码也就是两天，为什么5天了，还是差一点呢?我决定就是代码功力不够造成的，如何提升呢?一是要靠自己多思考，下班多花点功夫练习，不是单纯的练习手敲代码的速度，而是对自己的代码重构，模式，思考怎么提高代码复用性，怎么才能让自己写的代码不是改来改去呢，要做之前先想一想，设计一下。只有在这方面下工夫了，才能真正的提高开发效率，减少加班的频率。二就是公司要组织这方面的训练，抽出一半天的时间，来个面向对象的头脑风暴，出几个小题目，大家一起讨论，在完成的过程中学习，锻炼思考能力，设计能力。三就是专事由专人来做。我不推荐让程序员参与业务讨论和定位，因为做业务和开发是两种不同的思维方式。做开发是很严谨的，业务则是很灵活的。四就是不要外行领导内行，会很惨的，至少进度会拖后很多。
难道这就是大家说的30岁之后要转型吗?在国内30岁之后真的写不动了吗?于是这几天顺便就做了一个思考。发现了一个惊天大秘密(哈哈)。发现了为什么30岁就写不动了呢?为什么国外的程序员，很多都是40、50还可以继续写呢?而且写的很享受的样子，我们就需要转型到管理呢?但是管理就像是金字塔，越往上越小，需要的人越少，不是每个人都可以做到管理的位置，况且不是每个人都适合做管理的。难道写程序没有出路吗?不是的，这纯属是有些人的谬论，误导了不知道多少人啊，至少我是这么认为的。
大家也许会说是环境因素、社会问题。是的，这些因素是影响到了我们程序员的生涯，但是他们不是主要因素，而且这些不是一天两天可以改变的，也不是我们一个两个就可以改变的，就像革命一样，需要时间，需要人来牺牲，需要前赴后继，积累到一定程度才可以变革。
我觉得我们可以控制的，又是主要因素的就是我们自己。至于30岁以后写程序没有前途的论调，可以用一句话解释。
30(35)岁写20岁的程序。
怎么解释呢?就是说30岁写的程序还是20岁的时候写出来的样子，没有发展，没有变化。那肯定干不过20的小伙子了，他们可以加班、熬夜，但是我们怎么办，身体根本不允许你那么干了，肯定就不行了。老板就觉得要30岁的还不如要20岁的呢?20岁的还可以更少的工资，更好忽悠，30岁的老油条，不好忽悠，而且产出也不行了，那就辞掉吧。
其实是我们自己断了自己的后路，是我们自己没有成长，还在写20岁时候写的代码，没有长进。在代码的设计(且不说架构设计)方面没有长进，所以写出来的还是较为混乱的，牵一发而动全身的代码。如果让年轻人改，他可以熬夜该，但是我们就不行了，所以都说30岁就不能写程序了。其实决定权在我们自己，要在20-30岁之间，提升自己，就算不想做架构，只想写程序，也要越写越精炼，要有自己的一套，要提升代码的功力。要学习设计模式，重构，要思考代码的结构，不是一上来就写一大丢，然后推到重新来过，那样肯定干不过年轻人的，哪有那个精力啊，是不是呢?
只想写程序也可以，但是一定要想办法，在30岁的时候不要在写20岁的代码，否则就真的没有前途了，甚至要早点回家了，因为你干不过20岁的小伙子啊。
希望大家不要在30岁的感慨，希望大家作出改变。改变这个潜规则。

Ⅶ 为什么程序员的思维很难理解

1、程序员的思维比普通人要严谨。
对编程有一定了解的人都能理解这一点，一是一二是二，电脑不认模棱两可的回答，因为“模棱两可意味着更多的可能答案”，所以你跟程序员交谈的时候，如果你问他“为什么要这样问”或“你为什么听不懂”，你就会知道你自己的描述有多么的不严谨了。
最简单的例子，你妈妈让你去市场买水果，如果看到有苹果就买一个苹果，看到梨就买两个。你看到市场有苹果和梨，你会买什么回家？
首先给出一个大前提，在程序上不存在“潜台词”或者“潜规则”这种东西，唯一起作用的只有“字面意思”。
一般人肯定是买一个苹果和两个梨。当然程序员也不是脑子有坑，以一个正常人的思维考虑也会买一个苹果和两个梨，但是看到这问题的第一个瞬间的直觉反应，却是“如果看到梨就买两个苹果”。这个问题不存在潜台词，所以所有人都会直接从字面理解老妈的意图。
按照程序的逻辑分析，这句话共分为两个部分，代表两个程序任务。“如果看到有苹果就买两个苹果”为任务一，条件是“看到有苹果”，目标对象“买苹果”，数量“一个”；“如果看到有梨就买两个”为任务二，条件是“看到有梨”，数量“两个”，没有给出新的目标对象。
因此按照程序逻辑来讲，第二句话将继承上一个目标对象，也就是“买苹果”，所以这句话被看起来像职业病一样的思维直接翻译成了“如果看到有苹果就买一个苹果，如果看到有梨就买两个苹果。”

————————————————————

2、程序员看问题比一般人透彻。
这是职业特性导致的，因为电脑编程的严谨性，因此程序员面对一个问题、一个需要实现的目标或者一个bug时，他会思考更底层的问题，并且会习惯性采用归纳法来尽量避免以后可能遇到同样的问题。
比如用输入法输入中文的词句，有的时候打出了一串拼音，然后按下数字2选取发现不是自己想要的词，然后发觉数字1对应的才是自己想要的，删掉，重新输入拼音，这次按下数字1的瞬间却发现两个词的位置调换了，于是又删掉重新键入，这次认真地看了看，终于选对了想要的词的序号。
这个时候你会说，啊，我下次应该更小心一点，不要马虎大意想当然，看清楚了再点。
程序员不这么想，他会想，导致这个问题的看来是输入法的“词语顺序自动调整”功能，他会自动监测使用者输入的各种词语的频率，来自动调整词语的顺序，底层代码实现的逻辑很简单，每个不同的词对应一个从输入法安装到现在的输入次数的计数器，直接按计数器排列顺序就好了；也有的输入法会监测你输入后是否会将其删掉，那么这时候会被智能识别为打错字，计数器不会加一。
然后再一思考，这种功能一般都是可以开关的，如果我想要靠记忆记住顺序使用而不用输入法自动调整的话，比如对汉字输入的速度有一定要求需要考记忆记住汉字序号，我只需要进入输入法设置将其关掉即可；如果我想要它帮助我调整词句位置，但是又不需要频繁地调整，那么在我有工作需要的时候我会提前关掉，平时开启即可；而如果我想单纯依赖这一功能，那就不用管它，下次看清楚再选就好了。

Ⅷ 程序员思维会给你的生活带来哪些影响

比如：对于许多重复的、线性的事物，大脑将独立于编程。我要检查强迫症，反复检查是必要的，比如锁门，我会把锁分为几个步骤，顺序执行，返回结果，因为方法执行起来也不例外，上班时会放心，我只好在这个检查中进行治疗。驾校实习，第二节考试，编译程序，顺序执行，突发情况，分行解决方案，满分。

6。永远想想2的力量

职业原因：计算机存储信息的基本单位是位（位）。在二进制系统中，每个0或1是一个位。

日常行为：通常不是在10计算，而是在2计算。有些平凡的日子在程序员眼中也是神奇的。例如，程序员日是每年的第二百五十六天（2·8）。还建议每年使用10月24日作为程序员日（2？10）。

7。生活方式不健康

职业原因：程序员编写半天程序，没有电脑屏幕的眼镜，甚至在灵感爆发时熬夜。

Ⅸ 一名网站程序员的思考

既然有了想法就去做啊，不要犹豫。其实做好了哪一方面都需要很大努力的，而且只要努力，一定会有所成就的。望早做决定，早做努力呀。