写点什么

大师级程序员,都用哪些工作法?(下)

  • 2019-05-31
  • 本文字数:3436 字

    阅读完需:约 11 分钟

大师级程序员,都用哪些工作法?(下)

你好,我是郑晔,《10x程序员工作法》专栏作者,火币网首席架构师。


程序员是一个忙碌的职业,与这个职业联系在一起的词儿,通常是忙碌、加班、熬夜、过劳、亚健康……当忙碌成为了主旋律,“高效”一词就自然浮出了水面。


可是,程序员工作效率是由编程能力决定的吗?答案是“未必”。


这些年,我一直在研究一件事儿:为什么那些大师级程序员,可以兼顾 N 倍于一般人的工作,还有条不紊?他们究竟用了什么工作法?根据我的观察与总结,他们往往绕不开四个工作原则。


「大师级程序员,都用哪些工作法?(上)」中,我给大家介绍了“以终为始”和“任务分解”这两个工作原则,相信你对 DoD、精益创业、微操作等有了一定的认知。下面,我给大家继续介绍另外两个工作原则:沟通反馈和自动化。

沟通反馈

可视化:技术雷达

ThoughtWorks 技术雷达用来追踪技术,通过可视化的方式给程序员提供了一种更系统、直观地了解新技术的方式。



在雷达图中,组织技术的方式也并不复杂。每一项技术表示为一个 blip,也就是雷达上的一个光点。然后用“象限”(quadrant)和“圆环”(ring)组织这些 blip。


其中,象限表示一个 blip 的种类,目前有四个种类:技术、平台、工具和语言与框架。圆环表示一个 blip 在技术采纳生命周期中所处的阶段,目前这个生命周期包含四个阶段:采用(Adopt)、试验(Trial)、评估(Assess)和暂缓(Hold)。


雷达图是一种很好的将知识分类组织的形式,它可以让你一目了然地看到了解所有知识点,并根据自己的需要,决定是否深入了解。


比如,每次技术雷达发布之后,我会特别关注一下“采用”和“**暂缓”两项。“采用”**表示强烈推荐,我会去对比一下自己在实际应用中是否用到了,比如,在 2018 年 11 月的技术雷达中,事件风暴(Event Storming)放到了“采用”中。


“暂缓”则表示新项目别再用这项技术了,这会给我提个醒,这项技术可能已经有了更优秀的替代品,比如,Java 世界中最常见的构建工具 Maven 很早就放到了“暂缓”中,但时至今日,很多人启动新项目依然会选择 Maven,多半是不了解技术趋势。


在我看来,雷达图不仅仅适用于组织,也可以适用于团队。


我也曾经按照雷达图的方式将自己的团队用到的技术组织起来。把最需要了解的技术必须放在内环,比如:一个 Java 项目,我会要求程序员了解 Java,向外扩展的就是你在这个团队内工作会逐渐接触到的技术,像 Docker 这种与部署相关的知识。至于最外面一层,就是被我们放弃掉的技术,比如,Maven。


这样一来,团队成员可以更清晰地了解到团队中所用的技术。当有新人加入团队时,这个雷达可以帮助新人迅速地抓住重点,他的学习路径就是从内环向外学习。


出自第23讲|可视化:一种更为直观的沟通方式

Fail Fast

写程序有一个重要的原则叫 Fail Fast,遇到问题,尽早报错。


很多人以构建健壮系统为由,兼容了很多奇怪的问题,反而会把系统中的 Bug 隐藏起来。靠 debug 来定位问题是最为费时费力的一种做法,别怕系统有问题,有问题早点报出来。


举个例子,我做了一个查询服务,可以让你根据月份查询一些信息,一年有 12 个月,查询参数就是从 1 到 12。


问题来了,参数校验应该在哪做呢?如果什么都不做,这个查询参数就会穿透系统,传到你的数据库上。如果传入的参数是合法的,当然没有任何问题,这个查询会返回一个正常的结果。但如果这个参数是无意义的,比如传“13”,那这个查询依然会传到数据库上。


