程序員怎麼看懂需求文檔

1. 程序員喜歡什麼樣的需求文檔

程序員實際上並不需要這個文本的需求供認書，程序員喜歡「圖片」，文檔的文本應該是產品學生在腦子里思考，而不應該直接把這個想法描述成文字。
程序員需要的是一個清晰的交互圖,在關鍵位置的交互圖顯示,有一些邊界條件,交互圖不需要使用亂七八糟工具輸出,一張紙和鉛筆描述清晰,但恢復需求描述的所有元素就可以了,雖然沒有UI設計,但程序員可以開始開發演示。
一、產品介紹和行業簡介。首先，給程序員簡單介紹一下產品的價值，比如產品的作用，產品可以提供的服務，以及產品相對於競爭對手的優勢。還要介紹產品的目標用戶和使用場景。第二點是簡要說明行業的現狀，未來的趨勢是什麼，同行業競爭對手的情況如何?

二是產品的介紹。第一，實體關系圖很重要。當您將產品從0變成1時，為了使資料庫開發人員更快地了解您的產品，實體關系圖(e-r圖)將發揮很大的作用，資料庫開發人員可以參考圖來做數據表結構設計。
第二是用戶角色表的訪問。當涉及到角色和許可權時，需要一個全面的角色許可權表單來促進開發人員的參考。第三是業務流程圖。通過業務流程流程圖，可以從總體方向了解產品的整體邏輯，通過拆卸業務流程流程圖得到流程流程圖。

三是各種細節問題。產品的要求、功能和交互指示。寫功能描述，交互說明，不能漏掉一些細節，導致邏輯不嚴謹。可以從以下幾個方面來考慮，它會讓你更全面地思考:欄位，欄位描述，數據源；先決條件，排序機制，刷新機制；狀態流(頁面可能有多個狀態，需要解釋)；交互操作(正常操作，異常操作)

2. 程序員在上班時，允不允許大量的看說明文檔來幫助寫程序

程序員日常開發工作，基本是上離不開閱讀文檔，這也是很多程序員喜歡兩個顯示器的原因。

項目方面

技術方面
是不是很多人都認為，如果在開發過程中，還要不斷地翻技術文檔，說明他的開發能力不扎實。其實不是這樣的。

首先IT行業技術升級換代的速度太快，當我們大多數公司還在用Java8的時候，Java11都已經出來了。如果非得要程序員熟知每一個類、每一個方法，是很不現實的。

很多時候我們只需要了解有這么一個東西，作用是干什麼的，具體的細節可以在用的時候再去翻文檔，比如方法名字是什麼？參數有幾個，都是什麼類型的？

所以我們都習慣至少兩個電腦屏幕，一個屏幕寫代碼，一個屏幕看文檔；如果豪一些的話，再加一個屏幕展示日誌信息。

看文檔的屏幕要買豎屏！

我們團隊
我這幾年也帶過幾個團隊，對於每個團隊成員，我對他們的要求是：實現需求的前提下，最好能對所用的技術有一定的了解，千萬不要從網上抄過來一段代碼就用，這樣是很危險的行為。所以鼓勵大家多找一些資料，最好是閱讀框架的官方文檔。

現在的團隊，我已經這樣要求了：代碼寫累了，或者覺得自己沒有狀態寫代碼，可以找點兒自己有興趣的技術文檔學習學習，這個技術甚至是可以跟現在的項目沒有關系的。

首先，我不是程序員，我是一個設計工作者，不過我來說一下我的觀點：很多人以為程序員像電影里的一樣，啪啪啪幾下鍵盤，屏幕數據颼颼的變，其實真實情況是程序員寫代碼就像學生寫作文，也會遇到不會的詞語跟修辭手法，那這個時候就要停下來想一想，查一查，看看例子是怎樣寫的怎樣用的，寫錯了還要劃掉（刪掉）再來，至於這個大量不大量看的情況，如果這個是個新手，那肯定是可以的，那如果是個老手，還需要大量時間查說明文檔，那就說明這個項目肯定不會小，不是一兩天能做完的，那一個用月做單位的項目，用一個天做單位的時間來查文檔，不過分吧！程序員也是人，不是因為他的工作高端，就覺得這個人萬能，他也會當機，要吃飯，要休息，也會忘記一些東西，所以請各位多多體諒，能一起工作實屬不易，感恩2018，謝謝。

