聊聊技术人的素养

参与相关讨论,请在公众号回复关键词
读者群。

未经审视的人生不值得过。

——苏格拉底

在我的工作经历中,会发现有一些技术人员成长很快,能够迅速成为团队的骨干,也有一些技术人员总是在原地踏步,工作十年和工作一年的区别并不大。渐渐地,我发现这些优秀的技术人员都有一些共同的特质和素养,从而帮助他们不断进步,脱颖而出。

10.1不教条

软件的世界里没有“银弹”,在技术人的众多素养中,“不教条”占有重要的地位。我在工作过程中看到过太多教条主义的错误,例如,我曾见过一个团队为了做微服务,将本来的一个不大的应用拆分成了几十个微服务应用。

教条的主要原因是我们还停留在有样学样的阶段,导致我们忘记了 软件的第一性原理是“控制软件复杂度”
。但凡能提高代码可读性、可扩展性和可维护性的方法,都是值得考虑的,并不一定要拘泥于某种特定的开发过程或者编程范式。

就像 Effective Java
一书的作者Joshua Bloch说的,“同大多数学科一样,学习编程艺术首先要学会基本的规则,然后才能知道什么时候去打破规则”。

10.1.1瀑布还是敏捷

选择软件开发过程绝不是要么瀑布(Waterfall),要么敏捷(Agile)这么简单。实际上, 软件开发的生命周期风格类似一个连续光谱——有从瀑布式到敏捷,以及它们之间的多种可能性。

以我的工作经验来看,软件开发过程并不是软件工程中最大的障碍,不是你花了大量时间需求分析和设计上,项目就一定会失败;也不是你每天早上花5分钟讨论“昨天做了什么,遇到什么问题,今天做什么”,项目就一定能成功。

敏捷开发是基于迭代模型发展起来的一套软件开发指导原则。我们在实际操作中应重视指导原则,弱化方法论。

就像Scrum的创始人Jeff Sutherland在其敏捷宣言中说的,“我建立Scrum模型就是为了把敏捷的价值观糅进一套工具集以便于更好地实践, 敏捷模型没有方法论。

敏捷还有一个误区,就是弱化设计。其实我对此事的认知也是有一个过程的,我是敏捷的极力拥护者,非常感激敏捷让我们摆脱了软件能力成熟度集成模型(Capability Maturity Model Integratio,CMMI)的沉重枷。凡事过犹不及,实施敏捷就可以“无设计”吗?设计可以在敏捷过程中自然涌现吗?实践告诉我们,似乎不能。就像盖房子,在盖之前要打牢地基,如果地基还没完工就匆忙建造房子,那么就很难摆脱糟糕的地基了。类似地,系统架构中的基础改动起来会变得困难,从而不得不做出各种妥协和临时方案。

因此,我们需要在大设计和无设计之间找到一种平衡。一个软件从无到有,不管你是瀑布、迭代,还是敏捷,一般会经历下面的过程。

(1)需求:对于系统该做什么,建立并保持与客户和其他涉众的一致意见,定义系统的边界。

(2)分析与设计:将需求转化为系统设计,设计将作为在特定实现环境中的规格说明,包括逐渐形成一个健壮的系统架构,建立起系统不同元素必须用到的共同机制。

(3)实现:编码、单元测试以及对设计进行集成,得到一个可执行的系统。

(4)测试:对实现进行测试,确保它实现了需求,通过具体的展示来验证软件产品是否像预期的那样工作。

(5)部署:确保软件产品能被它的最终用户使用。

基于此,我推荐一种综合了瀑布模式、迭代模式和敏捷思想的软件开发过程。在此提倡根据迭代所处阶段的不同,在不同科目上花不同的时间,如图10-1所示,灰色部分代表一个阶段在当前迭代中所花时间的比重。

聊聊技术人的素养

图10-1改良的迭代开发

10.1.2贫血还是充血

一提到事务脚本(Transaction Script)和DDD,人们就习惯性地给它们扣上贫血 [1]
和充血的帽子。简单来说,贫血模式提倡模型对象只包含数据,并提供简单的Getter和Setter;而充血模式提倡数据和行为放在一起,是一种更加面向对象的做法。两种模式都有自己的道理,也都有人支持。

