軟體開發心得體會範文 篇1
時間過的好快啊，為期三個禮拜的實習生活即將結束了，短短的三個禮拜讓我們收穫很大，專業知識、編程水平都有很大的提高。剛開始三天的高強度的課程安排讓我們受益匪淺;接下來的上機實習又讓我們可以鞏固了課程。這讓我覺得實習生活充實而有意義。輔導老師配好了環境之後，我們開始了項目的製作，這次項目實習算是自己國小期間主要完成的項目。最後，自己的努力還是有收穫的，看著電腦上記錄得滿滿的代碼，看著自己的項目最終能夠運行成功，就覺得很有成就感。
在本次的實習中，除了讓我明白工作中需要能力，素質，知識之外，更重要的是學會了如何去完成一個任務，懂得了享受工作。當遇到問題，冷靜，想辦法一點一點的排除障礙，到最後獲取成功，一種自信心由然而生，這就是工作的樂趣。有時候也需要虛心請教，從別人的身上真得能學習到不自己沒有的東西，每一次的挫折只能使我更接近成功。除此以外，我還學會了如何更好地與別人溝通，如何更好地去陳述自己的觀點，如何說服別人認同自己的觀點。這次所學知識與實際的套用，理論與實際的相結合，讓我大開眼界。也是對以前所學知識的一個初審吧!這次實習對於我以後學習、找工作也真是受益匪淺，在短短的一個星期中讓我初步從理性回到感性的重新認識，也讓我初步的認識這個社會，對於以後做人所應把握的方向也有所啟發!相信這些寶貴的經驗會成為我今後成功的重要的基石。
在此，我非常感謝學院領導和指導老師對這次實習的大力支持。
軟體開發心得體會範文 篇2
立項前
1、統一元素設計需考慮周全
也許是初創團隊的緣故，我不得不感嘆團隊對產品經理要求之嚴格之縝密，項目全程只有一個人負責，所以大到產品線對接，小到一句提示的位置和展示形式都需要一一推敲。
哪些元素應該做到統一
a、提示方面：統一的操作成功/失敗提示;統一的彈窗形式;提示語言採用較統一的句型;為空情況的友好提醒;溢出情況的友好提醒;表單實時驗證的提醒形式等。
b、文字方面：是否有統一的段落前“·”號;統一的連結狀態;統一的字型、間距、行高等。
c、圖片方面：調取圖片的統一尺寸;如果是上傳圖片類的操作，需要考慮周全全站的調取情況，以及考慮是否統一預覽圖的尺寸等。
d、細節互動：未激活功能的按鈕做“灰色”處理(例如用戶沒有勾選信息時批量刪除按鈕不可使用);按鈕點擊的狀態統一(例如增加“提交中”的按鈕狀態，以防止網速慢用戶狂點某一按鈕的情況);特殊控制項的統一等。
也許會有朋友說，上面有些是互動設計師需要做的事，但我一直認為作為一個產品經理考慮周全一些，沒壞處。這些“統一”同樣可以用在驗收階段，要知道，即使一個像素也可以改變整個產品的感覺。
2、原有功能的去留
我一直覺得升級已有產品比開發新產品難一些。這就像栽培植物一樣，新種下一棵果樹無非需要選對了土地，然後刨個坑種下去，然而成長期的去病枝、打頂等各種修剪所消耗的精力往往更多。
改進已有產品常常需要面對一個最棘手的問題：原有功能是去是留?
原功能去掉的話是不是會影響部分用戶使用?是否需要通過公告、站內信、界面引導等方式友好地告知用戶?怎樣把對用戶的傷害降至最低?
原功能留下的話是不是可以最佳化完善?聽到了什麼用戶群怎樣的聲音?是否要在這次升級中做調整?
這些問題當接到項目的時候，產品經理就應該考慮周全了。特別需要注意的是，如果這個產品之前不是自己設計的，那么最好找到prd說明文檔細細研究一遍，對把握不準的功能點找到原負責人確認，畢竟樹苗是ta摘的，別把將來最能結果的枝幹給砍了。
3、產品線上下游的對接
昨天有跟朋友聊起淘寶強勢之處，就是產品與產品緊密捏合，線上線下、跨平台跨行業形成了一個盤根錯節、根深蒂固的根基，無可撼動。
所以把握產品線上下游和產品周邊很重要，即使一個看似簡單的新聞展示頁面修改也會牽扯到編輯後台、廣告位管理、幫助中心，甚至是訪問統計、數據需求的變更。
這要求在產品設計開始前，需要把該產品“連根拔起”，仔細梳理相關脈絡，如果產品線夠長，一個清晰的產品線結構圖很有必要。
項目中
1、項目期間來自相關產品線調整的影響
項目期間相關產品線的調整是我最不願意遇到的情況，這就像你在通往目的地的道路上高速行駛，就快要到達終點了，突然一個人告訴你：你走錯路了。
項目里有一個通用模組，產品設計到一半，這個通用模組改了;項目里有一個流程，產品做到一半，這個流程廢棄了;最要命的是已經立項開發了，你不得不硬著頭皮跟程式設計師說：“因為一些不可抗拒原因，這個需求咱不做了。”
對於一個耗時較長的項目來說，這種情況難以避免，事出原因私自總結有三：
a、嚴重體驗性問題：例如某個流程遭到大量用戶的不滿，為防止用戶流失，不得不做臨時調整，而倒霉的是，你也在用這個流程。
b、相關項目的影響：包括並行項目和新項目。例如你的同事在設計另一個產品，你們的產品相互牽扯較多，所以需求分析時做過很多溝通，但有一天，同事告訴你，ta的一個需求做臨時調整了會影響到你，怎么辦?
c、老闆的突然決定：不舉例。
最終的解決方法不外乎三種：立即調整、延期調整、不調整。個人的處理原則一般是對a種情況進行立即調整，對b、c情況討論並選擇性延期。
為什麼這么做呢?a情況是必須要改的，時間早晚問題，長痛不如短痛，b、c兩種情況必須坐下來細細討論。需了解這個需求為什麼要改?是長期對策還是臨時決定?能否延期，記錄需求等下一版本再開發?如果b、c情況提出來的需求沒過兩天又有改變，那與你配合的前端和程式設計師也太沒有安全感了。
這個時代能耐心閱讀完枚漢字的人越來越少，較大型項目的產品工作心得[下]未完待續，歡迎交流……
2、需求變更
承上，需求變更是每個程式設計師、產品經理、設計師等都會遇到的情況。產品經理不是神，項目組也不可能是開了無敵狀態抵擋任何外界的影響。
當遇到不得不變更需求的時候，產品經理應該怎樣處理呢?下面是個人的四條建議：
a、積極處理。往往，當一個設計愈是趨於完成，人們愈是傾向於局部調整，而不是做重新設計。當一個需求因為眾所周知的原因不得不調整的時候，作為產品經理需要做的第一件事便是積極面對問題，積極處理。
項目開發往往是一個緊張的過程，每半天甚至每幾個小時就有若干個功能點開發完成，當一個需求變更傳達出現“延遲”，這個變更對項目的正常進程的“破壞力”就會更大一些。
b、保持溝通。“說話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時候，溝通是個自己掙扎的過程”這話沒錯。需求變更直接會影響到下一道工序，產品經理需要將需求變更的細節和原因傳達給相關人員，包括視覺、前端、程式、測試等。
這是很多產品經理表示非常痛苦的過程，因為可能會遭到數落和冷眼，日本有一個禮儀原則是“不要給別人添麻煩”，但是在項目中，這不可避免。
個人認為所有溝通的障礙都源於思想的不統一，如果讓大家覺得這個需求修改是在浪費時間，那么溝通上的不暢快在所難免。項目不是這樣算的，需求既然更改一定有所目的，產品經理需要將這個原因講明白，不做修改或節約溝通時間導致的返工，後果往往更嚴重。
軟體開發心得體會範文 篇3
為了方便學校院系考評本院系各班級預備黨員的學風、品行，作為預備黨員轉正的參考依據，校方委託我團隊設計製作“校園預備黨員評優系統”，通過學生不記名線上打分的形式考評預備黨員的各項素質，並按照各項考評分數給出每個被評分人員的綜合考評得分以及排名情況。建設目標：學生考評做到有理有據，公平公正為了方便學院領導對每個處於預備轉正期的學生的綜合考評，學院除了要考評其個人學習成績外，還要聽取廣大師生的意見，從而為我黨選拔品學兼優的人才。
為此考評系統從學生的德、智、體、美、勞以及宗教信仰共6個方面進行考評，並為每個考評設定優、良、差三個等級供師生評判，且採用網上線上投票的形式進行打分，同時禁止重複打分，惡意修改分數，跨班級打分等現象，進而做到有理有據，公平公正。解決方案：校園預備黨員評優系統評優系統分為三大模組，用戶管理模組、學生評分模組以及考核統計模組。用戶管理模組，收錄參與評分師生以及預備黨員的個人信息，系統會給出預備黨員的個人信息描述，以便評分者了解，而評分師生則只收錄登錄用戶的基本資料，方便管理。學生評分模組，評分師生對預備黨員的6項指標進行評分，等級為優、良、差三個級別，系統後台則會記錄不同等級對應的分值。系統會記錄每個評分師生的評分操作，以防止跨班級評分，修改評分，重複評分等現象。考核統計模組，學院黨支部老師可以從班級、專業、個人、考評項目等多維角度查看被評者的分值，進而從多方面了解該生的情況。
項目收益：使校方能從多個角度了解，認識學生校園預備黨員評優系統不僅僅是一個針對預備黨員個人素養的綜合考評工具，更重要的是，它能夠幫助校方更好的了解自己的學生，包括學業、愛好、性格、宗教信仰、為人處事等，為學校選拔優秀人才，預防校園不良事件提供了一定的支持。
智慧型表單系統在網站中經常會遇到需要用戶填寫一些資料的情況，這個過程對於用戶來說沒有任何問題，但如果表單樣式經常修改，對於網站開發人員來說，將是一個比較繁瑣的過程，他除了要修改表單的網頁樣式，還要相應的修改後台資料庫的樣式。是否有一種軟體，既能實現表單創建、資料庫表創建以及表單發布一站式服務，又能讓非計算機技術人員輕鬆掌握，智慧型表單系統應運而生。建設目標：表單創建及發布一站式服務，非計算機專業用戶輕鬆掌握智慧型表單系統面向的主要用戶是那些不懂計算機編程，並且需要經常發布表單或者修改表單的網站文案人員，藉助這套系統，用戶只需簡單的拖拽一些表單控制項，並為這些控制項命名，告知信息錄入人員該填寫的條目項即可，而資料庫表則在發布後自動生成，無需技術人員另行建立。解決方案：智慧型表單系統智慧型表單系統的核心價值就是簡單易用，且高度自動化。
它完全基於B/S架構開發，能夠很好的套用與網頁表單。智慧型表單系統由表單引擎、資料庫引擎、信息發布及處理引擎組成。1、表單引擎，負責表單控制項以及表單界面的生成;2、資料庫引擎，負責表單對應資料庫表的生成;3、信息發布引擎，負責表單生成後的網站發布;4、信息處理引擎，直接面向信息錄入人員，接收信息的錄入以及資料庫信息的調取;智慧型表單系統不僅僅允許新增表單及其資料庫表，同時也允許用戶線上修改欄位，包括添加、修改名稱以及刪除欄位，相應的資料庫表也會改變，做到了全程自動化。產品特色及用戶受益：一站式服務，簡單易用智慧型表單系統具有表單創建、修改、發布、資料庫表的編輯一站式特性，用戶只需簡單的拖拽控制項即可完成這一整套工序。這套系統能夠縮短網站表單建設周期，同時也解放了開發人員。
軟體開發心得體會範文 篇4
首先我是一個女孩，學軟體開發的女孩相對於男孩來說並不是太多，但是因為我自己對編程比較感興趣，所以就從事了這個行業。
我們學校的學生從20xx年的下半年就已經開始出來實習了，據我所知我們計算機系的學生大都從事別的行業去了，從事計算機行業的人數非常少，我想大部分是沒有過硬的技術知識的原故，不敢去應聘本行業的工作吧。
我一直是一個有上進心的女孩，對軟體編程有很大的興趣，總想著自己也要像男孩一樣，做一番屬於自己的事業，不能白白的虛度自己的青春，但我又不想從事與計算機沾邊的初級職位，比如文員之類的。因為如果自己的第一份工作從做文員開始，以後自己的職業生涯就不好規劃，肯定會離軟體編程越來越遠的。
說實話我的家庭條件並不富裕，但是我有一個非常支持我上學的父母，他們狠狠心在我上了幾年大學之後又給我交了幾千元的培訓費。從那時候起我就想著我一定要好好學習，對得起父母。
就這樣開始了我的培訓旅程，其實說實話在培訓的過程中我是時而感到特別迷茫，時而又有了奮鬥的激情，這不免有個人的因素，也有培訓環境的影響。
在這裡我想提醒一下那些想參加軟體培訓的學生，在你們選培訓班的時候一定要看清這個學校以前培訓學員的就業情況，特別重要的是培訓老師有沒有教學經驗，一些培訓機構總是以賺錢為目的，鼓吹著自己的培訓老師擁有幾年幾年的項目經驗，其實我感覺沒有教學經驗的老師還不如項目經驗少一些的老師。
我們培訓部就是一個例子，我有時候就感覺聽我們老師講課簡直是一件非常痛苦的事情，他講課從來就不備課，只是根據自己的工作經驗，想到哪個知識點就講哪個，我們聽課的學生一點思想準備都沒有，而他常常在課堂上為了調試一個程式的一個小小的錯誤耽誤一兩個小時的時間，而這期間往往也是我們最煎熬的時候，因為我們要坐在那個地方陪著他找錯誤，這種情況下的我們非常受折磨，並且感覺時間都白白浪費掉了，以至於根本沒有什麼收穫。
再來談談我自己的情況吧，我在大學期間程式語言學的還算不錯，當時我們只開了c++、java兩門程式語言課，還有軟體開發相關的SQLServer20xx資料庫，我的這三門主修課程每次考試都很優秀，參加培訓時也有老師勸我學軟體前台，網頁設計什麼的，說是女孩比較適合學這個，好就業，而軟體開發大都是男孩子，女孩幾乎是學不通的。我當時就是為了證明自己的能力，根據大學期間自己的學習情況，我相信自己能學好。
但是也因為我們老師講課的無計畫性，課程拖到現在還沒有結束掉，時間已經過去6個月了，我開始思索我自己的人生了。
經過四個月的培訓，我不能說我沒有學到什麼東西，但我還要說一點，我雖然每一樣技術都知道了，但是我學的僅僅還只是一個皮毛而已。軟體開發最重要的就是編程思想，可我現在的水平只是編寫代碼達到非常熟練的程度罷了，對於編程思想感覺還是沒有踏入軟體開發的門檻。而編程思想主要來自於你所做過的實際項目獲得的經驗。而我們培訓部的項目不僅少而且不怎么實用。所以要想參加培訓還要看清這個培訓部的項目是不是夠份量，沒有實際的項目經驗去應聘軟體開發的工作還是不行的。
經過仔細的思索，我已經決定去找工作了，現在正是找工作的好時候，雖然我沒有多少項目經驗，但我相對於應屆畢業生自信多了，也許這就是培訓的力量。不過哪怕找到一份小小程式設計師的工作幹著也行，因為現在對自己的職業定位還有點迷茫，我自己的性格屬於那種做事情非常認真、踏實、細心，感覺更適合做軟體測試方面的工作，對於軟體開發我還是抱著先試試工作的態度，主要源自於我自己頭腦反應太慢，估計一直做軟體開發對職業發展前景是有礙的。
最後告誡那些還在上大學的朋友們，如果你們想在軟體行業發展，那你們一定要在上學期間多上網看一些編程方面的視頻，自已嘗試著把企業要求的知識點自學一下，跟著視頻做一些小型的項目。其實自學知識點是不難的，只有你有恆心。因為我培訓的感覺就是公司要求的一些東西很多並不是我們不懂，而是我們在學校其實是連聽說過都沒有聽說過，這樣的話哪個公司會願意。
軟體開發心得體會範文 篇5
隨著我礦“兩化”融合工作的推進，軟體開發方面人才顯得更加缺乏，所以我選擇對Asp.net進一步深入學習；經過近兩個月的自主學習，進一步掌握了Asp.net動態網頁製作的一些理論知識和基本常識，不僅要套用各種方面的知識還要對所學的知識學會變通使用，雖然會有一些成功的地方。曾經看到網上有這么一句話，一個優秀的網路程式設計師不但要了解自己領域的一些專業技術，而且很多時候還要充當半個網路工程師，半個美術設計師和半個資料庫管理員。Asp.net是戰略的核心產品，Asp.net憑藉它豐富的控制項，以及具有革命性的code-behind技術，以及良好的封裝性，無疑成為業界開發activeserverpage的一門巨將，
Asp.net是ASP（微軟動態伺服器網頁技術）的最新版本。執行效率大幅提高：Asp.net構架是可以用Microsoft（R）公司最新的產品開發環境進行開發，WYSIWYG（WhatYOUSeeIsWhatYouGET所見即為所得）的編輯。簡單性和易學性、高效可管理性Asp.net使用一種字元基礎的，分級的配置系統，使你伺服器環境和應用程式的設定更加簡單。因為配置信息都保存在簡單文本中，新的設定有可能都不需要啟動本地的管理員工具就可以實現。這種被稱為"ZEROLocalAdministration"的哲學觀念使Asp.net的基於套用的開發更加具體，和快捷。一個Asp.net的應用程式在一台伺服器系統的安裝只需要簡單的拷貝一些必須得檔案，不需要系統的重新啟動，一切就是這么簡單。多處理器環境的可靠性Asp.net已經被刻意設計成為一種可以用於多處理器的開發工具，它在多處理器的環境下用特殊的無縫連結技術，將很大的提高運行速度。即使你現在的Asp.net套用軟體是為一個處理器開發的，將來多處理器運行時不需要任何改變都能提高他們的效能，但現在的ASP確做不到這一點。自定義性和可擴展性Asp.net設計時考慮了讓網站開發人員可以在自己的代碼中自己定義"plug-in"的模組。
這與原來的包含關係不同，Asp.net可以加入自己定義的如何組件。網站程式的開發從來沒有這么簡單過。安全性基於Windows認證技術和每應用程式配置，你可以確性你的原程式時絕對安全的。Asp.net的語法在很大程度上與ASP兼容，同時它還提供一種新的編程模型和結構，可生成伸縮性和穩定性更好的應用程式，並提供更好的安全保護。可以通過在現有ASP應用程式中逐漸添加Asp.net功能，隨時增強ASP應用程式的功能。Asp.net是一個已編譯的、基於.NET的環境，把基於通用語言的程式在伺服器上運行。將程式在伺服器端首次運行時進行編譯，比ASP即時解釋程式速度上要快很多.而且是可以用任何與.NET兼容的語言序。另外，任何Asp.net應用程式都可以使用整個.NETFramework。開發人員可以方便地獲得這些技術的優點，其中包括託管的公共語言運行庫環境、類型安全、繼承等等。
Asp.net可以無縫地與WYSIWYGHTML編輯器和其他編程工具（包括）一起工作。這不僅使得Web開發更加方便，而且還能提供這些工具必須提供的所有優點，包括開發人員可以用來將伺服器控制項拖放到Web頁的GUI和完全集成的調試支持。當創建Asp.net應用程式時，開發人員可以使用Web窗體或WEB，或以他們認為合適的任何方式進行組合。每個功能都能得到同一結構的支持，使您能夠使用身份驗證方案，快取經常使用的數據，或者對應用程式的配置進行自定義.如果你從來沒有開發過網站程式，那么這不適合你，你應該至少掌握一些HTML和簡單的Web開發術語(不過我相信如果有興趣的話是可以很快的掌握的)。你不需要先前的ASP開發經驗（當然有經驗更好），但是你必須了解互動式Web程式開發的概念，包含窗體，腳本，和數據接口的概念，如果你具備了這些條件的話，那么你就可以在Asp.net的世界開始展翅高飛了。
在這短短的兩個月中，我知道在程式設計的時候，不要太在意程式是否最簡潔靈活，對於一般開發者而言，程式規範化和可讀性可能比追求程式的靈活性更加重要。在網際網路資源越來越豐富的情況下，我們可以參考一些規範的程式原始碼來學習。同時我也知道，想要學好這門課程，所要具備很多條件，首先打代碼要規範，要做注釋，這樣回頭來看程式時可以很快的看懂，一方面可以練習自己的邏輯表達能力，對以後遇到難以實現的功能也可以很好的表達出來向別人請教，而且出去從事編程工作的話，代碼的規範是相當重要的。還有一點要學會總結，把自己做的程式用到的知識點列出來就可以很好的總結自己的知識點。當形成知識體系，對知識的理解就會更上一層樓。
軟體開發心得體會範文 篇6
20年2月2日，我有幸成為的一員，應聘為公司的java軟體工程師。入任職以來，在部門領導的帶領下，自己感覺無論學習、技術、生活等方面都有很大的提升。
20年裡我主要完成的工作有三方面：
1、荊門石油石化巡檢系統的調研和開發。
該項目是我工作以來第一次涉及到調研，對我來說算是一個不小的挑戰。在調研過程中，讓我學會了如何通過和客戶的溝通來了解客戶的需求。由於自己的工作經驗不足，在調研工作中體現出一些問題。不能很直接的在和客戶溝通中非常準確的了解客戶的更多需求，有很多需要和客戶交流溝通多次才能明白客戶的最終需求，也沒有把自己作為最終用戶並站在用戶的角度上來考慮問題，這些都是我在以後的工作中需要提高和改進的地方。在巡檢系統的開發工作中，讓我進一步鞏固和加強了自己的開發能力。
2、電信12530增值業務的開發與維護。
從5月以來我就開始接手公司的主要業務之一，12530電信增值業務。由於前面負責這個項目的同事突然離職，導致這個項目的交接工再做得不夠好，對我順利接手這個項目造成很大的困難。而剛一接手這個項目，馬上就需要新上一個投票活動，並要對一些主要代碼進行修改，讓我倍感壓力，幾乎都快放棄。最後在金總的指導和鼓勵下，順利的完成這次活動。在完成這次投票活動後，為了避免下一個接手這個項目同事與我遇到同樣困難，我第一時間將這個項目的相關技術文檔補充完全，保證別人能夠順利的進行該項目工作。通過這個項目，讓我加強了自己在高強高壓下工作的能力，也讓我找到更多自信。
3、家政網路服務中心的開發與實施。
在這個項目中，除了承擔開發工作以外，也逐漸涉及到項目管理的職責，讓我在個人能力上有所提高。為了這兩個項目能夠順利完成，除了完成自己的工作外，還主動關心其他同事的工作完成情況。讓我在項目管理和項目進度的把控能力有很大的提高。將家政網路服務中心順利實施，為我公司拿下湖北省其他市的家政網路服務中心奠定基礎。在工作之外，我也注重個人能力的提高。工作之餘，主動學習一些新技術，與同事溝通配合，搭建一個ssh的開發框架。也學習spring security知識，這些新知識的積累，對我以後的工作有很大幫助。
20年工作展望：
1、將學習的spring security整合到我們自己搭建的ssh框架，進一步完善框架。
2、利用搭建的ssh框架，開發一套oa系統平台。
3、做好襄樊、鄂州家政網路服務中心的維護工作。
4、希望公司能夠大量拿下湖北省其他市的家政網路服務中心，繼續開發和實施湖北省其他市的家政網路服務中心。
5、繼續學習新技術，努力提高自己的個人能力。為以後能夠更好，更順利的工作奠定基礎。
6、希望通過自己的進步和努力，能為公司的發展做出自己最大的貢獻，體現出自己的最大價值。
軟體開發心得體會範文 篇7
歲月流轉，時光匆匆，轉眼間我的大學生活已經接近了尾聲。回首往昔，有太多美好的，也有太多艱辛。我的大學生活的主旋律還是學習，我所選學的專業是軟體技術，在這條道路上走了那么久，也有一些小小的感悟與體會。
還記得上國中時，英語課本上有一篇關於比爾蓋茨的文章，當時真的很佩服比爾蓋茨，也就是那時我才第一次接觸到軟體一詞，學過那篇文章後我有個想法，就是也要做個比爾蓋茨，可是由於家庭條件的限制，那也只能是個美好的夢想。後來上了高中，再報考時我就選擇了軟體技術這個專業，這樣我想就向那個遙遠而又美好的夢想邁進了一點點吧。
然而當我真正上了大學，學了這個專業，我才知道要做個比爾蓋茨是多么的難，要想學好我的專業要花費很大的精力。第一學期我們開設了C語言這門課程，當時我學著真的是雲裡霧裡、一竅不通，很是失落，學了不久之後我開始覺得自己可能並不喜歡這個專業，只是一時昏了頭，錯以為喜歡了。現實的打擊讓我有點不知所措，然而我已經選擇了它，有句話說：既然選擇了遠方便只顧風雨兼程。我既然選擇了這個專業，我便也只有硬著頭皮也要走下去了。有了這樣的想法之後，在之後的一段時間裡，只要是沒課的時候我就抱起了C語言課本，努力的看，記語法知識，語法規則，學語句、小算法等等。經過一段時間的研究學習，我發現C語言並沒有我想像中的那么難了，還是很有意思的。就這樣在學與玩中我的大學第一個星期就過完了。
後來又開設了很多課程，有VB、網路、資料庫、作業系統、數據結構等。在這些課程中最令我頭疼的就是資料庫了，老師講的時候老是劃重點，講的很少，當時學的時候真的好難受，一學期下來啥也不會，後來看書上的操作，一步一步的操作，才終於學會了建個資料庫，做下備份還原等操作。開設的那么多課程也有我很喜歡的課程，比如數據結構，這門課程理論的比較多，上機操作的很少，這門課程是很需要理解的，當然有的還是要死記的。學習這門課的時候，我覺得並不像其它課程那么吃力，可能高中是學理科的緣故吧，理解起來並不太費勁。所以當時就很喜歡這門課，然而這門課表皮的好學，但要深學起來還是很有難度的，所以期末考試的時候我的成績並不太理想，但這些打擊不了我對它的興趣，至少我知道我所學的這個專業還是有很多我是很喜歡的。
這樣走著走著就到了大二的下學期了，那個學期，我們有一門課是C++，這門課的老師很和藹，能力也很高，從他那裡我學到了很多東西。老師教給了我們很多算法，也很系統的講解了語法知識，還教我們做小系統，有的時候他會給我門們一些小系統的代碼，讓我們去改寫，剛開始的時候我也是不會，後來經過學習請教改寫成功了，這個時候我就會很開心，很有成就感。就這樣在學與玩中，在快樂和憂愁中我們迎來了我們的大三時光。
大三剛一開學，老師們就告訴我們這學期就上十二周的課，然後就考試，就畢業了。這讓我很有緊迫感，一想到畢業在即，心頭就有種不捨，這兒有我美好的時光，然而我就要對這裡說再見了。大三了我們的課全變成了專業課，也幾乎全成了上機課，老師還給我們布置了一個程式，就是一個小組要交一個系統來算作成績。我們這小組所選的課題是圖書管理系統，針對這個系統，我們上機的時候，利用網路資源在網上查找了相關的資料，因為說實話，我們對此並不太理解，也只有通過網路來查找信息，做好需求分析，功能模組設計等工作。在這同時我們還去了學校的圖書館理解了相關的信息，這個系統並不要求功能有多么強大，關鍵在與一種鍛鍊，思維的鍛鍊，對所學東西的總結等。建立資料庫時我們就根據需要建立幾個表，裡面的數據也是從我們學校圖書館裡找來的。後來的界面設計，為了追求美觀，我們又在網上搜了很多美麗的圖片來美化界面。具體到功能的時候，有很多東西都不會，後來老師在課堂在做了講解，我們就把它用到了我們的系統中，真的就是學一步做一步的。整個的系統做下來，我學到了很多東西，也對那么知識有了很好的套用能力。
現在這個星期也就到了期末，這短暫的校園時光也在飛速的流逝著。回首過去學習的經歷，真是苦中有樂，樂中亦多苦，然而無論如何這些都已經走過去了，未來的路還要我們好好的走下去。人生本就是一個不斷的學習的過程，也是一個不斷完善的過程，在未來的道路上我會更加努力地學習，走出一個美好的人生。
軟體開發心得體會範文 篇8
受某化公司委託，開發一款用於視頻和圖像處理的軟體，開發難度高，高到從未搞過，開發周期長，長到是我以前項目監控最長開發周期的兩倍，開發成本之底，讓我覺得程式設計師成了高級打字員。首先是需求分析書、產品規格說明書、設計說明書、代碼規說明書、測試計畫，光稿就不知道熬了多久才做完。
緊接著，遇到一系列問題，首先是語言選擇，vc++和c#都是可以保證開發完成的選擇，但是vc++記憶體容易報錯，界面很難修改，而客戶要求的界面質量甚至比程式的功能更嚴格，沒辦法，客戶就是上帝，上帝做事一定有他的道理。c#語言易於開發，而且圖形界面繪製也易於修改，可以做出客戶體驗很的界面，但是在資源的消耗上，讓我很吃驚。做到第二個月，大概的界面已經完成時，出現界面刷新的問題，刷新時開始卡，界面不流暢。沒辦法，改。
開會，總結，技術骨幹找問題，拿出解決方案，力爭第一次做軟體把它做：
重新做軟體開發進度計畫和軟體測試計畫，並且讓獨立功能demo製作和測試先行；
用direct draw、direct 3d或者opengl中的一個替代c#本身的gdi繪圖，將在接下來的開發任務中加入進去。
事無巨細，當我滿意的看著界面流暢，功能也已實現時，發現軟體在低解析度或者小本上根本亂到沒法看，甚至是界面功能按鈕錯位，重疊等等。沒辦法，改。畢竟軟體的多解析度兼容和作業系統兼容是必須要做的。
接下來一大堆的麻煩找了上來，軟體出現各種各樣想都想不到的問題，總算是按時將第一個版本發布出去，並且開始接下來的升級開發任務。
最後，給剛剛接手軟體開發項目的朋友一些忠告：
一、相關的檔不是給別人看的，而是給自己看的，相關檔一定要齊備，而且讓所有涉及開發的人員都清楚的知道你檔里所要表達的意思；
二、一定要注意多做demo，多做實驗，一個demo程式設計師幾個鐘頭就可以完成，甚至更少，但是不做demo，核心程式沒有做實驗，其他的東西都圍繞核心程式做了上去，到時候耽誤的可不是幾個鐘頭
三、程式設計要注重用戶體驗，當初客戶對我要開發軟體提出近乎苛刻的要求時我不在意，但是當我自己反覆使用軟體時有了很多體會，流暢美觀的界面帶給人心理的快感的確能替代一些尚未開發完整的功能帶給用戶的遺憾。
四、測試計畫多次進行，分批進行，不要全部開發完成再對軟體做測試。
還要堅持三個月，軟體馬上發布，希望大家的支持，謝謝！！！
軟體開發心得體會範文 篇9
作為一個軟體開發人員, 記得在我第一天進入公司實習的時候, 首先要學習的就是編程規範. 相信每個搞開發的同學都跟我一樣吧.
編程規範在學校里是十分不重視的. 老師也不會硬性地要求學生要遵照怎樣的規範去編寫代碼, 實驗或者作業什麼的, 只要能實現功能就ok了. 但是公司卻不一樣, 公司的代碼並不是一個人編寫, 別人很可能需要閱讀甚至修改你的代碼, 閱讀一個不符合規範的代碼, 所需要的時間可能比重新開發還要漫長. 代碼規範的重要性是不言而喻的.當然, 作為一個開發人員的前提, 我還是公司里的一個員工(雖然不是正式的...). 我還必須遵守員工的規範.
其實員工規範也沒有什麼特別多的要求, 個人認為就跟上學差不多, 雖然規範是差不多, 心態上卻有著很大的差異. 原因無他, 你到學校是自己交錢上學, 上班卻是別人發工資給你. 拿了人家錢, 還要擾亂人家的規範, 這種事我還真乾不出來. 看來錢不論到哪裡都是一個問題, 呵呵
感悟二: 我其實是一種很唯心的動物
其實本來, 我是寫"人其實是一種很唯心的動物", 但不知道別人是不是也這樣, 雖然我覺得是, 卻無從考究, 還是嚴謹點.
為什麼說我唯心呢? 當我心裡把自己當作一個學生, 跟把自己當作一個上班族時, 在各種細節上都會不一樣, 例如那有點虛無縹緲的"氣質", 或者是說話的語氣.
這個大概是"站在不同的高度, 看到不同的風景"吧. 正如老總看的是公司發展方向, 主管卻在看業績, 經理在看項目, 小弟們在看代碼...
感悟三: 設計模式很重要
設計模式是我到公司才接觸的事物, 主要是講述一種面向接口的編程思維, 按照設計模式所編寫的代碼, 會比學校那種直接實現功能的代碼繁瑣一點, 增加很多看似多餘的虛類或者接口. 但是這種代碼更加具有拓展性, 更好地把數據封裝起來. 在增加狀態, 增加類的時候, 並不需要修改過多代碼, 這種代碼對於版本升級尤其重要.
在公司培訓學習中, 我總能很快地掌握各種設計模式的要領, 獲得上司的好評. 但是我明白, 設計模式真要套用到代碼中去, 是要培養一種習慣.
個人觀點好像說得有點多了, 下面說說我這3個月裡的實習情況. 總的`而言, 我到公司接觸了2個平台, 一個是現在很火的android, 另一個則是nokia的qt. android 用的基本是java語言, 其中還會帶點xml語言; 而qt用的則是c++.
對於這2個平台, 用著的感覺其實大同小異, 用我上司的話說, 基礎打好了, 語言就不應該是障礙. 感覺挺有道理的. 想當年我作為一個vb助教, 卻沒半點vb基礎, 對vb那些基礎問題還是可以比較輕鬆地解決, 這跟我其他程式語言基礎比較好有著密不可分的關係.
android平台的一個基本視窗是一個activity, 除了基本的activity外, 還提供listactivity和tabactivity這些拓展的子類, 每一個activity都可以看作一個視窗, 一個進程可以有多個activity, 每個activity都擁有一個view, view可以通過xml設定, 當使用activity的子類時, 必須注意這些子類的xml必須含有特定id的控制項, 或者不用xml實現view, 系統會有一個默認的xml去實現那些一個基礎view並且實現必要的id.
在談到view, 那么就必須說到layout了, android的layout很強大, 最基礎的是橫向或豎向的排列布局, 另外還有格線, 表格布局等等. 掌握好布局的方法可以讓我們對界面設計事半功倍.
android有趣東西有很多, 在我完成那個移植套用的時候, android總能給我一些驚喜, 例如popwindows這個設計, 他作用是彈出一個視窗等, 或者你可以把他看作一個acticity, 效率卻比activity快很多. 利用popwindows, 你可以做出風格各異的訊息框, 選單欄, 下拉選單等等.
另外還有一個抽屜類也很特別, 他就像觸屏系統的解鎖一樣, 拖動手柄, 便可拉出一個界面, 這種設計大大地節省套用的空間, 減少切換界面的操作, 從而降低套用的功耗.告訴大家一個很多人不注意的地方, android套用如果進行橫豎螢幕切換的時候, 進程會完全關閉後, 再重新打開的, 因為android做了保存狀態的操作, 所以很多人會以為螢幕切換後, 進程還是本來的進程.
qt跟android有很多共通點, 例如android的activity就如qt的qwidget, 當然, 他們的狀態機有著很大的區別.
qt最大的特點是他的信號槽, 通過信號和槽的連線, 可以把很多類與類間相關的函式連線在一起, 甚至可以傳遞參數
實習心得
從學生到走上工作崗位，一步步的熟悉和認識著周圍的環境，熟悉這社會生存之道!在這裡我學到了我離開校園的第一筆知識，這些都是從書本上學不到的知識，從體驗公司的文化到親身接觸公司的每個部門的人員，從公司的季刊雜誌上，從其他員工的言談中，有好的信息，也有不好的耳聞，總之，我的感覺中，我們的公司還是在不斷前進發展。
從學校邁入社會，華潤以自己的姿態給我這樣一個良好的鍛鍊平台。從學生到工作，華潤以自己的品質和精神讓我了解和洞察並融入社會這個大家庭，華潤為我創造了這樣一座橋樑。融入華潤，融入社會，我以華潤的精神強化自己，以華潤的記紀律規範自己，每一天努力，每一步的行動，都讓我逐步提高和完善自己，以至於在這個平凡的崗位上做到一個合格稱職的職業人。
工作中有苦有樂，產線上同事之間的互幫互助，讓我充分體會到與人協作，共謀發展，合作共利的快樂。產線5s讓我深刻認識到良好整潔的工作環境是工作效率和品質保證。產線紀律是我規範和端正自己的工作態度，保證每一顆電路的品質。在這樣的環境下，在這樣的氛圍中，我也漸漸養成了良好的工作習慣和責任意識，努力將這份工作做到更好。從華潤到社會大家庭，從一顆細小的電路到做人做事，不容置疑每一步都至關重要。“千里之行，始於足下”，我想，一切都從身邊做起，從細節做起，從小事做起，從當下這份工作做起。播種行為，收穫習慣;播種習慣，收穫性格;播種性格，收穫命運。一點一滴的積累，一點一滴的進步都將決定和影響著我的將來!
軟體開發心得體會範文 篇10
在大學裡的最後一個冬天，我完成了3個月的實習，實習對我而言是一個難忘的.體驗，讓我不論做人還是做事都改變了很多。 總的來說，雖然說不上樂在其中，但實習的確是一段充實而有意義的事。
實習期間積蓄了太多太多的感悟。 藉此機會跟大家分享一二。
感悟一: 當我們進入社會工作，就先要進入各種規範中去。
作為一個軟體開發人員，記得在我第一天進入公司實習的時候，首先要學習的就是編程規範。 相信每個搞開發的同學都跟我一樣吧。
編程規範在學校里是十分不重視的。 老師也不會硬性地要求學生要遵照怎樣的規範去編寫代碼，實驗或者作業什麼的，只要能實現功能就ok了。 但是公司卻不一樣，公司的代碼並不是一個人編寫，別人很可能需要閱讀甚至修改你的代碼，閱讀一個不符合規範的代碼，所需要的時間可能比重新開發還要漫長。 代碼規範的重要性是不言而喻的。
當然，作為一個開發人員的前提，我還是公司里的一個員工(雖然不是正式的。。。)。 我還必須遵守員工的規範。
其實員工規範也沒有什麼特別多的要求，個人認為就跟上學差不多，雖然規範是差不多，心態上卻有著很大的差異。 原因無他，你到學校是自己交錢上學，上班卻是別人發工資給你。 拿了人家錢，還要擾亂人家的規範，這種事我還真乾不出來。 看來錢不論到哪裡都是一個問題，呵呵
感悟二: 我其實是一種很唯心的動物
其實本來，我是寫"人其實是一種很唯心的動物"，但不知道別人是不是也這樣，雖然我覺得是，卻無從考究，還是嚴謹點。
為什麼說我唯心呢? 當我心裡把自己當作一個學生，跟把自己當作一個上班族時，在各種細節上都會不一樣，例如那有點虛無縹緲的"氣質"，或者是說話的語氣。
這個大概是"站在不同的高度，看到不同的風景"吧。 正如老總看的是公司發展方向，主管卻在看業績，經理在看項目，小弟們在看代碼。。。
感悟三: 設計模式很重要
設計模式是我到公司才接觸的事物，主要是講述一種面向接口的編程思維，按照設計模式所編寫的代碼，會比學校那種直接實現功能的代碼繁瑣一點，增加很多看似多餘的虛類或者接口。 但是這種代碼更加具有拓展性，更好地把數據封裝起來。 在增加狀態，增加類的時候，並不需要修改過多代碼，這種代碼對於版本升級尤其重要。
在公司培訓學習中，我總能很快地掌握各種設計模式的要領，獲得上司的好評。 但是我明白，設計模式真要套用到代碼中去，是要培養一種習慣。
個人觀點好像說得有點多了，下面說說我這3個月裡的實習情況。 總的而言，我到公司接觸了2個平台，一個是現在很火的android，另一個則是nokia的qt。 android 用的基本是java語言，其中還會帶點xml語言; 而qt用的則是c++。
對於這2個平台，用著的感覺其實大同小異，用我上司的話說，基礎打好了，語言就不應該是障礙。 感覺挺有道理的。 想當年我作為一個vb助教，卻沒半點vb基礎，對vb那些基礎問題還是可以比較輕鬆地解決，這跟我其他程式語言基礎比較好有著密不可分的關係。
android平台的一個基本視窗是一個activity，除了基本的activity外，還提供listactivity和tabactivity這些拓展的子類，每一個activity都可以看作一個視窗，一個進程可以有多個activity，每個activity都擁有一個view，view可以通過xml設定，當使用activity的子類時，必須注意這些子類的xml必須含有特定id的控制項，或者不用xml實現view，系統會有一個默認的xml去實現那些一個基礎view並且實現必要的id。
在談到view，那么就必須說到layout了，android的layout很強大，最基礎的是橫向或豎向的排列布局，另外還有格線，表格布局等等。 掌握好布局的方法可以讓我們對界面設計事半功倍。
android有趣東西有很多，在我完成那個移植套用的時候，android總能給我一些驚喜，例如popwindows這個設計，他作用是彈出一個視窗等，或者你可以把他看作一個acticity，效率卻比activity快很多。 利用popwindows，你可以做出風格各異的訊息框，選單欄，下拉選單等等。
另外還有一個抽屜類也很特別，他就像觸屏系統的解鎖一樣，拖動手柄，便可拉出一個界面，這種設計大大地節省套用的空間，減少切換界面的操作，從而降低套用的功耗。
告訴大家一個很多人不注意的地方，android套用如果進行橫豎螢幕切換的時候，進程會完全關閉後，再重新打開的，因為android做了保存狀態的操作，所以很多人會以為螢幕切換後，進程還是本來的進程。
qt跟android有很多共通點，例如android的activity就如qt的qwidget，當然，他們的狀態機有著很大的區別。
qt最大的特點是他的信號槽，通過信號和槽的連線，可以把很多類與類間相關的函式連線在一起，甚至可以傳遞參數
軟體開發心得體會範文 篇11
一、項目實施進度評估。ERP項目是複雜項目，其涉及的部門、人員、資金、資源等對於任何一個企業來說都是空前的，而在上一節中我們通過項目三角形分析出來，項目的進度是否能夠按照設計規劃的進行是影響項目效果的關鍵因素，所以評估項目的成功與否，首先必須評估項目的進度是否按照預期的進度進行，如果每一步或者每一階段，都能夠嚴格的按照進度進行，相信項目會成功的，否則就是項目設計出現了問題。一般來說現在評估項目實施進度的方法可以使用目前最為常用的項目管理工具，其中Microsoft的Project就是不錯的工具之一。其實很多項目的實施失敗原因是虎頭蛇尾，開始的時候大家心氣十足，進度基本可以按照計畫進行，而到了後來，每個人的工作都是交叉的，往往會受到其他工作的影響而忽視了項目的進度，致使項目進行不下去。所以除了有相應的制度保障之外，一定要有工具，再者說了搞IT的人不用IT工具，那不是“賣鹽的喝淡湯”嗎?當然現在的IT行業非常普遍。
二、項目成本評估。項目成本是評價一個項目是否成功的第二個關鍵因素，同樣在項目三角形中成本占了一條邊，所以成本的變化將直接影響項目的成功，如果一味追求項目的功能和進度，而忽視成本，那將不是搞項目，而是在賭博。現在的ERP項目本身的費用就很高，而且沒有公開價格，國家價格監督都沒有依據，全靠軟體商的一張嘴，說多少是多少，會侃價的省點，不會侃價的就多花點。但是一旦我們已經和軟體公司和服務公司(諮詢公司)達成了一致意見，關鍵的問題就在於如何有效的利用雙方同意的費用達成預期的任務目標，而往往在項目的開始企業的管理者認為項目剛剛開始，投入還不多，而不注重有效控制成本，而到項目實施一段時間之後，發現項目的預算已經不能保證項目的完成了，或者半途而廢，或者追加投入，而追加投入又會遇到企業資金是否充足的影響。所以我們建議在項目開始之前一定儘量準確的做出項目預算，並拿出專款，避免在途中因資金影響項目進展。另外成本控制要從採購、人員工時等多方面嚴加控制。並建議分階段進行成本評估，如果每個階段都能夠在成本控制範圍之內最終的項目一定保證在成本範圍內成功，關鍵在於當出現項目費用超出預算成本的時候要及時調整，確保總體成本控制在範圍之內。
三、項目功能評估。ERP是功能性產品，最終項目是否成功很重要的一點要看功能，看功能是否達到了預期的要求。ERP的功能從總體上來說分為幾大部分:進銷存管理，或者現在有的公司定義的內部物流管理;財務管理，包括總賬、應收賬、應付賬、固定資產等;計畫管理，在企業中大都會涉及到兩種生產模式的計畫方法，分別是單件小批量生產模式的MRP計畫方法和大規模流水線生產模式的JIT計畫方法;粗能力計畫和細能力計畫等核心資源管理;另外還包括人力資源管理;設備管理;工、模、量、夾具管理;質量管理等外圍資源管理。一般來說，軟體商在簽約之前都會給企業的管理者演示他們的功能，我告訴企業一個秘訣，在觀看演示的時候一定要刨根問底的看功能，而不能走馬觀花的瀏覽。兩者之間的區別就在於不要被軟體商的演示者的各種託辭搪塞過去，一定要親眼看到他們說能夠實現的功能，不要相信沒有數據不能演示、不是最新版本等解釋理由。如果他們說有什麼功能就當場拿出來。否則就是沒有，在事實面前任何理由都是蒼白的。在項目結束之前，對照雙方約定的功能清單，逐個推敲，如果每一個功能都實現了，項目一定能夠成功。
四、項目效果評估。功能具備只是基本的要求，關鍵還要看效果，這一點可能有人不容易理解，其實在ERP管理軟體中有很多功能從表面上看功能和效果是有很大的區別的，比如MRP計畫，可能大多數的ERP軟體現在都能實現這個功能，但是是否準確，是否可以通過MRP計畫直接指導生產，甚至直接根據計畫產生的結果安排採購，這並不是任何一家軟體都可以做到的，這裡面涉及到計算方法是否科學，是否符合行業的規範，考慮的因素是否完整，預置的參數是否科學，比如提前期設計的是否合理，安全庫存設計的是否合理等等都會直接影響計畫的結果，其實真正的軟體公司的功底就在這裡區別。
五、可操作性評估。ERP軟體的最終目的是讓企業的廣大職工都能夠使用，所以可操作性如何是項目成功與否的另一項重要指標。企業的大多數使用者，尤其是一線的職工，計算機的水平都不會太高，如何讓軟體具有很容易操作的界面，讓普通的職工也能夠使用軟體來操作，確保每一位使用者都能夠方便快捷的使用ERP軟體是項目成功的重要條件。有很多軟體功能很強，但是就是操作起來難度也很大，非專業人士無法使用，這絕對不是優秀的ERP軟體，優秀的軟體應該是只要熟悉業務的人就可以操作，所謂所見即所得。
六、項目的延續性評估。ERP項目是企業賴以發展的長期投資項目，絕對不是消費型項目，所以項目是否能夠伴隨著企業的發展而持續得到套用是評估項目成敗的另一向重要指標。持續性體現為升級能力、功能的擴展能力、客戶化能力、跨平台能力等幾方面:現在的軟體平台每幾個月就升級一次，當然套用系統的升級不一定要求緊跟系統軟體的速度，但是也要及時升級，隨著管理理論和管理方法的不斷發展，管理軟體的升級至少要跟得上管理方法和計算方法的更新速度，否則就是落後的;功能的擴展能力，就像上面我們所說的功能是評估的一項指標，但是功能能否根據企業的發展而及時更新，另外還有客戶化的能力和跨平台的能力也很重要。
軟體開發心得體會範文 篇12
本周是實習的第一周，很幸運碰到了產品部很有耐心的leader詹老師。 實習第二天他讓我做一個H5的遊戲類套用， 主要用於微信中分享。之前對於自己的水平是否能完成完全沒底，但感覺第一次實操確實也有點讓人興奮，之前關於產品開發的印象只停留在書本上。
詹老師讓我模仿“過家家gogaga”所開發的“打電話認師姐”微信小遊戲寫一個類似的套用。 我把原始套用找出來便開始摳代碼， 第一步是將套在微信接口中的原始套用摳出來(套在微信接口的原始套用只能在微信瀏覽器中運行，無法在電腦上測試)，周二開始做.
一開始我的效率非常低， 因為我很多測試方法並不熟悉， 在參閱了微信JS-SDK後總算把原始代碼摳出來， 釐清該套用的基本邏輯後開始重寫， 在詹老師的耐心地指導和對基礎知識的講解下，我們將原始代碼中120行的CSS代碼最佳化到60行，將五百多行的JS代碼最佳化到只有60行，這事實上是在原有的邏輯上完全重寫了，這讓我開始有點成就感了。
也第一次感受到產品開發中的大局觀，這種大局觀更多的是體現在細節上，比如代碼變數名的設定需要與檔案存放聯合考慮，以便日後修改和維護。 詹老師在講代碼邏輯的時候親自寫了一個例子讓我體會， 雖然消化這些用了快一天，但感覺真的收穫很大， 有拔雲見日之感。
實習一周后所遇到的種種困難也讓我意識到自己很多問題，歸納如下：
1.儘管之前對於書本的學習有一定積累，但還是暴露出代碼的不熟練，細節方面處理能力差，在細節上耗費時間太多。
2.缺乏基本的軟體開發測試思路， 比如之前不知道chrome具有相當強大的錯誤測試功能，它對於沒有觸發的函式也有錯誤提示。
3. 缺乏專注的習慣，比如詹老師讓我先完成功能方面，但我卻習慣於去找找界面的素材， 這就導致兩邊都沒有做好。雖然認識上知道不該這么做，但是習慣上卻很難改。
4.自己很多時候雖然有問題但是不能完全闡述清楚，所以跟leader溝通的時候往往支支吾吾，以後有問題自己首先得想清楚，將問題講明白也是很關鍵的能力。
另外也記錄一些自己的淺薄感受：
1.工科出身的詹老師對於代碼的運行效率有很多的考慮，但對於用戶體驗和互動效果似乎稍微少點，當然也可能是我新來並不了解的原因。
2. 公司在做小套用的時候並不會在用戶測試和產品結構功能上討論太多，公司要的是疊代效率， 就是要快速出套用，然後再快速上線下一個。
本周接到新的任務，為中國教育線上製作H5的招聘頁面， 之前的“給師姐打電話”的H5套用還沒有最佳化好，能做的改進的地方還有很多，leader詹老師讓我先把招聘網站做好， H5套用先放放， 他給了我大街網做的“中國好Offer”作為參考， 拿到之後確實感覺這些頁面都做得很好， 詹老師蒐集的資源確實十分豐富，從實習到現在他發給我的參考很實用，在看完了五六十個H5的招聘頁面之後開始構思， 在將產品架構基本做好後，測試又發現很多問題， 有技術層面的，但更多的設計本身的問題。
技術的細節的問題：基於jquery mobile的開發框架國內的資料十分有限，不得不查閱原始的英文API，很多問題也只能去JQM的論壇查找，這些都十分考驗英文閱讀能力。CSS的布局問題繁雜，在各個瀏覽器，各個套用的渲染都不一樣， 也是很折磨人的過程，我現在就碰到了css中font-weight屬性在Safari沒有渲染的問題，至今沒有解決。
逐漸體會到前端工作的繁瑣與細節， 需要學的東西很多， 有時候可以憑自己一些小聰明在當前解決，但並沒有摸到問題的根源，揚湯止沸不是長久之計，但又好像沒有足夠的時間來系統的摸索，我只能先將這些問題一一記下來。這些技術的體會是一方面，另一方面便是產品的設計層面， 現在就是因為產品快做好後發現有很多地方犯了低級錯誤， 以往的紙上談兵頭頭是道，等到自己親身實踐卻感到把握不住很多設計原則， 比如界面設計給用戶造成的不必要的干擾， 功能可見性的不足，邏輯上的不嚴謹， 以下我歸納了下崗做好的H5界面存在的互動問題：
1.頁面的設計初衷是左右滑動來切換頁面，但給幾個朋友測試後都不能進入頁面後就自然而然的知道是左右滑動。
2.join us的圖示給用戶是按鈕的錯覺，在測試中很多用戶以為是按鈕，都會下意識的點擊。
3.互動效果的乏善可陳，與滑動的邏輯似乎也沒有太大關聯，只是單純的加入了一些css3的動畫。
4.用於提示左右滑動的動態箭頭會讓用戶以為是點擊作用
軟體開發心得體會範文 篇13
我是公司一名文員，部門涉及很多業務數據的東西，在此之前，公司的所有業務記錄都是通過一張excel表格來完成，第一次看到那張表的時候是真心嚇到了，欄位有幾十個，項下又有很多拆分合併，其中又大多為數據和日期，通過幾天的整理髮現了不少錯誤，更加感嘆需要一個資料庫來解放人力、提高效率。
從開始接受access培訓到現在已經有半年時間，雖然上學期間學校的老師也有給我們講過access的知識，但只是講了些關係的建立及簡單的查詢，以為access就好比word、excel等相對比較簡單的辦公軟體一樣。但開始接受盟威Access的培訓後，對Access的看法才改變，原來Access還可以這樣玩；參加學習之初，由於自身一開始認識誤區的心態導致自己走了很多彎路。一開始所有的Access老師就告誡我說一定不要心急，要按培訓指南指導，要按照教程一步一步做下去，切忌眼高手低。但因為心想自己對電腦還算有點感覺，加上公司一直比較急，又很想短時間內做出點東西，就沒有很耐心的把教程步驟做完，導致後期回爐再造無數次耽誤很多時間，在這裡希望大家引以為戒。
在學習的過程中，因為老師是一個階段一個階段發教程的，當我看到報銷系統時，就已經覺得十分十分的強大了，然後自己就想邊看教程邊偷懶開始自己開發，雖然老師一再強調不能不會走就想跑，但自己還是開始蠢蠢欲動了，等到做了一部分之後看到了進存銷系統後，又發現裡面有很多自己可以學以致用的東西，然後又開始重新做，再等到新版的快速開發平台出來了，自己又一次被震撼了，感慨Access快速平台的強大，基本的模組都不需要自己手動創建了，簡直太厲害，真是技術宅改變世界。
整個開發過程可以說是充滿艱辛，但又有很強的成就感。雖然自己有時候會想不出來該怎么做，但是！還有一群很厲害的老師可以幫你，有時候老師們一句話、一段代碼就能幫我搞定自己苦思冥想很久都做不出的步驟，可以說每一個成功的系統背後都有一群默默無聞的老師。
每次把自己一些亂七八糟的想法告訴一對一老師，其實自己都覺得可能做不了了，但每次杜老師都會給我驚喜，幫我完美解決掉，十分欣慰。
現在系統開發的已經在測試套用，雖然還有些部分在一步步完善修改，但我相信access的強大，能解決我的數據問題，也相信盟威老師們的技術給我的支持，在此感謝這半年來所有老師的大力支持與幫助，也希望盟威軟體快速開發平台做得越來越好，讓更多跟我一樣的菜鳥開發出屬於自己的資料庫軟體，解放自己的工作強度。
軟體開發心得體會範文 篇14
一、實訓過程
首先，我們學習通用編程：任何類類型的所有值都可以同object類型的變數來代替。封裝：就是把數據和行為結合起在一個包中)並對對象使用者隱藏數據的實現過程，一個對象中的數據叫他的實例欄位(instance field)。重載：當多個方法具有相同的名字而含有不同的參數時，便發生重載。編譯器必須挑選出調用哪個方法。數組列表：ArrayList動態數組列表，是一個類庫，定義在java.util包中，可自動調節數組的大小。
class類 object類中的getclass方法返回class類型的一個實例，程式啟動時包含在main方法的類會被載入，虛擬機要載入他需要的所有類，每一個載入的類都要載入它需要的類。Java中對記憶體的分配是動態的,它採用面向對象的機制，採用運算符new為每個對象分配記憶體空間,而且，實際記憶體還會隨程式運行情況而改變。程式運行中 Java系統自動對記憶體進行掃描,對長期不用的空間作為”垃圾”進行收集，使得系統資源得到更充分地利用.按照這種機制,程式設計師不必關注記憶體管理問題，這使Java程式的編寫變得簡單明了,並且避免了了由於記憶體管理方面的差錯而導致系統出問題。而C語言通過malloc和free這兩個庫函式來分別實現分配記憶體和釋放記憶體空間的，C++語言中則通過運算符new和來分配和釋放記憶體，總之，Java語言是一個純的面向對象程式設計語言。
Java語言是分散式的。Java語言支持Internet套用的開發，在基本的Java套用編程接口中有一個網路套用編程接口(java net)，它提供了用於網路套用編程的類庫，包括URL、URLConnection、Socket、ServerSocket等。Java的RMI(遠程方法激活)機制也是開發分散式套用的重要手段。 Java語言是健壯的。Java的強類型機制、異常處理、廢料的自動收集等是Java程式健壯性的重要保證。對指針的丟棄是Java的明智選擇。Java的安全檢查機制使得Java更具健壯性。 Java語言是安全的。Java通常被用在網路環境中，為此，Java提供了一個安全機制以防惡意代碼的攻擊。除了Java語言具有的許多安全特性以外，Java對通過網路下載的類具有一個安全防範機制(類ClassLoader)，如分配不同的名字空間以防替代本地的同名類、位元組代碼檢查，並提供安全管理機制(類SecurityManager)讓Java套用設定安全哨兵。 Java語言是體系結構中立的。Java程式(後綴為java的檔案)在Java平台上被編譯為體系結構中立的位元組碼格式(後綴為class的檔案), 然後可以在實現這個Java平台的任何系統中運行。這種途徑適合於異構的網路環境和軟體的分發。 Java語言是可移植的。這種可移植性來源於體系結構中立性，另外，Java還嚴格規定了各個基本數據類型的長度。Java系統本身也具有很強的可移植性，Java編譯器是用Java實現的，Java的運行環境是用ANSI C實現的。
Java語言是解釋型的。如前所述，Java程式在Java平台上被編譯為位元組碼格式，然後可以在實現這個Java平台的任何系統中運行。在運行時，Java平台中的Java解釋器對這些位元組碼進行解釋執行，執行過程中需要的類在聯接階段被載入到運行環境中。 Java是高性能的。與那些解釋型的高級腳本語言相比，Java的確是高性能的。事實上，Java的運行速度隨著JIT(Just-In-Time)編譯器技術的發展越來越接近於C++。 Java語言是多執行緒的。在Java語言中，執行緒是一種特殊的對象，它必須由Thread類或其子(孫)類來創建。通常有兩種方法來創建執行緒：其一，使用型構為Thread(Runnable) 的構造子將一個實現了Runnable接口的對象包裝成一個執行緒，其二，從Thread類派生出子類並重寫run方法，使用該子類創建的對象即為執行緒。值得注意的是Thread類已經實現了Runnable接口，因此，任何一個執行緒均有它的run方法，而run方法中包含了執行緒所要運行的代碼。執行緒的活動由一組方法來控制。Java語言支持多個執行緒的同時執行，並提供多執行緒之間的同步機制(關鍵字為synchronized)。
二、心得體會
剛開始時張宇老師先教我們配置JAVA的編程工具和運行環境，然後教我們學JSP，在此期間，我們自學了JAVA，又學了Tomcat的使用及MySql和HTML語言，當我們JSP入門後，陳老師開始教我們學習JSF框架，但由於學校的安排，剛開始學，陳老師便去了蘇州，由在蘇州帶隊的孔祥盛老師回來教我們，在孔老師的安排下，我們又學習了SQL Server 20xx和Struts框架，教我們學會了Javawebstudio的使用。總之，
在兩位老師的細心輔導下，我們有了很大的進步，知識得到了擴充，認識得到了加深，也使得我們的自學能力得到了很大的提高，在此，我向兩位老師表示由衷地感謝。這次實訓是三年中所學知識的一次匯總，是三年來學習能力的一次集中體現，有的知識在這次實訓中用不到，但以後會用到，我敢說肯定會用到。因為好多東西都是厚積而薄發，所學的知識在關鍵的時刻也許只有一種用得上，但這一種也許足以成就我們的人生，到那時我們才能真正體會到知識的偉大，才能真正了解老師的重要性。我覺得要成為一個合格的程式設計師，首先要具備的是一種自學能力，遇到了問題自己要有能力去解決，當你嘗試了各種方法，實在無能為力時再去請教別人，這時你所學的知識你一生都不會忘記，它將成為你一生的財富。有句話說得好：進攻是最好的防守!當你遇到了問題，你要試著去解決，編程嘛，想到了就要去試，你的面前就一台電腦而已，它又不會爆炸，你怕什麼呢?我不敢說我的觀點一定正確，每個人有每個人的想法，也正是因為大家的觀點各不相同，才使得IT業這個新興的產業在短短的幾十年中得到了長足的發展，給人類社會創造了超過以往人類社會所創造的價值的總和，這不能不令人驚嘆，也正是因為如此，它才使得我對它產生了強烈地好奇心和探索欲。未來的社會是信息的社會，信息業所創造的財富在人類社會中占據首位，經濟、軍事、教育、醫學、農業等領域無一不用到信息業所產生的科技成果。我能感受到它所創造的經濟效益會有多大，所以，我要說：我愛編程,海枯石爛，矢志不渝!我是一個新技術的狂熱追隨者，每次上網時總要到MLDN上逛一下，當看到短短的幾行代碼卻能產生令人驚嘆的功能時，我就被編程者的那種魅力所折服，我想成為其中的一員，我為自己現在所學習的專業感到自豪。
在我學習的過程中我也遇到了很多的問題，可是我卻發現我遇到的好多問題在網上總能找到答案，我才明白我遇到的問題很多人都遇到過，並且他們也把解決的辦法發布到了網上，以使我們這些初學者少走些彎路，我覺得他們太善良了，同時我也明白了自己是多么的渺小，我正在走前人走過的路，到底前面的路有多長多遠，我不知。他們是開路先鋒，他們為我們學習新技術新知識鋪平了道路，我們所要做的就是把他們所發明和創造的東西掌握使用而已，並且知識量又很大，當我看到有無窮無盡地學習資源供我享用時，我只能說，他們像太陽一樣照耀著我成長，他們太好了。當我看到程式代碼，我就有一種特別的感覺，讓我不斷想成為一名編程高手，如果真的有一天，我的理想會實現，我會加倍努力好好學編程，永遠不改變!通過三個月的實訓，我感到自己學到了很多東西，雖說不精，但已經入門，於世間萬物之中，遇見我所遇見的事物;於千萬年之中，時間的無涯荒野里，沒有早一步，也沒有晚一步，剛巧趕上了，上蒼讓我有機會接觸編程，給了我一條路。我很清楚以後的路還很長，再長的路，一步步也能走完，再短的路，不邁開雙腳也無法到達。任何業績的質變都來自於量變的積累，成功不是將來才有的，而是從決定去做的那一刻起，持續累積而成，讓我們將事前的憂慮，換為事前的思考和計畫吧!在實訓的過程中，我深深感覺到自身所學知識的有限，有些知識點以前沒有學過，但我也沒有去研究，實訓時突然間覺得自己真的有點無知，雖然現在去看依然可以解決問題，但要浪費許多時間，這一點是我必須在以後的學習中加以改進的地方，同時也要督促自己在學習的過程中不斷的完善自我。另外一點,也是在實訓中必不可少的部分，就是同學之間的互相幫助。所謂”當局者迷,旁觀者清”，有些東西感覺自己做的是時候明明沒什麼錯誤，偏偏程式運行時就是有錯誤，讓其他同學幫忙看了一下，發現其實是個很小的錯誤。所以說，相互幫助是很重要的一點，這在以後的工作或生活中也是很關鍵的。
俗話說：“要想為事業多添一把火，自己就得多添一捆材”。此次實訓，我深深體會到了積累知識的重要性。在實訓當中我們遇到了不少難題，但是經過我們大家的討論和老師細心的一一指導，問題得到了解決。兩個月的實訓結束了，收穫頗豐，同時也更深刻的認識到要做一個合格的程式設計師並非我以前想像的那么容易，最重要的還是細緻嚴謹。社會是不會要一個一無是處的人的，所以我們要更多更快地從一個學生向工作者轉變，總的來說我對這次實習還是比較滿意的，它使我學到了很多東西，為我以後的學習做了引導，點明了方向，我相信在不遠的未來定會有屬於我們自己的一片美好天空。
軟體開發心得體會範文 篇15
軟體開發過程中的任何一個活動都是為了能夠產出優秀的代碼。所以，代碼才是核心。
1. 代碼是軟體開發的基礎
編碼是軟體開發過程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領域的專家都需要花費大量的時間來進行基本技藝的鍛鍊，木匠需要花費大量的時間來鍛鍊他們對各種工具的掌握，廚師則需要練習刀工和火候。程式設計師也是一樣的，對我們來說，語言的各種特性必須要瞭然於胸。而對軟體的管理也需要從代碼做起。
從20xx年到現在，國內興起了一股軟體工程熱，需求管理、配置管理、甚至CMM。面對紛至沓來的各種方法學、UML、OOA，大家似乎已經熱衷於這些概念本身了，卻往往忽略了軟體開發中最基本的元素:代碼。在和很多軟體組織的接觸過程中，我們認為大多數組織急切需要的並不是這些工程理論，不是說這些理論不重要，而是這些組織的癥結不在於此。很多的組織連代碼的質量都管理不好，又何談其它呢?代碼管理是基礎的基礎，從管理的角度上來看，任何一個組織的管理都需要一個從上至下的管理過程，有基層的管理人員，也有高層的管理人員。對代碼的管理就是軟體開發中的基層管理，它起到的作用就是能夠把需求、設計的思路貫徹到最終的代碼中。
“管理無大事”。對軟體的管理也是一樣，大部分的問題都是由於很小的原因引起的。例如，一個產品如果後期在debug上花費了大量的時間，那么，這種現象是由於什麼原因引起的?一種可能的原因是前期的代碼設計中對代碼質量的把握不嚴。每一次代碼功能的演化並不會產生太多的問題，但是當代碼累積越來越多的時候，問題也就慢慢出現了。那么如何解決呢?可以加強QA的力量，也可以引入複審，還可以引入單元測試。總之，要有一種方法對代碼進行控制。
軟體的開發過程就象是一部精密的機器，任何一個環節的變化，都會對其它的環節產生影響。把軟體過程按照瀑布的形式進行劃分是一種分解的處理思路，但同時我們還應該看到不同活動之間的相互影響。軟體開發中的生命周期模型也是一個層次模型，從業務建模一直到軟體實現，需要跨越數個層次，同樣會出現執行不力的情況，例如，代碼設計偏離需求、偏離設計的情況比比皆是。
如何避免這種情況呢?這就需要我們從原始碼的角度，反思其上游的實踐活動，是否足以約束代碼設計?就拿XP來說，他解決這個問題的方式是儘快的進入代碼開發階段，從代碼開發中發現問題，並在下一輪的開發中解決。這種思路是正確的，但XP畢竟是方法論，他不會告訴你過於細節的東西，儘管XP已經提供了大量面向代碼的實踐。因為方法論的抽象級別比較高，使得他必須捨棄部分的細節。而這篇文章告訴你的，就是這些細節。就像我們在下一節中討論的例子，需要在代碼中加入對異常的處理，那么，異常的源頭在哪裡呢?是需求，在需求中，我們發現了一些業務的非正常的處理序列，發現了一些業務實體的限制性的要求，所以在代碼實現中，就需要有相應的異常處理。在例如，一個優秀的異常處理，還需要讓客戶端程式設計師了解可能發生的異常，以保證不同代碼間正確的集成。
2. 面向對象的代碼
面向對象的代碼已經在現在的軟體開發中占據了主流的位置，面向對象的思路也有其優勢所在，就像後文所討論的，面向對象代碼有著非面向對象代碼的很多優勢，而軟體業中很多新的思潮的產生，也都是基於面向對象語言的，所以我們關注的代碼將是面向對象代碼。
面向對象的思想來自於抽象數據類型。對於面向對象來說，它最重要的改進就是把世間萬物都描述為對象，而類則描述了同一種對象的特徵，而不是像傳統的開發方法那樣，按照機器指令的執行順序來進行設計。當然，面向對象代碼最終仍然是要按照時序來執行的，但是從程式設計師的角度看來，面向對象代碼更側重於對象之間的互動，多個對象各司其職，相互協作以完成目標。而面向對象技術的發展，也是朝著更加貼近我們世界觀的方向發展。從這點來看，有人說完全沒有程式設計經驗的人學習面向對象可能會更加的容易，因為他不需要從原先的時序程式的桎梏中擺脫出來，但這未必是事實。面向對象決不是一種簡單的程式設計思路。這是我們的觀點，也會在下文中反覆的論證。
和所有的職業一樣，程式設計師，或者是面向對象程式設計師，始終堅持的一點就是嚴謹。你會看到各種各樣優秀的代碼，但那決不是一次能夠寫成的，要不斷的嘗試，不斷的改進。為什麼重構和測試優先是敏捷方法中很重要的一項實踐?因為程式設計師不是神，他們需要慢慢改進他們的代碼。雖然羅馬不是一天能夠建成的，但是在編寫面向對象代碼的過程中，有一些實踐是需要堅持的，它體現了我們所說的嚴謹。
3. 編寫並管理面向對象的代碼
編寫優秀的面向對象代碼並不是一件容易的事情，優秀的OO代碼如行雲流水，糟糕的OO代碼讓人覺得渾身起雞皮疙瘩。編寫優秀的OO代碼要求程式設計師有一定的自我修養，能夠以抽象的思路看待問題，找到問題的核心並對問題域進行分解。它強調的是一種解題的思路，但這個解不是唯一的。
典型的例子是設計模式，設計模式確實給了我們以很大的啟發，通過它，我們能夠了解到優秀的代碼是如何用於解決實際問題的。但是是不是你必須在軟體中照搬設計模式呢?如果你這么做，那么你對設計模式的理解仍然不夠。我曾和在建築行業的朋友聊起Christopher Alexander的建築的永恆之道。他很興奮的告訴我，那確實是一本很好的書，能夠引發人很深的思考，但是現在也有另外的一種觀點，認為美仍然是無形的，應該發自建築師的內心。對這句話我思考了很久，其實建築是給人使用的，因此最重要的是它能都給人帶來的價值，隱含在其中的那種活生生的氣質，這是建築師文化底蘊的外在表露。所以，Christopher Alexander在那本書中的目的，也是為了找到一種總結自己觀點的方法，來總結自己對人文的認識。至於現在大家對他的思路提出了質疑，那也是一件好事，這說明大家對建築之道的認識到了新的高度。建築是這樣，軟體中的模式也是一樣的，我也曾熱衷於研究模式的使用，直到某一天我猛然驚醒，與其沉迷於模式的表面形式，為什麼不去研究隱藏在它背後的文化底蘊呢?武俠小說中常說無招勝有招，模式的套用也應當到達這個境界，你如果可以在不經意間套用模式的思想，那又何必拘泥於模式的形式呢?
編寫優秀OO代碼雖難，但還有更難的事情，就是讓整個開發團隊都產出優秀的OO代碼。我們剛才說了，OO對問題的解不是唯一的，但各個不同的優秀解匯集到一起，可能就是一個糟糕的解，這是風格和架構的問題。你如何在團隊中制定製度，營造氛圍，讓優秀OO代碼成為團隊最終的成果?這些問題，在我看來，要比CMM難得多，這個問題並不是靠花錢就能夠解決的。如果能夠解決這個問題，這個團隊的創造力一定是驚人的。
4. 面向對象軟體開發過程
普通的軟體開發過程和面向對象開發過程有著很大的不同。回想我們在非面向對象中開發過程中，最經常採用的任務分配方法就是以軟體模組為單位，這樣的好處是分配簡單，不同任務之間耦合程度低，容易操作。壞處是幾乎無法做到重用，也缺乏整體性的設計。而面向對象軟體開發則不同，它是以類、類集合作為基本單位的。類之間關係錯綜複雜(雖然我們提倡低耦合的設計，但類之間的關係仍然是相對複雜的)。這種情況下程式設計師之間相互協作的要求就非常之高，這種關係如果處理恰當，則能夠完全體現出面向對象的威力，否則，那將會是一場大災難，面向對象的軟體開發過程要養成一些好的習慣：
4. 1 儘量簡化和穩定客戶端。
個人編程可以是一種享受，但團隊開發始終是一項嚴謹的職業活動，因此多考慮別人，不要設計複雜的接口，雖然你省事了，但這會給理解和使用你的接口和人造成障礙。
4.2 準備一份簡潔的文檔，並保持更新。
隨便一種形式的穩定，可以是代碼，可以是UML圖，也可以是純粹的文字(估計沒幾個程式設計師喜歡這種形式)。只要它能夠傳達你的代碼的目的，那就足夠。記住，更新代碼後，同時更新你的文檔。過期的文檔不僅是廢紙這么簡單，它會給其它人造成麻煩。切記!
4. 3 儘可能多的考慮異常和錯誤的情況。
軟體開發心得體會範文 篇16
受某文化公司委託，開發一款用於視頻和圖像處理的軟體，開發難度高，高到從未搞過，開發周期長，長到是我以前項目監控最長開發周期的兩倍，開發成本之底，讓我覺得程式設計師成了高級打字員。首先是需求分析書、產品規格說明書、設計說明書、代碼規範說明書、測試計畫，光文稿就不知道熬了多久才做完。
緊接著，遇到一系列問題，首先是語言選擇，vc++和c#都是可以保證開發完成的選擇，但是vc++記憶體容易報錯，界面很難修改，而客戶要求的界面質量甚至比程式的功能更嚴格，沒辦法，客戶就是上帝，上帝做事一定有他的道理。c#語言易於開發，而且圖形界面繪製也易於修改，可以做出客戶體驗很好的界面，但是在資源的消耗上，讓我很吃驚。做到第二個月，大概的界面已經完成時，出現界面刷新的問題，刷新時開始卡，界面不流暢。沒辦法，改。
開會，總結，技術骨幹找問題，拿出解決方案，力爭第一次做軟體把它做好：
重新做軟體開發進度計畫和軟體測試計畫，並且讓獨立功能demo製作和測試先行;
用direct draw、direct 3d或者opengl中的一個替代c#本身的gdi繪圖，將在接下來的開發任務中加入進去。
事無巨細，當我滿意的看著界面流暢，功能也已實現時，發現軟體在低解析度或者小本上根本亂到沒法看，甚至是界面功能按鈕錯位，重疊等等。沒辦法，改。畢竟軟體的多解析度兼容和作業系統兼容是必須要做的。
接下來一大堆的麻煩找了上來，軟體出現各種各樣想都想不到的問題，總算是按時將第一個版本發布出去，並且開始接下來的升級開發任務。
最後，給剛剛接手軟體開發項目的朋友一些忠告：
一、相關的文檔不是給別人看的，而是給自己看的，相關文檔一定要齊備，而且讓所有涉及開發的人員都清楚的知道你文檔里所要表達的意思;
二、一定要注意多做demo，多做實驗，一個demo程式設計師幾個鐘頭就可以完成，甚至更少，但是不做demo，核心程式沒有做實驗，其他的東西都圍繞核心程式做了上去，到時候耽誤的可不是幾個鐘頭
三、程式設計要注重用戶體驗，當初客戶對我要開發軟體提出近乎苛刻的要求時我不在意，但是當我自己反覆使用軟體時有了很多體會，流暢美觀的界面帶給人心理的快感的確能替代一些尚未開發完整的功能帶給用戶的遺憾。
四、測試計畫多次進行，分批進行，不要全部開發完成再對軟體做測試。
還要堅持三個月，軟體馬上發布，希望大家的支持，謝謝!!!
軟體開發心得體會範文 篇17
國貿軟體實訓心得體會(793字)經過長時間對國貿軟體的的使用，在不斷練習操作的過程中，我對國貿軟體的最深刻感覺是：學以致用、有趣、必須細心耐心反應迅速。
1.學以致用
作為國貿專業，經過長時間的理論學習，急需通過實際操作或某種近似於實際操作的平台對所學的理論知識加以實踐，以求進一步掌握和鞏固，而國貿軟體正提供了這樣一種平台。該軟體涉及了及出口貿易的各個方面和環節，從外貿公司的經營運作到實際的進出口業務流程，都能進行模擬實訓。在使用過程中，會遇到很多國貿的基礎理論知識和實務技能，這是對國貿理論掌握程度的最好考察。眼過千遍不如手過一遍，相對於理論部分而言，國貿實務更注重實際操作，通過這種理論結合實踐的方式，鞏固基礎知識，查找理論學習的不足，以前學習的實物理論基礎知識會更加的具體和直觀。同時，該軟體的實務操作部分與報關員報關實務所涉及的知識基本一致，這對於我的報關員考試複習提供了很大的幫助。
2.有趣
該軟體通過“實戰”方式訓練，會在操作過程中遇到很多難題和挑戰，這些必須自己想辦法解決。由於大家進行了角色劃分，形成了一個虛擬市場，所以大家之間相互的競爭是必不可少的，大家會從各個方面進行競爭。競爭在現在是無法避免的，意識正是現代社會生存發展所需要的。正是這種競爭，使得我(相信大家)對該軟體產生了濃厚的興趣。
3.細心、耐心、反應迅速
國貿軟體涉及大數據計算的繁瑣的單證填寫，所以必須做到細心耐心，例如，在填制外貿契約時，一個小小的數據錯誤或是貨物裝運、指運港名稱的錯誤都會是契約填寫失敗;填寫保險單或是報關單證，沒有嚴格按照契約數據填制就會導致填寫出現錯誤，無法進行下一步驟，影響實驗效率。
在操作過程中，除了複習、鞏固所學國貿理論外，另一個重要任務就是想辦法“賺錢”，提高自己企業的盈利水平和生存能力，這就要求必須反應迅速、判斷準確，否則會覺得企業經營的舉步維艱。 以上就是經過一段時間對國貿軟體的操作使用產生的心得體會。
軟體實訓心得體會四：軟體實訓心得(778字)轉眼間，到崑山已經兩個多月了。不知不覺中我已經從一個在校生變成了一個職員。這跟在我們學校是完全不一樣的。除此之外，安博還制定了嚴格的制度，這些使我們在安博的培訓像職工在公司工作一樣，讓我們提早接觸到公司的氛圍。
來安博最重要的目的還是學技術，那就說說這裡的教育情況吧。安博實行的是上午授課，下午上機練習的制度。我覺得我們這個班上午的授課經理非常好，他對java的理解非常透徹。我在大學學了半年的java，僅僅停留在表面上，對實質的內容根本都不了解。比如說==與equals的區別，方法的覆蓋，變數的隱藏等等。老師通過圖的方式，給我們講解它們在記憶體中的情況，使我們從本質上了解了這些東西。他的這種授課方式，既生動又形象，徹底地將問題講明白，我們接受起來輕鬆容易，也不容易遺忘。
除了他的講課方式以外，他還是一個非常幽默的人，坐在凳子上聽四個小時的課，會很乏味的，他時不時的給我們說一些搞笑的事，或者開玩笑的話，使課堂氣氛非常活躍。他每講完一個新知識點，都給我們留一點時間練習，加深對新知識的理解。我們有什麼問題，他都會很耐心的跟我們講解，不管程度是好是壞，他都一樣對待。總之，聽他的課就是一種享受。他還把跟知識相關的材料發給我們，讓我們有研究的空間。有時還給我們一些面試題，讓我們提早看，只有準備好了去應聘才有機會。
崑山還給我們開了一些素質課，講解一些職場素質，如何為人處事，如何同面試官講話，還要求我們在日常生活中也儘量做到。在我們就業之前開這樣的課，對我們這些即將踏入社會的大學生來說是非常重要的。公司招聘員工，一看實力，二看素質，兩者缺一不可。
總之在崑山的這段時間中，我學到了很多。時間雖短，但所學到的和知識的實用性很強。所有的老師們都教給了我們很多工作習慣、工作技巧、日常禮儀、職業素養和心態方面的東西。使我們對今後的工作有了新的認識，增添的極大的信心。
軟體實訓心得體會五：軟體工程實訓心得體會(1521字)這次軟體工程實訓是從20xx.12.26號開始的，截至20xx.12.31號。實訓內容是用java相關知識(主要是jsp)做一個物流配送系統。下面談談對這次實訓的看法。
因為自己平時對java知識儲備不足，特別是jsp這一塊基本不了解怎么回事，所以一拿到這個項目，我心裡都是沒有底的，再加上我被分到的那個組，我知道就意味著是我一個人在戰鬥了。呵呵，26號，實訓開始了，我們的老師是來自中軟國際公司的程式設計師，一個是周褀，一個是朱映，都是一身樸素的著裝，讓我感覺做軟體的也沒什麼兩樣。老師介紹了自己之後，就直接切入正題了，分析了下我們各個組的系統，即將用到的知識，然後就總體把覺得需要補充的知識(jsp和資料庫連線等這幾塊)給我們實際操作了下，因為當時看到用jsp，還講的那么認真，當時我就後悔了，平時要是多聽點，現在老師這么認真的給我們講，這是一個多么難得的機會啊。後悔也沒用啊，開始還勉強能理解一點，後來就直接暈了。然後再給大家介紹了一些即將用到的工具，比如rationalRose，SVN，MyEclipse等等。接下來的幾天就不再細講了。下面談談通過這次實訓的心得體會吧。
通過這次實訓，讓我了解到工程開發的過程，可行性分析——>需求分析——>概要設計——>詳細設計——>代碼編寫——>測試——>驗收。從技術方面上，我開始jsp基礎基本上就是零的，在老師和syz2(另外一個物流小組，我一個人基本上是跟她們做的，或者說是看著她們做的)的幫助下，對jsp有了一個大概的認識。其實實訓開始前，我還以為做個系統沒什麼大不了，可是當真正拿到一個項目，我卻真的無從下手了，而且就是在知道需求分析和詳細設計，在代碼編寫時，一樣寸步難行。通過這個實訓，也讓我了解到，團隊協作是多么的重要。一個人的精力是多么的有限。進一步理解到，企業為什麼如此重視團隊協作。同時借用老師的話就是團隊協作固然重要，但是是建立在個人素質的基礎上，假設你個人素質不行，將會影響到整個團隊，就別提對團隊作更多貢獻了。**老師說這幾句話的時候，朝向了我，估計是有特殊意義的吧，所以，我將謹記老師的教導。
還有一個收穫是從一個同學(小胖)那裡得到的，他的那組成員跟我的這組大體一樣，我倒是覺得沒什麼了，不過他倒是很重視這個問題吧。然後他說出來，我也覺得這個問題確實其實是個大的問題。就是不管你會不會這門技術，會不會做這個東西，態度要正確才好，就算你不會做，你也應該認真的對待，將來 出身到社會，就不是說像你現在，不會做就不做，跑去玩遊戲了。小胖說出了這段話，也在我身上有了一個印證，雖然我jsp技術知識為0，但我也還是在認真的跟著他們一起做，不會做，就多問，畢竟現在我們是學生，可以毫不顧忌的詢問各種問題，老師也會盡力為你回答。將來出身社會就不一樣了。雖然，我就算個打醬油的水平，但是這個醬油也要打得有涵量啊。不管怎么樣，我能對自己有個交待，雖然我不會，但是這次實訓我確實是認真對待了，六天的實訓，除了晚上加班外，還花了2個通宵來完成不同階段的任務，完成與否也不重要了，我至少我做了，這點，是這次我應該對自己的一個肯定。
這次實訓的心得基本上就是這些了，最後特別感謝中軟國際帶我們的那兩個老師(周褀，朱映)，這兩個老師對待我們很平易近人，對我們提出的問題，總是不光解決了，還進行了擴展，晚上也跟我們一起加班加到很晚，印象尤其深刻就是朱映老師為了給小胖解決一個問題，臉都變紅了，還在繼續努力，這點我並不會覺得老師知識儲備不夠，我想應該是這個問題的突發吧，一時沒想到怎么處理。相反讓我感覺更多的就是老師很認真，很負責。
軟體開發心得體會範文 篇18
來到北大青鳥通州校區學習已經快一年了，雖然時間不算太長，但對於我而言，在北大青鳥，我的收穫是無法用時間長短來衡量的!
因為在來北大青鳥之前，我從沒接觸過軟體方面的知識，所以剛開始很擔心自己學不了，自卑的情緒很嚴重。但是細心的班主任發現了我的問題，總是很耐心的找我談心，開導我!慢慢的，我想明白了，不要盲目的和其他同學作比較，今天的我只需要比昨天的我有進步，我的目的就達到了!
想通了以後，我自己也越來越自信了。就像一隻從起跑線上開始爬行的蝸牛，雖然很慢，但是我目標很明確，很堅定!或許很多人會認為學習軟體是一門很枯燥的課程，但是我覺得這乏味中也有不少樂趣。例如學習.NET和C#時，我們小組就自己製作了一款小遊戲，雖然是一款很簡單的小遊戲，只能有一些普通的攻擊動作，但是它就是我們的學習成果。玩著自己編寫出來的小軟體，想著以後能開發出更厲害更完善的系統，讓我們對未來的工作和學習充滿了動力!
剛開始接觸三層架構的時候，我上課聽老師的講課真是一頭霧水。但是我並沒有放棄，而是更加認真，調整好心態，強迫自己反覆的看書，查資料，一遍遍的練習，遇到不懂的就馬上去問老師，就這樣，終於攻下了一道道難題。
如果你問我在學習軟體的過程中，什麼學習方法最重要，那我會認為勤奮是最重要的。一定要反覆的練習，這樣你才會掌握得更紮實，基礎打得好，後期的學習才會更省力!另外，我覺得課餘時間應該好好的利用起來，不要局限於課本，要主動的去學習更多的知識和技能，為以後的工作準備更多的能力!