這個問題怎麼說呢，開發過程中會遇到各種各樣的問題，沒有一個人是全能的，也沒有人可以絕對的說自己在整個項目中不會遇到一點問題，不去查東西，自己大腦里的東西完全可以讓我把這個項目測測底底的做完，並且沒有任何bug。

上班的時間，也沒有老闆或者誰在後面一直看著你去做東西，大家都挺忙。文檔是幹嘛的，文檔本身就是用來看的，甚至很多項目開始之前，總監都會讓你去搜集一些這個項目可能會遇到的bug，可能會用到的效果，盡量在之前找到比較好用的插件，這樣會節省很多時間，自己如果寫代碼的話不可能百分百的確定沒有人和bug，但插件不一樣很多插件都是前輩通過很長時間慢慢完善出來的插件，所以很多人才會用。所以你提問的可以肯定的回答你允許。

程序員上班的主要工作就是看說明文檔，根據說明文檔編碼。如果實在沒有說明文檔，有時還得親自披掛上陣寫說明文檔。

寫介面的有API文檔，寫通訊協議的有協議欄位說明文檔，寫資料庫的有資料庫規範文檔，

總之任何一個大公司文檔扮演的一個至關重要的問題，因為形不成文檔，公司管理就會陷入混亂不堪的局面，當某個核心員工離職後，下一個接盤的程序員會丈二和尚摸不著頭腦，一頭霧水，邊填坑邊罵娘，有了文檔就可以看文檔結合代碼，了解其中模塊邏輯以及結構，包括哪些坑不能踩等等好處。有些公司會專門有文檔工程師這個職位來專門負責整理各種文檔，並且保存在伺服器上。

好的文檔都是程序員等人智慧的結晶，是一盞指路明燈，是一條通往光明的道路。程序員不能看說明文檔等於在黑暗裡摸爬滾打，有了說明文檔才迎來了黎明的曙光。

說個我遇到的2個真事吧，

第一個，公司找的外包公司寫項目程序，已經要交付了，發現有幾個功能沒做，產品經理和開發那邊都找我，我一個搞運維的又不懂，只能讓他們去對開發文檔，我也就順便看了看，開發文檔中明確的寫明怎麼做，然後就讓他們就重新按開發文檔繼續寫，

另一個，由於 歷史 原因業務系統處於託管狀態，只有部分參考文檔可用，開發那邊只能按當前已有文檔進行開發參考，開發那邊也一直在根據現有相關文檔進行開發，杯具的是這幫子不仔細看，有問題總想著我能直接給他們答案，我也只是會用而已，開發我還真搞不來，然後和他們一起看開發文檔，加密演算法部分給她們指出後，問題解決了。

所以我覺得，開發團隊在開發中很有必要閱讀開發文檔，這可以避免繞圈子，也會清楚開發文檔中提供的內容。

先說觀點，我認為看文檔沒什麼問題，但是「大量」這個程度很難衡量，按照需要看文檔是個非常重要的事情。
需要花費時間的情況 不需要花費大量時間的情況 小結
在工作中閱讀文檔其實也是工作內容的一部分，而且現在大多數互聯網公司都靠KPI進行考核，平時就算你把時間都用來看文檔沒關系，最後KPI沒完成一樣會被公司淘汰。所以公司不會阻攔你花費時間看文檔，最多你老闆會提醒你浪費這么多時間看文檔而沒有實際的產出會對你年終考核造成影響罷了。

題主對文檔的定義不是很明確
第一個是需求說明文檔
這個是在開發過程中必不可少的文檔，只有清楚了開發需求，程序員高效率的開發，程序員一天的工作時間並不是都是在寫代碼，而是在看文檔，了解需求，理清思路，只有什麼都清楚了，寫代碼或許只要十幾分鍾。

再者對於一個項目新人來說不看文檔了解需求，沒人給你從頭到尾的在講一遍需求，你不看文檔自己發揮？進入項目是和別人共同開發，你不肯能不顧及之前的代碼規范。
第二個是開發文檔
就拿微信開發來說，微信開發不是每個程序員必須會的東西，但是用到了怎麼辦，還不是去看他們的開發文檔，只有將開發文檔思路理清楚了，才可以進行下一步開發。
第三個是API文檔
在前後端分離的開發模式中API文檔是必不可少的文檔。不看API不知道數據是什麼樣。也就是不可能順利的和後端進行結合。

