我應該是對maya第一階段的學習有一個初步的認識了，在接maya之前一直覺得這個軟件很神祕，當栩栩如生的三維動畫就是用它製作出來的，我又對這個軟件產生了幾分“愛意”。帶着這份“愛意”我到清美報名了，接待的老師很熱情，教學老師也很認真負責，這裏不累贅闡述。下面就我第一階段的學習作一個簡單的學習心得彙報：
maya軟件的主要有四個模塊：maya建模、maya動畫角色建模、maya材質燈光、maya角色動畫、maya後期特效。我首先接觸到的就是建模，想學好三維動畫，當然要把這個maya角色建模學好啦。三維動畫的建模主要有：a、nurbs曲面建模技術。b、polygons多邊形建模技術。c、subdiv細分建模技術。當李老師給我們上完第一堂課後，我對maya的“愛意”就全消了，因為軟件基本都是英文，而我又是一個英語盲，除了簡單“thank you”之外估計就説不出完整的第二句，加上翻了一下教材，難度之大完全觸及了我的底線。
當然“愛意”頓時消退，可是我還是很認真地去學，鑑於我個人的職業發展方向的需求和動漫產業的朝陽性，我的學習動力依舊，老師也很負責地在教授。由於寫速度慢，又寫得不好，所以上課做的龍飛鳳舞的筆記也只有我自己看的懂，亂七八糟的圈圈叉叉中藴涵着大致內容和操作步驟，整個上午所要學的東西很多很繁瑣，動手操作時腦袋時常會混淆一些東西，導致步驟混亂，所以做我做起東西來會很慢。好在我們上課的時候都人手一機，可以及時消化，在不至於打亂仗。
經過老師多天來的孜孜不倦的教誨，以及自己的勤學苦練。一個月後自己終於可以動手做出完整的模型了，嘿嘿……雖然做出的東西還比較粗糙和幼稚。經過幾天的鏖戰，最終做出了機器貓，那個得瑟勁不知道大家能否體會，讓我也有了無比的成就感。當然現實是殘酷的，在我得瑟完畢靜下心來，把自己做的模型和參考的圖片進行比較時，我才認識天壤之別是什麼意思。這種差距源自於兩者的創作意圖，源自於時間的磨礪，源自於經驗，文化和技術的沉澱，快餐和速成文化對我們這代人的影響等等等等。這些都是我從兩幅作品的對比中體會到的。作品本身不會説話，卻可以感染我這樣去想。
於是我此時此刻深信一句話“學習是沒有捷徑可言的，唯一的捷徑就是不斷的學習和練習，只有這樣才能學到真功夫”。我學maya還只邁出了第一步，路漫漫其修遠兮，吾將更加努力。我也相信在李老師的教導下，我在清美一定能學到更多的東西。以後的學習心得我會慢慢更新，希望有同樣經歷的朋友能夠多多交流!
軟件開發心得體會軟件心得體會範文2篇 | 返回目錄受某文化公司委託，開發一款用於視頻和圖像處理的軟件，開發難度高，高到從未搞過，開發週期長，長到是我以前項目監控最長開發週期的兩倍，開發成本之底，讓我覺得程序員成了高級打員。首先是需求分析書、產品規格説明書、設計説明書、代碼規範説明書、測試計劃，光文稿就不知道熬了多久才做完。
緊接着，遇到一系列問題，首先是語言選擇，vc++和c#都是可以保證開發完成的選擇，但是vc++內存容易報錯，界面很難修改，而客户要求的界面質量甚至比程序的功能更嚴格，沒辦法，客户就是上帝，上帝做事一定有他的道理。c#語言易於開發，而且圖形界面繪製也易於修改，可以做出客户體驗很好的界面，但是在資源的消耗上，讓我很吃驚。做到第二個月，大概的界面已經完成時，出現界面刷新的問題，刷新時開始卡，界面不流暢。沒辦法，改。
開會，總結，技術骨幹找問題，拿出解決方案，力爭第一次做軟件把它做好：
重新做軟件開發進度計劃和軟件測試計劃，並且讓獨立功能demo製作和測試先行；
用direct draw、direct 3d或者opengl中的一個替代c#本身的gdi繪圖，將在接下來的開發任務中加入進去。
事無鉅細，當我滿意的看着界面流暢，功能也已實現時，發現軟件在低分辨率或者小本上根本亂到沒法看，甚至是界面功能按鈕錯位，重疊等等。沒辦法，改。畢竟軟件的多分辨率兼容和操作系統兼容是必須要做的。
接下來一大堆的麻煩找了上來，軟件出現各種各樣想都想不到的問題，總算是按時將第一個版本發佈出去，並且開始接下來的升級開發任務。
最後，給剛剛接手軟件開發項目的朋友一些忠告：
一、相關的文檔不是給別人看的，而是給自己看的，相關文檔一定要齊備，而且讓所有涉及開發的人員都清楚的知道你文檔裏所要表達的意思；
二、一定要注意多做demo，多做實驗，一個demo程序員幾個鐘頭就可以完成，甚至更少，但是不做demo，核心程序沒有做實驗，其他的東西都圍繞核心程序做了上去，到時候耽誤的可不是幾個鐘頭
三、程序設計要注重用户體驗，當初客户對我要開發軟件提出近乎苛刻的要求時我不在意，但是當我自己反覆使用軟件時有了很多體會，流暢美觀的界面帶給人心理的快感的確能替代一些尚未開發完整的功能帶給用户的遺憾。
四、測試計劃多次進行，分批進行，不要全部開發完成再對軟件做測試。
還要堅持三個月，軟件馬上發佈，希望大家的支持，謝謝！！！
軟件開發心得體會（2）：
作為ｐｍ，有時需要招聘軟件開發人員。這幾年也一直在想，如何能在短短的30分鐘或1小時內，快速識別出，坐在你對面的應聘人員，是否適合你的team。這幾年也一直在觀察和反思，經歷過的team和現在team中的軟件開發人員。有幾點小的心得。
1. 傾向於招什麼樣的軟件開發人員
- 經歷過歷練的人
吃過苦的，比如以前工作，經常被外派出差，又如曾在業內都知道以加班多而著稱的公司呆過，還有些，留過學，但都是自己邊打工邊讀書的，等等。
這些人員，入職後，通常都是能幹活，能作為骨幹。
- 思路清晰，思想活躍的人
讓談談自己現在的產品，如果能清晰表述，有條理，會發散，但又能適當控制住，並收回到原話題。談到技術問題和解決過的難題時，眼中有光芒：）
這些人員，今後工作中，學習能力強，對解決難題有幫助，能作為中堅。
- 坦誠、堅定、平和的人
面試中，坦誠，目光堅定。有時坦誠到甚至於顯得有點木訥：）
我曾經遇到一個，面試下來，我最後介紹我們產品中用到的技術，他對這些技術知之不多，最後他説，“我可能不是非常適合，我知道一個朋友，他可能更適合。”我綜合評估後，最後還是選了他，事實證明，他後來做的很不錯。
坦誠堅定的人，會有恆心去學習，去解決問題。這些人員會作為team的基石。
- 有缺陷的人才
這是一個朋友（lance）的想法，我認為還是有道理的。
大公司，會看重綜合素質，而如果是小公司，可以考慮選擇一些有缺陷的人才。所謂有缺陷，是指，比如他英語很差，或溝通不清晰，但他能用程序員該有的思維去思考問題。這樣的人員，通常進不了大公司，故會相對踏實地呆在一家公司，做好自己的工作。
2. 謹慎考慮這樣的開發人員
- 太活潑，太易興奮
太易興奮，説到投機處，“是是是是，對對對對。。。”，又蹦又跳，還時不時來點，“oh yeah, you are right“，然後還擺個 v 手型。討論問題，不易固守在技術問題本身，時常跑到“我們產品中用到的技術（或第3方產品）很強，我挺他們，不可能有問題”，又或者“我們對客户要強勢，我們要堅持我們的產品沒問題"。
軟件開發工作本身，顯得比較沉悶，優秀的技術人員，都略顯有些內向，因為解決問題，很多時候需要耐得住寂寞，時刻保持相對冷靜。
太活潑的人，會在遇到問題之初，表現出很強的衝勁，但當長時間不能解決時，會表現出沒有耐心，會經常抱怨（對team、管理、產品、流程等），非常情緒化。有些女程序員還會吵，會哭，這時項目經理只能放下手中的活，下去給她買點零食來哄哄，“莫哭，這裏有你最愛吃的貓哆哩。”一邊擦着鼻涕、眼淚，一邊嘴裏塞滿東西，鼓鼓啷啷“這是酸角口味的，那個西番蓮口味的才叫好吃..."
這些通常不太容易在面試時表現出來，在試用期時，要觀察。
軟件實踐課程學習心得體會軟件心得體會範文3篇 | 返回目錄經過潘老師講授軟件工程實踐後，感覺對軟件工程這門學科有了深一層的認識。軟件工程是一門重視實際操作的科學。對於軟件產品，無非是產品定義、設計代碼、調試維護幾個步驟，看似簡單，可是實際操作卻複雜困難，它不比其它行業產品可預見可觸及，所以學好軟件工程能為以後從事軟件開發行業打好基礎。
在軟件實踐這門課中，講到了有效利用現有資源進行軟件編程的方法。提到軟件開發也可以像練習書法一樣，採用臨貼的方式，借鑑他人的優秀代碼資源。臨摹優秀軟件是學習軟件開發的一個重要方法。正如一首詩中説的：“熟讀唐詩三百首，不會寫來也會吟”。軟件開發也是一個道理。為了真正地掌握軟件開發的技巧，“臨貼”是個不錯的起步方法。
以前總是覺得，既然編寫一個程序，就應該完全靠自己，那樣寫出來才有成就感，才算是自己的程序，可是這門課程教會我原來適當地借鑑別人的東西，也不算抄，相反，還可以提高效率，節省時間。這可真是與以往的觀點不一樣了。具體如下：
“軟件編程，拿來主義的作用很大：
1、源代碼交換方便。
2、可行的例程序用處大。
3、借鑑現成少走彎路。”
不過借鑑別人的東西可是有説法的，可不是盲目地抄襲，下面是一些提到的途徑：
1、既有系統：借雞下蛋，買來就用;
2、書本例子：簡單修改、直接使用;
3、聯機或聯網幫助：幫助文檔、官方支持;
4、開放軟件源代碼：linux apache eclipse …
5、互聯網資源:論壇、搜索引擎、新聞組
借鑑過來後，還要多方面綜合考慮，比如説代碼的具體作用，完整性，還要考慮每個借鑑過來的東西的好壞。這些都要多方面考慮，可不能因為前面説軟件編程可以借鑑別人的，就盲目地抄襲。到時候代碼弄一堆湊在一塊兒，誰也不知道它們會不會好好工作。弄不好亂了程序計劃是小，公司的損失可不是哪個人都能承受得起的。
課程還提到，應該用一個小項目先從頭到尾地練完，這樣，有個整體性的瞭解，可以增加不少開發經驗。看來，不學習此門課程，還不能深入地解讀軟件工程的奧義。這門課程為我們深入地瞭解軟件工程這個龐大的前沿學科起到了推動性的作用。以上是我就此門課中提到的眾多方法的一小段做的一些淺談，更多的知識還在於我們自己去學習體會。
軟件測試心得體會軟件心得體會範文4篇 | 返回目錄下面簡單談談我的幾點體會：
體會一：軟件測試在整個軟件週期中的重要性。
它存在於整個項目週期，在項目開始之初需求調研的時候就開始了，在形成需求規格説明書的時候就需要針對文檔進行測試。這個環節在後續整個項目中佔了很大的比重，能主導整個項目的走向，成敗與否全在於開始階段的決策。
體會二：軟件測試的真正意義在於發現錯誤，而不在於驗證軟件是正確的。
再嚴密的測試也不能完全發現軟件當中所有的錯誤，但是測試還是能發現大部分的錯誤，能確保軟件基本是可用的，所以在後續使用的過程中還需要加強快速響應的環節。結合軟件測試的理論，故障暴露在最終客户端之前及時主動的去發現並解決。這一點就需要加強研發隊伍的建設。
體會三：在系統性能測試方面需要重視。
經過這次培訓中多個案例的講解，讓我瞭解到系統在上線之後會有很多不能預知的性能問題，需要在上線之前實現進行模擬，以規避風險，包括大數據量訪問，高併發數等等。
當然也有很多應對手段，沒有哪種手段可稱為最完美，只有最合適的，需要靈活掌握，綜合運用以達到最優程度，這是個很值得研究的領域。
下面是本人的幾點想法：
想法一：加強系統上線前的性能測試。
目前我們在項目建設過程中對性能壓力測試的重視程度還不太高，廠家也很少有僱傭第三方的測試機構。而是在現網進行試用，遇到問題再解決，可能會產生滯後問題，影響客户使用。希望以後能在性能測試方面提高重視程度，加大人力投入，以保證系統上線後能夠穩定運行。
想法二：適當介入相關項目研發
對於快速響應這塊，我們不能一味依賴廠家，而希望自己就能快速響應，及時將問題解決。這也是一個比較長遠的問題，需要加強研發力量的投入。
我個人是做開發出身，有此類經驗，當時是在客户現場，因為了解系統內部結構，能夠在第一時間排查解決客户所反饋問題。
現在系統完全由廠家開發，很難了解內部結構，或許會造成後期維護困難。所以，是否應該針對某些項目介入廠家研發工作，比如請廠家提供源代碼等相關要素，以增進維護人員對系統的瞭解。
最後再次感謝公司提供的平台，感謝領導的信任，讓我有機會得到更深層次的學習以及展示自己能力的機會，我也會盡我所能來完善工作的系統，提高整體工作效率，為南方電網的發展建設提供更堅實，優秀的支撐服務平台。