你说尴尬倒是比较好理解，自卑属实不太理解啊。。。

本质就是不断更新 jira issue 的状态，通过各种状态来统计。事实上 jira 并不能提高多少效率，只是对 issue 的追踪比较好，然后可以做一些分析罢了。提升效率还是要从研发流程，沟通基准，自动化程度来做的。毕竟是死板的工具，你只要定规则，那么必定就有漏洞可以钻，一项任务的复杂度，难易程度，都会影响他的工时，人员技术能力以及业务的熟悉程度也会影响它的工时，单纯从 jira 很难解决这些问题，而这些问题又是影响评判的主要因素之一。
我司基本只用 jira 来做：
1. 提需求，投票评判需求
2. bug 追踪，设计好流程，记录原因，解决方案
3. 分析 bug ，某些反复触发或者相关问题，需要梳理重新解决的
4. 一次上线内需求拆分成多个 issue ，这里其实并没有太多作用，只是象征性记录，更多的还是靠组内沟通

送暑假补课班

15 年年底就已经末期了，那会我们公司挂个 iOS 岗位一天能收 200 多简历

感觉没有。。。16 年新款挤牙膏，直接海鲜市场 1.1w 入了 LT2 ，用到 21 年 3k 多出了，入了 M1pro 32+1T

书的内容感觉还是存文件合理些，你要实现的功能再用其他数据库。
比如书先丢到各种云存储中，path 入关系型数据库，做一些分类，收藏，标题搜索等内容。
后续的功能针对书 id 建立笔记，高亮内容等。比如 https://github.com/alienzhou/blog/issues/28

不对外，感觉 git 写点 markdown 就行了

icloud , 主打一个不用操心

0.其实要求不高的话，一个路由器也能覆盖，就是有些地方速度会比较慢
1.网口 2 做柜子的时候设计一下，看是否能留两个面板的位置挖孔，到时候 ap 贴在衣柜里面
2.有线 mesh 网口 1 网口 2 ，感觉应该差不多了，书房可能信号不是那么好

基于关系型数据库 能优化的：
1. 首次 fetch 只查 id ，根据 id 最后获取想要的数据
2. 部分冗余，部分卡顿场景具体分析解决
3. 分表，这个要针对业务场景了，有些情况要就是没法分的
4. 冷数据处理，比如几年前的数据，把它迁移走
5. 建立好索引，优化查询语句
基于 CDC：
1. 做个新的宽表，数据仍旧放在 PG
2. 新宽表放到 ES CH 等地方

想用就下，下了一般不删，让系统自己变成云图标~，时间长了感觉真没用过了，就给删了

@Jinnrry 不用过分紧张，大部分小孩都有二月闹的问题，月子内好带，出月子开始各种胀气，睡不安稳等等问题，抗过去就好了

我觉得这点果子还真是有先见，如果用的还是英特尔的芯片，那我觉得优势不大了，毕竟屏幕触控板外壳，这些慢慢都在接近了，上了 M 系列芯片后，续航真的是拉开英特尔芯片的一大截。真的良好的做到了笔记本的工作场景，好看，轻便，续航不错（偶尔出差），平时连显示器性能也很够，光光做工和质感感觉放到现在都还领先不少

有没有可能争取点别的选择
1. 经常出差武汉，拿上海的工资在武汉工作 hahaha
2. 在上海干几年，以后有机会再回武汉
不然的话，我的建议是直接回，27 也不小了，不如回去发展