程序员的思维方式探讨.docxVIP

程序员的思维方式探讨文/汪琳珊Mail：Wonly3@163.com(欢迎来信讨论)??? 我并不想探讨程序员们是怎么思考问题的，近几年来这方面准确和不准确的文字太多了，而且每个人，每个程序员的想法本身也都不一样。一直想要探讨的是程序员应该怎么去思考问题。当然这确实是个见仁见智的问题，所以这仅仅是个人的一些想法而已，仅仅是就事论事，请勿对号入座。?[怎么去想]??? 一定要简单清晰，在我看来首先一定要把问题看得简单化，满足实际需求是不变的基础，在这个基础上你总能找到一个简单而清晰的结构来构架你的世界，你能够将你架构中的各部分以清晰的定位。简单的结果不仅让你的开发过程变得清晰快捷，还易于沟通、协调，易于扩展，易于维护。但要做好简单可不是一件简单的事。??? 常常会出现一种感觉，关键不是我们怎么想的，而是怎么去想。这并不是说在选择解决问题的一个方法以后需要花很多时间去讨论为什么要选择这个方法，也许有些思维和分析过程所需要的时间就是一瞬间，而且也很简单，但这并不意味着不重要，相反其重要程度可能还需要下来专门的分析。往往有很多事情，包括分析与设计都是一瞬间的过程，却需要多少年的功底为之做准备，这大概就叫厚积薄发吧。这个时候也许会说“（根据多年的经验）你这么去想，这个问题就很简单了”。??? 记得在我刚毕业那一两年，觉得做一个游戏程序的规划其实也很简单，只要把模块划分好，分担到所有程序员手上，大家把各自模块完成后整合起来就完事儿了。就这样的思路我问过一些程序，如果我们做一个机器人，是不是也开始设计模块划分，分成头、手、躯干、脚等然后组装起来就可以了，这貌似正确、貌似简单。但这显然并不清晰，这种搭积木的思路，只是一种表象的简单，积木搭得越高越危险，也经不起任何风吹草动。真正的简单只有把机器人看成一个整体，拆分模块必须有拆分模块的理由，手要离开了躯干，怎么保证今后它跟躯干的的关系完整性，如果为了便于生产和组装需要分成几个模块，那从简单的整体来讲，首先要关注的就是他的整体脉络，这对于各模块来讲，关键在于关节，因为我们知道胳膊只能向内弯不能向外弯，知道至少有三个手指头才便于抓拿东西，这些最基本的原则一旦确定，每个模块的定位和要求才能清晰下来。所以我们在设计之初，开始设计的不是部件而是关节。对于程序来讲就是根据脉络确定接口，根据接口确定模块。不是一来就设计模块的。毕竟你的模块怎么划分你凭什么作为依据呢？??? 我始终相信任何事物都存在着他的简单抽象模型，有些模型可以用一些更加简单的事物来代替，只是抽象模型中可能存在一些概念，有些概念需要我们去创造，有些可以借用现有的概念，比如游戏服务器程序结构里的心跳这个概念，借用了人的心跳，相当贴切相当清晰。整个程序似乎一下就活了起来。再比如，在人们发现速度这个概念之后，创造了加速度这个概念来描述速度的变化，进而创造了变化率微积分这些思维方法，人类今天享用的科技可以说又都是基于这些创新的概念推演出来的。有时候程序员在思考怎么认识所要面对的事物的时候，就需要抽象一些基本的概念，甚至创造一些新概念借以将所要面对的事物清晰化。而且人类发展到今天可以借以抽象的原形已经很多很多了。我们没有理由还在糊里糊涂的没有把问题想清楚就开始写代码。??? 程序员不仅仅是代码员，因为涉及到每一个具体的逻辑，所以程序员扮演的是一个对事物和事务分析最透彻的一个角色。??? 需求提出者或者说游戏中的策划，在扮演着需求提出者的角色，需求的提出本身是很有学问的，需求的合理性，便捷性，似乎可以作为评价一个需求的好坏的一些标准，要提出一份好的需求，其实蛮难的。问题的关键就在于，在没有对客观现实有比较清晰的分析与认识的基础上，很难提出合理的需求。除非是可以参照的已有系统，否则就需要对客观现实进行比较清晰的分析，这一步工作程序员不仅要参与，还要作为分析工作的主要承担者，你不想等着看策划提出一个个不合理的策划案被你打回去，你就得要在开发之初承担起系统分析的角色，系统原型、数学模型的建立和分析都是程序员需要做的工作。当然，这并不是说程序可以去写需求，可以去写策划，程序仅仅只是提供需求与策划所依赖的原始模型。??? 这个问题说得有点大，与现实也似乎靠得不近，但在我看来，他是一个方向，是一切问题的出发点，也是程序思维一个有意思的归属。??? 对世界认识得越清晰，跟真理靠得越近。如果说程序员是在用代码创造一个世界的话，那么程序员当然是最幸运的职业之一了，因为历史上只有神和上帝在做这件事。??? 好像那些离心灵最深处的真相靠得越近的东西，往往跟现实都靠得不近，但你首先都不清楚心灵最深处的真实需要，说你的人生不过就总是在家与公司之间徘徊一点都不过分。徘徊的人生就不要指望什么了。??? 不过现实还是现实，下回说点现实的……?[思维需要一个良好的习惯]??? 有人说文化