第一篇：軟件開發實習心得

軟件開發實習心得

一直以來期望從事自己喜歡的事業的我，對軟件開發有者及大的興趣，可由說種種原因使我從事工作以來走了好幾年彎路，心中的夢想遲遲不能得以實現，可程序員的夢想從來沒有從我的心中抹去，但這扇大門好像并沒有向我敞開，今天，貴公司給了我敲開這扇大門的機會，讓我真實體驗了程序員的誕生過程。早就聽說，程序員的前幾個月是最苦的，可從來沒有感受到，海馬實習基地讓我提前感受到了剛剛進入軟件行業的壓力和困惑，再也沒有在自己家里隨便寫段小程序后的那種“自豪”感了。要面對每天必須面對的問題，再也不可能以“逃避”而了之了。也讓我感覺到做為一個程序員所應該具備的基本素質在這不到一個月的實習過程中也讓我深深體會到了作為一個合格的程序員應該具備的基本素質。

團隊精神和協作能力是程序員應該具備的基本素質，最近的工作中讓我深深休會到了這一點，由于小組成員配合不好，使本來很方便的cvs給自己的工作帶來的及大的麻煩，一不小心自己寫的的東西就會被小組別的成員在上傳文件的時候給覆蓋掉，一整天的工作可能就這樣被反工，我們小組這次就是因為協作不好，導致各模塊之間不法連接，給工作帶來了及大的麻煩，消耗了大量的勞動力還沒有提高工作效率。這使我深深的體會到：一個成功商業性軟件的開發必須有一個有強大凝聚力的團隊，個人的力量是有限的，團隊精神和良好的協作會使我們做出優秀的軟件。

良好的文檔是正規研發流程中非常重要的環節，作為代碼程序員，30％的工作時間寫技術文檔是很正常的，缺乏文檔，一個軟件系統就缺乏生命力，在未來的查錯，升級以及模塊的復用時就都會遇到極大的麻煩。這次的這個小小的項目，就因為文檔上的一點點理解錯誤讓我們花了很大的工夫去改代碼，改頁面。很慶幸的是，這是一個小項目，要是大項目，這種問題可能就會導致大量的代碼修改，可見文檔在一個項目中起者巨大的做用。

此外，良好的代碼編寫習慣，不但有助于代碼的移植和糾錯，也有助于不同技術人員之間的協作。作為一個程序員，對需求的理解能力也是很重要的，只有真正理解了一個模塊的作用，才會寫出高效率的代碼，才能使整個軟件項目作出來更加優秀，具備更好的安全性和穩定性，我在寫代碼的過程中就遇到了需求理解上的問題，使得寫出來的代碼功能不全，幸好不是給客戶發現在，要不，這個軟件的商業價值可能就會打折扣了。單元測試對于一個程序員來說是不可不做的一項工作，不做好測試就會給后期的集成工作帶來麻煩，往往為了一個小問題會讓我們查找好多模塊，給后期工作帶來很大麻煩。

這一段時間的工作也讓我明白了一點：一個優秀的程序員必須不斷的學習，隨時總結，找到自己的不足，這樣逐步提高，才能讓自己很快的成長起來。建站俠客 發表于 2008-4-28 10:19

對軟件開發的一點心得體會

一、前期規劃：

我理解的前期規劃是：在市場人員們匯總一個需求提交給產品專家帶領的產品經理團隊，然后經過這個團隊根據公司具體情況再次分析和規劃出一個最終需求文檔。

這個需求文檔應當首先提交給技術研發部門的負責人以及核心開發人員。由開發團隊對其進行技術和風險分析。如果對此需求統一有異議的地方，需要返回給產品團隊，重新修正需求。反復如此，直至需求完善準確，細致，清晰。

前期規劃就像高樓的地基，如果馬馬虎虎，就算是一塊磚塊沒擺好都可能導致整個高樓建設的失敗。在規劃中我認為，交流永遠是需要雙方積極主動，能認真聽取每個人的建議。前期工作思維不慎重，不細致，不認真，不夠完善，將產生連鎖效應直接導致整個工程和項目的失敗。

這種失敗可能表現為：第一種，軟件按需求實現但是功能根本不能滿足用戶需要。第二種，功能都有了，軟件沒有達到可用性、易用性。

