程式設計師心得體會 篇1
就現在經濟大環境而言，很不樂觀，程式設計師的日子也很不好過，無論是還在找工作的、還是已經入職多年、哪怕做到項目經理技術經理的，壓力都異常巨大，似乎處處充滿危機。但是，仔細分析一下，出路還是有的，甚至解決溫飽、過上有房有車沒貸款的生活也是很可能的。首先，在如今這個浮躁的社會，大多數人的心態也是浮躁的，只要你能潛下心來，深入研究某個技術，有了一技之長，溫飽問題肯定就可以先解決了。
1、一技之長
新技術層出不窮，而核心的精髓的東西卻變化不大，就像.NET，從VS20xx到VS20xx，已經有10個年頭，VS的版本不斷更新，而.NET核心的最新版本也才4.0，所以，作為程式設計師，我們要多掌握核心的東西，精髓的東西。
我們的學習積累毛病在於：貪多、貪全、而不夠深入。對於很多技術，我們都很有興趣，對於剛興起的技術，也緊緊跟隨。但是，幾乎都是蜻蜓點水、一知半解。回頭想想，我們似乎什麼都會一點，什麼類型的項目都可以做，B/S的、C/S的、資料庫的、分散式的，等等，但是，卻不敢說，在某某方面，我的水平已經超越了圈中同類型的80%的人。只是我能做的，大家都會做，而且，我也沒有把握比別人做得更好。
必須要讓自己有價值，而自己的價值在於不可替代性或是難以替代性。如果，隨便找個程式設計師就能把你replace掉，你的價值就很低廉了。如果在你負責的某個方面，只有20%的人超越你，那你的價值、你的重要性就凸顯出來了，你與僱主的關係就從被動轉向了主動，你就有了談判的籌碼。
在專業化高度分工的今天，一技之長並不是說需要你掌握某個很大的方面，而只需要你能掌握其中的某一個小的領域，並不斷地深入下去。就這個小的領域來說，你花個3、5年的時間擠進前20%是非常可能的。比如，有人專門研究SqlServer資料庫最佳化、有人專攻TCP通信、有人深入研究IIS、有人深入鑽研WCF，等等。
2、打造自己的精品
當你在某個小領域鑽研了3、5年後，你一定會有很多心得，積累了很多經驗，其中有些經驗是異常寶貴的，為什麼了?因為在鑽研這個領域一段時間後，會陸續碰到很多問題，而那些80%的人，在碰到某個問題時就停止向前了，在這個小領域的水平就到此為止了，而你卻不斷地解決這些問題，不斷地超越那80%的人。
而且，很可能的一個情況是，作為幾年鑽研的一個副產品，你積累了一套類庫或框架，而基於該類庫或框架來開發該領域的項目，不僅開發速度更快，效率更高，而且項目的質量更有保證。然後，你可以把積累的這套類庫/框架打造成一個精品，不斷的打磨，直到某一天，可以讓更多的人來用它。
當你在某一領域有了豐富的經驗，或者有了自己的精品類庫/框架之後，你便可以面向更廣闊的市場。
3、更廣闊的市場
在公司做個小白領，你的生死榮祿幾乎就完全掌握在你的.上司手中，你不得不關注他，被他的情緒所左右，很可能因為他的一句批評，你就整夜難眠。你覺得自己做得很好，可是他不認可。但是現在，你不需要再過分的關注他，你可以將眼光轉向更廣闊的市場。
網際網路時代的一個好處就是，任何人都可以以非常低廉的成本來向大眾市場展示自己或自己的產品，評判你價值的不再(僅僅)是你上司，而是整個市場，相比於你的上司，市場的評判會更客觀、更公正。你可以把自己的經驗能力說明放到自己的部落格上、寫專業的技術文章來分享知識、順便推廣自己，或者把積累的框架放到網上去賣，或者去項目交易平台接那些與你精通的領域對口的項目，由於在這個領域你超越了80%的人，所以，成功接到項目的可能性是非常之大的。有了這些基礎，以後就算是靠技術創業也是有可能的。
如果做到了這三點，我想，你的“有房有車沒貸款的生活”差不多就可以實現了。
就我個人經歷而言，我花了10年的時間積累了ESFramework通信框架和OMCS語音視頻框架，單靠它們的收入，滿足家庭的生活開銷已經足夠了。我作為一個普通的程式設計師，既然我可以做到，我相信後來人也可以做到，甚至做得比我更好。祝福大家。
程式設計師心得體會 篇2
軟體開發
作為程式設計師，接觸最多的當然是軟體開發了，以下是7條心得：
1、若無必要，勿增實體。
這是奧卡姆剃刀的定義，所謂剃刀就是法則，是奧卡姆這個英國學者提出來的。這個剃刀核心的點在於不要浪費較多東西去做，用較少的東西同樣可以做好的事情。放在軟體領域，就是不要過度設計，添加當前不需要的功能，也不要一開始就做的非常複雜，難以維護。
不需要用設計模式，就不用硬套。不需要用額外功能，就不要寫擴展。用設計模式和寫功能擴展，必須要有不得不這么做的理由。
無論是新創建的軟體系統，還是添加功能到現有系統中，都應該從一個最簡單的版本開始，這個最簡版本甚至幾乎沒有可用功能。然後，再一步步疊代與重構，擴展它的功能，完善它的設計。簡單的系統自然而然會演變成複雜的系統，而不是人工注入複雜，影響它的正常進化。
2、日誌記錄，錯誤處理。
開發新系統必須要做的一件事就是搭建日誌記錄和錯誤處理能力，系統上增加功能也要接入日誌記錄和錯誤處理。雖然這不會影響正常場景的功能，但是非常重要。
日誌和錯誤可以告訴我們程式運行的時候發生了什麼，程式有沒有按照預期工作，通過日誌和錯誤我們可以基本知道程式運行的路徑，也可以用來做監控，統計和預警。
3、每行新代碼都要能被執行到。
新寫一個功能，一定要保證你的新代碼都能被執行到，也就是你的測試用例能夠覆蓋到代碼的每一行。有些特別的分支可能很難走到，但你要想辦法走到，比如構造符合該分支的請求入參，再比如異常分支可以使用mock工具mock異常出來做觸發。
4、一次只改一個地方。
這是種變數思維。在你開發時，發現程式掛了，如果你只改一個地方，很容易定位到問題所在，因為就一個變數，不可能是別的原因了，但如果你改了好幾個地方，之前也沒有測試，找出原因就會花費你大量的時間和精力。
所以，要小疊代，每疊代一個點確保功能符合預期，再進入下一個疊代，如此重複，而不是一股腦改掉所有的內容。
5、集成測試前要單元測試。
你負責一個單元，你的同事負責另外一個單元，入口側集成了這兩個單元，入口有專門的測試同學來測，以驗證整體功能的正確性。如果單元測試充分，就能使測試同學只關注各個單元之間協調的正確性，從而節省整體的時間和複雜度。
6、開發時間往往比預期長。
有時候，你可能會把事情想簡單，真正寫代碼的時候才會發現評估有遺漏，工期會比預期長。
有時候，代碼寫的非常順利，測試的時候可能就會被某個不符合預期的場景卡主，需要花很長的時間解決。
有時候，你依賴的下游未能按期向你交付服務，你的開發工作就要延期。
寫代碼容易，讓代碼正常無誤的跑起來，就比較費勁了，所以評估工作量要給自己留點buffer（緩衝），以應對一些特殊情況。
7、讀代碼並且跑代碼。
對於一段代碼，想要理解它做了什麼事情。一種方法是閱讀它，憑藉自己的大腦去得出代碼運行的邏輯。
但這種方式並不可靠，畢竟人往往是靠不住的，不過系統是可以靠得住的。
那我們就可以跑這段代碼，去分析真實系統環境運行的結果。
職場協作
作為職場人，我的工作除了寫代碼，還有就是和各個角色的協作，像產品經理，項目經理，其他開發，測試，以下是職場協作方面的7條心得：
1.選擇適當的溝通方式。
就溝通效率而言，當面>視頻>電話>聊天軟體>郵件。
打擾強度和正式程度是反方向。
緊急的問題就當面或視頻或電話，搶奪對方的注意力，儘快解決。
重要的結論一定要落在聊天軟體或郵件里。畢竟電話沒有存檔，出了問題沒法追溯。
但如果你什麼小事都要發郵件，那也太浪費自己時間了，什麼事情都要給人打電話，那也容易讓別人厭煩。
所以大多數場景，還是聊天軟體，你留言，對方看到了再回復，不必把雙方的溝通綁定在同一時間段。
2.藉助身邊人的力量。
有些時候，你做事情可能會卡主，這非常困擾你，而你也毫無頭緒。
這個時候你就可以藉助下身邊人的力量了。
比如一件事你在三個方案裡面糾結，你就可以整理好自己的'思路，分析各個方案的優劣，然後帶著這些信息和同事或老闆溝通，尋求他們的建議。
有時候，你在向他們表達的時候，可能就意識到自己的方向了。當然，你也可以得到不同視角的建議，這對你方案的完善是很有幫助的。
所謂：好風憑藉力，送我上青雲。
3.善於提問。
很多事情自己是可以搞定，比如讀代碼和運行代碼可以理解這一塊邏輯，但這要花很多時間。如果你直接問作者，幾分鐘內你就可以拿到這些信息。
信息是可以換能量的。所以多提問，多獲取信息，你可以少做很多無謂的工作，從而把精力投身到重要的事情上。
4.不輕易承諾。
承諾並能順利完成事情，是值得佩服的。
但過分過早承諾不適合自己做的事情，對自己無疑是一個負擔。如果你本身帶團隊，對團隊也是個負擔。
承諾要慎重，如果還不明朗，就帶回去再評估考慮下。對外部團隊如此，對團隊同事也應該如此。
不要給了對方期待，又給對方失望，弄得自己信用也不佳。
5.分享利益。
一件事，如果有他人的貢獻，我們要感激這個人，也要分享利益給他。
比如你寫的專利里某個人幫助了你，作者中一定要加入他的名字。
比如你在向領導匯報你主導的項目的時候，一定要提到其他參與者的名字。
之前看周杰倫演唱會錄影帶的時候，有一段是杰倫專門介紹場上樂隊各個成員的名字，當時看這段挺動容的，怪不得像方文山，楊瑞代這些人能和杰倫合作20多年。
6.清楚自己的角色，做角色份內的事情。
一張地圖上，首先要有定位，然後要有目標，才能去看走什麼樣的路徑。
角色就是這樣的定位。你把自己的角色定位成純開發，一般來講專注技術就好了。
但如果你想和產品經理更好的溝通，最好還是培養一些產品思維。這樣有個好處，就是一些技術類需求，你可以自己判定和定義了，此時你的角色就轉換成產品經理了。
如果需求比較多，不能馬上都做，需要排下期，周期長的項目還要管理下項目節奏，此時也沒有專職的項目經理介入，那你就可以嘗試做項目經理的角色。
你技術一路發展，對自己負責的領域了如指掌，你開始接觸了一些架構設計和決策的工作，那此時已經有新角色了，就是架構師的角色。
所以一個人是可以有多種角色的，角色決定了職責，因此一件事情中，要清楚自己的角色，做好角色份內的事情，不要越界，也不要失職。
7.讓子彈飛一會兒。
如果一件事存在爭議，你並不是爭議雙方的領頭人，只是這件事可能會涉及到你落地。那么不要急著去介入具體方案和落地，讓他們再爭會兒，很可能最終的結論是你啥也不用做。
認知成長
作為終身學習者，職場工作的同時，也關心著自己的成長，以上更多是技能方面的，以下是認知成長方面的7條心得：
1.技術是工具，也可以是資產，還可以是商品。
技術有三個階段：技術支撐業務，技術驅動業務，技術創造商業價值。這三個階段技術是分別作為工具，資產以及商品存在的。
我們看到的一個個網際網路產品，背後都是由技術搭起來的，技術只是工具。
隨著業務發展，逐步沉澱面向某個問題的解決方案，有些以專利的形式體現，技術就成為了資產。
把通用的技術提煉出產品能力，像阿里雲的很多服務那樣，技術就變成了商品。
2.提升效率。
什麼叫效率？
效率就是你完成了多少事，除以你開始了多少事。你開始了一百件，只完成了一件，你的效率就是1%。
所以提高效率的辦法，一個是你多完成事，第二個是你少開始事。
3.打造自己的知識系統。
人的大腦天生喜歡記憶結構化系統化的知識。零碎的知識點太多，也只是隱藏在大腦的某個角落，經常被忽視。
關鍵是建立體系化的知識結構，去幫助生活和工作上的決策。
4.機會留給主動的人。
主動向項目組同步進展，主動向領導匯報，主動把事情推向正確的方向。你會發現自己的運氣在變好。
5.凡事需要平衡。
一個算法要想獲得更快的時間，勢必要犧牲更多的空間。
同樣，無論項目方案還是架構設計，都沒有對和錯，要權衡當下更重視什麼，可以容忍什麼，做出適當的選擇即可，後邊可以再調節。
6.任何事都是一個IPO。
I是Input，P是Process，O是Output，凡事都可以歸為輸入-處理-輸出的路徑，想好依賴方，處理方式以及交付物，事情就可以變得簡單。
7.公司是你的放大器也是你的限制器。
公司是一種組織，組織能輔助個人做成一些事，比如個人在組織中做項目得到成長，能得到優秀同事的幫助，能享受公司發展的紅利，能獲得公司的學習資源和其他福利。
但個人做事往往會受組織的限制，比如制度約束，工作時長，發展方向等等。
需要好好利用放大器，同時也要評估限制器是否超出了自己的容忍度。
程式設計師心得體會 篇3
走過的路，回憶起來是那么曲折，我把自己的一些心得體會分享給程式設計師兄弟姐妹們，雖然時代在變化，但是很可能你也會走我已經做過的20xx年的路程，有些心得體會你可以借鑑一下，覺得說得有道理的你就接納，覺得說得沒道理的，你就拋棄，以下是我發自內心總結的`十點心得。
1、自己的戶口檔案、養老保險、醫療保險、住房公積金一定要保管好。
2、不要輕易換筆記本電腦，不要跟潮流，不要買過多的電子產品，不要過於頻繁的更換手機。
3、未來的生活節奏會更快，生活壓力會更大，競爭會更激烈，社會服務體系會更完善。
4、不要談過多的女朋友，談女朋友要看準，下手要穩準狠。
5、工作不要更換得太過於頻繁，選好了行業方向最好別更換太頻繁。
6、要對身邊的人好，要得到老闆的信任、同事的認可及支持、珍惜良好的工作環境。
7、錢很重要，但是生活質量比錢還重要，工作是很重要，但是家人比工作還重要。
8、當創業的收入比打工還少時，那就別創業，要找比自己能力強的人創業，你不會吃虧。
9、對程式設計師來講，開發思想、架構、代碼就是財富，別老丟棄你的勞動成果，要學會保護你的勞動成果。
10、當程式設計師要防止原地踏步，不勝作年限長了，經驗就豐富了，能力就強了，年紀越大工作越難找。
程式設計師心得體會 篇4
是非常重視效率的公司，工程師文化盛行，給我面試電話的是一個工程師，他說我是騰訊的軟體工程師，近日收到你的簡歷，想找你聊聊。
我還第一次接到非 HR 式的面試通知。過去後也是工程師接待我的，當時一直在想 HR 有什麼可乾的呢?
技術面試分為四輪，第一輪是兩個年輕的程式設計師，問一些項目背景啊，技術方向啊，也結合我的項目經驗聊了實現原理之類，聊得還比較開心和輕鬆。
第二輪是 Team Leader，重複了一遍項目經驗，他的側重點在項目進度控制和風險控制方面，他也問了我的薪資要求及技術意向，也說明了他們目前需要一個什麼類型的人才。
第三輪是專家評審，他們的側重點在於計算機基礎知識，項目實現原理，數據結構和算法，他們採取讓你先陳述，然後由淺入深提問，層層遞進鋪開的面試思路，非常專業，這相比很多公司面試喜歡冷門的技術細節，不知道高到那裡去了，這輪面試有很多開放性的問題，我回答時他們也會幫我糾正錯誤，整理思路。
第四輪是技術總監面，這哥們穿著真太隨意了，他好像比較忙，一直不斷在電腦上敲，只問了我兩個問題，說說你從業生涯中遇到的最大技術難題和解決過程，說說你熟悉的兩個開源項目以及項目背景和原理。
我在小白板上寫和說，過程中他很少說話，過程中他一直：然後呢?還有呢?最後看了一會小白板就走了，我一直納悶他到底聽了沒有。
最後就是 HR，她說該了解的都了解了，你有什麼問題問我沒有，我簡單問了幾個公司結構的問題，然後她就和我談薪資了，肯定是我開的薪資太低了啊，吐血啊啊啊，她淡淡說了一句，這個薪資沒問題，我們一周左右給你發 offer 就結束了。
開始有 HR 簡單聊了一下，然後筆試，有 10 個不定項選擇題，2 個編程題，1 個開放性的三列交叉排序算法題，整個筆試不難，感覺要得高分非常不容易，基礎的廣度和深度均需要顧及，接著就是兩輪技術面試，筆試答錯的題目都被抓出來問了，他會給予思路和背景知識，直到你弄懂了為止，有種上課的感覺，其他問的都是簡歷上的內容，譬如我大學的 SCI 論文是點陣識別方向，兩個面試官都非常感興趣，交流過程中他們都非常謙卑，不斷問我是不是這樣理解，沒有很多公司面試官高高在上的 SB 感。
最後是 HR 談薪，他很坦誠說了其他面試官對我的評價和三星給我的薪資，也談到了我將來入職的部門和工作，以及對我的期望和建議，他並沒有說三星多好多好，反而讓我比較目前已有的 offer，選擇適合自己的。
程式設計師心得體會 篇5
近年快速發展，也是我一直想加入的公司之一，只是我一直不知道廣州有研發分公司，直到後面聽一個朋友說的，於是就過來聊聊了。
首先是前台 MM 給我一張我很介意的背景調查讓我填寫，儘管不想填，還是耐性填了，有一份比較簡單的筆試題需要做，題目主要還是一些執行緒，訊息之類的 Android 基礎題，感覺並沒有根據級別來出題。
技術面試有三輪，首先是一個酷酷的灰衫人，問題集中在計算機基礎上，項目背景我介紹完了他也比較簡單問了一些問題，相對而言會少涉及 Android 開發，深度也有所欠缺，他理解能力非常好，有些專業性問題看得出來他沒有接觸過，但是很快就可以理順，途中他有問我這個面試題怎樣，我坦誠回答對我而言知識點深度廣度有所欠缺，如果有針對性會更好。
二輪是一個看起來很 Nice 的年輕哥們，面試過程一直保持微笑，口頭禪是為啥?面試內容上項目經驗涉及會比較多，也有一些設計模式和數據存儲相關，項目周期和風險控制也有所 Check，總體下來理論為主，技術點比較少比較淺，面試聊得挺愉快滴。
三輪是總監面，大部分問題圍繞在你有什麼優點，相對其他程式設計師有什麼優勢，有沒有某個項目因為你加入而變得不同，前兩輪也有一些這類問題，但不像這輪變成一個針對點，確實有一些項目組因為我的加入變得不同，但並沒有發生過質的裂變，雖然這種問題有壓價鋪墊的嫌疑，我一直覺得開源技術的發展已經讓整個網際網路行業變化，相對上個時代，團隊才是決定因素，但整個面試都有這類問題，也能側面反映出公司有個人主義趨向。
最後是 HR 談薪，HR 帥哥很贊很爽快，沒有很多公司的職業套路和誇誇其談，我的面試評價挺好，薪資要求超過了總監決定範圍，他說去申請，很快就收到了 offer。
在呆的時間短暫，和同事的相處挺好的，經常在一個小檯球桌上玩兒(一面的灰衫人花樣虐菜我)，業餘活動也很豐富，有健身房和滴滴，加班很多(22 點離開算早)，行政 MM 各個節日活動都很用心，年會也非常高大上玩得很嗨森。
在這裡從事了很多業務方向的編碼，獵豹有一些原有的通用模組，但大部分已經無法適應要求，每個項目都需要造一次輪子，努力想推進一些通用模組的編碼，很難有機會和支持，雖然一直覺得不適應，覺得這並非一個有技術氛圍的公司，開發地位相當低，但還是想努力改變自己來適應環境。
真正促使我離職是轉正評審，其實我覺得自己在獵豹的輸出還是不少的，有諸多槽點，也相信自己是至少及格的，轉正評審投影一直不太好用，時有時無的，我分別從項目輸出、技術輸出幾個方面說了，期間參與評審的兩個上司一直在玩手機，講完後卻說我未說過對項目的貢獻，幾乎全盤否定了我在通用技術的輸出，內部通用組件和開源方案也覺得沒有任何意義，有一種野路子出身的土軍閥感，當時本想辯解九層之台起於累土。
但因為另一位同事插話說我某個項目 PPT 寫成全是自己做的(其實只有少部分)，業務方面的業餘程度讓我震驚，心累沒話說了(不與傻子論短長)，後來只能離職。
離職原因一方面是我本身對獵豹廣研瘋狂加班的文化不適應，另一方面是想換個更適合技術人員發展的環境，離職感受一般，我前後對所有工作上有過支持和合作的同事都表示了感謝，期間簽字領導保持漠不關己的麻木感，缺少人與人之間的基本尊重，覺得欣慰的是最後收到入職帥哥 HR 一個離職祝語的小卡片，上面的打油詩讓我覺得離職獵豹還是有所遺憾。
程式設計師心得體會 篇6
隨著資訊時代的迅猛發展，軟體工程師這一職業變得十分搶手，其中java軟體工程師更是倍受青睞。有數據統計顯示，20xx年，我國對軟體開發人才 的年需求量達到20萬，並且仍舊在以20%的速度增長，其中java軟體工程師需求占比60%以上。由此可見，在巨大市場需求推動下，java軟體工程師 的薪資待遇將再創新高。
“對於職場人士而言，人人都期待高薪，可是並不是每個人都能順利拿到高薪。不少已經工作的人打電話過來諮詢，問道不是計算機專業可以參加java培 訓嗎?毫無基礎可以學習java嗎?我都會說，只要努力，沒有辦不到的事兒。”國內知名IT培訓機構尚學堂的負責人說到。的確，java技術看似高深，其 實也並沒有多么高深，只要學員們跟著老師的課程按部就班的學習，一定能夠順利畢業，也能夠通過每周5-10家企業上門招聘找到合適的工作。
大學學習土木工程的劉同學在畢業後找工作遇到了重重坎坷，看到IT行業風生水起，有了參加java培訓的想法，最後來到了尚學堂。劉同學說，因為自 己從來沒有接觸過java編程相關的知識，在報班之間還曾猶豫過，怕自己跟不上老師、同學的節奏。但開課之後，看到老師手把手敲代碼授課，看到每一個同學 都很認真的學習，知道自己沒有選錯。“四個月的時間，我完成了從門外漢到java開發程式設計師的完美蛻變，我每天都很充實，不光是知識的進步，同時在學習中 我也獲得很多快樂，跟同學們一同解決困難的問題，一同探討學習方法，老師也很認真、責任，知識點講的既明白又深刻，老師還把實際開發中積累的經驗毫無保留 地教授給了我們，這些寶貴的財富會讓我這樣零基礎的程式設計師少走很多彎路。”
20xx結合十年教學經驗及業界流行趨勢，全新推出“JAVAEE+大數據+移動4G前端”課程，被清華大學和中科院計算所的有關專家認可為最具技術含量的java課程體系。想要獲得高薪的人士，不妨著手開始學習。
程式設計師心得體會 篇7
不知不覺做軟體已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上並沒有成為高手的捷徑，但一些基本原則是可以遵循的。
1. 紮實的基礎。數據結構、離散數學、編譯原理，這些是所有計算機科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀察，學計算機專業的人比學其他專業的人更能寫出高質量的軟體。程式人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP，即使你再精通OOP，遇到一些基本算法的時候可能也會束手無策。
2. 豐富的想像力。不要拘泥於固定的思維方式，遇到問題的時候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想像力是建立在豐富的知識的基礎上，除計算機以外，多涉獵其他的學科，比如天文、物理、數學等等。另外，多看科幻電影也是一個很好的途徑。
3. 最簡單的是最好的。這也許是所有科學都遵循的一條準則，如此複雜的質能互換原理在愛因斯坦眼裡不過是一個簡單得不能再簡單的公式：E=mc2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要求時再考慮複雜的方案。
4. 不鑽牛角尖。當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕音樂，和朋友聊聊天。當我遇到難題的時候會去玩遊戲，而且是那種極暴力的打鬥類遊戲，當負責遊戲的那部分大腦細胞極度亢奮的時候，負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，我會發現那些難題現在竟然可以迎刃而解。
5. 對答案的渴求。人類自然科學的發展史就是一個渴求得到答案的過程，即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念，一定要找到問題的答案，你才會付出精力去探索，即使最後沒有得到答案，在過程中你也會學到很多東西。
6. 多與別人交流。三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈感的火花。多上上網，看看別人對同一問題的看法，會給你很大的啟發。
7. 良好的編程風格。注意養成良好的習慣，代碼的縮進編排，變數的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤，卻往往忽視了對注釋的排錯。注釋是程式的一個重要組成部分，它可以使你的代碼更容易理解，而如果代碼已經清楚地表達了你的思想，就不必再加注釋了，如果注釋和代碼不一致，那就更加糟糕。
8. 韌性和毅力。這也許是"高手"和一般程式設計師最大的區別。A good programming is 99% sweat and 1% coffee。高手們並不是天才，他們是在無數個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個10000以內的素數表，把它們全都抄下來，然後再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條。
這些是我這幾年程式設計師生涯的一點體會，希望能夠給大家有所幫助
程式設計師心得體會 篇8
在為期兩周的實習時間已悄然離去，剛來時的那種新鮮好奇早飛到了九霄雲外，更多的是離開時的那種不捨和對自己及所學的反思。
當我第一天來這裡時，和其他同學一樣懷著興奮得心情踏進達內it培訓中心，或許是單純的對這個新環境的好奇、也或許是曾經對這兒有一點了解想親自見證一下，因為聽大二的學長說只有來到達內才能學到與學校不同的東西，才能更接近實際項目工程。的確如他們所說，運行程式前必須作許多準備工作，如：在classview內的 csdidemodoc文檔內創建變數或增加成員函式;在resourceview內創建快捷鍵或增加選單項……當然做成功一個項目必須先寫好需求分析。
就這樣既興奮又好奇的跟著老師一步一步往下走，跟著在鍵盤上忙碌的敲代碼、調整程式。實習時間慢慢的在減少，而程式卻相反——越來越難，越來越繁。因為一個小環節與大家拉開了距離，在一個龐大的項目中是不允許任何一處掉鏈子的。看到同學們早已“輕車熟路”操作自如了，而我卻不知所措，立刻就有了壓力。一天下來感受最深的就是那種巨大的差距。學校所學與實際套用中的脫節。
在我困惑與迷茫時，老師給我解釋說：“咱用的編程軟體是vc6。0，更加注重的是對學生實戰能力的培養，在學校所學專業知識的基礎上讓我們學習最新的編程技術，通過做項目的方式來讓我們明白實踐中的編程到底是怎樣的……”正是冀老師的耐心講解讓我重新找回了自信，幾天下來從簡單的c++程式到第一個win32程式，從mfc到第一個dialog……雖然程式中還是有太多的疑惑但更多的是增長了見識看清了差距。
通過實際項目的開發我有以下幾點收穫：
1。多向老師、同學虛心請教，也別說自己學的不怎么樣，不然會大大減少自己的自信，從而與大家的差距越來越大。
2。編程以前一定要對整個項目有仔細的了解，最好能寫好需求分析，這樣在實際操作時就會更加調理，而且不會遺漏東西。
3。做任何項目都離不開團隊合作。所以我們一定要注意團隊合作意識，多和小組內的人交流。
4。在編程中一定要規範，絕對不可以隨性
在X內的這半個月培訓我感覺獲益匪淺。雖然與課本知識不同，至少我看清了實際做項目與書本知識之間的差距，不至於在就業後手足無措。這次實習對我以後的學習甚至就業帶來了巨大的幫助。
程式設計師心得體會 篇9
是非常重視效率的公司，工程師文化盛行，給我面試電話的是一個工程師，他說我是騰訊的軟體工程師，近日收到你的簡歷，想找你聊聊。
我還第一次接到非 HR 式的面試通知。過去後也是工程師接待我的，當時一直在想 HR 有什麼可乾的呢?
技術面試分為四輪，第一輪是兩個年輕的程式設計師，問一些項目背景啊，技術方向啊，也結合我的項目經驗聊了實現原理之類，聊得還比較開心和輕鬆。
第二輪是 Team Leader，重複了一遍項目經驗，他的側重點在項目進度控制和風險控制方面，他也問了我的薪資要求及技術意向，也說明了他們目前需要一個什麼類型的人才。
第三輪是專家評審，他們的側重點在於計算機基礎知識，項目實現原理，數據結構和算法，他們採取讓你先陳述，然後由淺入深提問，層層遞進鋪開的面試思路，非常專業，這相比很多公司面試喜歡冷門的技術細節，不知道高到那裡去了，這輪面試有很多開放性的問題，我回答時他們也會幫我糾正錯誤，整理思路。
第四輪是技術總監面，這哥們穿著真太隨意了，他好像比較忙，一直不斷在電腦上敲，只問了我兩個問題，說說你從業生涯中遇到的最大技術難題和解決過程，說說你熟悉的兩個開源項目以及項目背景和原理。
我在小白板上寫和說，過程中他很少說話，過程中他一直：然後呢?還有呢?最後看了一會小白板就走了，我一直納悶他到底聽了沒有。
最後就是 HR，她說該了解的都了解了，你有什麼問題問我沒有，我簡單問了幾個公司結構的問題，然後她就和我談薪資了，肯定是我開的薪資太低了啊，吐血啊啊啊，她淡淡說了一句，這個薪資沒問題，我們一周左右給你發 offer 就結束了。