已經給了你這樣的需求，那么接下來要做什么？PM當然會詢問排期。如果讓你排期，你會給幾天時間？你怎么考慮的排期？
反正讓我排期，我排不出來。于是接下來我要做的是拿出我的xmind軟件，在跟PM確認需求，定方案。最后用了兩個小時，把需求再次確認，并給出了如下的排期：
后來我又問了一個細節，新域名service.xx.com是否已經有了？PM告知無，所以需要走申請流程1d?！詈蟮臅r間定位1周(5天）時間。
編碼是個細致活，那么在編碼開始階段你要做什么？不會是著急把代碼寫好吧？
我考慮的是：
第一、干凈的代碼；
框架：能讓你的代碼結構很整齊，我用的是Thinkphp，也是第一次使用。先找到官方的文檔，記住不要一次性想把整個文檔看完，我是邊用邊看的方式進行的。開始階段主要看的地方是：mvc結構；
好的命名：不要用自己習慣的命名方式，要以框架的命名方式去編碼，要不然其他coder也習慣用自己的命名方式去coding，那么代碼看起來就沒那么干凈了。
第二、傳入參數的校驗；
通過業務，你要確認，你的系統將會接受什么樣的參數？
int型的是最讓我舒服的，不會引起什么SQL注入，XSS問題，直接用intval強類型轉換。
最讓人頭痛的就是字符型，考慮很多方面，SQL注入，XSS攻擊等。對于SQL注入，我仔細看了一下Thinkphp的文檔，只要你用數組傳遞參數給指定的類，你就不用擔心SQL注入的問題（這也是用框架的好處）。xss攻擊：利用php的htmlspecialchars， 把字符轉成html結構的字符。
第三、更新、插入操作；
1、事務:優點是插入和更新時保證數據的一致性、原子性、隔離性、持久性；但是也有一個問題，會有鎖行記錄的問題。
2、在更新和插入之前，你做了查詢嗎？就是判斷是否有這條記錄。
第四、日志；
1、線上代碼出問題，你是怎么定位問題的？很多時候，有些問題，你是無法在開發機和測試機器上復現出來的。我的辦法就是日志。
2、安全性：你的日志是否有安全漏洞（把公司內部的信息暴漏到日志里）？那你怎么控制的？——一個辦法就是設置日志級別，thinkphp框架自身就有日志級別。
3、方便性：你的日志打出來之后，你能找到問題嗎？
原來的做法：程序讀到日志斷點的位置的時候，就把日志追加到日志文件里?！獑栴}來了，當有一些并發的時候，日志里會把很多請求的日志交錯的打到文件里，查詢問題非常不方便。
thinkphp給出的做法（不錯的做法）：本身也有上面的做法（原來的做法）；新學到的招數是，把日志內容一行一行的放到內存里，最后結束的時候，一次性打到日志文件里。
4、錯誤碼；
你的錯誤碼是什么樣的？你設計過嗎？是否成功就0，錯誤就<0，錯誤碼挨著往下出溜。最好有個統一的規范。
5、開發文檔
你有寫文檔的習慣嗎？很多程序員跟我說，寫文檔太費時間了，我個人是習慣邊寫代碼邊寫文檔.你的文檔用什么寫？我早期習慣在公司的系統上寫，但是發現速度很慢，而且查某個點的時候，比較麻煩，所以我習慣用word編寫。
文檔有什么用?
1>是容易讓我理解代碼;
2>是后期維護方便;這系統不是寫完了就了事的，后期還需要你維護，或者給別的程序員維護。
我經常接手別的程序員寫的代碼。出了問題，問他怎么回事？每次回我的話就是看代碼啊！這時候我就要從內心罵人了!
3>是你寫的接口是給人調用的，你怎么告訴調用者你的接口形式？我比較懶，直接把文檔交給他，省事了。如果他有些地方看不懂，那就說明，你沒理解或者你沒寫清楚，一方面加深你對系統的理解，另一方面也能增加你寫文檔的功底；