對于第一種，當然是因為前期規劃疏漏了某些細小功能，沒能把需求文檔做完善。應該是規劃工作做的還不夠認真和細致。

對于第二種情況，我認為更多是在產品設計規劃方面經驗還不夠成熟。這種問題應該是很難避免的。因為每種新產品對產品團隊來說都很陌生。即使以前做過類似的東西，也難免面面俱到。這只能通過不斷努力和認真的態度來彌補。

前期規劃的交流涉及了市場、產品和技術研發等多個團隊之間。需要的不僅是團隊內部的交流，更多需要協調好團隊之間的交流?？赡苡袝r候需要公司高層和中層參與協調。

目前，很多開發人員深感項目的需求文檔寫的都很單薄。大家可以想一想，如果沒有好的開始，怎么會有好的結束呢？需求文檔單薄，不夠細致，由誰來繼續完善呢？難道讓程序員們自己去完善。我想程序員也可能沒有這種能力。對于程序員能把代碼寫的很健壯很穩定就已經是很不容易的事情了。

二、概要設計：

我理解的概要設計步驟：（以項目為中心的開發流程）

1〉項目經理仔細閱讀項目需求文檔。

2〉項目經理召集項目開發成員，開項目啟動會議。具體商議項目的開發任務和責任分配。

3〉核心開發人員開發確定，以及各模塊開發人員確定。

4〉由系統分析員和核心開發人員仔細閱讀需求文檔，對系統整個架構分析和做技術規劃。

5〉系統分析員整理和書寫最終的系統架構和概要設計文檔。

6〉系統分析員在文檔提交日，提交給項目經理。項目經理確認文檔并審批。

7〉項目經理召集項目開發成員，開一個概要設計以及系統架構確定的會議。向每個成員分發文檔，并討論確定最終概要設計文檔。

8〉開始詳細設計文檔的工作

三、詳細設計：

1〉項目經理組織成立各個模塊的開發小組，并確定開發小組組長（程序經理）。

2〉各開發組長書寫各自模塊的詳細設計文檔，開發成員需要協助，配合。

3〉在指定提交日，開發組長提交文檔給系統分析員。由系統分析員審批。

4〉系統分析員組織召開一個詳細設計文檔確認的會議。

5〉然后開發組長分發各自模塊的詳細設計文檔給程序員，程序員在指定時間內完成。

6〉程序員做內部測試。開發組長協調并配合。

7〉確認無bug提交給開發組組長。

8〉所有模塊整合工作，由整個開發組成員參與完成。由所有開發組長和系統分析員負責主要部分工作。程序員協助和配合。

9〉對整合后工程做詳細測試。

10〉確認測試通過后，開發組長根據開發成員表現以及提交成果填寫績效考核表。然后提交給項目經理。

11〉項目經理會召開項目總結會，同時向優秀成員頒獎。同時鼓勵所有成員繼續努力。對不能按時完成導致項目能按時提交，以及對導致失敗的關鍵人員給與懲罰處理。

當然，以上只是一個簡單的開發流程，一定是有很多不足的地方。希望能起到拋磚引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，關鍵還是在人本身了。沒有一個流程和制度，一個團隊也必將是一盤散沙。正所謂“無規矩無以成方圓”。這句話說得很有道理。

四、具體編碼：

開發幾個項目之后，對編寫程序有了更進一步的了解。

好的程序應該具有: 易讀性，易擴展性，容錯性。

易讀性: 所有變量和函數以及類名用簡單易懂易記憶的命名方式。所有類和函數甚至變量都有關鍵的注釋說明。這點很重要，也是最基礎的。如果代碼書寫不夠美觀和易懂，我想自己以后也不想再看。就更別談功能的擴展和新版本開發了。

易擴展性: 整體系統架構邏輯簡單清晰。模塊與模塊之間盡量做到互不影響，也就是盡可能的獨立。這部分工作主要體現在前期設計工作中，需要掌握好的設計經驗和方法才能夠做得比較好。

