軟件開發心得體會

第一篇：軟件開發心得體會

受某文化公司委託，開發一款用於視頻和圖像處理的軟件，開發難度高，高到從未搞過，開發週期長，長到是我以前項目監控最長開發週期的兩倍，開發成本之底，讓我覺得程序員成了高級打字員。首先是需求分析書、產品規格説明書、設計説明書、代碼規範説明書、測試計劃，光文稿就不知道熬了多久才做完。

緊接着，遇到一系列問題，首先是語言選擇，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、管理、產品、流程等），非常情緒化。有些女程序員還會吵，會哭，這時項目經理只能放下手中的活，下去給她買點零食來哄哄，“莫哭，這裏有你最愛吃的貓哆哩。”一邊擦着鼻涕、眼淚，一邊嘴裏塞滿東西，鼓鼓啷啷“這是酸角口味的，那個西番蓮口味的才叫好吃..."

這些通常不太容易在面試時表現出來，在試用期時，要觀察。

第二篇：軟件開發學習心得體會

軟件開發學習心得體會

隨着我礦“兩化”融合工作的推進，軟件開發方面人才顯得更加缺乏，所以我選擇對進一步深入學習；經過近兩個月的自主學習，進一步掌握了動態網頁製作的一些理論知識和基本常識，不僅要應用各種方面的知識還要對所學的知識學會變通使用，雖然會有一些成功的地方。曾經看到網上有這麼一句話，一個優秀的網絡程序員不但要了解自己領域的一些專業技術，而且很多時候還要充當半個網絡工程師，半個美術設計師和半個數據庫管理員。是microsoft 戰略的核心產品，憑藉它豐富的控件，以及具有革命性的code-behind技術，以及良好的封裝性，無疑成為業界開發active server page的一門巨將，

是 asp（微軟動態服務器網頁技術）的最新版本。執行效率大幅提高：構架是可以用microsoft（r）公司最新的產品 visual 開發環境進行開發，wysiwyg（what yousee is what you get所見即為所得）的編輯。簡單性和易學性、高效可管理性使用一種字符基礎的，分級的配置系統，使你服務器環境和應用程序的設置更加簡單。因為配置信息都保存在簡單文本中，新的設置有可能都不需要啟動本地的管理員

工具就可以實現。這種被稱為"zerolocal administration"的哲學觀念使的基於應用的開發更加具體，和快捷。一個的應用程序在一台服務器系統的安裝只需要簡單的拷貝一些必須得文件，不需要系統的重新啟動，一切就是這麼簡單。多處理器環境的可靠性 已經被刻意設計成為一種可以用於多處理器的開發工具，它在多處理器的環境下用特殊的無縫鏈接技術，將很大的提高運行速度。即使你現在的應用軟件是為一個處理器開發的，將來多處理器運行時不需要任何改變都能提高他們的效能，但現在的asp確做不到這一點。自定義性和可擴展性 設計時考慮了讓網站開發人員可以在自己的代碼中自己定義"plug-in"的模塊。這與原來的包含關係不同，可以加入自己定義的如何組件。網站程序的開發從來沒有這麼簡單過。安全性基於windows認證技術和每應用程序配置，你可以確性你的原程序時絕對安全的。 的語法在很大程度上與 asp 兼容，同時它還提供一種新的編程模型和結構，可生成伸縮性和穩定性更好的應用程序，並提供更好的安全保護。可以通過在現有 asp 應用程序中逐漸添加 功能，隨時增強 asp 應用程序的功能。 是一個已編譯的、基於 的環境，把基於通用語言的程序在服務器上運行。將程序在服務器端首次運行時進行編譯，比asp即時解釋程序速度上要快很多.而且是可以用任

何與 兼容的語言序。另外，任何 應用程序都可以使用整個 framework。開發人員可以方便地獲得這些技術的優點，其中包括託管的公共語言運行庫環境、類型安全、繼承等等。 可以無縫地與 wysiwyg html 編輯器和其他編程工具（包括 microsoft visu(請你繼續關注本站)al

studio ）一起工作。這不僅使得 web 開發更加方便，而且還能提供這些工具必須提供的所有優點，包括開發人員可以用來將服務器控件拖放到 web 頁的gui 和完全集成的調試支持。 當創建 應用程序時，開發人員可以使用 web 窗體或 web，或以他們認為合適的任何方式進行組合。每個功能都能得到同一結構的支持，使您能夠使用身份驗證方案，緩存經常使用的數據，或者對應用程序的配置進行自定義. 如果你從來沒有開發過網站程序，那麼這不適合你，你應該至少掌握一些html和簡單的web開發術語(不過我相信如果有興趣的話是可以很快的掌握的)。你不需要先前的asp開發經驗（當然有經驗更好），但是你必須瞭解交互式web程序開發的概念，包含窗體，腳本，和數據接口的概念，如果你具備了這些條件的話，那麼你就可以在的世界開始展翅高飛了。