事实上,很多不经心的系统就是这么做的,一旦系统出了什么状况,你很难判断问题的根源。在这个极度简化的例子里,你可以一眼看出问题出在输入参数上,一旦系统稍具规模,请求来自不同的地方,这些请求最终都汇集到数据库上,识别来源的难度就会大幅度增加。尤其是系统并发起来,很难从日志中找出这个请求的来源。


你可能会说,“为了方便服务对不同数据来源进行识别,可以给每个请求加上一个唯一的请求 ID 吧?”看,系统就是这么变复杂的,我经常调侃这种解决方案,就是没有困难创造困难也要上。当然,即便以后加上请求 ID,理由也不是这个。


稍有经验的人都知道,参数校验应该放在入口的位置上,不合法的请求就不让它往后走了。这种把可能预见的失败拦在外面的做法就是 Fail Fast,有问题不可怕,让失败尽早到来。


上面这个例子很简单,我再给你举一个例子。如果配置文件缺少了一个重要参数,比如,缺少了数据库最大连接数,你打算怎么处理?很多人会选择给一个缺省值,这就不是 Fail Fast 的做法。既然是重要参数,少了就报错,这才叫 Fail Fast。


出自第27讲|尽早暴露问题: 为什么被指责的总是你?

自动化

SOLID 原则

《敏捷软件开发:原则、实践与模式》的作者 Robert Martin 提出的面向对象设计原则:SOLID,为软件设计的目标“高内聚、低耦合”提供了很好的指导。“SOLID”其实是五个设计原则的缩写,分别是


  • 单一职责原则(Single responsibility principle,SRP)

  • 开放封闭原则(Open–closed principle,OCP)

  • Liskov 替换原则(Liskov substitution principle,LSP)

  • 接口隔离原则(Interface segregation principle,ISP)

  • 依赖倒置原则(Dependency inversion principle,DIP)


什么是单一职责原则呢?Robert Martin 把单一职责原则的定义修改成“一个模块应该仅对一类 actor 负责”,这里的 actor 可以理解为对系统有共同需求的人。


这可能不是很好理解,我举个例子你就懂了。在一个工资管理系统中,有个 Employee 类,它里面有三个方法:


  • calculatePay(),计算工资,这是财务部门关心的。

  • reportHours(),统计工作时长,这是人力部门关心的。

  • save(),保存数据,这是技术部门关心的。


之所以三个方法在一个类里面,因为它们的某些行为是类似的,比如计算工资和统计工作时长都需要计算正常工作时间,为了避免重复,团队引入了新的方法:regularHours()。


接下来,财务部门要修改正常工作时间的统计方法,但人力部门不需要修改。负责修改的程序员只看到了 calculatePay() 调用了 regularHours(),完成了他的工作,财务部门验收通过。但上线运行之后,人力部门产生了错误的报表。


如果你问程序员,为什么要把 calculatePay() 和 reportHours()放在一个类里,程序员会告诉你,因为它们都用到了 Employee 这个类的数据。


但是,它们是在为不同的 actor 服务,所以,任何一个 actor 有了新的需求,这个类都需要改,它也就很容易就成为修改的重灾区。更关键的是,很快它就会复杂到没人知道一共有哪些模块与它相关,改起来会影响到谁,程序员也就越发不愿意维护这段代码了。


人的大脑容量有限,太复杂的东西理解不了。所以,我们唯一能做的就是把复杂的事情变简单。我在“任务分解”模块中不断强调把事情拆小,同样的道理在写代码中也适用。单一职责原则就给了你一个指导原则,可以按照不同的 actor 分解代码。


出自第34讲 | 你的代码是怎么变混乱的?

领域分层

分层,实际上是在构建抽象,构建抽象,最核心的一步是构建出你的核心模型,核心模型就是表达你业务的那部分代码。换句话说,别的东西都可以变,这部分不能变。


这么说有点抽象,我们回到前面提到的三层架构的演变:REST 服务的兴起,让 Controller 逐渐退出了历史舞台,资源层取而代之。换句话说,访问服务的方式可能会变。


放到计算机编程的发展中,这种趋势就更明显了,从命令行到网络,从 CS(Client-Server) 到 BS(Browser-Server),从浏览器到移动端。所以,怎么访问不应该是你关注的核心。同样, 关系型数据库也不是你关注的核心,它只是今天的主流而已。从前用文件,今天还有各种 NoSQL。