兄dei，假設你是程序員，你在寫程序時，旁邊會有人守著你嗎？

假設你不是程序員，你在做本職工作時，旁邊會有人守著你看你怎麼做事嗎？

答案肯定是沒有的。誰會閑著招個人去監督你，看你用什麼方式去完成給你的任務。

所以，其實你看不看大量文檔，沒有人會在乎，關鍵是你自己，建議自己寫東西時，不要一味的復制粘貼，要有自己的想法。太依賴文檔對於自己成長很不利

當然允許看文檔。

要知道，隨便哪個類庫，都有無數的類和方法，每個方法又有若干參數，鬼知道它們都是什麼意思，誰的腦子能記得那麼多內容。別說是人家提供的類庫，就是自己寫的代碼，過一段時間也不記得什麼意思了。沒有注釋和文檔，怎麼看懂代碼？

如果沒有需求分析文檔，程序員怎麼理解正在開發的這個軟體的基本業務流程？

如果沒有架構設計文檔，程序員怎麼理解軟體各個功能模塊之間的功能與業務邏輯？

如果沒有介面文檔，那麼多類和方法，都怎麼調用，會返回什麼值，難道靠猜？

……

在日常開發工作中，不僅允許看文檔，還會強迫你寫文檔。如果你寫的文檔別人看不懂，別怪領導罵你不認真。文檔對於軟體開發的重要性是不言而喻的。

還有一個秘密告訴你，那些經常寫文檔的程序員，要比不寫文檔的程序員工資更高。

真的！！！

迎娶白富美，從會寫文檔開始！

這個問題要根據具體開發的功能模塊來看，不過原則來說，花大量的時間看說明文檔，至少給人的印象是經驗不夠豐富，開發能力有待提高。

具體來說，如果是普通的功能開發，技術挑戰不大，這種如果還要看文檔，會被認為是開發能力問題。如果是有一定的技術挑戰，公司在這方面的積累比較少，開發團隊也對此有共識，這種問題看文檔無可厚非，當然如果能業余時間學習相關的知識，會給團隊留下開發能力強的印象。對於一些前瞻性研究，公司沒有任何技術積累，或者全新的技術方向，這個看說明文檔是加分的，甚至可以要求公司購買相關書籍或者在線培訓，當然，自己啃下來會更NB。

3. 怎樣做一名高效率程序員

很多人問我，你怎麼效率那麼高，工作很忙，又要帶娃，還寫博客，還有時間運動。今天就寫寫這個話題：程序員如何提高工作效率
保持高工作效率，我覺得主要有一下4個方面，希望能對大家有幫助。
集中目標
工作列表
不論是開發還是設計，還是其他職業，工作列表都很重要，工作目標很明確。工作的時候才能格外專注，才不會走神。
用自己最熟悉的工具（我用Evernote），把待辦工作列表（今天要做什麼）記錄下來，很重要的一點是記錄分解後的小目標（分解任務也是一個很重要的能力）。同時也保持工作中產生的新的問題（任務），經常性地調整當前工作任務列表，根據重要性對這些任務進行劃分，經常想著那些最重要的問題。
專注目標
專注目標不是那麼容易做到的，需要學會分離與當前無關的任務/問題，工作中經常會碰到的問題可以首先尋找簡單可用可靠的方案，並將心中的疑慮記錄下來，集中成一個列表，工作之外翻翻書，系統思考和學習，而不會因為這個問題而叉開思路對相關的內容研究一番。總之，專注當前的任務，把新問題記錄下來，回頭再專心攻克。
學會避繁就簡，在基本功的增強後，會發現很多問題可以簡單閱讀或查找文檔，或瀏覽問題相關的庫的源碼解決；
學會簡化問題
無論是在廣義的工作方法/工作態度上，還是在針對具體問題上，很重要的一個個人能力就是化繁為簡了。化繁為簡是所有工作方法/軟體設計的核心。將那些可以砍掉的工作砍掉，做到盡可能地簡單。
從工作方法和態度上來講，真正需要去做的工作才值得去做，大力砍掉那些不應該在當前工作中處理的事情。例如不必要的優化，不必要的擴展性，不必要的性能，不必要的功能，可以不要的技術，不必要的流程，不必要的文檔，統統砍掉，一切可以沒有的全都不能有。
工作中也可能遇到非關鍵的難題，通常繞過它們，使用更簡單的方案就是了。糾纏於這些不重要的難題，最容易浪費時間。
從設計/實現來講，最好的方案就是最簡單直接、一眼就能看懂的方案。而且通常最簡單直接的方式，通常性能也最好。
基本功
基本功的內容十分復雜。
第一項基本功是對整個計算機體系的理解，對操作系統/虛擬機/資料庫本質的理解，對語言基礎類和庫的理解，這些是核心基本功。
第二項基本功是學習能力。通過快速閱讀核心文檔理解核心思想，然後其他的東西總是能從文檔中查到就行。細枝末節的東西，即學即用，學過就忘可也。
第三項基本功是文檔、代碼、資料的搜索和收集，技術問題建議大家用Google搜索，有意識的整理出自己的代碼庫。
工具
選擇工具核心標准，就是簡單樸素可信賴，如果一個工具出幾次詭異現象，那就乾脆丟掉它。
熟悉工具，實際上我們工作中，就是和各種各樣工具打交道，各種IDE，編輯器，版本管理工具，命令行終端，TODO工具等等。要想在工作中如行雲流水，一定要熟悉工具，包括工具快捷鍵，命令，原理等等。
寫自己工具，很多時候，我們需要重復的做一件事情，當你做第2遍，第3遍的時候，就應該想一想，能不能自動化，很多簡單的幾句shell就可以搞定，麻煩的一點的，可以先記錄下來。比如，我就寫了非常多的腳本：一個命令反編譯APK並查看源碼、提取當前版本號打git tag並提交等等。很多時候幾分鍾到幾十分鍾的事情可以壓縮到幾秒鍾完成，也避免了對工作的打斷。

