正儿八经 - 资深Java/React工程师

浪起来？技术博客与求职信息

0%

发表于

最近在和领导对团队运行的方案。其中有一条是关于考核的，由于团队的动态轮换性，一开始我认为需要有个考核不然团队成员可能就没法认真对待，因为会想反正过一段时间就撤了。

后来看到了陈皓老师写的一篇文章https://coolshell.cn/articles/17972.html。

深表赞同，我一直就对绩效考核深恶痛绝总觉得它在否定我的付出，好像我做的所有事都不是我想做的而是绩效要求我做的。而且老感觉自己有意无意在违背自己的真实想法做事情。

值得警醒的是当自己成为参与规则制定的一员的时候竟然会想到用绩效考核，真是让我无地自容。值得好好深思到底自己哪儿出了问题。

摘抄一句话：

用一颗平常心来面对公司给你打的分数，因为那并不代表你的整个人生。但是，你要用一颗非常严肃的心来面对自己的个人发展和成长，因为这才是真正需要认真对待的事。

我把考核那一条往后挪了，第一条换成了目标达成路径，额外还加上了奖励机制。

考核在某些场景下还是需要的，但是也仅仅是作为一个信息的输入，而不是奉为圭臬。

发表于

最近有疑惑，又在开始看陈皓老师的文章。看到了这篇努力就能成功[1]。做个转载。

摘了其中一段文字，详细请点击原文。

你喜欢这句话吗？
“努力就会成功”，“加班就会有成就”，“勤劳就会致富”……是这样吗？

仔细思考一下，这些话存在严重的逻辑问题，我们在高中的时候学过“充分条件”，“必要条件”和“充要条件”！

“努力就会成功”这句话，把“努力”说成了“成功”的充要条件，这不就是错的吗？努力只是成功的必要条件之一。你在错误的方向或是格局很小的方向上努力，能有用么？你努力地要饭，你努力地当搬运工，你努力地打骚扰电话销卖保险…… 在错误和小格局的方向上努力，你还觉得努力还有用吗？

个人感悟

虽然一直知道努力就能成功不过是一句鸡汤，但是看了这篇文章还是有醍醐灌顶的感觉，work smart和work hard有着本质的区别，一个是通过技能挣钱一个是通过劳动力挣钱。所以应该是通过不断的学习和迎接挑战来提升自己的技能，而不是找个简单的，然后想着用蛮力堆出成功，过程中还把自己感动的一塌糊涂。

References
[1] 努力就能成功: https://coolshell.cn/articles/19271.html

发表于 分类于 ，

最近一段时间在断断续续看老板推荐的一本书《精益产品开发》

背景

最近一段时间在断断续续看老板推荐的一本书《精益产品开发》。

我这人不太爱看书，是因为看书要犯困，我也不知道为啥，我内心是想看书的，但是一看上就打瞌睡，太难受了，所以导致我看书的节奏是只能概看，偶尔能专注（比如遇到难理解的、有兴趣的）。

在这儿记个流水账啦。纯属个人观点，不喜就算了。

开始

XP方法

即极限编程，一开始以为XP是啥没听过的新东西，一查原来就是早有耳闻的极限编程。

这里想说一说，XP里有个点，正是我目前比较推崇且是这么做的-简单设计

极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。也就是不过度设计不追求完美不刻意追求可扩展（需要申明一下当你个人都不清楚或者不确定未来的场景的情况下），以最短的时间和最简单的方式实现。

这儿我不跟任何人抬杠，我目前就是认为“简单设计”是让我体验最好的编程方式。

我从中能获益两点，这两点带给我的正反馈是可以让我放弃追求完美和一定要可扩展的目标的。

  • 时间，通常会加快我对产出的交付，特别是当我扮演的是生产者或者叫被依赖方时，会让使用方的用户体验比较好，比如写后端的时候前端开发者会少一些抱怨和矛盾，比如写前端的时候，产品、UE会比较满意。总体来说，不仅仅只是少花了一些时间，在各方的满意度方面都会有所提升，从而最终个人幸福感得到提升。多说一句，团队为啥搞敏捷，说的直白点，很大的一个因素不就是各位消费方都想尽快看到产出吗？而不是多方动不动就墨迹工期的问题。

  • 可靠性，因为是简单设计，所以满足当前场景的出错概念低，且易于维护。

聚焦价值流动效率，而不是资源利用效率。
这一点是我一直比较坚持的观点（虽然没啥人听我的），只是不知道有这么个专业的词语“价值流动效率”，现在公司几乎我接触过的team，不管是办啥事一上来都是先聊资源问题，往往就把事情聊死了或者需要老大出面了。

其实我觉得，不管啥事先要搞清楚，这个事的背景，是为了解决什么问题，最终对于产品的价值的是什么。这就是我认为的价值流动效率，就是咱们得聚焦于交付的价值，而不是资源问题。