在我看来,这种争执是没有必要的,因为没有抓住问题的本质。问题的核心不在于行为和数据是否在一起,而在于你能否有效地控制复杂度。如果你有很好的面向对象思维,使用贫血也可以写出好的代码;没有面向对象思维,即使采用DDD,也会陷入复杂性的泥潭。

纠结于贫血还是充血,一方面是因为没有抓住问题的本质,另一方面也源于一种非黑即白的教条思维。就像4.2节中的Rectangle案例所展示的,行为和数据是否放在一起,只是表现形式的差别,并不是用来区分面向对象和面向过程的关键区别。

10.1.3单体还是分布式

在业务发展早期,因为用户少、流量少,功能相对简单。如图10-2所示,基本上单体(Monolithic)应用架构就足以支撑业务的发展。

聊聊技术人的素养

图10-2单体应用架构

然而,随着业务的发展和用户的增加,单体应用的局限性开始显现。具有水平扩展性(scale out)的分布式系统架构几乎已经变成互联网公司的标配,如图10-3所示。

聊聊技术人的素养

图10-3分布式应用架构

虽然面向服务的架构(Service Oriented Architecture,SOA)和微服务有一统天下之势,但是并不代表单体架构就会退出历史舞台,特别是在中台概念提出来以后。中台要求通过集中式的中台管控来提升软件系统的复用,避免趋同的业务重复造轮子的现象。中台的目的就是要通过中台能力来赋能前线业务,提升对前线业务的支撑效率,其架构如图10-4所示。

聊聊技术人的素养

图10-4中台架构

可以看到,中台虽然也是对业务进行聚合,但并不是对单体架构的简单回归,而是综合了分布式理念之后升级版的“超级单体”。正是这种不教条和辩证的发展思维,才推动互联网架构不断地向前发展演进。

10.2批判性思维

批判性思维(Critical Thinking)是一种谨慎运用推理去断定一个断言是否为真的能力。它要求我们保持思考的自主性和逻辑的严密性,不被动地全盘接受,也不刻意地带着偏见去驳斥一个观点。批判性思维也是一项能够被习得,并且通过训练和运用来提高的能力。

技术人员虽然有很强的逻辑推理能力,但不见得都有很强的逻辑思维,我也是如此。在知晓批判性思维之前,我曾吃过很多亏,明知道对方在强词夺理,可就是找不到很好的反驳理由。无论是在公司和同事争辩,还是在家里和老婆斗嘴,几乎没有赢过。后来我学习了一些批判性思维的知识,情况才有所改观,可以抓住对方的一些逻辑漏洞和推理谬误进行反驳,这使我在职场上拿回了不少话语主动权。不过在家里,我依然是输多赢少,后来我才发现,原来家不是一个讲逻辑的地方。

关于训练批判性思维的书有很多,我重点推荐两本,一本是尼尔•布朗写的被誉为批判性思维领域经典读物的《学会提问》,另一本是樊登读书会推荐的《思辨与立场:生活中无处不在的批判性思维工具》。我在读这两本书的时候,经常会有aha moment(顿悟时刻),真的很有收获。

在《学会提问》一书中,有这样一个案例。

小张:“小王真不是个男人,酒吧里那个醉汉威胁说要揍他一顿,他吓得屁滚尿流。”

小李:“他要不是男人,你怎么解释他身上那些鼓鼓的二头肌呢?”

你觉得小李的话有道理吗?如果你觉得有点道理,但又觉得有点不对劲,那么就应该去好好读读这本书。这里小李犯了一个典型的推理谬误——偷换概念谬误(Equivocation Fallacy),小张说的“男人”是指“男子气概”,而小李说的“男人”是指“男人生理”,这两个概念是不一样的,这就是问题所在。

10.3成长型思维

成长的过程中不可能是一帆风顺的,肯定会有痛苦、有阻力、有挫折。面对逆境,我们应该怎么做?有些人也许不堪重负,就此沉沦了,而有些人可以越挫越勇,把每一次失败都当成学习的机会。研究发现,成长型思维(Growth Mindset)和固定型思维(Fixed Mindset)会极大地影响我们面对逆境的处理方式。我在最低迷的时候,正是成长型思维帮我渡过了难关。

斯坦福大学心理学教授卡罗尔•德韦克在经过数十年的研究后,发现了 思维模式的力量
。她在《终身成长》中提醒我们:我们获得的成功并不是能力和天赋决定的,更多受到我们在追求目标的过程中展现的思维模式的影响。

