如何写日报

写日报的意义

对自己的意义
  • 梳理思路:对自己思路的整理
  • 总结思考:对当前工作的总结,同时也是反思“如果再做一次能不能做的更好”
  • 未来预期:对未来(接下来一天或多天)工作的展望

预期很重要

没有预期很容易造成节奏缓慢,目的性不强等问题

在开始工作之前有合理的预期,是达成目标的开始

对组织的意义
  • 成员间相互了解
  • 相互了解对方做的事
  • 相互监督和帮助

开始写日报

思考并开始
  • 给自己15分钟时间

5分钟思考,10分钟撰写并修改

不要花费过长的时间,日报15分钟足够了

日报毕竟只是一个简洁的总结,如果针对某一个事项或者问题有深入的分析,可以单独wiki中填写,在日报中填写链接

  • 量化思考

少用/不用形容词

多用数字,从数字中明确结果和期望

当前的工作
  • 手上有几件事,整体期望是啥样

分清楚主次

哪些事情是主要工作,哪些工作是临时工作和突发工作(比如排查问题)

哪些事情投入了多少精力,占用了多少时间

  • 每件事情的进度,以及是否满足期望

计划当日完成哪些工作,什么进度

实际当日完成哪些工作,什么进度

如果进度提前了,为什么

如果进度落后了,为什么,怎么解决(能不能追回来)

  • 事情的结果和分析

结果是什么样?

结果之后是否要需要关心?(功能上线就结束了么?)

如何分析结果之后的效果?(线上的使用率,正确率,等等)

遗留工作/接下来的计划
  • 和以上很像

几件事情,分别是什么,整体期望是啥样

接下来一个/几个工作日的期望是啥样,如何量化说明

遇到的问题

把自己遇到的问题分享出来,当然也不是什么问题都需要分享

a. 有普遍性的,别人也会出现的问题

b. 比较严重的问题,有一定深度的问题,可以采用贴wiki的方式

c. 没有解决/不好解决/解决成本比较高的问题

几个关键字

预期

首先得有“这个事情应该什么样”

在这个基础上谈“怎么做”

最后总结“做到了什么程度”

量化

尝试量化工作,并用量化的结果衡量进度

避免宽泛的形容词:完成一小部分,完成大部分,基本完成

避免无意义的量化:(第一天)完成90%,(第二天)实现95%

主次

弄清楚哪些是主要工作(需要结合OKR,当前业务重点,等等),哪些是临时/突然工作

分析清楚两者的占比

是否真的在主要工作上投入了恰当的精力?

是否在非主要工作上过多的投入了精力?

思考

发现问题,解决问题

不能麻木的看见问题也放着不管

有问题,思考,寻找解决方案,然后解决

学会写代码

关于代码

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

关于方法

突出主流程
典型案例-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)>