第一篇：大型軟體開發心得
最近做的一個專案從需求分析到上線綿延了四個月之久，這也是目前接手過功能點最繁複，產品線對接最多的一個專案。從中得到的一些關於設計較大型產品的心得，拿出來跟大家分享。
立項前
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 儘可能多的考慮異常和錯誤的情況。
寫出一個功能並沒有什麼，但是要把這個功能寫的非常的完善那就很難了，因為你需要考慮各種各樣的情況，正常的、非正常的。所以，寫完一個類的定義應該是，完成編碼和穩定，並通過原定的測試。本文摘自惠集網