出数概要思路

弄清报表意义

解决什么问题
  • 为了解决某一个问题,我需要出一个报表
  • 不针对实际问题的出数都是耍流氓
展示什么现实
  • 事实不能被歪曲
  • 事实有很多,选取合适的事实,说明想说明的现实情况
谁需要看这个报表
  • 谁提出问题
  • 谁解决问题
  • 谁决策

设计报表内容

选取合适的周期
  • 小时报/日报/周报/月报/不定时
选取合适的粒度
  • 时间粒度:分钟/小时/天/周/月
  • 领域:SKU/门店/供应商/仓库
分层次的展示
  • 多粒度

分析事实数据

简单分析:汇总
  • 总计多少数据
  • 有多少case是delay的?
周期内分析:粒度
  • 有问题的SKU占比多少?
  • delay的case占比多少?
跨周期分析:比较
  • 有问题的SKU和上周比较的变化是多少?
  • delay的case比上周减少了多少?
整体分析:业务含义
  • 报表的数字,含义是什么?
  • delay的case比上周减少了10%,意味着什么?

学会写代码

关于代码

合理换行
合理空行
写注释和更新注释
最小变量作用域

关于方法

突出主流程
典型案例-badcase
void doSomething(...){if(? == null) {throw new Exception();} if(a == "") {a = "abc" + name;} List l = new List();for (i in array) {result = aService.aservice(i);if (result == 1) {l.add(result);}} bService.bservice(l); ......}

Icon

1. 主流程和分支流程冗杂
2. 方法篇幅巨大
3. 非常难以阅读


典型案例-改进
void doSomething(...){// 1. 校验参数verifyParameter(...);// 2. 调用a服务List l = handleA(...); // 3. 调用b服务handleB(l); // 4. 其他处理......} void verifyParameter(...) {......}void handleA(...) {......}void handleB(...) {......}

Icon

clean code里面建议
1. 一个类不要超过50行
2. 一个方法不要超过5行

OK,我承认这个有点激进,但是根据经验稍微放宽标准之后是都能做到的
1. 一个类不要超过200行
2. 一个方法不要超过20行

(针对绝大多数case,一定会出现反例,具体问题具体分析)

相信我,都能做到,只是需要一点耐心和脑筋

起个合适的名字

Icon

我们不要最牛的,不要最怪的

我们要的是最“合适”的

注意区分:trim,trimToNull,trimToEmpty

强烈推荐无副作用的方法

关于类

注意类和包的层次
从类开始一次只专注一件事
合理使用继承

方便阅读

Icon

写代码当然要能执行,但是写能执行的代码很容易,我们不纠结一次

我们强调的是写容易阅读的代码

1. 好的代码应该能“自解释”,这需要你有良好的结构/命名/符合通用的设计思路

2. 不好理解的部分才需要注释

3. 最可怕的是写了注释别人都理解不了

设计模式

推荐:静态构造
推荐:builder
推荐:策略

集群操作工具polysh

背景

线上服务集群一般至少有2台机器,并发稍微高点的集群,机器数量就更多了。在公司的运维不够给力,或者还没做到将日志集中处理的时候,查日志就是一件极其痛苦的事情,你每次需要查询某个东西,甚至只是测试一下这个条件,就得要所有的服务器跑一遍。。。有时候还很难一下找到需要的日志。这时候,一个可以批量操作某个规则下机器的工具就必不可少。

总而言之,我们需要有一种方式,可以批量请求线上机器

使用polysh

step 0 : 登陆线上机器
step 1 : 安装polysh
sudo yum search polysh

Icon

很可能查不到这个工具
这时候要刷新yum仓库
sudo yum clean all

sudo yum install polysh.noarch
step 2 : 配置个人信息
...~]$ sudo vi .ssh/config
Host *StrictHostKeyChecking no
step 3 : 运行polysh
[root@l-group1 ~]$ polysh "l-service<1-2>.example.cn1"
ready (2)> m-service.example.cn1 :  17:24:57 up 334 days,  2:23,  3 users,  load average: 0.13, 0.21, 0.24l-service.example.cn1 :  17:24:57 up 334 days,  2:23,  4 users,  load average: 0.10, 0.14, 0.19
ready (2)>