控制在制品的数量
其中有一节讲看板方法的实践，里面说到一个实践：控制在制品的数量。
个人认为，首先产品端要克制，每个迭代不要以故事数来定，而是基于故事闭环以及研发工作量，聚焦最终交付的价值

看板

可视化价值流动

看板系统设计的原则

  • 体现价值

  • 反映协作

  • 暴露问题

  1. 分析价值流动过程
    1. 识别团队交付的价值类型（业务需求、技术改进等）
    2. 确定看板系统的基本流动单元（通常选取工作比重较大的价值类型，比如：业务需求。）
    3. 分析流动单元的流动步骤（分析、开发、测试等）
    4. 识别流动过程中的价值分解和合并（分解为多人完成再合并）
  2. 选取可视化设计元素
    1. 队列。形成的条件：某个状态存在一段时间的停留。比如：开发中、测试中等
      1. 列的划分可以很细，具体细化到哪个级别，依赖于:
        1. 工作是否会在该阶段显著停留。比如：待验证
        2. 使用者是否需要特别关注这些阶段。比如：自测阶段
    2. 泳道。表达流动单元的层级关系，起分割作用，常用的划分依据:
      1. 处理规则的不同，如:业务需求和现场问题。
      2. 需要给予不同的关注，如需求的受益方不一样。
    3. 区域。表示特定信息。
    4. 卡片及标识
  3. 用看板墙建模价值流动过程

显示化流程规则

核心要求：团队成员对流程规则形成一致的理解和承诺。

发表于

最近看到一个视频：如何在六个月内掌握一门外语挺让我惊喜的，里面的内容跟以往我看到的一些教学习语言的内容有挺大不同，做个记录。

开始

两大误解

  1. Talent（需要天赋）
  2. Immersion per se（沉浸式语言环境）

特别是第二点再没看到这个视频之前我一直以为学习一门新语言最好的方式是去到说该语言的环境中，沉浸式体验才能快速学会，看过视频后最起码让我觉得这应该不是最好的方式，因为我回过头来一想，之前在重庆上学的时候因为学校就在重大旁边，所以认识了几个公派留学生，他们在中国留学2年，据我的了解，这些留学生没一人能说超过10句中文，尽管他们天天待在中文的环境。

5个原则

7个动作

发表于 分类于

背景

最近了解到公司在抓研发效能这块，所以也学习学习，了解下相关内容。

研发效能提升

msup分享：

指标定义

指标是养出来的，不是一蹴而就。

分析模型

通常单个指标是不能说明问题的，需要多个指标按照一个分析模型来。

基于场景

基于场景下的实践反向验证指标的有效性

GSM

考察尽量以团队来考核，不要以个人。
不要有奖励，否则最终肯定会变形。

https://mp.weixin.qq.com/s?__biz=MzU1MjAzNjE4NA==&mid=2247484603&idx=1&sn=cc6e8341e604bab54235f9691dc23046&chksm=fb89768cccfeff9a3d4ac30fcdda18137869e486da4dfb9e9dddf3224e5a5f21d6bf301d746b&mpshare=1&scene=1&srcid=0926DpH4CCppnllj3x6aUd34&sharer_sharetime=1664164535153&sharer_shareid=90feac59023ea9aa307820b1dbe10e7f&version=4.0.16.99169&platform=mac#rd

发表于

背景

最近刚深度参与了客户现场一个堆的OOM问题的排查，在这儿简单记录一下使用到的工具。

产品为刚发的第一版，功能还在迭代中。

这个现场，是实验局现场，产品运行了1个多月，突然有一天告诉我们程序在能用和不能用之间反复横跳。

开始

我个人先下个结论。

  1. 对于发布市场的产品版本发生OOM，肯定是由于存在某个外因进而触发了内因引起的。
  2. 对于堆的OOM，很可能不是单点问题，而是多点问题，只是在某个时刻由某个单点触发了而已。

问题：

  1. 为什么突然就OOM？而且一天内发生了多次？
  2. 为什么程序直接被系统级的干掉了，连最后的dump都来不及输出？
阅读全文 »

发表于 分类于

背景

由于最近在查一个OOM问题，所以借机读起了《深入理解Java虚拟机》第三版。简单做个记录。

垃圾收集算法

分代收集理论

大多数垃圾收集器的都应用的理论。

弱分代假说（年轻代）：绝大多数朝生夕灭的对象。
强分代假说（老年代）：熬过越多次垃圾收集就越难消亡。
跨代引用假说

Partial GC（部分收集）:

  • Minor GC/Young GC(年轻代收集)
  • Major GC/Old GC（老年代收集）
  • Mixed GC(混合收集)：JDK 11 ，只有G1有，针对年轻代和部分老年代。
    Full GC（整堆收集）：整个堆和方法区
阅读全文 »