4. 如何寫一份易用的產品需求文檔

產品需求文檔分很多種，這里我只說一種讓程序員看起來舒服的需求文檔格式吧：

作為程序員，在需求文檔當中，最關注的內容是哪幾種呢？
1、流程：包括業務流程和基本流程；
2、數據：包括輸入數據和展示數據；
3、事件流：特別是分支事件流和例外事件流，感覺很多需求文檔中，缺少了這部分；

那麼，文檔的模板是怎麼樣的呢？
1、需求說明：主要闡述為什麼要做這個需求；
2、業務流程：最好使用VISIO來繪制，畫出整個業務的流程圖，特別是其中所要涉及的判定，分支等，都要畫出來，越詳細越好；
3、基本流程：繼續使用VISIO，畫出基本流程即可，一般來說都是業務流程中的最主要部分，但是可以加入更多的細節；
4、分支事件流：VISIO，各種分支事件的詳細流程，越詳細越好；
5、例外事件流：這里要使用表格，示例如下：主要是系統判定和對應的提示；6、輸入數據：用戶可以輸入數據的欄位，已經相應的定義，包括是否必填，欄位長度，錄入方式，對應規則等；
7、顯示數據：頁面顯示給用戶的數據，對應的欄位，取數規則，對應規則等;
8、補充說明；這個需求文檔模板，更傾向於傳統的軟體模板，而不是網路上比較流行的AXURE文檔。

5. 作為一名程序員，你真的理解需求嗎

作為一個程序員，最重要的職責就是： 按時保質保量地完成需求開發。

像開發新業務這樣的復雜需求， PM （Proct Manager，產品經理） 一般會寫出詳細的 PRD （Proct Requirement Document，產品需求文檔） ，甚至可能會製作高保真原型。

而像調換兩個按鈕順序這樣的簡單需求，PM有可能只會口頭通知一下，最多在JIRA之類的項目管理平台上創建一條只有標題的ISSUE。

如果是有和用戶交互的需求，負責設計的部門或人員一般會提供設計圖。專業一點的話還會幫你把圖都裁好，並准備不同屏幕解析度下使用的多個尺寸版本。

當然，如果你在一個剛剛成立的創業公司，很有可能是創始人在白板前（或者是飯桌上）講了半個小時，然後就問你：「需要多長時間把它做出來？」

不管提出需求的是PM還是創始人，他們的腦海中一定為這個需求設想好了一個自洽的邏輯和形態。PRD也好，口頭宣講也罷，都是在描述這個邏輯和形態。他們提出需求，就是希望程序員能夠最大程度地還原他們的設想。