成长型思维和固定型思维体现了应对成功与失败、成绩与挑战时的两种基本心态。你认为才智和努力哪个更重要、能力能否通过努力改变,决定了你是会满足于既有成果,还是会积极探索新知。通过了解自己的思维模式并做出改变,人们能以最简单的方式培养对学习的热情,以及在任何领域内取得成功都需要的抗压力

具有成长型思维的人相信自己可以通过学习来提升自我,相信学习和成长的力量,相信努力可以改变智力和能力。我们可以通过图10-5所示的对比来判断一个人是“成长型思维”还是“固定型思维”。

聊聊技术人的素养

图10-5成长型思维和固定型思维对比图

我曾经就是一个典型的固定型思维的人,在遇到困难和挫折时很容易引发自我怀疑和自我否定。在了解了成长型思维之后,我开始逐渐转变思维模式,会用更加理性的态度看待一时的成败得失,内心坚定地相信成长和学习的力量。从某种意义上来说,你正在读的这本书也是我在习得了成长型思维之后,才得以写出来的。

技术人员的工作面临着很多的挑战,我们需要具备成长型思维才能应对工作和生活中的压力,这样在遇到问题时,我们才不会轻言放弃,而是会积极主动地去学习,去寻找解决方案。即使最终还是失败了,我们也不会一蹶不振,而是把失败当作学习的机会。

10.4结构化思维

在日常工作中,我们时常会碰到有的人讲一件事情的逻辑非常混乱,前后没有逻辑性关联,甚至无法把一件事情说清楚。思维混乱是缺少结构化思维的典型表现。实际上,我们不仅在表达上要结构化,在分析问题时更要有结构化思维,这样才能分析得更全面、深刻。

什么是结构化思维呢?我给结构化思维的定义就是 “逻辑+套路”
。 

1.逻辑

所谓逻辑,是指结构之间必须是有逻辑关系的。例如,你说话时用“第一、第二、第三”这个逻辑顺序是合理的,而如果用“第一、第二、第四”就会显得很奇怪。实际上,组织思想的逻辑只有4种。

(1)演绎顺序:比如“大前提、小前提、结论”的演绎推理方式就是演绎顺序的。

(2)时间(步骤)顺序:比如“第一、第二、第三”和“首先、再者、然后”等,大多数的时间顺序同时也是因果顺序。

(3)空间(结构)顺序:比如“前端、后端、数据”和“波士顿、纽约、华盛顿”等,化整为零(将整体分解为部分)等都是空间顺序。在做空间分解时,要注意满足“相互独立,完全穷尽”(Mutually Exclusive Collectively Exhaustive,MECE)原则。

(4)程度(重要性)顺序:比如“最重要、次重要、不重要”等。

只要我们的思想和表达在这4种逻辑顺序之内,就是有逻辑的,否则就是没有逻辑的。

2.套路

套路是指我们解决问题的方法论、路径和经验。比如,5W2H分析法就是非常好的,是可以帮助我们分析问题的一个“套路”。试想一下,面对任何一个问题,你如果都能从“Why、Who、When、Where、What、How和How much”(如图10-6所示)这7个方面去思考,是不是比不知道这个方法论的人用点状模式思考要全面得多呢?

聊聊技术人的素养

图10-65W2H问题分析法

逻辑是一种能力,而套路是方法论、经验;逻辑属于道,而方法论属于术。二者都很重要,只有熟练地掌握二者,我们才能有更好的结构化思维。接下来,通过两个案例来介绍结构化思维在实际工作场景中的应用。

10.4.1如何落地新团队

想象这样一个场景,你刚刚入职一家新公司或者转岗到一个新团队,作为一个技术人,你将如何落地开展工作呢?

这里就能用上结构化思维来帮助我们理清思路,从而有条不紊地开展工作。要知道对一个企业来说,核心要素无外乎就是 业务、技术和人
。我们所要做的就是如何去熟悉业务、熟悉技术、熟悉人,然而每一部分又可以进行进一步的结构化拆解,如图10-7所示。

聊聊技术人的素养

图10-7落地新团队的策略

1.熟悉业务

(1)了解产品形态:任何一个团队都有自己要负责的产品,申请一个测试账号去用一下产品,是熟悉产品比较好的方式。