如此说来,三层架构中的两层重要性都不是那么高,最重要的是剩下的部分,我们习惯上称之为服务层,但这个名字并不能很好地反映它的作用,更恰当的说法是“领域模型”(Domain Model),它便是我们的核心模型,也是我们做软件设计时,真正应该着力的地方。


为什么“服务层”不是好的说法呢?这里会遗漏领域模型中一个重要的组成部分:领域对象。很多人理解领域对象有一个严重的误区,认为领域对象属于数据层。数据存储只是领域对象的一种用途,它更重要的用途还是用在各种领域服务中。


由此还引出另一个常见的设计错误,领域对象中只包含数据访问,也就是常说的 getter 和 setter,而没有任何逻辑。如果只用于数据存储,只有数据访问就够了,但如果是领域对象,就应该有业务逻辑。比如,给一个用户修改密码,用户这个对象上应该有一个 changePassword 方法,而不是每次去 setPassword。


出自第35讲| 总是在说MVC分层架构,但你真的理解分层吗?


内容选自极客时间10x程序员工作法专栏


2019-05-31 17:5112816
用户头像

发布了 22 篇内容, 共 14.4 次阅读, 收获喜欢 49 次。

关注

评论

发布
暂无评论
发现更多内容

数字货币持币生息钱包系统开发案例

全球第一个 Serverless Redis 服务:Lambda Store 免费用

donghui

redis Serverless Lambda Store

区块链交易所系统开发,合约交易模式软件方案

架构师 3 期 3 班 -week5- 作业

zbest

作业 week5

十日谈:我的 2020

escray

2020 七日更 十日谈

Linux安装MySQL标准教程

Simon

MySQL centos 安装 七日更

盘点2020 | 云上建站流程全解,教你如何节约成本

老魚

云服务器 建站 盘点2020 web全栈

突破某度云盘下载限速,提速30倍!想学?我教你啊

Silently9527

百度云 HTTP

数字货币交易所币币OTC交易系统开发

RPC 核心,万变不离其宗

yes

Java 微服务 后端 RPC

Java并发编程:AQS的互斥锁与共享锁

李尚智

Java Java并发

FGC青蛙钱包系统开发|FGC青蛙钱包软件APP开发

系统开发

智慧平安小区搭建,智慧社区综合服务平台开发

t13823115967

智慧城市 智慧社区管理平台开发

第十三周 学习总结

熊桂平

极客大学架构师训练营

Flutter动态创建UI实现方案

FisherJoe

文件写入的6种方法,这种方法性能最好

王磊

Java io 文件读写 文件操作 文件写入

架构的业务属性

soolaugust

架构 设计 架构师 七日更

阿里不允许使用 Executors 创建线程池!那怎么使用,怎么监控?

小傅哥

Java JVMTI 线程池 七日更 Executors

第十三周 作业

熊桂平

极客大学架构师训练营

数字货币量化交易所系统开发案例

量化交易模式系统开发app案例

数字资产交易所系统开发交易平台APP

vivo 商城架构升级-SSR 实战篇

vivo互联网技术

大前端 服务端 Node SSR

和 lvgo 一起学习设计模式.PDF

米凤君

Java 设计模式 23种设计模式

IDC发布2021年中国云计算10大预测;Docker 桌面为 M1 推出技术预览版

京东科技开发者

云计算 AI 程序人生

智慧公安防控管理,重点人员管控系统建设方案

t13823115967

智慧公安 情报研判系统建设

菜鸟实时数仓2.0进阶之路

Apache Flink

flink 流计算

什么是定点数?

Kaito

计算机基础

区块链钱包软件系统开发及费用

Win10环境前后端分离项目基于Vue.js+Django+Python3实现微信(wechat)扫码支付流程(2021年最新攻略)

刘悦的技术博客

django Vue 微信支付 python3 请求数据 扫码

天源迪科获2020年度中国产业供应链(中央企业集采供应链)百强企业荣誉

DT极客

大师级程序员,都用哪些工作法?(下)_文化 & 方法_郑晔_InfoQ精选文章