Mobility

《干法》是一本讲工作态度、工作方法的经典书籍。在劳资矛盾严重、阶级趋向固化的今天，是很难完全向该书作者稻盛和夫先生一样，去践行这一套理念的。但这不代表这本书就没有价值了。努力工作，提升自己的价值，一直都是藏在人类内心深处的精神诉求，我们要做的，只是要让价值提升后带来的收益，能够给到我们自己。 在读这本书之前，我强烈建议先认真思考一下你和工作的关系究竟是什么样的。如果你就是公司的老板，那没什么好说，公司的收益就是你的。如果你不是，那就要理一理你创造的价值去了哪，是有了经济收益，有了能力的提升，有了将来可以成为自己能力证明的资历，还是帮老板多买了两辆跑车呢？ 之前读过一篇文章，说是将你自己当做一家公司来经营，将任职的公司当做自己的客户。我觉得这是一个很好的思考的思路，你需要考虑你这家「公司」，是立刻就去追求现金收入，还是先打磨能力与口碑，以期将来去获得更大的收益？要考虑与任职公司的交易是否公平？ 想清楚了这些，再来读《干法》这本书。否则，你可能会觉得这本书是马老师写的。话说回来，马老师确实也在践行这本书的很多理念，在他当英语老师的时候。没有当年“业余”时间的辛勤奋斗，哪里来今天的...

为什么需要 Code Review在通常的开发流程中，会有各种各样的评审(review)环节，比如产品稿评审、设计评审、测试用例评审、code review等。为了做这些评审，难免会引入一些会议。有的人会觉得这些事没什么用，太浪费时间。而实际上，这些事情是非常重要的，如果你产生了评审不重要的印象，原因无非两个，一是认知不到位，而是你所在的环境评审实施的不好。 Review 对团队的价值关于评审的价值，首先对于团队来说，最大的作用其实就是提升团队的下限。试想一下，如果各个环节都不进行评审，而是直接产品交付一个产品稿，开发就对着开发，任何个人的疏忽都会给整个项目带来无尽的风险。多次的评审环节，实际上就是将一个业务方案，分别用产品稿、代码、测试用例等形式描述，再分别引入更多的人来检查，避免一个人的疏忽造成业务上的风险。 此外，本文的重点，我实际上是想讲讲除了给团队带来的价值外，对于一个个体的人来说，参与评审有什么价值。 Review 对被审查者的价值首先说一下对于被评审的人，即产品稿、代码等的提交人来说，评审就是一个其他人来帮助你提升的过程，是难得的能获取直接的反馈信息的机会。其实...

今天结合我的个人经历来聊一聊应届生的职业选择问题，主要针对后端开发（对岗位的选择，话题也比较大，后边有机会的话会单独开一篇文章写），我这几年的时间里历经了国企、大公司、小公司这样不同的工作环境，所以对于不同公司的情况还是比较有发言权的。 四个维度的取舍职业选择，最重要的无非就是城市和公司选择。城市选择是一件非常主观的事情，比如我，作为一个北方人，既不喜欢南方城市的气候，又想离家近，还需要大城市的机会，北京就几乎成了唯一选择。当然，给大家的建议，功利点的话，建议选择一些快速发展中的强二线城市，比如重庆、合肥，这样随着城市平台的发展，你自己身处其中，身价也会提升。 接下来，我会限定在北京的范围内，结合我自己的经历，说一下公司的选择。 户口：一线城市的入场券提到北京，一个不得不提的问题就是户口的问题。不过，我强烈不建议你依据一个户口就决定了整个人生怎么走，比如明明不想进体制内，却为了个户口就去了。务必在考虑户口问题之前，优先想好职业发展方向的问题。 很多人会纠结于体制内/体制外、大公司/小公司这些明面上的选择，但这些其实都只是表象而已，同样是体制内，也可能有天差...

