Zacard's Notes

DQC数据质量中心开发沉思

程序员的自我修养

这里主要和大家分享我在开发DQC(数据质量中心)的过程中,对产品需求、架构设计、编码、自我提升这4个环节的反思与经验。

产品需求

产品需求阶段,我们能做什么,该做些什么?

我认为有2点很重要:

  • 沟通:高效沟通,可以减少歧义,加快开发
  • 参与:参与其中,可以减少返工,保持扩展

那如何做到这2点呢?我认为有个非常重要的概念:领域通用语言

领域通用语言

领域通用语言(Ubiquitous Language),其实是DDD(Domain-Driven Design,领域驱动设计)中一个非常重要的概念。但是我认为他适用于每个项目的开发流程。

  1. 什么叫领域通用语言:领域(业务)专家、产品经理、开发、一个团队中的所有人使用的一种公共语言,能够准确表达领域结构的术语
  2. 为什么要用领域通用语言
    • 降低沟通成本:一个团队中的所有人,使用同一种语言,中间没有翻译的过程,也不会产生歧义
    • 提升沟通效率:产品、开发、测试使用同一种语言。产品提需求开发能够准确的明白其意图;测试反馈bug,开发能做准确得知异常模块
    • 加速开发:清晰定义好领域通用语言,也为之后的程序设计也定义了一个清晰的概念(领域模型)
  3. 如何定义领域通用语言
    1. 提炼领域专家的术语:合适的领域术语也将降低系统的使用门槛
    2. 团队成员共同确认:一个团队,一种语言
    3. 领域专家认可:领域专家都无法理解的语言肯定有问题

架构设计

架构设计阶段,我们应该遵循什么原则,应该注意什么?

我认为有一个原则:升维思考,降维攻击

升维思考,降维攻击

之前网上看过一句话:

你所解决问题的复杂度决定了你技术的高度

抛开业务逻辑自身的复杂度,我认为维度越高,复杂度必然也越高。所以我们要在更高的维度思考,才能得到更大的技术挑战和更快的技术成长。

何为高维&低维

我认为的高维->低维:跨部门->跨项目->跨节点->跨线(进)程

想想我们做的技术方案、公共服务、基础类库等,能否做到跨线程、跨节点、跨项目甚至跨部门使用呢?

如何升维思考

先和大家分享一张图:

上图表达的其实是一个4维人看3维人下楼梯。我们可以看到,4维人可以看到3维人下楼梯的全过程。所以我想说的是,我们在更高的维度,可以看到更全面的信息,看到更多的问题。

如何升维思考,我认为要做好2点:

  • 总是递归的在更高维度思考

    例如,写了一段代码,要想想,在跨线程维度,会不会有什么问题?有没有更好的方案适应多线程环境?完了之后再想想在跨节点这个维度是否会有什么问题?有没有适应跨节点维度的更好方案?以此类推…

  • 保持对问题的饥渴和敏感

    例如,popo群里的产品或者前端提的问题我往往第一时间去排查,然后总是想,为什么会出现这样的问题?我能否通过技术手段或者架构设计来屏蔽此类问题?

什么是降维攻击

降维攻击这个词出自《三体》,看过《三体》的同学肯定知道。其大体流程为:

(歌者文明)先把自己改造为低维度生物,而后发动降维打击,投掷“二向箔”使得目标空间的一个维度无限蜷缩,这样,原先的那些同维度的生物,就都被无限压缩挂掉……

例如如下图降维攻击地球:

使用二向箔,无限压缩地球,导致地球上的生物都被压成纸片挂掉。

所以,我总结降维攻击的步骤,如下:

  1. 改造自己
  2. 创造某种有利条件
  3. 发起攻击

再举个通俗例子:

  1. 一个习武之人,戴着眼罩每天苦练听声辨位,终成一位”盲人”武学高手
  2. 将整个武林都带到一个伸手不见五指的小山洞里
  3. 在黑暗中轻松击败所有人

题外话: 这个例子改编自一个网友写的,原文是习武之人戳瞎自己的双眼再苦练,我觉的实在太蠢了,改成戴着眼罩苦练。其实一直不太明白武侠小说中练某种武功为什么会动不动就要自残,比如《xxx宝典》

大家应该都知道,这个例子其实就是《笑傲江湖》里面思过崖的桥段。

所以,降维打击最关键的一步就是别人凭什么愿意跟你进伸手不见五指的小山洞呢?

《笑傲江湖》中的做法是:让别人主动进“小山洞”!告诉整个武林,思过崖里面有各大门派的失传武功秘籍,让大家免费参观。

那我们技术如何降维攻击呢?

技术如何降维攻击

KISS(Keep It Simple & Stupid)原则 - 好用方便,这才是我们技术方案的二向箔。其优点如下:

  • 接入便捷:接入只需引入jar->提供少许配置项->代码有侵入 (接入是否便捷决定了迁移成本)
  • 侵入低:无侵入->低侵入->高侵入 (是否有侵入决定了修改成本)
  • 适用度高:适应多个维度,多种语言 (适应度高低决定了受众程度,kpi)

编码

coding的艺术

认知负载

这里指的是理解你写的代码所需要的思维量。

你写的代码逻辑越清晰,越简洁,理解起来就越容易。

常见错误:

  • 主流程中一堆的get/set。一屏代码可能也就30,40行,结果你一堆get/set占用了20行,不仅代码丑陋,理解起来也相当费劲,这时候特别适合在实体类中出一个静态工厂模式来生成你想要的实体对象
  • 命名混乱。代码尽量要能自解释,命名尤为关键。那如何命名呢?有个相对通用的原则:释义命名选择器,什么意思呢,就是在命名的时候,要描述他们的效果和目的,而不需要表露他们是通过何种方式达到目的