(2)了解业务流程:任何业务都有自己的业务流程,而业务流程中的核心是信息流。我们可以通过人员采访了解关键节点的信息输入和信息输出;通过画一些泳道活动图来理清楚系统的主要角色,以及它们之间的交互关系。

(3)走访客户:通过走访客户,我们可以获得业务的第一手资料,更加贴近业务和客户诉求。

2.熟悉技术

(1)了解系统架构:可以让团队的技术人员介绍他们当初做系统设计和架构时的思路。

(2)了解领域模型:查看关键的核心表结构和系统API,快速了解系统的领域模型。

(3)了解代码结构:下载系统工程,熟悉整个工程结构和模块职责;以一个最重要的流程为入手点,阅读代码,看清楚核心的执行逻辑;做一个小需求,掌握相关的流程和权限。

3.熟悉人

(1)了解组织结构:查看公司的组织树,知道公司大概是如何运作的,以及哪些是关键人(Key Person,KP)。比如,一个典型的电商公司会包括产品部、运营部、销售部、技术部、人力资源部、财务部和法务部等。

(2)了解人员角色:了解公司都有哪些岗位,以及各岗位的职责范围。

(3)勤沟通:找出和自己工作息息相关的岗位,比如产品和运营,积极和这些同事沟通,向他们请教业务问题,多多交流。这样既可以建立良好的人际关系,也可以更快地熟悉业务。

10.4.2如何做晋升述职

我在阿里巴巴已经做了多年的晋升评委,发现很多人都缺乏结构化思维,讲着冗长的PPT,却不能很好地把一件事情说清楚。实际上,做工作汇报或者述职是很容易结构化的。

最清晰和实用的结构化表达是“ 提出问题,定义问题,分析问题,解决问题,最后展望未来
”。如果按照这个逻辑顺序去阐述一件事情,会比不知道这个“套路”的效果好得多。这也是麦肯锡常用的解决问题的框架。

另一个有用的思维框架是“zoom in/zoom out”。 我们说事情时,应该像电影镜头一样,先从远拉近,再由近拉远。
“zoom in”是先从宏观背景开始,首先让大家知道你的事情发生的背景,为什么这件事情很重要?然后讲到具体细节,怎么做成的?解决了什么问题?后端思考是什么?最后“zoom out”,从细节调回到整体,结果是什么?带来的客户价值是什么?你对未来的思考是什么?

可以看到,这些结构化的方法论可以帮助我们做到事半功倍,经常锻炼结构化思维可以极大地提升我们的职场竞争力。


本文选自 《代码精进之路:
从码农到工匠




,作为建飞的朋友和读者,特别推荐本书。

《代码精进之路:从码农到工匠》

聊聊技术人的素养

聊聊技术人的素养

张建飞

本书是一本专门为专业程序员而写的书,主线是介绍如何化解代码复杂度,帮助程序员写出可读性好、可维护性好的代码。

本书共有13章内容,主要分为技艺部分、思想部分和实践部分。技艺部分详细介绍了编程技巧和方法论,并配以详尽的代码案例,有助于读者提高编写代码的能力,优化代码质量。思想部分主要包括抽象能力、分治思想,以及程序员应该具备的素养等内容。实践部分主要介绍了常见的应用架构模式,以及COLA架构的设计原理。

最后再给大家安利一场直播分享
本周三晚19:00,博文视点直播间聚集风、陈皓、唐巧、孙玄、程军5位
国内神级程序员大咖,现场论道,妙解趣谈,进行关于传奇程序员修炼之道
主题的分享。
l 领军人物亲述从小工到专家
l 程序员务实最高境界之我见
l 宗师相对论与现场答疑解惑
强烈推荐一波!建议大家一定不要错过!

聊聊技术人的素养

进入读者群讨论,公众号后台回复:读者群

进入读者群讨论,公众号后台回复:读者群





END-

往期推荐

  • 运维违规操作被判五年半,IT从业需要懂法律

  • B站搞了一场价值60亿的跨年晚会!

  • 蚂蚁金服大规模分布式事务实践和开源历程

  • 从业务架构梳理到技术架构设计


  • DDD如何讲清楚,做出来?

技术琐话 

以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。

聊聊技术人的素养

原文 

http://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&mid=2651036298&idx=1&sn=d5842ee6df5c26e0bb8687673f733a95

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 聊聊技术人的素养

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址