工作原则

１．正式上线代码时，若是一个全新功能，需理清部署之前需要走的流程，如创建文件夹(/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和产品查阅，打消不安感