說起來簡單，做起來難。 我們可以通過一個小實驗來揭示這一點。

首先，你需要找一張長方形的紙。如果你在辦公室，那就找一張A4紙；如果你在家，那就找一張紙巾。然後按照下面的步驟進行操作：

你的作品是什麼樣子？中間開洞了嗎？邊上呢？角上呢？如果再做一次，你能完成同樣的作品嗎？

你可以拿著同樣的紙去找你的家人、同事或朋友，請他們來完成同樣的操作。在你不施加影響的前提下，他們完成的作品極有可能和你截然不同。

為什麼會這樣呢？

如果你仔細觀察他們操作的過程，就會發現：

由於每次對折都會可能產生兩種不同結果，在撕第一個角時紙的朝向有四種可能性，旋轉180度時有兩種可能。所以僅僅兩個撕角的位置，就至少有 2 x 2 x 4 x 2 = 32 種不同的可能性。

就這樣，我們還沒有考慮撕角的大小、角度的區別，還有極少數人是會沿對角線對折的……

上面撕紙的需求，其實是我自己拿了張紙隨意擺弄，然後記錄下來的操作流程。我照著這個流程，可以十分輕松地做出完全相同的作品。但是如果讓別人來做，結果就完全不一樣。其原因就是，我在完成作品的過程中，不光是按照流程進行操作，還隱含了自己的一些小習慣，卻並沒有把這些細節記錄下來。

如果把所有細節都完整地記錄下來的話，需求應該是這樣的：

同樣，PM在寫PRD時，很有可能會漏掉一些自己認為應該是「常識」，無需再進一步說明的內容。比如「把一張紙對折」，我們很容易想當然地認為，應該是沿著長邊對折，但事實上並非所有人都是這么理解「對折」的。

由於每個人的成長經歷不同，其認知結構之間必然存在差異，因此對同一概念未必持有相同的理解。 你所認為的「常識」，我可能並不知道，或者擁有和你截然不同的理解。所以程序員在看PRD時，一定要把自己對需求的理解復述出來，跟PM確定是不是這么回事。否則就容易出現開發中、提測甚至上線後發現邏輯性錯誤，需要緊急修復甚至返工的情況。

此外， 很多問題在設想階段是發現不了的，只有到了具體實施時才會暴露出來。 PRD不可能真正做到完備，也不能保證沒有錯誤和遺漏。比如一個表單需求，很可能在做的過程中發現某個非法數據case是PRD里沒考慮到的，這時的用戶交互怎麼做？文案怎麼定？這都要和PM溝通來解決，而不能自己拍腦門決定。

PRD只是需求的一個快照性描述文檔，並不是需求本身。 程序員應該對需求負責，而不是對文檔負責。 只有和PM保持溝通，不斷地細化需求，才能讓需求真正落地。當發現PRD里有不合理或者有疑問的地方時，一定要提出來讓PM進行解釋。千萬別視若無睹，甚至乾脆將錯就錯，等著看PM笑話。

如果我們拿到了一份圖文並茂、十分詳盡的PRD，是不是應該馬上照著文檔開工呢？那可不一定。

一位優秀的程序員，應該在開工之前把下面這些問題想清楚：

程序員有責任對需求方案進行review，並協助PM改進設計。 要知道，PM一般不會從技術角度對需求進行考慮，所以往往提出的並非最優方案。有時只要做一點點調整，技術實現的難度就會大大降低，卻不影響目標的達成效果。

比如某個業務需要用到日期選擇器組件，PM為此專門設計了一個，而你知道系統中某個功能頁面里有現成可用的同類組件。這時就應該和PM溝通是否可以直接復用，或者在原有組件的基礎上進行功能擴展。這樣既節省了開發資源，又保持了用戶體驗的一致。

程序員要對整個產品的可用性負責，全面評估需求可能導致的不良影響，謹慎對待有破壞性的需求。 PM由於不了解系統的底層實現和實際數據的組織方式，所以很可能無法全面地評估需求的影響面。如果程序員忽視在這方面的思考，只是機械地按部就班地執行方案，就很可能導致嚴重的線上事故。

比如要對某數據進行批量修改，在做的過程中時發現該數據有多個業務正在使用。這時就應該必須停下來和PM溝通，因為PM可能只了解自己負責的那一塊業務，不知道修改可能會對其他業務產生影響。此類需求要和相關各方溝通協商，確認修改沒有不良影響後才能繼續。

