程序員的思考

Ⅰ 什麼是程序員，程序員是什麼，思考

作為程序員的我來為你解惑，同時也希望可以有更多人了解我們的職業。很多人也問過我程序員是做什麼的？難道修電腦的？ ！！

正解：程序員(英文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。生活方式不健康

職業原因：程序員編寫半天程序，沒有電腦屏幕的眼鏡，甚至在靈感爆發時熬夜。

Ⅸ 一名網站程序員的思考

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