對於程式設計師這個「質樸」的職位來說，說的再多，也沒有做的多來的實在。
就以程式設計師找工作為例，哪怕你簡歷上寫了再多你上了什麼課，會多少種語言，都沒有別人簡簡單單的幾個專案經驗來的吸引面試官。
乙個懂專案的程式設計師是很容易出彩的，特別是應屆畢業生那種新入職場的小菜鳥。
如果你說，你沒有專案經驗怎麼辦呢？你可以在網上搜尋乙個中等大小的專案，把整個流程摸透，**搞清楚，邏輯理清楚，然後再寫在簡歷上。這樣做，至少能讓面試官覺得，你做這個專案是沒問題的，不是只會紙上談兵，是能直接實操的；同時，也能讓你在面試的時候，不會無話可說，沒有特別的優點吸引面試官。能直接幹活的新人，可是非常難得的。
一、大體的專案開發流程
各模組的開發流程要能講述——技術點的用處，只需要大體概括不需要詳細講解。
二、自己開發的模快
必須熟練你負責的或者說你熟悉的模組的開發流程、原理；細節方面必須了解，自己開發的所有邏輯要能講清楚明白。
三、需求文件或者自己負責的功能模組文件如何寫以及裡面包含哪些
其實開發人員自己編寫的文件比較少，你只需要寫好詳細的邏輯功能結構和詳細的流程圖大體就可以啦，但是也會因公司而不同。
雖然需求文件一般是產品經理來寫，但是作為一名程式設計師，尤其是你現在如果去面試的話，你一定要懂產品經理是如何做需求文件的，這樣才能跟pm進行較好的交流和對接，否則很可能會被直接淘汰。
下面來介紹一下產品經理需要做的文件
1、如何寫prd（產品需求文件）
產品需求文件主要是描述產品功能，業務流程和lofi。可以提供給ue，美工 …產品需求文件，也叫業務需求文件。
一般寫這樣的文件用word+visio或axure，建議網際網路產品經理都熟悉一下axure這個軟體的使用，能直接生成prd。
產品需求文件主要是描述產品功能，業務流程和lofi。可以提供給ue，美工和專案經理執行的文件。
2、一般每個業務功能怎麼來寫 一般都按以下格式寫：
（業務功能名稱） 業務功能基本資訊
業務功能
業務流程
業務規則
介面管理
資料要求
輸入輸出
費用處理要求
列印單據／檔案要求
引數要求
與其它介面的整合建議
三、文件分為兩輪
第一輪：
1，文件使用方：ui設計師
第二輪：
文件使用方：開發人員 用高保真原型圖來對開發人員寫技術需求說明 有了高保真原型圖，開發人員看的最明白，我們只需要寫好詳細的邏輯功能結構和詳細的流程圖 在工作流程中，特別是面向ui和工程師，沒有必要詳細的寫出來什麼行業分析，開發背景之類的內容，因為ui和工程師是在幹活，不去關心這些問題，但一定要寫清楚功能範圍和此產品的目的，這樣有助於ui設計人員的理解。
另外，上面說的是個人理想狀態，可能每個公司有自己的現實情況而有不同的流程。關鍵是提高效率減少不必要的扯皮溝通。
四、詳細講解模組開發流程：
1、定義本模組及其子模組的名稱。
比如：個人空間、薪資模組、文化建設、薪資調薪審批等。
2、定義本模組的業務流程
比如薪資調薪審批流程：新表單填寫完成後提交到二級審核人，二級審核人審核通過後再由一級審核人 審核。其他人員只能查詢審核通過的內容。
3、定義每個頁面中的功能
比如：新增、修改、刪除、查詢、提交、匯入等。
4、資料庫設計
4.1針對每乙個模組，分析該模組需要建幾張表，確定這些表間的關係（比如：一對多），是否要引用其他表的外來鍵。
4.2表名與欄位名要遵守開發規範。
5、在資料庫中建立表。
6、根據資料庫中的表生成對應的實體物件。
7、編寫持久層、業務邏輯層、表現層**，並在配置檔案中進行相應的配置 注意包名、類名遵守開發規範。
8、開發完成後進行單元測試。
以上就是乙個專案的具體開發流程。
乙個專案的開發是需要很多個部門相互配合來製作的，在這個過程中，程式設計師是佔了很大的比重的，因此程式設計師除了自己的個人專業硬實力之外，對專案開發流程的熟悉、與其他部門的溝通對接、對客戶、使用者偏好的了解等這些軟實力也還是非常重要的。
在學習公升級自己的專業能力之外，也不要忘了提公升自己的軟實力。
注：你知道為什麼很多人能受得了生活的苦，受不了學習的苦？
乙個是主動，乙個被動。
生活是只要你活在這個世界上，每天就是在生活。
而讀書就是你到了乙個年紀，父母送你去乙個學校讓你讀書學習知識。
而且你也必須接受，在這裡你並不是主動的。
部分人覺得口說無憑，去花點錢花點時間表態，但他們統統倒在了用心這一關卡前。
世上哪有這麼好的事，吃點苦就能過上好生活了？
吃苦很容易，難的是不吃苦。
程式設計師接專案的四點技巧
程式設計師接專案的四點技巧 本人在軟體行業已經闖蕩多年，因為單位工作不是很緊張，因此也經常在網上接點專案做，幾年下來也總結出了幾點經驗。因為經常有程式設計師 朋友因為接不到專案而向我請教，在此我把自己在這方面的經驗寫出來，給準備接外包專案的同行一些參考 在實際的承接專案時，我認為主要有以下四點技巧 ...
程式設計師應該做開源專案的 6 個原因
開源開發人員都是義務勞動者 的觀點已經成為程式設計世界中的陳詞濫調，即使是那些偉大的開源舉措也無法駁倒這種風靡一時的心態。但是真理總是掌握在少數人手裡 即使是在開源慣例中，也需要參與開源的開發人員主動為其他人貢獻他們的技能，一些企業 或企業集團 往往會因此雇用 並支付 這些程式設計師 去研究特定的開...
程式設計師應該做開源專案的 6 個原因
開源開發人員都是義務勞動者 的觀點已經成為程式設計世界中的陳詞濫調，即使是那些偉大的開源舉措也無法駁倒這種風靡一時的心態。但是真理總是掌握在少數人手裡 即使是在開源慣例中，也需要參與開源的開發人員主動為其他人貢獻他們的技能，一些企業 或企業集團 往往會因此雇用 並支付 這些程式設計師去研究特定的開源...