容錯性: 對數據流和指針以及數組都做數據有效性檢查；對第三方接口的調用失敗的容錯性。對所有代碼都做調用失敗后的錯誤處理。以及在大的工程中加入trace文件輸出，把關鍵的數據流和關鍵處理部分的操作信息輸出。以便對工程異常情況產生條件的定位，及時解決問題。

我覺得程序員能在這三方面做得很好就算一個優秀的programmer了。

五、調試、跟蹤與測試：測試需要注意的：

對每個模塊的接口做測試，數據邊界的檢查。在對整個模塊做測試。

主要測試穩定性，效率以及功能是否正常。

確認單個模塊完全正常后，再加入工程。

在系統架構設計的時候，可能會引入原型參考。要對原型做完成測試后，確認沒有問題后，才可使用?？梢圆捎肰C自帶Trace或者將信息輸出為文本文件的方式跟蹤程序并輸出關鍵信息，以便定位程序異常的原因。對于通信模塊的測試，特別注意服務端和客戶端的數據流?？梢葬槍π缘膶懸粋€客戶端或服務端的測試程序，檢驗通訊過程是否正常。在用VC做開發中，一定先要讓Debug版本正常運行，保證沒有任何異常，內存泄漏和Assert等調試警告信息。如果用到其他Lib,一定要保證Lib本身不存在問題。

這里只是提到一些自己容易忽略的東西，希望能對大家有所幫助，歡迎指正！謝謝。

第二篇：軟件開發實習心得

軟件開發實習心得

參加軟件開發實習的同學，你們從中收獲了哪些實習心得?不妨分享一下吧!以下是軟件開發實習心得，歡迎閱覽!

軟件開發實習心得1

不知不覺，在XX實習的日子快過去半個月了，記得剛來XX的頭幾天，感覺非常不適應。首先是環境：這里吃的東西很貴，而且這里的物價很高。其次是XX人：XX人辦事的效率很高，這就是鐵人的精神吧。

對于以上種種，待了3，4天基本就適應了，難怪一些長輩老是說：習慣了，就好了。

來的第一天，我們聽了付X萍老師講了一節課，可以說完全不知所云，但還是可以聽到一些東西的，譬如：工作環境的適應，人與人之間的交際，處理各種事情的能力，其中最重要的就是養成良好的工作習慣。有良好的工作習慣，才會被上司，老板和同事認可，將來也會比同輩有著更快更多的升職機會，而且一個良好的工作習慣，無論你從事哪個行業，都是受用終生的。然后，就是認識我們的董亮老師了，一個可親可愛的老師，傳說中他們一個月會賺十幾萬呢!天文數字，望塵莫及啊。

在隨后的一段時間里，我們被分為了八組，每組六七個人，有一個組長帶領。我們組織作一個項目論壇，在第二，第三個禮拜感覺沒有剛來時那么拘謹了，我更明顯感覺到自我計劃，制定目標的重要性了。在我們犯錯誤的時候，老師會懲罰我們，陳發的方式很另類唱歌或者講笑話，不算是體罰大事可以達到對我們的約束。然而，歇息期間有組織我們做游戲，看似很簡單的游戲其實是想培養我們合作意識。

在實習的過程中，我深刻的體會到了三點：第一，項目是以迎合客戶和使用者為目的的，不可能像教師那樣為我們制定一套教學計劃。想要知道些什么，渴望懂得些什么，全要靠你自己想學，你自己不問，沒人會主動來告訴你。第二，紙上得來終覺淺，絕知此事要躬行!在短暫的實習過程中，讓我深深的感覺到自己在實際運用中的專業知識的匱乏，在行業中的經驗真的很重要。

第三，能更早的接觸你所在行業的真實情況。不出來自己轉一圈，根本不知道自己學的一些專業知識，哪些是十分重要，十分實用的。就比如說英語。以前聽老師說過，聽朋友也說過，將來工作了，英語相當有用，外企就更不用說了。當時沒什么感覺，但當我頻繁的看到一打打英文資料手冊、幫助文檔時，我已經切身地，的的確確地感受到英語的重要性。

這次實訓讓我學到的東西太多，使我受益非淺，它讓我知道了工作上的辛

