HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

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

  • 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:5112692
用户头像

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

关注

评论

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

Flutter Hero 动画组件的飞行过程显示控制

岛上码农

flutter ios 安卓 移动端开发 跨平台开发

Apipost接口自动化测试功能详解

测试人生路

Postman 自动化测试 接口自动化测试

连续四年发布科技趋势预测,他们在探索中国科技的“主干道”

脑极体

Java学习者看过来!这些优质项目千万别错过

Jackpop

harbor从1.6.1升级至2.7.0

小黄鱼

Harbor

云渲染动画价格一般多少?

Renderbus瑞云渲染农场

云渲染 云渲染价格

科技创新实力受认可,网易有道入选 2022 中国技术品牌影响力企业榜

有道技术团队

技术 数据分析

Kyligence 客户案例“泰康集团精细化经营分析与运营平台”获评数据智能最佳实践案例

Kyligence

数据分析 指标管理

Github上有什么好的unity开源项目?

Jackpop

CMD有哪些有趣的命令?

Jackpop

Python专属搜索引擎!又一款Python库学习神器?

Jackpop

关于接口测试自动化的总结与思考

阿里巴巴云原生

阿里云 云原生 TPS

软件测试 | 测试开发 | 相比Selenium,Web自动化测试框架Playwright

测吧(北京)科技有限公司

测试

2022 OpenMLDB 硕果累累,颁奖台上荣耀连连

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

WorkPlus平台多业务系统集成,让企业沟通协作更畅通

WorkPlus

创作技术博客以来的一些成就

嵌入式视觉

知乎 博客 CSDN 博客园

精华推荐 |【深入浅出Sentinel原理及实战】「原理探索专题」完整剖析Alibaba微服务架构体系之轻量级高可用流量控制组件Sentinel(1)

洛神灬殇

sentinel 1月日更 Sentinel 系统

8.3K Star!这才是我们苦苦寻找的PDF阅读器。。。

Jackpop

RayLink远程控制软件:叮~你收到一份年度关键词报告

RayLink远程工具

远程控制软件 RayLink

企业专用的即时通讯产品如何选择?

WorkPlus

性能测试技术笔记(三):如何设计一个压测平台

老张

性能测试 压测平台

一加11:新的赛场,“不温和”的答卷

脑极体

阿里云张献涛:无影,让计算触手可及

云布道师

无影云电脑

Apipost——让前端、后端、测试共用一份API文档!

不想敲代码

好家伙!阿里最新SpringBoot进阶笔记涵盖了SpringBoot所有骚操作

程序员小毕

程序员 后端 ssm springboot java面试

EditText(输入框)详解

梦笔生花

android edittext 输入框设计 文本框(TextView)

InfoQ写作社区 2022 年度优质创作者评选名单公布!

InfoQ写作社区官方

热门活动

2022 InfoQ 写作社区年度优质企业号评选名单公布!

InfoQ写作社区官方

热门活动

TiDB 6.5 LTS 发版

PingCAP

#TiDB

同盾科技 x TiDB丨实时数据架构为风控智能决策保驾护航

PingCAP

#TiDB

Git遇到冲突?解决也太简单了!

Jackpop

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