在這短短的兩個月中，我知道在程序設計的時候，不要太在意程序是否最簡潔靈活，對於一般開發者而言，程序規範

化和可讀性可能比追求程序的靈活性更加重要。在互聯網資源越來越豐富的情況下，我們可以參考一些規範的程序源代碼來學習。同時我也知道，想要學好這門課程，所要具備很多條件，首先打代碼要規範，要做註釋，這樣回頭來看程序時可以很快的看懂，一方面可以練習自己的邏輯表達能力，對以後遇到難以實現的功能也可以很好的表達出來向別人請教，而且出去從事編程工作的話，代碼的規範是相當重要的。還有一點要學會總結，把自己做的程序用到的知識點列出來就可以很好的總結自己的知識點。當形成知識體系，對知識的理解就會更上一層樓。

第三篇：招聘軟件開發人員的一點心得體會

招聘軟件開發人員的一點心得體會

因為工作原因，有時需要招聘軟件開發人員。這幾年也一直在想，如何能在短短的30分鐘或1小時內，快速識別出，坐在你對面的應聘人員，是否適合你的team。這幾年也一直在觀察和反思，經歷過的team和現在team中的軟件開發人員。有幾點小的心得。

1. 傾向於招什麼樣的軟件開發人員

經歷過歷練的人

吃過苦的，比如以前工作，經常被外派出差，又如曾在業內都知道以加班多而著稱的公司呆過，還有些，留過學，但都是自己邊打工邊讀書的，等等。

這些人員，入職後，通常都是能幹活，能作為骨幹。

思路清晰，思想活躍的人

讓談談自己現在的產品，如果能清晰表述，有條理，會發散，但又能適當控制住，並收回到原話題。談到技術問題和解決過的難題時，眼中有光芒：）

這些人員，今後工作中，學習能力難，對解決難題有幫助，能作為中堅。

坦誠、堅定、平和的人

面試中，坦誠，目光堅定。有時坦誠到甚至於顯得有點木訥：）

我曾經遇到一個，面試下來，我最後介紹我們產品中用到的技術，他對這些技術知之不多，最後他説，“我可能不是非常適合，我知道一個朋友，他可能更適合。”我綜合評估後，最後還是選了他，事實證明，他後來做的很不錯。

坦誠堅定的人，會有恆心去學習，去解決問題。這些人員會作為team的基石。

有缺陷的人才

這是一個朋友（lance）的想法，我認為還是有道理的。

大公司，會看重綜合素質，而如果是小公司，可以考慮選擇一些有缺陷的人才。有缺陷，是指，比如他英語很差，或溝通不清晰，但他能用程序員該有的思

維去思考問題。這樣的人員，通常進不了大公司，故會相對踏實地呆在一家公司，做好自己的工作。

2. 謹慎考慮這樣的開發人員

太活潑，太易興奮

太易興奮，説到投機處，“是是是是，對對對對。。。”，又蹦又跳，還時不時來點，“oh yeah, you are right“，然後還擺個 v 手型。討論問題，不易固守在技術問題本身，時常跑到“我們產品中用到的技術（或第3方產品）很強，我挺他們，不可能有問題”，又或者“我們對客户要強勢，我們要堅持我們的產品沒問題"。

軟件開發工作本身，顯得比較沉悶，優秀的技術人員，都略顯有些內向，因為解決問題，很多時候需要耐得住寂寞，時刻保持相對冷靜。

太活潑的人，會在遇到問題之初，表現出很強的衝勁，但當長時間不能解決時，會表現出沒有耐心，會經常抱怨（對team、管理、產品、流程等），非常情緒化。女程序員還會吵，會哭，這時項目經理只能放下手中的活，下去給她買點零食來哄哄。

這些通常不太容易在面試時表現出來，在試用期時，要觀察。

家境太好的人

家境好，可能沒吃過什麼苦，抗壓差，並不太容易珍惜這份工作。工作強度不大時，還好。遇到技術難題、項目進度緊、壓力大時，這些人員，可能會表現出不易妥協，難於溝通，”我反正也不在乎這麼一個工作。。。我工作不工作都可以，有什麼大不了“。

我team中曾經有這樣一個”富2代“，幹了一年不到就閃了。他在的幾個月中，就像是一場鬧劇，來這裏，旅遊觀光罷了，東看看西看看，拋下幾句狠話，刻下”xxx到此一遊，就走了。

身體太差的人

身體常年有疾者，通常都會性格怪戾，脾氣暴躁，難於跟team很好相融。

第四篇：分享軟件開發小心得體會——(廈門ios開發培訓)

