[散分] 讲点俺们作后台的那些事

[散分] 讲点俺们做后台的那些事!

本帖最后由 mu_rain 于 2012-11-01 11:18:30 编辑 写点俺用的后台的那些口水杂记,以下是个人见解,欢迎各大侠指点.

/////////////////////////扯点交互////////////////////
//1 登陆界面一定要靓,第一眼决定了很多.[道理就不解释了]
//2 选一个合适的前端交互包,我用的是easyui,主要是看中了他的layout,视觉效果不要太深沉,像csdn 这样清爽的配色即可,交互不要太眩,对一个长期工作者而言,太多的过度效果,会让人想吐. 仅在重要处理时,来点效果即可.
//3 关于后台布局,我没有太多的想法,基本上照着ide的那个布局的感觉去做做.
//4 内部信箱是个快速沟通的方式,也是通知发布,工作提醒的好手段,有兴趣,还可以折腾点sns [例如,你手下的xxx 于xxx登陆后台,他今天做了***],这里遇到了一个,大家不收信,不愿意去使用的问题.木有办法,直接模式对话框弹出,点击确认后,不再骚扰,并闲着没事时,与行政,老板,推广这东西.再说了,数据都在自己这,搜索时也方便,要查个什么,都挺快的.
//5 菜单的交互,点击后,工作区tab 效果,这个同事都很乐意接受.[和ide 一样的不啰嗦了]
//6 添加截图上传处理[需要firefox 浏览器支持],发布时截图为html５ 显示时html 版本. 详细看帖 http://topic.csdn.net/u/20121018/10/16e8f8d2-2955-4680-9e69-167681f0363c.html
//7 表格数据,每行交替颜色,滑过时浅色,选中时深色. 事虽小,给业务人员带来的效果是很明显的.
//8 操作全ajax 处理,批操作完后,hold 住查询条件. [例如对今天的数据做审核,查询条件,为今天,未审核,按时间排序]这样,每操作一次,再reload 一下数据,不用二次去选择查询条件.
//9 最后一点,也是最重要的,用心去服务. 技术在基础实现没什么大问题后,服务是一个展示出不同能力层次的好地方,服务好了,人人看你爽,只要碰到一个明智的,正常的老板,幸福会来的.还有就是不要急,有时,业务也会扯不合理的东西,慢慢疏导,用心沟通,时间长了,都会明白的.


/////////////////////////谈点功能////////////////////
//1 权限管理部分,我采用的简化文化,把角色和菜单关联一下.通过可见性,完成基本的角色权限控制. 然后在控制器的钩子上加一个过滤表,防止非法闯入. 对这块,多说两句,把握一个原则,less is more. 难的不是技术,是对人,所以建议一开始,就行成一个良好的约定,不要过多的去满足太个性化的整合需求. 一旦有一个不好的开始, 人类的欲望的变化,直接让你崩溃,对需求方而言,你小子写再快,难到有他想得快. 当然,比较严格,已有成熟业务的体系另当别论. 大家都用过一些 bug 管理, oa 类的产品,如果想做细致点,就照做比较合适. 我在07 年,还做过一个类似权限树的东西,一个子结点角色,发布一个文件,他向上三级,直系链的结点可以看,向上找三层,其下子结点遍历,再与发布人,有项目往来历史的人可以看之类似的需求,现在想得就蛋疼,最后的建议,别给那些无聊的人太多的空间. 他们做项目的目的,就不是为了出产品,而是为了自已那所谓的价值的存在,想深了,这事麻烦,所以 less is more!
//2  登陆是 不要去写 where `name` = '$name' && pwd = '$pwd' 这样的查询, 先查用户,再比对密码. 对每次的提交做必要的xss 处理.  用360检测一下网站安全,把一些基础的全安漏洞处理一下.当然,还有很多东西,需要服务器工程师去协作,尽早明确这个概念,别一个人折腾得啥都做,全能战士是很悲催的.
//3 用lang 对语言文字进行处理.这样改文字时,就在一块,比较方便.[代码大全里,一直有讲这个中心控制的原则]
//4  添加用户操作行为追踪,通过钩子对每个控制器进行追查,并写入useraction进行日志.以数据为中心,对每个数据进行追踪处理,对重要的数据,进行数据链的追踪.
//5 后台是基于配置的,并基于约定大于配置的原则,对固化的东西,多采用约定的方案,对需求变化的东西,采用配置,便如数据列表显示哪些烈,对哪几个字段进行用户追踪,对哪些用户行为进行追踪.
//6 生成饼图柱图之类的,就直接用google 的api ,省事省心,找了N个php 的制作图,难用的居多.当然google Api 不能满足时,就硬着头皮用phpchart 相关类了. 确幸的事,这种事情还没发生.
//7 多写些支持excel的东西, 例如:批量导入数据,批量导出.
//8 swfupload ,editor 等 这些东西包装好,用的时候直接加上去就ok.写的时候 用css 样式去控制调整这些东西是否在两者之间转换.对通过 json 数据,数据库表生成的 select radio 用form_helper 包装一下. 我关注了一下,每个框架都有form 生成的地方. 但对仅一个input 的,闲着没事,也不用form_helper 去create 了.除非你整个表单都希望由配置生成. 但基于项目经验来看,这里,是TMD 业务要求变化最多最快的地方. 用手去写,确实是最实际的手段.感观直接,维护方便.当你要封装的东西,大量的是不可预期的时候,就要想想封装的必要性了,要想想是否过度设计了.
//9 对每个数据,插入前后有beforeInsert afterInsert 主流框架都支持, 其实还有挺多,写到这里就要收手了



/////////////////////////忽悠点代码////////////////////
 //1 组合自己的类时,可能涉及到autoload , 不要直接把框架的autoload 给改了[年青时喜欢这样折腾],把自己的代码,放在合适的地方去组合进去,方便装卸.研究可以,没事不要乱改人家框架的代码,虽然基于代码癖好,总觉得框架会在有些地方很烂,但记住,自己不要多手,别进行不亦乐呼.其一,你写的东西,没有团队与大量qa,tester 的支撑,容易出问题,其二:万一框架升级了,你难道再去折腾一遍??? 
//2 别写代码时就过度设计,更不要滥用设计模计,注重代码的体验,在写一个架构时,要多角度去体会,以后代码会如何去写,多品味这样写的好坏,多与团队人员沟通. 对大型框架,学之者生,用之者死,精华拼命的吸收,用的时候,不要盲从. 
//3 在熟悉和理解自己公司所处的业务时,要根据特性controller,model的基类重构一道,你熟悉了业务,自然有感觉怎么去写了. 
//4 一定要有一套命名的标准. 举个例子 userModel(model) user(controller) cfg_user(配置) v_user_index(视图),尽量见名知义. phpstorm 有个很好的 ctrl+shift+n 能根据文件名快速的找到文件,这样非常有助于提升效率. 
//5 常用的热键,快截键都包装好. 例如写个 foreach 直接 fe+回车,就全部出来了, lm+回车就是load model 的全部代码. 上次有位牛人,有个贴子,editplus 可以这样用. 精华一定要多吸引,我用的是phpstorm ,也有着大量的快截键的,editplus 能实现的,大点的ide 也可以做到的. 至于,查看类的结构,追述代码,整合svn ,phpunit ,语法检查,代码提示这些editplus 就不给力了.