问题的提出关于rpc接口的输入和输出，一直有一种观点是将输入和输出都包装成单个request和response类。本文，我们就分析一下这种方式是否是一个合理的设计。 输入参数封装分析先说输入, 这个我先说结论，当且仅当输入参数过多时，才应该做封装。其他情况下完全没有做封装的理由。 对于将输入参数包装成request类的理由，无非是下边这些 修改接口参数时保持兼容性 可以定义通用的抽象request类，方便做统一管理 首先，第一条完全就是个伪命题，第一次看到这种论断的时候，我也差一点被绕进去，但是仔细思考一下，就会发现这个完全不成立。 即便使用request体的形式，如果接口提供方增加了必传的字段，调用方仍然需要增加这个参数才能调用，那相比于直接传参数，没有解决任何问题。而这种问题实际上也是无法解决的，因为就不应该让这种情况出现。接口提供方有义务保证后续的修改是向前兼容的。而对于增加的是非必传字段这种情况，即便不包装request类，也可以通过适配器的形式实现新接口并兼容老接口，后续再找机会异步的将老接口下线。 第二条的话，确实存在一定意义。 比如在抽象类里加一些统一的请...

说一下我个人的经历，其实在我刚毕业的第一家公司里，做的就是底层的中间件开发。但是做的过程中，觉得并不喜欢这种远离实际业务的感觉，所以后来换工作的时候就有意的选择了业务部门。所以，今天想讲一下为什么会做这种选择。 我为什么不做底层开发首先，我想说一个很多人的认知，就是认为做底层的开发更容易学到东西，成长更快。我觉得这就是业务开发同学的臆想而已，底层开发没有大家想的那么利于学习，业务开发也没有大家想的那么不利于学习，原因我会在后边展开说。而之所以很多人有这样的认知，很大程度上是因为底层开发的招聘标准通常会高一些，所以这些人本身的学习能力和意愿就是要好一些。 其实底层开发的日常和业务开发也没有太大区别，都是在做需求。只是业务需求的来源是产品经理，底层需求的来源是其他开发，或者底层开发者本人的思考和想法。这里，我要说自己为什么不愿意做底层开发的第一个原因了，就是需求的来源不科学。首先，如果只做底层开发，而脱离了实际业务场景的话，对于技术的认知很可能是有偏差的，这样导致自己想做的一些事很可能是在自嗨，并没有实际应用价值。而如果从其他那些搜集需求呢，也会有类似的问题，业务开发的同学提出的...

大家好，我是流沙。设计模式是每个程序员都会经常接触到的东西，但是相信很多人对于设计模式究竟是什么还会有些疑问。所以，我们今天就聊聊这个，主要目标是帮大家理解设计模式的作用，以及要用什么样的心态对待设计模式。 前置知识提到设计模式，其实首先需要理解清楚的是面向对象思想。相信大家即使不能非常清晰的描述出来，对面向对象也应该是比较熟悉的。 我们就快速讲一下，面向对象有四大基本特性：封装、抽象、继承、多态； 封装：仅暴露有限的接口，授权外部来访问。将逻辑集中，因此更可控；可读性、可维护性也更好；易用性也更好。 抽象：隐藏方法的具体实现，让调用者只需要关心方法提供了哪些功能，并不需要知道这些功能是如何实现的。 继承：好处就是代码复用。 多态：子类可以替换父类。提高代码的可扩展和可复用性。 什么是设计模式设计模式是针对软件开发中经常遇到的一些设计问题，根据基本的设计原则，总结出来的一套实用的解决方案或者设计思路。 可以看到，设计模式是非常偏实际应用的，相比设计原则更加具体、可执行。 因此，在了解设计模式之前，就需要了解一些基本的设计原则。这些原则才是指导我们写出好代码的关键。 那么什么是...

大家好，我是流沙，一名近六年工作经验的程序员。我的工作经历里，包含了整体文化、氛围差别非常大的公司，和很多不同类型的人合作过，观察到过很多没效率的现象。同时，我一直觉得我自己的开发效率是非常高的。整个职业经历里，我很少在八小时的工作时间外处理任务性的事项。即使有时迫于公司制度不得不进行加班，也是在执行自己的学习计划，或者进行一些深层的思考。因此，我想做一个系统性的关于开发效率的总结，分享给大家。 首先，列两个非常没效率的场景。 小A开发过程中碰到一个没见过的报错，于是抱着电脑去找团队里的大牛小X, 小X努力的搜集相关的各种必要信息。与此同时，小A就在旁边看着，并且不时的和小X还有旁边的小Y聊着天。 小C拿到一个大型需求，匆匆看了一遍，接着就开始开发。开发一半了，发现产品稿上有个点看不明白，又去和产品问。问的过程中产品又想起来别的事，又说了起来。最后聊了半天，小C发现自己之前的工作基本白做了。 虽然有夸张的成分，但是这些事也是确实每时每刻都在发生的。造成这些现象的原因很多，我们今天就好好剖析一下。在剖析效率问题之前，我们需要先看看程序员日常都要做哪些事。其中对工作效率影响比...

