Shellj 的博客

因为 Win11 自带的中文输入法占用了 Shift+F6 键 ，并且无法取消设置，导致 Jetbrains 快捷键冲突无法使用，只能把输入法降级到比较老的版本，用了一段时间后打算尝试一下之前使用过的百度输入法，安装上正常使用，没什么问题。 几天后打算试试微信出的微信输入法，把百度输入法卸载，卸载完了之后提示需要重启电脑，拒绝后安装微信输入法，发现切换不了，怎么切换都是百度输入法，根本没有卸载，最后不得已重启了电脑才解决。 很不理解为什么一个输入法需要重启电脑才能卸载。虽然百度产品不怎么样，但我一…

最近公司做了一次比较大的业务调整，很多部门的资源整合到一起，来做一件事情。我们的产品经理给我们大概讲了一下流程(仅仅是一个流程)，然后就问什么时候能做完，What ? 好吧，这其实也是有预见到的，毕竟长久以来都是这个尿性。业务上有一块比较复杂的逻辑需要从现有系统迁移到新的系统，做一个业务临时的过度，后面会开发新的逻辑，在考虑这一块要不要做，有限的时间里来不来得及，然而产品老大(也是团队的负责人)直接说肯定是要的，要是做不出来给个理由，我带你们去老板那里说(其实这里是让找一个甩锅的理由)。开发比较…

三月最后一天，最近是做了不少事情，春节没回家，安排着清明节回家的事情，而且还要处理一下人生大事，对于我的性格来说，这完全是进入到了一种非常不舒服的状态，以往是能不做就不做，这次是没办法了，成家后会越来越多这种情况，得慢慢适应了。 工作上依然做着没太大意义的事情。有时候在想是不是自己太骄傲了，太膨胀了，觉得部门的产品经理都是废物，真希望他们能够拿出实力来打我脸，对于这些人，我是毫不吝惜自己的贬低之词，成天不知道在干什么，做事情总是很应付，当个传话筒他们也是不合格的，总是把真正需求隐藏，而堆砌一堆没…

做一个新需求，看了看产品给的文档，搞不懂他们在搞什么，明明很重要的流程上的逻辑一点都不说，偏偏把一些字段，操作步骤大篇幅的来描述，很多都是废话，而且那文档的格式，乱的一塌糊涂，毫无逻辑可言，真的是 “人人都是产品经理”。 我觉得只要真心的想要做好一件事情，认真的去做，还是不会做的太差的，而且你有一定时间的积累，怎么着也不至于和两三年前的水平一样吧，现在这个公司真的太适合养老的，没什么业绩，考核，很多随随便便的人，我自己有时候都快适应这个环境了。

大多数做技术的人都喜欢追求一些新的技术，都喜欢将其引入生产当中，但当一个不是以技术为主的公司也引入了一些新奇的技术就有一些其他的目的了。 我司最近有一个区块链的项目，有什么用目前不太清楚，追个技术风口？响应一下领导的号召？听起来高大上？至少互联网上的各种币，各种区块链项目的白皮书写的都还不错，我们这个传达到我们这里就只有 “领导想要这个效果”(一张链上资产数据的图) 了。 并不清楚领导真实想要的东西，至少在公司流程上是有些问题的。现在让我们做的是把数据推到链上，展示资产给领导看，如果仅仅是为了…

加完班刚回到家外面就吹起了风，下起了大雨，非常幸运，真的是 God Bless 啊。有雷雨才是夏天呀，很喜欢这种天气，小时候这种天气我妈妈就会在家里招待一些邻居和朋友，或者去邻居家玩，很喜欢这种悠闲的日子。 明天得穿着正式的去公司，上面要检查，这种正式是男士普通 T恤 都不能穿，必须得穿带领子的 T恤 。上面一位领导最近发表了一篇讲话，然后某些部门的人就下发通知要组织大家学习，每一位员工要写一篇学习心得，内容当然主要是销售相关的东西，里面提到了一些衣着方面的东西。行政也没闲着，下发通知严格制…

这几天公司在迁移机房，我也接触了一些老的项目，原来的人几乎都不在了，很多问题只有自己慢慢找，慢慢试，也了解了一些原来项目的一些设计和代码，程序员总是喜欢过度设计系统，想着以后怎样怎样扩展，结果扩展还没扩展，倒是留下了一堆坑。还有一些 Java 代码似乎是写 C# 的人写的，代码括号和命名风格按照 C# 来的，这也就罢了，主要是代码完全没有格式化过，非常乱，现在工具这个强大，随手格式化一些也很简单；Java 里面全是 Map 也是非常厉害了，从 Spring MVC 的 Controller jso…

今天下午开了两个半小时的需求评审，不得不再次说一说问题， 前面 吐槽过一次公司的产品经理，这才没几个月又到了忍不住要写一下的时候了。 上次说他们只是业务方的传话筒，但今天就觉得他们有些人不了解业务，还把话给传错了。比如前几天才上线的一个功能，修改了小功能A，把它改成了B，但今天评审的时候又把A给加回来了，A和B并存，当时就在想是不是你们上次把业务的需求没理解清楚，业务方可能只想要有个B，结果你把别人A给改了。还有一个例子是，在过有一个需求的时候，他们写了很多，非常复杂，感觉现在的技术很难实现，…

 来到这个公司后觉得以前公司的产品经理和策划都挺好的，至少别人能把一件事情给你讲清楚，虽然也修修改改的，但这也是没办法的事情。这个团队的产品经理就不一样了，各种业余的做法。 需求 我们是服务于业务部门的，大多数需求都是业务部门来的，但经常遇到一个问题就是产品经理对来自业务方的需求一点都不消化整理，直接就提给技术让我们来做，很多都是和之前的东西矛盾的，业务很多时候也不知道要什么，反正什么功能都得有，最后搞得业务复杂臃肿，产品如果不整理这些需求那还要他们何用，做一个传话筒？ 需求评审…

负责技术的人前期不管技术，然后到项目完成后再说哪里不对，哪里不符合他的预期。想起来了就盯着日志看哪里有错误，然后马上限定一个时间改完，完全不考虑实际的情况。 一个用户量不大的系统借着微服务之名给拆分成了几十个系统，过度设计，微服务的优点没体会到，缺点倒是都遇上了。过度拆分，业务划分不合理导致服务的耦合性非常大，挂掉一个其他的基本上也不能使用了，分布式事务的缺席导致一些业务的错误。还是简单点好。