工做原則

１．正式上線代碼時，如果一個全新功能，需理清部署以前須要走的流程，如建立文件夾(/data/deploy/logs)以及權限, 建立或更新增長字段（數據庫), 安裝package(npm install, pip install), 查看git log信息，確認正常，沒有臨時的修改，更新代碼(cap deploy, git fetch & rebase). 上線代碼後，也須要及時進行測試驗證，網頁點擊模擬用戶．

２．應逐步發展本身的util庫，封裝經常使用功能, 以及豐富經常使用使用場景

　　dateformat 格式化日期

　　moment.js 對日期的處理上，遠比dateformat好

　　querystring 產生url的query部分

　　iconv  頁面轉碼

　　request http請求

　　async  流程控制

　　underscore 一些函數式編程　　

　　excelbuilder　產生excel

　　xml2js, js2xml，xml2json  xml數據和js數據, json之間的相互轉化

　　wrap  定製本身的，如必須登陸才能訪問則wrap_login_in(movie.show)

 

３. 不在十分緊急的狀況下，不該該workround, 好比不該該輕易的上緩存，而是找出慢的本質緣由，是不是查詢沒有緩存，是不是數據量太大，須要按期刪除老的數據，是不是數據結構設計的有問題，若是是這種問題，則應該改進設計

４．被多個項目會用到的模塊，提煉到公共庫中，經過修改path, pythonpath, nodejs(的path) ，來達到公用，而不是各項目都各自重複開發

５．程序功能應緊跟項目，好比nodejs項目裏須要crontab定時更新緩存，就不該該是用python去刷新緩存，而應該是nodejs實現，也方便看代碼

6.　被證實是好的模式，應在全部適合的項目裏推廣，成爲標準

7.　應對本身的程序有極強的控制力，如一條請求的平均，最大相應時間，一個函數的執行時間（驗證隨着時間的推移，數據的積累，咱們的程序的性能是否不行了，及時改進），log文件(mongodb日誌, nginx日誌）的報錯信息，一切都是爲了，儘早找到潛在，咱們未能發現的問題

8.　當發現當前架構存在問題，但修改起來，工程量巨大，而當前必須發佈新功能時，考慮新功能儘量採用新的架構，對老版的功能創建branch, 在保證正常使用的狀況下，逐步遷移功能，最好列出一個roadmap, 請求配合

9.　發現問題時，當天當即修復，若能辦到的話，但至少也要找到緣由，積重難返，問題堆積的太多，就改不動了．應該是拉着車跑，而不是被車拉着跑

10.　儘可能避免少加班，經過增長工做時長來完成工做並不可取，應經過提升效率．諷刺的事是，工做時長越長，效率越低．必須保持頭腦清醒，coding前畫圖，仔細思考潛在的問題，而且和人商討下，商討的這點小時間，能夠避免不少之後的蛋疼

11.  博採衆長, 看看其它人在寫什麼，有哪些能夠借鑑，讓咱們寫代碼舒服些．若其它人寫的也明顯有問題，也須要委婉指出，鬼知道哪天你要接手誰的代碼．別人爽了，你才爽的了

12.　對於每個案例, 好比解決了某種問題，能夠列出一個screen, 列出完整的過程，方便舉例，並給出連接，更具體

13.  工做進度，應以一種可視化的角度每日呈現，方便boss和產品查閱，打消不安感