对于一个程序员来说，日常最常说的词恐怕就是「复杂」了，这段代码太复杂了，这个逻辑太复杂了，所以，在这篇文章里，我们就好好掰扯掰扯「复杂」到底是怎么产生的，又要怎么去避免。 复杂度的产生我们先列一下当我们在说「复杂」的时候，到底在说什么。 没有模块划分，整个一大坨代码摊在那儿 大量的重复代码 代码整体逻辑看不懂 本来一个很简单的需求，改的时候发现这也要改，那也要改 代码没办法迁移，没办法复用 整天有莫名的bug出现 … 上边列的这些问题，其实很多之间是互为因果的，比如模块划分的不好，导致了代码逻辑看不懂，也导致了代码没法复用，代码没法复用，又导致了大量重复代码，重复代码又进一步导致代码逻辑看不懂。 所以，下面我们尝试着规整一下这些问题，看看问题到底在哪。 我觉得，首先可以把代码复杂度的问题简单分个类，一类是代码本身的问题，一类是代码对现实世界的表现力的问题。前者主要关乎代码整体的整洁程度，以及容不容易进行持续的维护；后者则主要影响代码容不容易理解，别人看代码时是否需要大量的背景知识。 对代码本身问题来说，以我的观察，导致代码过度复杂的首要原因就是模块拆分不清晰，甚至没有模块...

什么是信息衰减看到这个标题，是不是有种要讲信息学的感觉。其实并不是，只是最近观察到一些事情，有些感触所以说一下。最近在网上碰巧看到过两个言论，恰好事实我是比较了解的，所以感慨，二手的信息实在不可信。 实际案例第一个，是北京西城德胜片区有一个小学叫三帆附小，因为可以直升三帆中学，这个在西城数一数二的初中，所以一直十分火爆。这个学校今年因为教室不够，招生由七个班缩减到了四个班，所以卡了落户四年，即落户不足四年的都要调剂。其实，调剂也不差，因为调剂校里有西城排名前五，而且学位极度充足的西师附小，也有雷锋消息这样的优质直升校。甚至有人买三帆附小学区房就是为了去调剂，因为西师附小的学区房要更贵。 然后，在一个公众号的高赞评论里，看到了「德胜」今年卡落户「两三年」这样的言论，言论作者还顺便以此为依据表达了对买学区房这种行为从智商上的鄙视。 衰减的三个层次结合事实和最后言论，其实大概猜的出整个传播链条中信息的变化。德胜的三帆附小逐渐变成了德胜，卡落户四年变成了落户两三年的被调剂，又变成了卡两三年。同时，调剂去的是西师附小这种关键信息被丢失。 第二个事，上周望京地区除了新冠的病例，然后各个社...

从今年十一左右开始看房，到上个月初就定了下来。其实没想到会定那么快，只能说缘分到了吧。回想起当时的经历，感觉还是要记录一下，毕竟是人生中最大的几件事之一了。 背景与需求其实从年初孩子出生就在考虑买学区房的事情了，不过自己本来房子要到明年初才满五，没法赶在西城731政策之前上车了，算是有点小遗憾。 首先针对要不要买学区房，我比较认同网上的一类观点：买房子实际上是在买圈子。买的是你的邻居是些什么人，你的孩子要和什么人做同学。同样价格，有的人会选择学区好一点，住的差一点，有的人会想住的舒适一些，学区差点。想了想，我还是愿意和第一类人混一起。 因此最后和爱人定下了基本的基调：在保障基本居住质量的前提下，去追求能力范围内最好的学区。算了下预算，期望控制在850万左右，最高不超过950万。户型别太差的小两居就可以。 看房区域分析首先做了一轮初步筛选，海淀大部分地方因为离我们俩工作地都太远，所以都不再考虑了。金融街的价格压力太大，因此首先将范围缩小到西城的月坛和德胜两个片区，先看看房子情况。 十一期间先去月坛看了次房子，主要是育民对口的小区，白云观、白云路、汽南、真武庙啥的。说实话，心理落...