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這個羣體了。那麼，這篇文章真正想表達的是我希望自己今後可以避免錯誤的思維方式。要學會一個通用的解決問題的套路，比如像我的那個程序員同時那樣的套路。在這個套路里，我們可以快速定位問題，高效地、完美地解決問題。最後，希望和我有着同樣問題的人一起交流。