分享軟件開發小心得體會——（廈門ios開發培訓）

如何能在短短的30分鐘或1小時內，快速識別出，坐在你對面的應聘人員，是否適合你的team。廈門博看文思來支招：

1. 傾向於招什麼樣的軟件開發人員

- 經歷過歷練的人

吃過苦的，比如以前工作，經常被外派出差，又如曾在業內都知道以加班多而著稱的公司呆過，還有些，留過學，但都是自己邊打工邊讀書的，等等。

這些人員，入職後，通常都是能幹活，能作為骨幹。

- 思路清晰，思想活躍的人

讓談談自己現在的產品，如果能清晰表述，有條理，會發散，但又能適當控制住，並收回到原話題。談到技術問題和解決過的難題時，眼中有光芒：）

這些人員，今後工作中，學習能力強，對解決難題有幫助，能作為中堅。

- 坦誠、堅定、平和的人

面試中，坦誠，目光堅定。有時坦誠到甚至於顯得有點木訥：）

我曾經遇到一個，面試下來，我最後介紹我們產品中用到的技術，他對這些技術知之不多，最後他説，“我可能不是非常適合，我知道一個朋友，他可能更適合。”我綜合評估後，最後還是選了他，事實證明，他後來做的很不錯。

坦誠堅定的人，會有恆心去學習，去解決問題。這些人員會作為team的基石。

- 有缺陷的人才

這是一個朋友（lance）的想法，我認為還是有道理的。

大公司，會看重綜合素質，而如果是小公司，可以考慮選擇一些有缺陷的人才。所謂有缺陷，是指，比如他英語很差，或溝通不清晰，但他能用程序員該有的思維去思考問題。這樣的人員，通常進不了大公司，故會相對踏實地呆在一家公司，做好自己的工作。

2. 謹慎考慮這樣的開發人員

- 太活潑，太易興奮

太易興奮，説到投機處，“是是是是，對對對對。。。”，又蹦又跳，還時不時來點，“oh yeah,

you are right“，然後還擺個 v 手型。討論問題，不易固守在技術問題本身，時常跑到“我們產品中用到的技術（或第3方產品）很強，我挺他們，不可能有問題”，又或者“我們對客户要強勢，我們要堅持我們的產品沒問題"。

軟件開發工作本身，顯得比較沉悶，優秀的技術人員，都略顯有些內向，因為解決問題，很多時候需要耐得住寂寞，時刻保持相對冷靜。

太活潑的人，會在遇到問題之初，表現出很強的衝勁，但當長時間不能解決時，會表現出沒有耐心，會經常抱怨（對team、管理、產品、流程等），非常情緒化。有些女程序員還會吵，會哭，這時項目經理只能放下手中的活，下去給她買點零食來哄哄，“莫哭，這裏有你最愛吃的貓哆哩。”一邊擦着鼻涕、眼淚，一邊嘴裏塞滿東西，鼓鼓啷啷“這是酸角口味的，那個西番蓮口味的才叫好吃..."廈門博看文思指出，這些通常不太容易在面試時表現出來，在試用期時，要觀察。

第五篇：大型軟件開發心得

最近做的一個項目從需求分析到上線綿延了四個月之久，這也是目前接手過功能點最繁複，產品線對接最多的一個項目。從中得到的一些關於設計較大型產品的心得，拿出來跟大家分享。

立項前

1、統一元素設計需考慮周全

也許是初創團隊的緣故，我不得不感歎團隊對產品經理要求之嚴格之縝密，項目全程只有一個人負責，所以大到產品線對接，小到一句提示的位置和展示形式都需要一一推敲。

哪些元素應該做到統一？

a、提示方面：統一的操作成功/失敗提示；統一的彈窗形式；提示語言採用較統一的句型；為空情況的友好提醒；溢出情況的友好提醒；表單實時驗證的提醒形式等。

b、文字方面：是否有統一的段落前“·”號；統一的鏈接狀態；統一的字體、間距、行高等。

c、圖片方面：調取圖片的統一尺寸；如果是上傳圖片類的操作，需要考慮周全全站的調取情況，以及考慮是否統一預覽圖的尺寸等。

d、細節交互：未激活功能的按鈕做“灰色”處理（例如用户沒有勾選信息時批量刪除按鈕不可使用）；按鈕點擊的狀態統一（例如增加“提交中”的按鈕狀態，以防止網速慢用户狂點某一按鈕的情況）；特殊控件的統一等。

也許會有朋友説，上面有些是交互設計師需要做的事，但我一直認為作為一個產品經理考慮周全一些，沒壞處。這些“統一”同樣可以用在驗收階段，要知道，即使一個像素也可以改變整個產品的感覺。

2、原有功能的去留

