Mobility

如果你像我一样，需要经常性的访问不同的远程服务器，记录服务器的ip和输入密码就是一件非常痛苦的事情。好在，通过在item2中做一些配置，可以很好的解决这个痛点。最终实现的效果，就是类似配置了一些ssh书签，能够在iterm2中记住ssh密码, 实现免密码登录和自动登录的效果。

技术分享基本在每个公司都会有。分享的效果因人，因团队而异。在有些团队中，分享会因为种种原因，逐渐沦为一个没什么用的时间杀手。

写这篇文章，是希望从选题等方面出发，通过一些比较基础的规则，提升技术分享的下限，争取让80%的人都能做出一次80分的技术分享。

近年来，云原生在整个开源社区中正在成为越来越流行的概念。那么云原生究竟是什么？架构？平台？又能影响什么？系统安全？开发效率？所以我们今天就刨根问底，理一下到底什么是云原生。

《干法》是一本讲工作态度、工作方法的经典书籍。在劳资矛盾严重、阶级趋向固化的今天，是很难完全向该书作者稻盛和夫先生一样，去践行这一套理念的。但这不代表这本书就没有价值了。努力工作，提升自己的价值，一直都是藏在人类内心深处的精神诉求，我们要做的，只是要让价值提升后带来的收益，能够给到我们自己。

在通常的开发流程中，会有各种各样的评审(review)环节，比如产品稿评审、设计评审、测试用例评审、code review等。为了做这些评审，难免会引入一些会议。有的人会觉得这些事没什么用，太浪费时间。而实际上，这些事情是非常重要的，如果你产生了评审不重要的印象，原因无非两个，一是认知不到位，而是你所在的环境评审实施的不好。

今天结合我的个人经历来聊一聊应届生的职业选择问题，主要针对后端开发（对岗位的选择，话题也比较大，后边有机会的话会单独开一篇文章写），我这几年的时间里历经了国企、大公司、小公司这样不同的工作环境，所以对于不同公司的情况还是比较有发言权的。

关于rpc接口的输入和输出，一直有一种观点是将输入和输出都包装成单个request和response类。本文，我们就分析一下这种方式是否是一个合理的设计。

先说输入, 这个我先说结论，当且仅当输入参数过多时，才应该做封装。其他情况下完全没有做封装的理由。

对于将输入参数包装成request类的理由，无非是下边这些

• 修改接口参数时保持兼容性
• 可以定义通用的抽象request类，方便做统一管理

首先，第一条完全就是个伪命题，第一次看到这种论断的时候，我也差一点被绕进去，但是仔细思考一下，就会发现这个完全不成立。

即便使用request体的形式，如果接口提供方增加了必传的字段，调用方仍然需要增加这个参数才能调用，那相比于直接传参数，没有解决任何问题。而这种问题实际上也是无法解决的，因为就不应该让这种情况出现。接口提供方有义务保证后续的修改是向前兼容的。而对于增加的是非必传字段这种情况，即便不包装request类，也可以通过适配器的形式实现新接口并兼容老接口，后续再找机会异步的将老接口下线。

第二条的话，确实存在一定意义。

• 比如在抽象类里加一些统一的请求参数，这一点我认为做在框架里更合适，没有必要暴露在业务代码中
• 再比如添加统一的参数校验，但是单纯为这种效果的话，我觉得用一个过于抽象的类是不合适的，而是应当一类相关的业务用一个抽象类，因为一类业务才会有这种需求。同时，即便不包装成request类，这类需求也没什么难做的，因为它的难度本身就不在输入结构不统一上。

而将输入参数包装成request类的最大问题就是会破坏代码的可读性，会造成语义不明确。本身类似 queryById(long id) 这么一个方法的语义是非常明确的，扫一眼接口定义就可以看清楚输入输出。但是强行封装之后，这个接口究竟要输入什么就不是那么明确了。同时，如果request中有三个参数，是否传入任意组合都能返回结果呢？这也是靠看接口看不明白的。而正常的用参数定义的话，可以使用适配器的形式定义一系列接口，接口调用方也更容易理解。

封装输入参数的唯一条件就是传入参数过多，这时候需要通过其他的方式，比如注释、文档，去约定接口的合法输入值和升级方案。

接下来说输出，将输出结果封装成一个response体，相对于封装输入参数，会合理一些，但也不能乱用。一般将输出结果封装的目的就是包一层返回状态码。

这一点实质上就是强迫调用方来了解接口的异常情况。我们知道，基本的设计原则中有一条叫「接口隔离原则」，其具体描述是 Clients should not be forced to depend upon interfaces that they do not use。对于这儿的情况要类似，如果调用方确实不关心请求成功或者失败的原因，那就不应该强迫调用方来了解这个。比如我就是要查个数，只存在查到或者查不到两种情况，并不想关心到底为什么没查到。

所以，在设计接口的时候，需要慎重的考虑接口的异常原因是否是一个应当提供出去的信息，在此基础上，才能说保障response合适或者不合适。

综上所述，盲目的一味去封装所有输入和输出参数，一定是不可取的。对于何时应该做封装，何时不应该，务必要做慎重的考虑。大家有什么想法的话，也可以跟我沟通。

原文地址：https://lichuanyang.top/posts/20888/

说一下我个人的经历，其实在我刚毕业的第一家公司里，做的就是底层的中间件开发。但是做的过程中，觉得并不喜欢这种远离实际业务的感觉，所以后来换工作的时候就有意的选择了业务部门。所以，今天想讲一下为什么会做这种选择。

大家好，我是流沙。设计模式是每个程序员都会经常接触到的东西，但是相信很多人对于设计模式究竟是什么还会有些疑问。所以，我们今天就聊聊这个，主要目标是帮大家理解设计模式的作用，以及要用什么样的心态对待设计模式。

大家好，我是流沙，一名近六年工作经验的程序员。我的工作经历里，包含了整体文化、氛围差别非常大的公司，和很多不同类型的人合作过，观察到过很多没效率的现象。同时，我一直觉得我自己的开发效率是非常高的。整个职业经历里，我很少在八小时的工作时间外处理任务性的事项。即使有时迫于公司制度不得不进行加班，也是在执行自己的学习计划，或者进行一些深层的思考。因此，我想做一个系统性的关于开发效率的总结，分享给大家。