程序員要有魄力去拒絕那些明顯不靠譜的需求。 有的時候，PM提出需求的動機不是為用戶創造更多的價值或提升用戶體驗，而是為了沖績效完成自己的KPI。為此拆東牆補西牆，從兄弟業務手裡搶流量入口；甚至殺雞取卵，以嚴重破壞用戶體驗的方式拉量。遇到這種事，程序員一定要堅持自己的原則，守住自己的底線。

6. 需求分析是什麼意思

需求分析就是對客戶提出的「要求」或者「需求」進行深入細致地調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼，為系統設計、系統完善和系統維護提供依據。

需求分析是項目計劃階段非常重要的環節，該環節決定了需要「實現什麼」，為下一步如何去「實現」提供了明確的方向。

進行需求分析需要做到以下幾點：

（一）需求獲取：在准備階段，我們首先要確定需求獲取的目標及范圍，根據你的目標來選擇對應的方式獲取需求。

（二）需求分類：一般情況下，我們會根據對象的不同，將需求分為業務需求、用戶需求、功能需求等。

（三）需求篩選：有些需求是偽需求，有些需求則不具備實現價值，我們可以通過真實性、價值性、可行性三個維度來篩選需求，過濾掉虛假的、不可行的、沒有價值、價值不大或投入產出比不理想的需求。

（四）需求提煉：對剩下的需求進行提煉，目的在於從獲取的表面需求中提煉出客戶的本質需求。找出「為什麼要做」比「做什麼」更重要。

（五）需求優先順序排序：挖掘到客戶的真實目的後，我們需要根據不同維度的需求歸類方法，如KANO模型分析法、投入產出比ROI等，對其進行歸納整理並排出優先順序，幫助產品有條理地安排開發秩序，避免盲目排序。

（六）產出需求文檔：通過以上的分析，我們需要將收集到的需求進行分析、匯總、歸類，輸出產出需求文檔，為接下來的工作做好鋪墊。

以上是對需求分析的一些理解和思路，做好需求分析工作之後，就可以對可實現的需求進行落地方案的跟進。

7. 北大青鳥java培訓：如何快速熟悉項目代碼

對JAVA程序員而言，換一份工作或進入一個新的公司，往往意味著要熟悉一個新的開發環境，要快速了解新的項目。
如何快速地熟悉項目代碼，是每個程序員都會遇到的問題，特別是對剛進入職場的應屆畢業生，這個問題更顯得棘手。
下面是我自己在經歷幾個工作之後結束的一些方法，河南IT培訓http://www.kmbdqn.cn/與大家分享一下，僅貢參考！1.通讀需求文檔，了解項目用途；一個企業級的項目，一定會保留一些相關文檔吧！比如需求文檔，設計文檔，項目計劃等，先通讀這些文檔，了解項目的用途、主要功能等。
2.熟悉開發工具、常用功能；每個公司用的開發環境都會有些不同，要熟悉新的開發環境，了解常用的功能、快捷鍵等，特別是前後使用習慣相差比較大的開發環境，如從MyEclipse到IntelliJIDEA。
Java的開發環境用的比較多的有MyEclipse(Eclipse)、IntellijIDEA.C++就比較多了，從VC6到VS2008、VS2010、VS2012、VS2013都有人用，還有一些用開源的開發工具如Qt。
3.部署環境，把項目跑起來；了解開發環境後，就把相關的配置部署好，把項目跑起來。
好處是：1.可以進一步實踐新的開發環境；2.把項目跑起來後可以快速地了解項目的用途和功能。
4.整體瀏覽代碼，了解代碼結構；整體瀏覽一下代碼，對項目的代碼有個整體結構的把握。
最好能把類圖畫出來，可以用一些UML工具(如EA、PowerDesign)的逆向工程把源碼導出類圖。
5.抽取其中的一部分進行細讀；對一個企業級的項目，特別是一些大型項目或積淀比較深厚的項目，不可一下就把所有代碼都熟悉。
那就選擇其中的一部分，如其中一個小功能，從界面開始，通過debug模式一步一步地跟下去，以點帶面地去熟悉整個項目。
6.嘗試修改一些程序bug；修改bug是熟悉項目最好的方法。
根據出現的bug，通過debug模式一步步地定位出現問題的位置，再分析出現問題的原因。
當你能夠修改bug，並且已經改了好幾個bug的時候，就說明你對項目有了一定了解了，基本熟悉這個項目的結構和邏輯了。