苦，讓我知道工作并不像在學校里學習一樣輕松。不過，雖然辛苦了點，但能讓我學到不同的東西、很充實，我心里還是高興的。人非生而知之，要學得知識，一靠學習，二靠實踐。沒有實踐，學習就是無源之水，無本之木。以上就是我在成都的進行實訓的心得和感受。不到半年的時間就將步入社會的我們，面臨是繼續深造，還是就業的壓力，我想我們更應該把握住最后的一段時間，充實、完善自我，爭取做一名出色的大學生!對于這次實習，我很珍惜也很懷念。

軟件開發實習心得2

本人自XX年9月份參加工作至今, 六個月的實習時間已經結束。在這段時間里, 在領導和同事們的悉心關懷和指導下, 通過自己的不懈努力, 在各方面都取得了進步。

實踐讓我的技能不斷增長, 工作能力不斷加強。剛開始工作的時候, 發現自己以前在學校學習的知識很死, 知識

面很窄, 以前做的練習項目的實用性也不是很好。在開始的幾周公司給我們實習員工培訓了xxxx平臺的使用, 通過這次培訓使我認識到xxxx平臺的優勢, 可以大大提高軟件開發效率

隨后我就加入到xxxxx稅源控管系統項目的開發中, 成為開發小組中的一員。在項目開發過程中一邊是同事們的悉心指導, 一邊是自己反復琢磨與理解, 幾個月下來大大提高了自己業務和技術兩方面的技能, 已經能夠比較熟練的掌握基本的工作方法和一些技巧, 而且能夠獨立完成一些模塊的開發。

通過實踐, 我解決實際問題的能力得到了很好的鍛煉。工作中也遇到了很多的以前沒有遇到過的新技術, 面對技術難題我總是直接面對, 沒有逃避, 也因此自學了好多新的技術, 大大提高了自己的自學能力, 也加深了對自己工作要負責的信念。在項目開發過程中也遇到了一些自己確實無法解決的困難, 在經理和同事的幫助下也順利的解決了，在此表示感謝。

在開發團隊中, 加強了自己的團結精神和集體感, 對工作認真負責, 對團隊認真負責。通過這個項目不僅學習到了很多技術也了解了整個項目的大體流程, 從需求分析、數據庫設計、詳細設計、代碼編寫、測試、項目維護等方面, 使自己不僅從一個代碼編寫人員的角度還從一個整體的角度來看整個項目開發, 加深了軟件開發概念的理解。

不斷學習使我對工作有了更進一步的認識和了解。不懂就學、就問, 是一切進步取得的前提和基礎。因為有大學專業課的底子和參加過專門的java培訓使我在工作過程中遇到的技術知識能更快的理解和掌握。工作中時常遇到新的問題, 就需要查閱相關資料, 請教同事和經理, 一個問題一個問題的解決, 一個困難一個困難的克服, 不僅將原有知識溫習鞏固, 產生新的理解, 而且學到很多新知識, 有了許多新的認識。但某些認識都還是膚淺的, 還需要我在實踐當

中去不斷深入地理解。

現場開發與維護使我不僅從一個開發人員的角度而且從客戶的角度去思考問題。在項目的開發后期, 也就是項目即將上線的階段我與其他幾位同事被派往現場去開發與維護項目。以前的開發都是根據需求分析來進行, 功能要求一般在分析里面都寫的很清楚, 但是在現場開發直接面對客戶, 客戶提出的需求一開始只是一個大體的功能描述, 如何將這個只是語言描述的功能轉化為技術實現需要很強的抽象能力和對業務的深入理解, 這個過程大大鍛煉了自己的綜合能力。在第一時間接觸客戶的需求, 從客戶的角度思考問題, 只有更了解客戶需求才能更合理的設計軟件的結構, 功能。

軟件開發實習心得3

短短兩周的很快就過去了，在xx的實習馬上就要過去了。雖然只有短短的兩周，但我學會了很多知識，熟悉了軟件開發的流程，也很好的增強了自己 的動手能力。

