1 | # 配置上传账户信息 |
develop-optimization
1. 1. 开发时重新设计内部结构, 不停改动优化改动
- 经验不足, 无法在设计阶段考虑全面
- 没有做全局设计, 没有多层次的思考问题
PDCA 能够不断改进, 但是会耗时, 所以在初期做计划(设计)的时候尽量全面.
2. 2. 逐点测试
逐点测试意思是一个bug点测一次, 逐步跑通整个业务过程.
但是每次从修改到服务启动, 再测试, 整个过程就变的缓慢了.
本地热部署调试, 减少发布服务消耗的时间.
如何说服别人
说服他人时, 最好从对方的切身利益出发, 而非理性.
相对于得到新东西, 人们更害怕失去已经拥有的东西.
既然如此, 利用人类这一恐惧心理 – 害怕失去有价值的东西: 工作, 名声, 金钱, 地位, 控制力等, 成功率就越大.
— 投资大家芒格2-探索智慧: 从达尔文到芒格
认知, 区别和理解
量子纠缠大概讲的是 2 个原本耦合的粒子分开后仍然相互影响.
这是不是多维空间的秘密?
比如一根绳子从一张纸的一点穿过, 再从另一点穿回来. 从纸的正面看来, 是 2 条在纸上不相干的绳子. 但是扯动其中一根绳子, 会带动另一根. 原因是在纸的背后, 绳子其实是连着的, 这本来就是一根绳子, 只是我们没看到纸的背面. 从多维空间的角度来讲, 绳子的背面在更高的维度, 我们的观察看不到.
所以许多事情, 在我们的认知范围之外, 只是我们并不知道他们的联系.
我们应该多观察, 多学习, 多思考, 提高对事物的敏感性, 才能触摸到那些看不见的联系.
另外, 既然是因为观察事物的角度不同而导致认识的不同, 那么多从不同角度观察, 就能更全面的认识事物. 通常我们的建模, 就是用于认识事物. 把事物罗列出来, 事物和事物之间的关系标识出来, 就是建模. 而日常生活中的换位思考, 体谅他人也是这个道理.
我们不喜欢不确定或未知的东西, 所以我们需要总结, 归类, 组织和构建整合世界.
把思想和物体进行归类, 有助于我们认知, 区别和理解, 它让生活简化了.
理解和控制我们的环境有助于更好的应对未来.我们要知道事情发生的过程和原因, 才能在未来更好的预见它.
这也是我们总是喜欢寻找模型和各种事物, 行动以及情境等因果关系的原因.
根据这些模型的相似点, 人们更容易分类, 理解以及作出推测.
寻找和识别环境中的事物以及事情之间的联系, 能帮助我们什么有效, 什么无效.
---- 投资大家芒格2-探索智慧: 从达尔文到芒格
nohup
1 | nohup command > myout.file 2>&1 & |
思维训练
被动收入
房产
- 房租
- 炒房
理财
- 股票
- 基金
- 利息
IT
- 广告
- Google Adsense
- 商品推广
- 京东
- 拼多多
- 淘宝
- 自媒体
- 公众号
- 知乎
- 简书
- 今日头条
知识产权
- 专利
- 版权
- 商标
后端开发技能
- 数据结构
- 数组, 队列和链表的实现原理
- 快速/归并排序算法
- sql
- 复杂统计 sql
- 优化
- java
- 反射
减少代码和避免性能问题 - 集合
知道并发集合类的场景和实现 - io
了解实现并能正确使用 - 泛型
知道java 对泛型的实现 - oop
熟悉常用设计模式 - JDBC
特点数据库驱动实现 - NIO/AIO
了解基于NIO的框架实现 - 多线程
多线程的实现机制和原理 - JVM
JVM调优和性能优化 - 字节码
能修改字节码, 具备应用字节码的能力 - 序列化/反序列化
了解序列化的原理和实现方法 - servlet
能够自行实现Servlet规范 - 连接池
自己实现连接池
- 反射
- 常用框架
- spring
- mybabis
- quartz
- guava
- 中间件
- 消息
- 缓存
- NoSQL
- Web Server
- Web Proxy
- LB
- 专长
- SOA
- 分布式
- 高并发
- 高可用
- 工具
- docker
- git
- maven/gradle
- 分析/设计
- DB 设计
- UML 模块设计
- 开源项目
- Linux
- 性能调优
- 其他语言
- 团队表现
- 安全知识
专业软件开发者必备:
设计模式. 必须能描述 GOF 书中的全部 24 种模式, 同事还要有 POSA 书中的多数模式的实战经验.
设计原则. 必须了解 SOLID 原则, 而且要审核理解组件设计原则.
方法. 必须理解 XP, Scrum, 精益, 看板, 瀑布, 结构化分析及结构化设计.
实践. 必须掌握测试驱动开发, 面向对象设计, 结构化编程, 持续集成和结对编程.
工件. 必须了解如何使用 UML 图, DFD 图, 结构图, Petri 网络图, 转台迁移图表, 流程图和决策表.
技能/技巧 专业知识
需求管理
预估
PERT
决策
时间管理
番茄工作法
注意力
协作
质量
测试
时间管理法
将事情按 重要 与 紧急 程度划分到四个象限中
紧急程度的判断就是看时间的紧迫性, 很容易区分;
重要程度则必须按照自己的人生目标和人生规划来衡量这件事的重要性.
- T0: 重要且紧急
必须优先处理 - T1: 重要但不紧急
有计划的处理该类事件, 避免拖延, 将事件升级至 T0 - T2: 紧急但不重要
条件允许的情况下, 授权给他人处理 - T3: 不紧急也不重要
尽量不做, 或者少做
| Level | Example |
|---|---|
| T0 | 跟切身利益有关的事 |
| T1 | 休息 |
| T2 | 生活琐事 |
| T3 | 游戏 |
1. 时间分配
黄金时间: 9~12 比较难, 需要深度思考的工作
次黄金时间: 14~16 不需要特别思考, 偏执行的工作
常规时间: 16~18 处理比较琐碎的事情
碎片时间: 无规律, 一直坚持在做的事情
一件事情需要多久才能完成, 取决于分配给这件事的时间
崔西定律: 任何事情的复杂程度与其执行的步骤数目的平方成正比
缓存常见问题
1. 常见问题
1.1. 代码耦合
假如业务代码中交织大量缓存相关的代码, 会增加维护工作量
可以使用 aop 的方式, 将缓存代码剥离出来, 集中在一起, 提高代码的可重用性和可维护性.
可以参考
以及 qiujiayu/AutoLoadCache
1.2. 缓存冲突
在多模块开发中, 可能有多个模块使用同一个 key 的问题
解决办法:
- 在每个 key 之前加上一个 namespace, 用来标识区分不同模块的缓存
- 在 redis 中, 也可以让不同的模块使用不同的 database 的方式
1.3. 缓存穿透
@TO-BE-CONTINUE 2020-04-27
1.4. 缓存雪崩
突然在某一时刻, 有大量的缓存失效, 导致大量查询请求涌向数据库. 如果数据库顶不住压力, 就会连锁导致服务报错与超时, 然后请求等待时间过长后, 服务不可用
解决办法:
- 在使用缓存时, 如果发现缓存即将失效, 则通过异步队列刷新缓存
- 使用查询锁的方式, 同一个缓存的查询, 保证只有一个线程处理, 防止大量重复查询