1.需求

　　沒有明確的需求不要急著開始幹，在需求不明確的前提下，基本上是越早開發坑越多。

2.設計稿

　　在此應該說是原型圖，再好的需求文字描述也不如一張完整的設計圖，對於後端開發，沒有設計圖沒關系，主要是要有原型圖，在原型圖的設計指導下，後端開發人員可以明確接口的調用，數據庫的設計，字段的返回以及邏輯的設計，這一點十分的重要。。

以上兩點主要是設計和PM的職責，接下來主要說說程序員的工作

3.環境

　　新的軟件系統是部署在新的服務器上還是舊的服務器上，新的服務器，給了你更大的控件，你可以選擇更高版本的PHP開發環境，選擇新的框架；但是對於舊環境來說，框架就要受限制了，同時也受PHP版本的限制。

4.數據庫設計

　　良好的數據庫設計是一個系統成功的一半，首先開始表的設計。

　　1. 在數據表的設計過程中，首先是表的引擎。是用MyISAM呢，還是Innodb？你知道這兩個表的區別嗎？——我選擇了Innodb【有事務操作的選該引擎】，當數據表主要是以搜索查詢為主的話，優先選擇MyISAM引擎。

　　2. 表結構，字段的類型，如狀態字段的類型選擇，我選擇了tinyint(1)

　　3. 表的命名和字段的命名，都需要按照一定的規則

　　4. 索引。在測試的時候經常使用explain來查看查詢的效率如何

　　5. 備註，建表的時候寫備註，方便客戶端查看

5.開發

　　5.1 優雅的代碼

　　框架：能讓你的代碼結構很整齊，我用的是Thinkphp，也是第一次使用。先找到官方的文檔，記住不要一次性想把整個文檔看完，我是邊用邊看的方式進行的。開始階段主要看的地方是：mvc結構；

　　優雅的命名：不要用自己習慣的命名方式，要以框架的命名方式去編碼，要不然其他coder也習慣用自己的命名方式去coding，那麽代碼看起來就沒那麽幹凈了。

　　5.2 參數校驗

　　通過業務，你要確認，你的系統將會接受什麽樣的參數？

　　int型的是最讓我舒服的，不會引起什麽SQL註入，XSS問題，直接用intval強類型轉換。

　　最讓人頭痛的就是字符型，考慮很多方面，SQL註入，XSS攻擊等。對於SQL註入，我仔細看了一下Thinkphp的文檔，只要你用數組傳遞參數給指定的類，你就不用擔心SQL註入的問題（這也是用框架的好處）。xss攻擊：利用php的htmlspecialchars， 把字符轉成html結構的字符。

　　防止SQL註入，只需要對SQL語句進行預處理就行了。

　　5.3 數據庫操作

　　　1、事務:優點是插入和更新時保證數據的一致性、原子性、隔離性、持久性；但是也有一個問題，會有鎖行記錄的問題。

　　　2、在更新和插入之前，你做了查詢嗎？就是判斷是否有這條記錄。

　　5.4 日誌

　　　1、線上代碼出問題，你是怎麽定位問題的？很多時候，有些問題，你是無法在開發機和測試機器上復現出來的。我的辦法就是日誌。

　　　2、安全性：你的日誌是否有安全漏洞（把公司內部的信息暴漏到日誌裏）？那你怎麽控制的？——一個辦法就是設置日誌級別，thinkphp框架自身就有日誌級別。

　　　3、方便性：你的日誌打出來之後，你能找到問題嗎？

　　　原來的做法：程序讀到日誌斷點的位置的時候，就把日誌追加到日誌文件裏。——問題來了，當有一些並發的時候，日誌裏會把很多請求的日誌交錯的打到文件裏，查詢問題非常不方便。

　　　thinkphp給出的做法（不錯的做法）：本身也有上面的做法（原來的做法）；新學到的招數是，把日誌內容一行一行的放到內存裏，最後結束的時候，一次性打到日誌文件裏。

　　　4、錯誤碼；

　　　你的錯誤碼是什麽樣的？你設計過嗎？是否成功就0，錯誤就<0，錯誤碼挨著往下出溜。最好有個統一的規範。

　　5.5 開發文檔

你有寫文檔的習慣嗎？很多程序員跟我說，寫文檔太費時間了，我個人是習慣邊寫代碼邊寫文檔.你的文檔用什麽寫？我早期習慣在公司的系統上寫，但是發現速度很慢，而且查某個點的時候，比較麻煩，所以我習慣用word編寫。

　　　文檔有什麽用?

　　　1>是容易讓我理解代碼;

　　　2>是後期維護方便;這系統不是寫完了就了事的，後期還需要你維護，或者給別的程序員維護。

軟件開發的流程