8. 要做程序員需要學會什麼

要做程序員需要學會什麼
程序員的崗位需求很多，例如大型網路公司、軟體開發公司等等都需要程序員。
程序員需要學習：
1、掌握數據及其轉換、數據的機內表示、算術和邏輯運算，以及相關的應用數學基礎知識；
2、理解計算機的組成以及各主要部件的性能指標；
3、掌握操作系統、程序設計語言的基礎知識；
4、熟練掌握計算機常用辦公軟體的基本操作方法；
5、熟練掌握基本數據結構和常用演算法；
6、熟練掌握C程序設計語言，以及C++、Java、Visual Basic中的一種程序設計語言；
7、熟悉資料庫、網路和多媒體的基礎知識；
8、掌握軟體工程的基礎知識，了解軟體過程基本知識、軟體開發項目管理的常識；
9、了解常用信息技術標准、安全性，以及有關法律、法規的基本知識；
10、了解信息化、計算機應用的基礎知識；
11、正確閱讀和理解計算機領域的簡單英文資料。
程序員必備技能：
1、熟練開發工具
做為一名程序員至少熟練掌握兩到三種開發工具的使用，這是程序員的立身之本，其中C/C++和JAVA是重點推薦的開發工具，C/C++以其高效率和高度的靈活性成為開發工具中的利器，很多系統級的軟體還是用C/C++編寫。
而JAVA的跨平台和與WEB很好的結合是JAVA的優勢所在，而JAVA即其相關的技術集JAVAOne很可能會成為未來的主流開發工具之一。
其次，能掌握一種簡便的可視化開發工具，如VB，PowerBuilder，Delphi，CBuilder，則更好，這些開發工具減小了開發難度，並能夠強化程序員對象模型的概念。
另外，需要掌握基本的腳本語言，如shell，perl等，至少能讀懂這些腳本代碼。
2、熟知資料庫
作為程序員，他們自然有自己的理由：很多應用程序都是以資料庫的數據為中心，而資料庫的產品也有不少，其中關系型資料庫仍是主流形式，所以程序員至少熟練掌握一兩種資料庫，對關系型資料庫的關鍵元素要非常清楚，要熟練掌握SQL的基本語法。
雖然很多資料庫產品提供了可視化的資料庫管理工具，但SQL是基礎，是通用的資料庫操作方法。如果沒有機會接觸商業資料庫系統，可以使用免費的資料庫產品是一個不錯的選擇，如mySQL，Postgres等。
3、了解操作系統
當前主流的操作系統是Windows，Linux/Unix，熟練地使用這些操作系統是必須的，但只有這些還遠遠不夠。
要想成為一個真正的編程高手，需要深入了解操作系統，了解它的內存管理機制、進程/線程調度、信號、內核對象、系統調用、協議棧實現等。
Linux作為開發源碼的操作系統，是一個很好的學習平台，Linux幾乎具備了所有現代操作系統的特徵。雖然Windows系統的內核實現機制的資料較少，但通過互聯網還是能獲取不少資料。懂得網路協議TCP/IP。
在互聯網如此普及的今天，如果您還沒有對互聯網的支撐協議TCP/IP協議棧有很好的掌握，就需要迅速補上這一課，網路技術已改變了軟體運行的模式。
從最早的客戶/伺服器結構，到今天的WEBServices，再到未來的網格計算，這一切都離不開以TCP/IP協議棧為基礎的網路協議支持，深入掌握TCP/IP協議是非常必要的。
至少，需要了解ISO七層協議模型，IP/UDP/TCP/HTTP等常用協議的原理和三次握手機制。
4、明白DCOM/CORBA/XML/WEBServices存在的意義
隨著技術的發展，軟體與網路的無縫結合是必然趨勢，軟體系統的位置無關性是未來計算模式的重要特徵之一，DCOM/CORBA是當前兩大主流的分布計算的中間平台，DCOM是微軟COM（組件對象模型）的擴展，而CORBA是OMG支持的規范。
XML/WebServices重要性不言而喻，XML以其結構化的表示方法和超強的表達能力被喻為互聯網上的「世界語」，是分布式計算的基石之一。
5、不要將軟體工程與CMM分開
大型軟體系統的開發中，工程化的開發控製取代個人英雄主義，成為軟體系統成功的保證，一個編程高手並不一定是一個優秀的程序員。
一個優秀的程序員是將出色的編程能力和開發技巧同嚴格的軟體工程思想有機結合，編程只是軟體生命周期中的其中一環，優秀的程序員應該掌握軟體開發各個階段的基本技能。
如市場分析，可行性分析，需求分析，結構設計，詳細設計，軟體測試等。
6、需求理解能力
程序員要能正確理解任務單中描述的需求。在這里要明確一點，程序員不僅僅要注意到軟體的功能需求，還應注意軟體的性能需求。
要能正確評估自己的模塊對整個項目中的影響及潛在的威脅，如果有著兩到三年項目經驗的熟練程序員對這一點沒有體會的話，只能說明他或許是認真工作過，但是沒有用心工作。
7、模塊化思維能力
作為一個優秀的程序員，他的思想不能局限在當前的工作任務裡面，要想想看自己寫的模塊是否可以脫離當前系統存在，通過簡單的封裝在其他系統中或其他模塊中直接使用。
這樣做可以使代碼能重復利用，減少重復的勞動，也能使系統結構越趨合理。模塊化思維能力的提高是一個程序員的技術水平提高的一項重要指標。
就業方向：
1、網路開發
現在網路已經成為世界通訊的一座橋梁，好像Javascript、PHP、Ruby這幾類開發語言大部分是用作網路開發方面。
2、企業軟體開發
JAVA、C#、VB這幾類開發語言都實現了面向對象開發的目標，更多時候用於企業系統的開發。
3、系統軟體
C語言、C++、Object-C這些軟體更多是用在系統軟體開發，嵌入式開發的方面。
當然，這分類不是絕對，像JAVA、C#、VB很多時候也用於動態網站的開發。在很開發項目都會使用集成開發的方式，同一個項目裡面使用多種開發語言，各展所長，同步開發。

