Coding？是不是Coder思维模式

Think in XXX

一直以来我认为GISers和Coders是没有太大关系的，我们有自己的专业思维方式，现在工作了觉得这个观念有必要修正一下，写点东西跟像我一样的GISers分享一下。首先，工具不能形成一种思维模式，思维模式需要待解决的问题来支持。从某种程度上GIS只是一种工具，一门技术型的专业为什么非要把这个东西弄成一个科学呢？有什么问题可以研究，有哪些技术是自己原创的呢？GIS中的理论知识完全使用的是地理学、数学、计算机科学中的概念、方法和技巧，不过，从更抽象的层面来看所有的知识都可以视为工具，那么反过来大部分的工具在使用上也具备固定的思维模式。所以Think in XXX是GISers和Coders都要有的基本技能，所以，所谓的专业的思维方式是在具体实践中的思维方式的表现。至少目前为止，我还没有遇到一项GIS的东西不要用到其他基础专业的知识；从研究的对象来说，我们只是在研究一种方法表示原本单一的地理数据，也并不是对所有的领域都可以起到支撑性的作用。各个方面都表现不出一个学科的性质。最后我们的领袖级人物还出了一本think in。。。这种技术标志性的专著，好吧，我要彻头彻尾地Think in GIS了。如果你是一个计算机科学专业的你会很熟悉这种命名模式什么think in C++，think in Java，think in 。。。

我的思维观

这里我对自己认知的思维做一点说明。对于这一点的阐释我想先抛开专业局限，我不想考虑任何的专业范畴，跟专业名称无关，只想把“思维是什么”问题说明白。思维，就是具备思维这个器官官能的生物对所见，所闻，所感，所做进行重新的确定，确定是不是自己想要的，是不是可行，是不是对，是不是自己喜欢的，是不是。。。。。。杜绝专业名词。“怎么思维”，思维都是来自思维的器官官能，有序地，有条件地，通常是伴随着一些刺激，怎么思维就是选择一个思维的顺序，如何在合适的适当的节点上接收适当的刺激。“思维模式”——长期接受某一种思维的方法形成了一个较为固定的形式就称之为“思维模式”吧。

专业不同的人思维的模式就不一样了。GISer有GISer的模式，那就是所见即所得，目标要明确，不丑。我个人很尊崇这一模式，和我一起工作的人也是遵循这一原则的，而且这个实践模式完成的工作不俗。我也很明白这些并不是一个优秀模式的全部，这些还有待改善，直到我可以完成一个优秀的工作，做一个明智的决定时。

没有好的思维模式的指导，现在的我时常会犯一些低级的错误，比如不知道自己的目标是什么，常常因为一些其他并不重要的事情将自己的目标忘记，不能快速定位最简单的达到目的的路线。

下面来具体地看一个不好的思维模式，我想放一份shp数据到osgearth上以便定制自己的三维场景，大概是这样：

这个事情本来只我的目标是要将数据按照说明的方法在程序里运行一遍，程序正确运行时我可以在程序中看到三维的场景，一个地球再深入一些一个国家，再深入一个城市，城市的建筑也在这时显示，最后在城市环境中漫游。我来描述一下自己的实现思路是想法：把数据先放到osgearth上，不做任何处理，确定数据是否正确。接下去，在配置文件中对数据显示进行一定的设置。最后一步，把完整实现的实例保存下来。但实际情况是，我在第一次尝试的时候就遇到了问题，造成配置文件的更改无法作用于数据，我还在没有深入分析的情况下就认为这是数据在重复加载的过程中使用了缓存被程序重复使用，所以没有应用配置文件中的修改。如果是这个问题，其实可以通过更改配置文件的名字很快就可以验证。可是我没有迅速想换文件名去验证，而是去搜索默认缓存路径在哪，试图去删除缓存目录下的缓存数据，结果搜了半天只有一些简单的关于缓存的说明没有一条提到osgearth示例里的软件默认的缓存目录在哪里。等我发现没办法找到这个缓存路径时，才想到更改只好去换文件名，改了配置文件的文件名后但是完成这些以后又遇到了问题，程序没有弹出就报内存读取错误，我还是没有分析具体问题，而是臆测随便想了个错误的可能的错误，又开始然后试图去搜索“所谓的问题”的解决方案。从这一段描述来看，上面提到的这些“操作”都只是在coding，而没有真正的思维。而在解决问题的思考过程中，明白问题是什么才是最关键的，明确了真正的问题再去思考解决的方法，可以提高效率。但实质上这个没有经过分析的可能的错误并不是症结所在，原本我应该通过更多的测试和分析定位错误，这些测试就是不断屏蔽数据中可能造成问题的值，直到问题不在出现为止。我应该做的是验证猜测是不是正确，也就是说问题是不是出在那一点上，否则，定位不了真正的问题，徒劳的搜索解决方法，就做很多无用功。这些都是我在一个下午的忙碌后，一个小时的正确时间总结得到的经验。

除了还有关于前段时间一直忙一个程序的设计，结果高手给我设计出了基本框架我却在没有理解问题的前提下试图修改他的架构，最终不能成功完成任务。首先要解决的问题没有被明确，不能理解这种设计的意义和用途，我也不知道问题之所在，我要做哪些工作来解决遗留下来的问题。

程序员思维

今天下午学习了一个好的模式就在这里分享一遍，是我的一个程序员同事教我的。首先，明确面向问题是什么，只要知道异常的表现是什么，和预期的表现存在什么样的差异。

接下来就应该去整理逻辑和调试代码，发现导致问题的真正原因。不要没有主观地臆断，通过合理的逻辑和代码的运行效果找到原因说明问题。

这个思维过程相对简单，但是是个体力活，程序异常的可能性会很多，要一个个去排除并最终确定问题需要时间和体力。

==============================================================

重读篇博文，让我想起了温伯格的《你的灯还亮着吗？》中的一些片段，他通过具体生动的例子告诉我在解决问题的路上，要首先明白如何确定问题，问题是什么（通过问题造成的影响，影响到了谁，谁能够解决问题等问题找到问题的边界），解决问题的同时避免引入新的问题。我一直想阐述的也不是GISers和Coders的思维有什么区别，而是我在同时做着两类工作的时候，当我的同事给我指出了问题之后，我发现自己的思维方式存在问题。或许我说的有点危言耸听，因为这可能只是我自己的思维问题，而我把它夸大到了GISers这个群体。而那个指点我的同事是一个优秀的程序员，那也可能只是他的个人思维方式，我可能也把他夸大到了Coders这个群体了。那么，这篇文章真正想表达的是我希望自己今后可以避免错误的思维方式。要学会一个通用的解决问题的套路，比如像我的那个程序员同时那样的套路。在这个套路里，我们可以快速定位问题，高效地、完美地解决问题。最后，希望和我有着同样问题的人一起交流。