0%

如果你像我一样,需要经常性的访问不同的远程服务器,记录服务器的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/

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

阅读全文 »

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

阅读全文 »

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

阅读全文 »