第一篇：大型軟件開發心得
最近做的一個項目從需求分析到上線綿延了四個月之久，這也是目前接手過功能點最繁複，產品線對接最多的一個項目。從中得到的一些關於設計較大型產品的心得，拿出來跟大家分享。
立項前
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、保持溝通。“説話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時候，溝通是個自己掙扎的過程”這話沒錯。需求變更直接會影響到下一道工序，產品經理需要將需求變更的細節和原因傳達給相關人員，包括視覺、前端、程序、測試等。
這是很多產品經理表示非常痛苦的過程，因為可能會遭到數落和冷眼，日本有一個禮儀原則是“不要給別人添麻煩”，但是在項目中，這不可避免。
個人認為所有溝通的障礙都源於思想的不統一，如果讓大家覺得這個需求修改是在浪費時間，那麼溝通上的不暢快在所難免。項目不是這樣算的，需求既然更改一定有所目的，產品經理需要將這個原因講明白，不做修改或節約溝通時間導致的返工，後果往往更嚴重。
第二篇：軟件開發心得體會
受某文化公司委託，開發一款用於視頻和圖像處理的軟件，開發難度高，高到從未搞過，開發週期長，長到是我以前項目監控最長開發週期的兩倍，開發成本之底，讓我覺得程序員成了高級打字員。首先是需求分析書、產品規格説明書、設計説明書、代碼規範説明書、測試計劃，光文稿就不知道熬了多久才做完。
緊接着，遇到一系列問題，首先是語言選擇，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、管理、產品、流程等），非常情緒化。有些女程序員還會吵，會哭，這時項目經理只能放下手中的活，下去給她買點零食來哄哄，“莫哭，這裏有你最愛吃的貓哆哩。”一邊擦着鼻涕、眼淚，一邊嘴裏塞滿東西，鼓鼓啷啷“這是酸角口味的，那個西番蓮口味的才叫好吃..."
這些通常不太容易在面試時表現出來，在試用期時，要觀察。
第三篇：軟件開發心得總結
有感於網盤開發過程
有感於網盤開發過程 ............................ 1
一、軟件開發個人體會： ...................... 2
二、做軟件開發我覺得要明白： ........................ 2
三、在開發中遇到問題應該怎麼去解決？ ................ 2
四、怎麼樣才能提高自身的能力？..................... 2
五、怎麼樣才能做好軟件開發？ ........................ 2
六、文檔的重要性 ........................... 3
七、我的收穫 ............................ 3
八、網盤項目開發的最大體會 ..................... 4
九、軟件測試（單體測試和連接測試） .................... 4
常熟理工學院sig小組3/28/2014
一、軟件開發個人體會：
1. 軟件領域中的知識在於積累。
2. 做軟件開發，就類似算數學題和世界盃足球賽一樣：重在結果，而不在乎過程。
3. 軟件服務於人類，軟件是在解決一些生活中的問題和錯誤，問題決定解決方案。
二、做軟件開發我覺得要明白：
1. 職業的樂趣：
(a) 用自己的智慧去創建新事物的快樂
(b) 開發對別人有用的東西
(c) 不斷學習來充實自己
2. 職業的苦惱:
(a) 總是追求完美
(b) 所有要實現的功能由他人而定
(c) 概念設計計是有趣的，但找bug總是很苦惱的
三、在開發中遇到問題應該怎麼去解決？
1.
2.
3.
4. 不明白就多問，不要自已一直去琢磨。 一個問題如果30分鐘還沒有解決就應該考慮是不是問問別人。 一個問題在沒有用過3種以上的方法解決過就不要去問別人。 解決問題思路是關鍵：
相信問題總歸有解決的辦法，就算連技術上都沒法實現的問題，相信通過良好的溝通終究也會有解決的方法。
5. 解決問題的前提是：理解別人的意思，理解別人的需求，多溝通，及時給客户反饋信息。
四、怎麼樣才能提高自身的能力？
1. 程序員怎麼樣進步最快？ － 理論結合實踐
2. 不要怕出錯，不怕遇到錯誤，有錯誤就有挑戰，這樣才可以進步，但不要讓同一個石頭
把你絆倒2次。
五、怎麼樣才能做好軟件開發？
1. 首先要明白解決的問題是什麼，理解問題，其次再決定怎麼解決這個問題
2. 碰到很複雜的問題，我們就簡單想，把問題簡單化，細化到能夠實現為止
3. 出了問題，我們要先分析問題，然後知道引起問題的原因，最後並想出問題的解決辦法
4. 我們應該從2個方面去把握一個項目：從業務角度和項目的關鍵問題上去把握一個項目
(a) 從不同的系統場景
(b) 從不同的用户角色（充當什麼角色）
(c) 從不同的系統使用角度（擁有那些權限）
5. 其實我覺得開發人員説實在應該要比使用系統的人更瞭解系統需求，只有真正徹底的了
解了項目的業務需求，我們才能做真的做好這個項目
六、文檔的重要性
記得我當初剛開發項目的時候都是寫個大致的需求説明書，做一個e-r圖，畫幾個大致的數據流程圖，然後建立數據字典和表結構關係。 再接着搭建一個開發環境，配置幾台服務器，劃分一下模塊，分工，我們就可以coding了，一直到項目結束了，也沒有完整的設計文檔，更沒有完整的測試文檔，雖然這樣的確是很快的完成了coding工作，感覺上好像節省了好多成本和開發時間，但後期的維護和bug 就是經常出現的事。
小項目沒有文檔關係不大，但如果遇到一個大項目的時候，那這樣的開發方式就很有問題很危險的。
大項目沒有文檔： 首先維護就很麻煩，也很亂，寫的代碼，過幾天都不知道它是完成什麼功能的了，其次系統的穩定性和可靠性也讓人懷疑，擴展性就不用説了。
七、我的收穫
a.程序員大多都不喜歡寫文檔,我們以前也是特討厭,記得以前都是系統開發完了，為了應付項目驗收，就匆匆忙忙的一組人在那裏補文檔。在我們的思想裏,所謂的文檔就是一些廢話,一句話硬是用十句話來代替的無聊透頂。
b.代碼風格要規範
以前做項目，我們都是不怎麼去注意代碼風格和寫代碼的規範，都是稍微想一下就直接開始寫代碼了。註釋也很少用，總感覺我們自己寫的代碼，我們怎麼會不知道它做了些什麼事呢 ？總覺得我們自己寫的代碼我們怎麼會不知道它是用來做什麼的呢。一直都不相信這是個事實，但事實上，項目驗收後，系統剛開始使用的人少，也就不會出現潛在的錯誤，隨着時間的增加，久而久之，當大量用户併發訪問的時候，系統的bug 就暴漏出來了，那時你再用熟悉的eclipse打開整個項目的源碼時，再去看自己寫的代碼的時候，真的發現，我們定義的這個變量名是什麼意思啊 ？ 我們的這個flag 是用來判斷什麼的啊 ？我們的if（）中條件不知道是判斷什麼？ function （） 也忘記是什麼功能了？ 想想好可怕啊。 難道真的都忘記了嗎 ？回答是肯定的： 真的忘了。
c.心得體會:
通過做該網盤項目，在這2年的鍛鍊中，我們才真的體會到，良好的文檔是正規研發流程中非常重要的環節,一個好的程序是先寫好設計文檔再進行編程的，在設計文檔的指導下，才能寫出安全的代碼。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設計好的路線走，而是想到哪寫到哪。小功能還好説，要是大功能，就容易混亂.
剛開始我們還很不習慣這一系列的編程風格，很多的規範，尤其是命名，方法和註釋，都有這着很多限制，讓我們覺得真羅唆，寫個程序完成功能不就可以了嗎，明明1小時做完的事情非得讓人用3、4個小時去做，我們現在真的明白這樣做的好處了，我們已經習慣這樣的編程風格了，這也養成了我們的一個編程習慣了，深有體會啊。
最忙的時候就是我們成長和收穫最多的時候。
八、網盤項目開發的最大體會
我們覺得項目開發的開始時候，應該由項目負責人很好的對項目是什麼項目，具體大概做什麼事情，是誰提出來的，目的是解決什麼問題，以及裏面用到的很多專有名詞做個細緻的説明，而不是從一開始就分幾本式樣書，給個靜態html 的demo看看，然後搭建好開發環境就按照式樣設計書來開發。
九、軟件測試（單體測試和連接測試）
我們首先認為，編寫程序的時候不要想出了問題再解決，而是要想如何不會出現問題，要根據經驗來預測可能出現的問題，然後避免出現。
測試，説的直接點就是給軟件找錯誤。
很多人認為發現錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上我們不這麼認為。
我們覺得對開發人員來説，我們要把測試出來的bug都應該做個分析，知道錯的原因之後，我們就應該在下個項目中防止類似的錯誤發生，而真正來提高我們開發的效率。
第四篇：軟件開發實習心得
軟件開發實習心得
一直以來期望從事自己喜歡的事業的我，對軟件開發有者及大的興趣，可由説種種原因使我從事工作以來走了好幾年彎路，心中的夢想遲遲不能得以實現，可程序員的夢想從來沒有從我的心中抹去，但這扇大門好像並沒有向我敞開，今天，貴公司給了我敲開這扇大門的機會，讓我真實體驗了程序員的誕生過程。早就聽説，程序員的前幾個月是最苦的，可從來沒有感受到，海馬實習基地讓我提前感受到了剛剛進入軟件行業的壓力和困惑，再也沒有在自己家裏隨便寫段小程序後的那種“自豪”感了。要面對每天必須面對的問題，再也不可能以“逃避”而了之了。也讓我感覺到做為一個程序員所應該具備的基本素質在這不到一個月的實習過程中也讓我深深體會到了作為一個合格的程序員應該具備的基本素質。
團隊精神和協作能力是程序員應該具備的基本素質，最近的工作中讓我深深休會到了這一點，由於小組成員配合不好，使本來很方便的cvs給自己的工作帶來的及大的麻煩，一不小心自己寫的的東西就會被小組別的成員在上傳文件的時候給覆蓋掉，一整天的工作可能就這樣被反工，我們小組這次就是因為協作不好，導致各模塊之間不法連接，給工作帶來了及大的麻煩，消耗了大量的勞動力還沒有提高工作效率。這使我深深的體會到：一個成功商業性軟件的開發必須有一個有強大凝聚力的團隊，個人的力量是有限的，團隊精神和良好的協作會使我們做出優秀的軟件。
良好的文檔是正規研發流程中非常重要的環節，作為代碼程序員，30％的工作時間寫技術文檔是很正常的，缺乏文檔，一個軟件系統就缺乏生命力，在未來的查錯，升級以及模塊的複用時就都會遇到極大的麻煩。這次的這個小小的項目，就因為文檔上的一點點理解錯誤讓我們花了很大的工夫去改代碼，改頁面。很慶幸的是，這是一個小項目，要是大項目，這種問題可能就會導致大量的代碼修改，可見文檔在一個項目中起者巨大的做用。
此外，良好的代碼編寫習慣，不但有助於代碼的移植和糾錯，也有助於不同技術人員之間的協作。作為一個程序員，對需求的理解能力也是很重要的，只有真正理解了一個模塊的作用，才會寫出高效率的代碼，才能使整個軟件項目作出來更加優秀，具備更好的安全性和穩定性，我在寫代碼的過程中就遇到了需求理解上的問題，使得寫出來的代碼功能不全，幸好不是給客户發現在，要不，這個軟件的商業價值可能就會打折扣了。單元測試對於一個程序員來説是不可不做的一項工作，不做好測試就會給後期的集成工作帶來麻煩，往往為了一個小問題會讓我們查找好多模塊，給後期工作帶來很大麻煩。
這一段時間的工作也讓我明白了一點：一個優秀的程序員必須不斷的學習，隨時總結，找到自己的不足，這樣逐步提高，才能讓自己很快的成長起來。建站俠客 發表於 2014-4-28 10:19
對軟件開發的一點心得體會
一、前期規劃：
我理解的前期規劃是：在市場人員們彙總一個需求提交給產品專家帶領的產品經理團隊，然後經過這個團隊根據公司具體情況再次分析和規劃出一個最終需求文檔。
這個需求文檔應當首先提交給技術研發部門的負責人以及核心開發人員。由開發團隊對其進行技術和風險分析。如果對此需求統一有異議的地方，需要返回給產品團隊，重新修正需求。反覆如此，直至需求完善準確，細緻，清晰。
前期規劃就像高樓的地基，如果馬馬虎虎，就算是一塊磚塊沒擺好都可能導致整個高樓建設的失敗。在規劃中我認為，交流永遠是需要雙方積極主動，能認真聽取每個人的建議。前期工作思維不慎重，不細緻，不認真，不夠完善，將產生連鎖效應直接導致整個工程和項目的失敗。
這種失敗可能表現為：第一種，軟件按需求實現但是功能根本不能滿足用户需要。第二種，功能都有了，軟件沒有達到可用性、易用性。
對於第一種，當然是因為前期規劃疏漏了某些細小功能，沒能把需求文檔做完善。應該是規劃工作做的還不夠認真和細緻。
對於第二種情況，我認為更多是在產品設計規劃方面經驗還不夠成熟。這種問題應該是很難避免的。因為每種新產品對產品團隊來説都很陌生。即使以前做過類似的東西，也難免面面俱到。這隻能通過不斷努力和認真的態度來彌補。
前期規劃的交流涉及了市場、產品和技術研發等多個團隊之間。需要的不僅是團隊內部的交流，更多需要協調好團隊之間的交流。可能有時候需要公司高層和中層參與協調。
目前，很多開發人員深感項目的需求文檔寫的都很單薄。大家可以想一想，如果沒有好的開始，怎麼會有好的結束呢？需求文檔單薄，不夠細緻，由誰來繼續完善呢？難道讓程序員們自己去完善。我想程序員也可能沒有這種能力。對於程序員能把代碼寫的很健壯很穩定就已經是很不容易的事情了。
二、概要設計：
我理解的概要設計步驟：（以項目為中心的開發流程）
1〉項目經理仔細閲讀項目需求文檔。
2〉項目經理召集項目開發成員，開項目啟動會議。具體商議項目的開發任務和責任分配。
3〉核心開發人員開發確定，以及各模塊開發人員確定。
4〉由系統分析員和核心開發人員仔細閲讀需求文檔，對系統整個架構分析和做技術規劃。
5〉系統分析員整理和書寫最終的系統架構和概要設計文檔。
6〉系統分析員在文檔提交日，提交給項目經理。項目經理確認文檔並審批。
7〉項目經理召集項目開發成員，開一個概要設計以及系統架構確定的會議。向每個成員分發文檔，並討論確定最終概要設計文檔。
8〉開始詳細設計文檔的工作
三、詳細設計：
1〉項目經理組織成立各個模塊的開發小組，並確定開發小組組長（程序經理）。
2〉各開發組長書寫各自模塊的詳細設計文檔，開發成員需要協助，配合。
3〉在指定提交日，開發組長提交文檔給系統分析員。由系統分析員審批。
4〉系統分析員組織召開一個詳細設計文檔確認的會議。
5〉然後開發組長分發各自模塊的詳細設計文檔給程序員，程序員在指定時間內完成。
6〉程序員做內部測試。開發組長協調並配合。
7〉確認無bug提交給開發組組長。
8〉所有模塊整合工作，由整個開發組成員參與完成。由所有開發組長和系統分析員負責主要部分工作。程序員協助和配合。
9〉對整合後工程做詳細測試。
10〉確認測試通過後，開發組長根據開發成員表現以及提交成果填寫績效考核表。然後提交給項目經理。
11〉項目經理會召開項目總結會，同時向優秀成員頒獎。同時鼓勵所有成員繼續努力。對不能按時完成導致項目能按時提交，以及對導致失敗的
關鍵人員給與懲罰處理。
當然，以上只是一個簡單的開發流程，一定是有很多不足的地方。希望能起到拋磚引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，關鍵還是在人本身了。沒有一個流程和制度，一個團隊也必將是一盤散沙。正所謂“無規矩無以成方圓”。這句話説得很有道理。
四、具體編碼：
開發幾個項目之後，對編寫程序有了更進一步的瞭解。
好的程序應該具有: 易讀性，易擴展性，容錯性。
易讀性: 所有變量和函數以及類名用簡單易懂易記憶的命名方式。所有類和函數甚至變量都有關鍵的註釋説明。這點很重要，也是最基礎的。如果代碼書寫不夠美觀和易懂，我想自己以後也不想再看。就更別談功能的擴展和新版本開發了。
易擴展性: 整體系統架構邏輯簡單清晰。模塊與模塊之間儘量做到互不影響，也就是儘可能的獨立。這部分工作主要體現在前期設計工作中，需要掌握好的設計經驗和方法才能夠做得比較好。
容錯性: 對數據流和指針以及數組都做數據有效性檢查；對第三方接口的調用失敗的容錯性。對所有代碼都做調用失敗後的錯誤處理。以及在大的工程中加入trace文件輸出，把關鍵的數據流和關鍵處理部分的操作信息輸出。以便對工程異常情況產生條件的定位，及時解決問題。
我覺得程序員能在這三方面做得很好就算一個優秀的programmer了。
五、調試、跟蹤與測試：
1 測試需要注意的：
對每個模塊的接口做測試，數據邊界的檢查。在對整個模塊做測試。
主要測試穩定性，效率以及功能是否正常。
確認單個模塊完全正常後，再加入工程。
在系統架構設計的時候，可能會引入原型參考。要對原型做完成測試後，確認沒有問題後，才可使用。
2 可以採用vc自帶trace或者將信息輸出為文本文件的方式跟蹤程序並輸出關鍵信息，以便定位程序異常的原因。
3 對於通信模塊的測試，特別注意服務端和客户端的數據流。可以針對性的寫一個客户端或服務端的測試程序，檢驗通訊過程是否正常。
4 在用vc做開發中，一定先要讓debug版本正常運行，保證沒有任何異常，內存泄漏和assert等調試警告信息。如果用到其他lib,一定要保證lib本身不存在問題。
這裏只是提到一些自己容易忽略的東西，希望能對大家有所幫助，歡迎指正！謝謝。
第五篇：軟件開發核心心得
軟件開發核心心得
在一個有效的組織中，必定擁有傑出的一線人才。軟件設計也是一樣的，一線人才的素質決定了軟件的質量。從敏捷的觀點來看，代碼是檢驗軟件過程是否有效的最終標準。目前為止，以及在短時間的未來，我們都不太可能完全脱離代碼進行軟件設計。所以，軟件過程中的任何一個活動都是為了能夠產出優秀的代碼。所以，代碼才是核心。
1. 代碼是軟件開發的基礎
編碼是軟件開發過程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領域的專家都需要花費大量的時間來進行基本技藝的鍛鍊，木匠需要花費大量的時間來鍛鍊他們對各種工具的掌握，廚師則需要練習刀工和火候。程序員也是一樣的，對我們來説，語言的各種特性必須要了然於胸。而對軟件的管理也需要從代碼做起。
從2014年到現在，國內興起了一股軟件工程熱，需求管理、配置管理、甚至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 儘可能多的考慮異常和錯誤的情況。
寫出一個功能並沒有什麼，但是要把這個功能寫的非常的完善那就很難了，因為你需要考慮各種各樣的情況，正常的、非正常的。所以，寫完一個類的定義應該是，完成編碼和穩定，並通過原定的測試。本文摘自惠集網
蒙田範文網