最近有一些思考，但是都是比較零碎的，想著來總結一下，也有記錄之宜。
我一直認為程式設計的實力分為硬、軟實力兩種。你所通曉的程式語言語法、三方庫框架、開原協議等等，這些是硬實力。而面對同乙個需求，你的思維方式以及你思維的**表達能力，這就是軟實力。硬實力之硬，硬在有較好的辨識度，隨便出幾道題考考你就知道你會不會c++，但是硬實力的軟肋在於「跨平台」不友好。乙個幾年經驗的c++工程師跟乙個零基礎的小白同時接觸js，在基本語言的學習速度上，前者不見得會有多大的優勢。但是在軟實力上，這名c++工程師多年的程式思維表達訓練一定可以讓他很快的適應js的表達方式。程式設計的本質就是一種思維方式的表達，這種能力是無所謂程式語言的。不同的人在解決同乙個問題時，有的人的方法是零零碎碎不著邊際，有的人的方法是一針見血的簡單利落，或許最終他們都能夠正確的解決問題，但是高低之分早已分明。而這種複雜的問題簡單化的能力，是一種高屋建瓴的思維方式，這種技能是可能在一定的熟練度的前提下訓練出來的，這也是我一直在追求的目標。
以上，應該是我這幾年來對程式設計最為本質的思考，不止於此，程式設計還對我的思維方式有了一些改變。
萬物皆有因，bug皆有道。這一點想必程式設計師看了都會感慨良多，誰還沒有個疑難雜症呢，但是愈是麻煩的bug，愈是不能失去耐心、沒有章法。按照我的經驗，在面對疑難雜症，且三十六計全出後依舊未能解決問題時，是很容易出現一些較為玄學的想法的，就好比我最近的乙個專案，同樣的**從ubuntu移植到windows下，效能下降了幾百倍，我想只要是乙個冷靜的頭腦都不會認為這是作業系統的問題，但是如果把你放在當時的情景下，你會怎麼做呢？我已將所有能夠排除問題的地方都仔細檢查了一遍，但是還未有結果，一般這種時候，最容易出現一些玄學的念頭，冷靜！系統級別的bug終究是非常之小的概率。
程式設計的思維方式。我想大部分人的debug思維方式可以用下圖粗略的表達：
但是debug不是一蹴而就的，如果本次流程結束後不能夠有效解決問題，那麼之後的解決思路是怎樣呢？難道就胡亂排雷？就目前我的經驗來說，在上圖稍做一些改動即可達到較好的效果，如下：
在排除了所有的猜疑目標之後，此時不應該洩氣，更不可胡亂猜疑，在確定了你都正確的排除了猜疑目標之後，接下來我們需要增大猜疑區域，再次通過去形成我們新的一波猜疑目標。有效的思維方式可以讓我們的debug過程更為簡單明瞭，這也不失為我上文所說的高屋建瓴的思維方式之一。
程式設計之路漫漫，切勿忙於奔跑而疏於思考。
OPC給我們帶來了什麼
眾說紛紜opc，說有什麼好處了，好像只要opc了，一下就ok了，冷靜的想一下也沒那麼多好處。opc只是提供了一種廠商之間的介面，尤其是在硬體提供商和軟體提供商之間可以完全實現各自開發自己的產品。大家都符合這個規範，以後用的時候就不用考慮怎麼實現硬體和軟體的互聯，而只用關心系統是如何實現 怎麼能更快更...
遊戲給我們帶來了什麼 ？
我是乙個遊戲愛好者 不是很瘋狂的那種 沒事的時候就玩玩遊戲。不知道是怎麼的玩遊戲的時候時間過的很快 比上課的時間快的多呢 雖然不是樣樣都玩的好，但是至少在這個過程中得到了不少東西 當然有好有壞啦 舉個例子吧，遊戲帶來的大多是快感，玩的時候幾乎什麼事情都忘記了 吃飯有時候都 有個名人說過 由於資金短缺...
OO給我們帶來了什麼？
oo到底給我們帶來了什麼影響？本文結合筆者實踐的體會，試圖對此做乙個簡單的 至於更為深入 細緻 完整的討論，大家自當查閱相關書籍。此外，本文沒有提及oo的負面影響。這裡採用了一種由特殊到一般，由簡單到複雜的思考方法。讓我們來考慮一種極端的 也是最簡單的情況，乙個系統中只有乙個類。此時，將類的屬性和對...