我一直覺得升級已有產品比開發新產品難一些。這就像栽培植物一樣，新種下一棵果樹無非需要選對了土地，然後刨個坑種下去，然而成長期的去病枝、打頂等各種修剪所消耗的精力往往更多。

改進已有產品常常需要面對一個最棘手的問題：原有功能是去是留？

原功能去掉的話是不是會影響部分用户使用？是否需要通過公告、站內信、界面引導等方式友好地告知用户？怎樣把對用户的傷害降至最低？

原功能留下的話是不是可以優化完善？聽到了什麼用户羣怎樣的聲音？是否要在這次升級中做調整？

這些問題當接到項目的時候，產品經理就應該考慮周全了。特別需要注意的是，如果這個產品之前不是自己設計的，那麼最好找到prd説明文檔細細研究一遍，對把握不準的功能點找到原負責人確認，畢竟樹苗是ta摘的，別把將來最能結果的枝幹給砍了。

3、產品線上下游的對接

昨天有跟朋友聊起淘寶強勢之處，就是產品與產品緊密捏合，線上線下、跨平台跨行業形成了一個盤根錯節、根深蒂固的根基，無可撼動。

所以把握產品線上下游和產品周邊很重要，即使一個看似簡單的新聞展示頁面修改也會牽扯到編輯後台、廣告位管理、幫助中心，甚至是訪問統計、數據需求的變更。

這要求在產品設計開始前，需要把該產品“連根拔起”，仔細梳理相關脈絡，如果產品線夠長，一個清晰的產品線結構圖很有必要。

項目中

1、項目期間來自相關產品線調整的影響

項目期間相關產品線的調整是我最不願意遇到的情況，這就像你在通往目的地的道路上高速行駛，就快要到達終點了，突然一個人告訴你：你走錯路了。

項目裏有一個通用模塊，產品設計到一半，這個通用模塊改了；項目裏有一個流程，產品做到一半，這個流程廢棄了；最要命的是已經立項開發了，你不得不硬着頭皮跟程序員説：“因為一些不可抗拒原因，這個需求咱不做了。”

對於一個耗時較長的項目來説，這種情況難以避免，事出原因私自總結有三：

a、嚴重體驗性問題：例如某個流程遭到大量用户的不滿，為防止用户流失，不得不做臨時調整，而倒黴的是，你也在用這個流程。

b、相關項目的影響：包括並行項目和新項目。例如你的同事在設計另一個產品，你們的產品相互牽扯較多，所以需求分析時做過很多溝通，但有一天，同事告訴你，ta的一個需求做臨時調整了會影響到你，怎麼辦？

c、老闆的突然決定：不舉例。

最終的解決方法不外乎三種：立即調整、延期調整、不調整。個人的處理原則一般是對a種情況進行立即調整，對b、c情況討論並選擇性延期。

為什麼這麼做呢？a情況是必須要改的，時間早晚問題，長痛不如短痛，b、c兩種情況必須坐下來細細討論。需瞭解這個需求為什麼要改？是長期對策還是臨時決定？能否延期，記錄需求等下一版本再開發？如果b、c情況提出來的需求沒過兩天又有改變，那與你配合的前端和程序員也太沒有安全感了。

這個時代能耐心閲讀完xx枚漢字的人越來越少，較大型項目的產品工作心得[下]未完待續，歡迎交流……

2、需求變更

承上，需求變更是每個程序員、產品經理、設計師等都會遇到的情況。產品經理不是神，項目組也不可能是開了無敵狀態抵擋任何外界的影響。

當遇到不得不變更需求的時候，產品經理應該怎樣處理呢？下面是個人的四條建議：

a、積極處理。往往，當一個設計愈是趨於完成，人們愈是傾向於局部調整，而不是做重新設計。當一個需求因為眾所周知的原因不得不調整的時候，作為產品經理需要做的第一件事便是積極面對問題，積極處理。

項目開發往往是一個緊張的過程，每半天甚至每幾個小時就有若干個功能點開發完成，當一個需求變更傳達出現“延遲”，這個變更對項目的正常進程的“破壞力”就會更大一些。

b、保持溝通。“説話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時候，溝通是個自己掙扎的過程”這話沒錯。需求變更直接會影響到下一道工序，產品經理需要將需求變更的細節和原因傳達給相關人員，包括視覺、前端、程序、測試等。

這是很多產品經理表示非常痛苦的過程，因為可能會遭到數落和冷眼，日本有一個禮儀原則是“不要給別人添麻煩”，但是在項目中，這不可避免。

個人認為所有溝通的障礙都源於思想的不統一，如果讓大家覺得這個需求修改是在浪費時間，那麼溝通上的不暢快在所難免。項目不是這樣算的，需求既然更改一定有所目的，產品經理需要將這個原因講明白，不做修改或節約溝通時間導致的返工，後果往往更嚴重。