如何评价项目的好坏(从客户角度) 功能:按期,效益,体验,稳定性(性能),扩展 按期完成功能是一定的,不然会被辞退,绩效考核才是最重要的 稳定性的指标:可用性 绩效考核指标:(分钟-故障分钟)/总分钟
一个项目的开发流程: 需求(文档) ->>>原型(需求可行性) ->>>设计(技术选型)(技术,测试人员测试,UI设计) UI,里程碑,原型对客户重要,影响体验 ->>>分工开发(分阶段,里程碑,哪个阶段完成哪些东西)
怎样把项目做好(高质量)客户认同 最重要的是要让客户看到项目的可控性,需要做到以下三点 1.需求阶段: 三家公司,都能做到,选哪一个 抓住客户的需求,如何做到 业务决定技术(一个好的架构师很重要) 认同客户想法: 哪些要砍掉,哪些保留,哪个UI适合你 不是只是完成技术任务,那是初级开发人员干的 好的程序员是告诉你需求,自己去处理 2. 原型阶段: 生成草图,可能只是某个控件,如何跳转,布局 理清流程,整个流程过一遍 3. 设计 UI: 用户喜欢,和潮流符合,不落后 动画,特效 技术: 安全性、业务逻辑序列图看得懂 功能可以横向扩展 不会导致系统完全崩溃,如数据库数据丢失 可测试的
做到上面三点,让客户明白团队在项目的每一个环节都把控的很好,也就会放心了。
出故障如何快速解决问题: 按分钟算故障,自己能不能升值很重要 如何避免? 1. 入口校验,数据进入时校验,也就是服务器校验
有人说客户端校验就行,用所谓的提高性能来说话,其实这种说法是大错特错的。
如果一个项目是因为进行了服务器校验拉低性能,那这个项目一点是搞笑的,连代码层面上的故障都不能排除,还能干什么呢?
或者说,明知道错误的数据很有可能容易出现故障,可以及时处理,但是就是不处理,这是多么的愚蠢,难道要等到以后出错了才处理吗? 2. 异常:日志,可查
日志是一定要有的,在可能出错的地方都给打算日志。 3. 项目流程方案部署文档清晰,知道是哪个地方有问题,部署架构图一定要有
部署架构图有什么用?能让我们了解这个项目的架构,通过日志能够知道定位出错位置 4. 监控系统,配合各种指标,预警:出错能够提醒,访问量爆增,错误日志一直在增加 CPU占用率飙升,磁盘空间达到90% ,JDK FULL GC消耗时间长,响应时间变长 用户数新增的减少(注册故障) 如何监控:涉及调用链,每个接口的调用数记录,智能拦截IP,每个过程跟踪 记得开会的时候有人说专门找人定时查看日志,Leader反问:你觉得可能实现吗?他自己都笑着说不能。
所以说监控系统是很重要的,大家很容易忽略
如何快速解决? 1. 制定应急方案,备份:每个部分都有备份(热备),可以回滚 灰度发布,有100万,用1万用户用到新发布的版本上,其他用旧的,几天没问题,转为50%,最后再100% 2. 异常日志:能打的都打,日志不仅要包含业务的,还有查看与sql连通日志 ,GC日志 我们最常见的就时听到伙伴说在我这里还跑的好好的,到你那里就不行了。 不允许e.printStack(); 3. 代码
用户使用者范围
解决使用者的什么问题
讲解项目内容是有方法的,不要这讲一块,那讲一块,不仅别人不懂,连自己都搞懵了。