做个调包侠

何谓”调包侠”?就是直接使用开源的jar包,而不用自己写相关的代码逻辑。这样有如下好处:

  • 充分测试:开源代码通常经过严格测试,我们可以省略很大一部分的测试时间
  • 该有的坑,别人都踩过了:我们可以相对正确的使用这个jar包
  • 设计优雅:通常来说,开源代码设计都比较优雅,使用方便
  • 社区支持良好:遇到问题,可以得到社区的支持

    所以,做个调包侠,轻松又愉快,高效不费劲,何乐不为呢?

测试友好

我们这边的测开比其实非常低,一度达到了1:5。所以,QA同学很辛苦,我们要对他们好一点。

如何编写对测试友好的代码呢?我觉得要关注以下2点:

  • 职责单一:职责单一的类/方法,测试目的是明确的。反例就是一堆if/else,不仅代码臃肿,测试也非常不友好
  • 抽象与封装:需要QA测试的,抽象出来(例如主业务逻辑的某个功能,用接口明确定义出来);不需要QA测试的,封装起来(例如一堆get/set操作,封装到实体内部。给他们点空间,不要什么隐私都暴露给他们,好吧)

自我提升

技术道路,如何“打怪”升级?

享受coding

我经常看到开发在码代码的时候,表情狰狞。其实我在写代码的时候是非常乐在其中的。我总是想着我要设计一段多么牛逼,多么优雅的代码,用上xxx算法,不仅高效而且简洁易懂,高度可扩展。秀出强劲的coding能力、设计能力、架构能力…

秀,就完事了

那我们如何才能享受其中呢?我觉得要有如下2点:

  • 成就感:有成就感才能享受coding
  • 认同感:有认同感才能保持coding的激情

具体怎么去做呢?

  • 精细设计:用上xxx算法,xxx设计模式;架构风骚,代码犀利
  • 回头重构:隔一整子,回头看总会觉得有些地方写的跟坨屎一样……继续重构优化

这是一个良性的过程。不仅能不断提高我们的技术能力,还能保持代码的活性,不至于变成一团大煤球僵死的代码。

为什么还是有些同学没法享受coding呢?我觉得是缺乏自信!

自信

青天不算高,人心第一高

我觉得自信真的特别重要,即使是迷之自信,也强过没有自信。

缺乏自信的表现大致有2类:

  • 害怕使用、尝试新技术、新设计

    这类开发害怕使用尝试新技术,担心出了问题,自己解决不了,影响业务开发的进度。我觉得这个问题非常严重,你不能把你学到的技术应用起来,你永远不知道你是否掌握了,学到的是否对的,你永远没法成长。其实这也反映出一些问题:

    1. 代码缺乏review,导致他们对自己的代码没有自信,害怕出现问题
    2. 发布上线规范制定的不够好
  • 觉得自己设计实现的代码或者方案就那样

    这类开发觉得自己的代码就是:一顿操作猛如虎,一看代码渣如雏。

    我经常和这类人说的是:战略上藐视所有人,战术上重视所有人。什么意思呢?就是说战略上,你要知道,你不比任何人差,你的技术也并不比任务人弱多少,你有什么好虚的呢?但是战术上,每个人都可能会有特别的想法意见值得我们去学习吸收。

    总有人要赢,那这个人为什么不能是你呢?

和缺乏自信的人相反,还有一类是超级自信的那种,觉得自己牛逼坏了。那这种情况应该怎么办呢?我们先来看看一张图:

当我们自信心爆炸的时候,我们如何检验自己是在愚昧山峰,还是在平稳高原呢?我觉得要挑战自己。

挑战自己

其实我在工作大概2-3年的时候,突然有一天,我觉得java不就那点东西嘛,我感觉我都会了。什么并发,AQS,锁,自旋锁、重入锁、读写锁、jvm、对象内存分布、gc、框架spring等,我都会啊。我那会觉得我可以做架构师了,然后我做了一个非常明智的决定,我决定去写一个框架,彻底代替spring,以后提到java企业级开发,就是我写的框架了(然后名字都起好了,他不是叫spring嘛,我就叫summer)。然后我大概构思设计了2周,发现我找不到一个点下手,我应该用个什么思想呢?用什么高大上的技术手段呢?然后再过了几天,我突然发现,我连java多线程都不了解了,并发他背后到底做了什么事情?我一度怀疑自己失忆了…

所以,我想说,如果你觉得自己牛逼坏了,不妨多挑战一下自己,比如自己设计个框架啊、写个提升工作效率的小工具等等,你会发现一个不一样的你。

那当我们挑战自己后,陷入迷茫困顿的时候怎么办呢?看书。

看书

付出的是价格,收获的是价值

我那会陷入迷茫的时候,我又做了一个非常明智的决定,看书。所有我感觉我不懂的地方,我都针对的买了相应的书,然后非常庆幸我把大部分书都看完了,至少现在我没有当时的那种啥都不知道,感觉掉入黑洞的焦虑。

  • 如何针对性的看书呢?

    我的做法是,一次性买3本相关领域的书。兼听则明,花几十块钱就能学到3位作者花了2-3年总结的知识,我真是太赚了!

  • 看一本书,其实很快

    很多开发跟我说,技术书都太厚了,看不完。我想说,看一本书,其实很快。我现在每天中午看10-20分钟,大概能看10页,一个月20天大概能看200页。一本稍微厚点的书也就400多页,2个月就看完了!

重要的不是你学习了多少新东西,而是你改正了多少错误,弥补了多少短板,根据你的需要学习了多少新东西

坚持原创技术分享,您的支持将鼓励我继续创作!

热评文章