9. 要做程序員需要學會什麼

其實簡單來說，程序員的工作就是使用編程語言，根據需求寫出一個程序。
但是，在這個過程中，涉及如下幾個方面：

使用的編程語言 程序員需要選擇一門或者多門語言來編程，不同的語言適合編寫不同的程序，目前主流編程語言包括，Java、JavaScript、Python、C++、php以及其他小語種等等，每種編程語言適合開發的程序有所不同。目前從程序應用分來，主要可以分為三類a 企業應用，主要用於解決企業業務。各種企業管理後台系統，銀行系統，公安系統，圖書管理系統等等。
b 互聯網應用，面向互聯網用戶，為互聯網用戶提供各類服務。比如現在的京東淘寶各類電商系統等。
c 移動應用，各類在移動端使用的APP，有面向互聯網用戶的APP，也有面向企業內部的APP。
目前相對而言，在移動應用和互聯網應用方面，資本投入比較熱的風口，程序員的薪資較高。企業應用，發展了很多年，相對平穩。

2. 明白需求，實現需求
需求就是編寫程序的要求。一個程序要編寫成什麼樣子，具備哪些功能，都是由需求來具體說明。程序員要需要能看懂需求文檔，並且能准確地使用編程語言，根據需求中的要求來編寫成程序。企業開發的項目，往往會由該程序的架構師提供一個程序框架，程序員在該框架的規范下進行編程，實現需求的功能，以確保程序的規范、可讀，以及可維護性。

3. 日常工作寫程序
一個軟體開發一般流程是產品經理根據用戶需求做一個項目出來，然後UI設計師做一些圖片設計，前端開發編寫頁面，後台開發編寫核心編程，然後介入一些大數據和人工智慧，通過測試之類上線實施，後期還有運維進行相關維護。
程序員一般大多指的是前端和後台寫代碼程序的開發人員，除了編寫代碼，可能還需要通過介面和其它系統對接，實現系統間的數據交換。像單體測試，是程序員對自己寫好的程序單元進行測試，檢測這個程序單元數據輸入和數據輸出是否符合預期等等。測試出來的問題，需要修改正確，然後再測試，直至沒有問題。和同事共同開發的時候也需要聯合測試，以及用戶測試過後如果存在BUG繼續進行修改。