我是一名即將大四的學生，縱觀現在的就業形勢，國家高校的擴招，世界金融危機的橫掃，大學生應該有一種居安思危的緊迫感，特別是對已經度過兩年大學的我來說，畢業并不是一個遙遠的詞匯。寶劍鋒從磨礪出，梅花香自苦寒來，缺少了平時的鍛煉，沒有厚積當然不能有薄發。首先我得有思想上的緊迫感，在學校學習的都是理論知識，實踐經驗則是少之又少。綜合能力強的人才才是這個社會需要的，成長成為社會需要的人才是我的個人奮斗目標。有了強大的精神動力，有了堅如磐石的毅力，相信成功并不遙遠。

首先，我的自我能力得到了加強。在實習的前幾天主要進行的是與JAVA有關知識的學習及預備知識的普及。在這之前由于種種原因我沒有學習過JAVA，所以對于J我幾乎一無所知。但我曾經學習過C++，所以對語言的理解和接受能力還不算太慢，盡管老師講解

速度較快但我還是盡量跟上老師的速度。在這個過程中我學會一種自學方法可以在第一遍時不求甚解，先了解知識框架，之后再在使用的過程中不斷加強對知識的理解，從而較快的學會知識并應用于實踐。

其次我的實際的操作能力得到了加強。知識講解告一段落后我們就進入了緊張而又短暫的項目中。但不得不說剛開始就碰了一鼻子灰代碼書寫總是出錯。由于對原理理解不夠透徹，語言使用缺乏足夠經驗所以進度極慢。在經過多次的討論后我們對項目理解逐漸深入，所以在此投入的過程就比較順利了。在這個過程中我明白了實踐和理論的差距及二者不可分割的關系。

最后是團隊協作能力的提高。在整個過程中團隊協作發揮著不可替代的作用。從在剛拿到項目時對項目進行分析，然后進行分工，之后就開始工作，既各干各的又不失默契的合作。在這個過程中我們誰遇到問題會互相幫助解決提高

了工作效率。由于各種原因，我們這組也存在些問題(自己編)。

這次實習拉近了我就和社會的距離，也讓自己在實踐中開拓了視野，增長了才干。社會和大學一樣也是受教育和學習的地方，在(寫實習地)的實習我收獲頗豐，再次感謝實習期間各位老師的指導教誨，你們給我的知識財富將讓我受益終生。但是我知道學無止境，僅僅這段時間的學習還是不夠的，在以后的生活中我會繼續努力學習，培養自己能力，進一步完善自己。

第三篇：軟件開發心得

軟件開發心得體會

08軟件（1）班 陳會敏 24號

歲月流轉，時光匆匆，轉眼間我的大學生活已經接近了尾聲?；厥淄簦刑嗝篮玫?，也有太多艱辛。我的大學生活的主旋律還是學習，我所選學的專業是軟件技術，在這條道路上走了那么久，也有一些小小的感悟與體會。

還記得上初中時，英語課本上有一篇關于比爾蓋茨的文章，當時真的很佩服比爾蓋茨，也就是那時我才第一次接觸到軟件一詞，學過那篇文章后我有個想法，就是也要做個比爾蓋茨，可是由于家庭條件的限制，那也只能是個美好的夢想。后來上了高中，再報考時我就選擇了軟件技術這個專業，這樣我想就向那個遙遠而又美好的夢想邁進了一點點吧。

然而當我真正上了大學，學了這個專業，我才知道要做個比爾蓋茨是多么的難，要想學好我的專業要花費很大的精力。第一學期我們開設了C語言這門課程，當時我學著真的是云里霧里、一竅不通，很是失落，學了不久之后我開始覺得自己可能并不喜歡這個專業，只是一時昏了頭，錯以為喜歡了。現實的打擊讓我有點不知所措，然而我已經選擇了它，有句話說：既然選擇了遠方便只顧風雨兼程。我既然選擇了這個專業，我便也只有硬著頭皮也要走下去了。有了這樣的想法之后，在之后的一段時間里，只要是沒課的時候我就抱起了C語言課本，努力的看，記語法知識，語法規則，學語句、小算法等等。經過一段時間的研究學習，我發現C語言并沒有我想象中的那么難

了，還是很有意思的。就這樣在學與玩中我的大學第一個星期就過完了。

后來又開設了很多課程，有VB、網絡、數據庫、操作系統、數據結構等。在這些課程中最令我頭疼的就是數據庫了，老師講的時候老是劃重點，講的很少，當時學的時候真的好難受，一學期下來啥也不會，后來看書上的操作，一步一步的操作，才終于學會了建個數據庫，做下備份還原等操作。開設的那么多課程也有我很喜歡的課程，比如數據結構，這門課程理論的比較多，上機操作的很少，這門課程是很需要理解的，當然有的還是要死記的。學習這門課的時候，我覺得并不像其它課程那么吃力，可能高中是學理科的緣故吧，理解起來并不太費勁。所以當時就很喜歡這門課，然而這門課表皮的好學，但要深學起來還是很有難度的，所以期末考試的時候我的成績并不太理想，但這些打擊不了我對它的興趣，至少我知道我所學的這個專業還是有很多我是很喜歡的。

這樣走著走著就到了大二的下學期了，那個學期，我們有一門課是C++，這門課的老師很和藹，能力也很高，從他那里我學到了很多東西。老師教給了我們很多算法，也很系統的講解了語法知識，還教我們做小系統，有的時候他會給我門們一些小系統的代碼，讓我們去改寫，剛開始的時候我也是不會，后來經過學習請教改寫成功了，這個時候我就會很開心，很有成就感。就這樣在學與玩中，在快樂和憂愁中我們迎來了我們的大三時光。

大三剛一開學，老師們就告訴我們這學期就上十二周的課，然后

就考試，就畢業了。這讓我很有緊迫感，一想到畢業在即，心頭就有種不舍，這兒有我美好的時光，然而我就要對這里說再見了。大三了我們的課全變成了專業課，也幾乎全成了上機課，老師還給我們布置了一個程序，就是一個小組要交一個系統來算作成績。我們這小組所選的課題是圖書管理系統，針對這個系統，我們上機的時候，利用網絡資源在網上查找了相關的資料，因為說實話，我們對此并不太理解，也只有通過網絡來查找信息，做好需求分析，功能模塊設計等工作。在這同時我們還去了學校的圖書館理解了相關的信息，這個系統并不要求功能有多么強大，關鍵在與一種鍛煉，思維的鍛煉，對所學東西的總結等。建立數據庫時我們就根據需要建立幾個表，里面的數據也是從我們學校圖書館里找來的。后來的界面設計，為了追求美觀，我們又在網上搜了很多美麗的圖片來美化界面。具體到功能的時候，有很多東西都不會，后來老師在課堂在做了講解，我們就把它用到了我們的系統中，真的就是學一步做一步的。整個的系統做下來，我學到了很多東西，也對那么知識有了很好的應用能力。

現在這個星期也就到了期末，這短暫的校園時光也在飛速的流逝著?；厥走^去學習的經歷，真是苦中有樂，樂中亦多苦，然而無論如何這些都已經走過去了，未來的路還要我們好好的走下去。人生本就是一個不斷的學習的過程，也是一個不斷完善的過程，在未來的道路上我會更加努力地學習，走出一個美好的人生。

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

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

立項前

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

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

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

第五篇：軟件開發核心心得

軟件開發核心心得

在一個有效的組織中，必定擁有杰出的一線人才。軟件設計也是一樣的，一線人才的素質決定了軟件的質量。從敏捷的觀點來看，代碼是檢驗軟件過程是否有效的最終標準。目前為止，以及在短時間的未來，我們都不太可能完全脫離代碼進行軟件設計。所以，軟件過程中的任何一個活動都是為了能夠產出優秀的代碼。所以，代碼才是核心。

1.代碼是軟件開發的基礎

編碼是軟件開發過程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領域的專家都需要花費大量的時間來進行基本技藝的鍛煉，木匠需要花費大量的時間來鍛煉他們對各種工具的掌握，廚師則需要練習刀工和火候。程序員也是一樣的，對我們來說，語言的各種特性必須要了然于胸。而對軟件的管理也需要從代碼做起。

從2000年到現在，國內興起了一股軟件工程熱，需求管理、配置管理、甚至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 盡可能多的考慮異常和錯誤的情況。

寫出一個功能并沒有什么，但是要把這個功能寫的非常的完善那就很難了，因為你需要考慮各種各樣的情況，正常的、非正常的。所以，寫完一個類的定義應該是，完成編碼和穩定，并通過原定的測試。本文摘自惠集網