金融科技的碎片化思考(中)

曾经,系列文只出一期是我的常规操作。今年,我想立个FLAG,有些坑我要努力找补回来。距离金融科技碎片化思考的上篇已半年有余,今天发个(中)篇,权当狗尾续个貂。不出意外,本人是打算在金融领域干到退休的,最终篇预计会出现在我退休之际,因为彼时的我应该会有更加成熟的视角和靠谱的沉淀,敬请期待。

其实此文字的底稿早已写就。突如其来地,2020年10月24日(该日头等大事,天选程序员,曲爷我的生日)的外滩金融峰会,强势挤入金融历史的时间轴,只因马CLOUD那21分钟的精彩发言。亦因为此,我这半个金融从业者不得不藏起底稿,吓得不敢说话了。然而,风头一过,我就在底稿上整了个PPT,去IT东方会的T-Chat上吐槽了一晚上。风吹过处好像也并没有想象中的那样一地鸡毛,想来此时更可以自由发言了。

《金融的背叛》

先从《金融的背叛》此书讲起。书的作者乔治·乌杜,曾在富通银行、摩根斯坦利、纽交所等担任要职,这种级别的金融大家对金融的理解必然非常人可比,绝不会是贸然指摘自己从业行当的杠精,却依然用了”背叛”这个相当重的词来形容近代金融的乱象。金融业的天价薪酬、利率欺诈、监管缺失、虚假创新等等都被作者一一点名。有趣的是,作者把比特币视作庞氏骗局,已经被炒到4万美金一枚的今天,不知道作者作何感想。

强烈推荐大家看看这本书,角度新奇且深刻。此书当然不仅是批判,更多是一种警告和呐喊,书的副标题“恢复市场信心的十二项改革”就可见一斑。这十二项改革分别是:

  1. 停止欺诈消费者
  2. 规范薪酬制度
  3. 让董事会真正负起责任
  4. 重整监管部门
  5. 制约金融创新
  6. 重归透明简单
  7. 确保资本诚信
  8. 给评级机构带上紧箍咒
  9. 重新界定金融风险
  10. 监督资本市场:关于对冲基金
  11. 让咨询顾问言而有信
  12. 全球维度

拉回主题。金融固然有它自身各型各色的问题,那金融科技身处金融之中,应该如何自处或避险?

牌照

金融科技从无牌照的野蛮生长,到争相布局抢夺牌照,再到暗戳戳的“去牌照”,金融科技对牌照的追逐精彩纷呈。千禧年前就成立的国内最早的第三方支付“北首信南环迅”,现在好像并不知名,要知道那时候还没银联、支付宝的事,而银联也不过2002年3月份才成立,支付宝是2004年底成立。沉沉浮浮,直到十年后的2010年6月份人民银行才公布了第三方支付牌照的准入制度,最后2016年底暂停支付牌照的核发,让存量支付牌照成了稀缺品。

第三方支付行业发展简史

https://zhuanlan.zhihu.com/p/157799876

现而今已经臭大街的P2P,在2015年互金整治办和网贷整治办发布的的指导意见中,给出的正式命名是网络借贷信息中介机构。追溯P2P的历史,应该由2007年上海成立的拍拍贷而起,历经2012年的快速扩张、2014年底的集中爆雷,在2020年11月P2P的完全清零之前,这个行业一直在热潮、爆雷、转型中水乳交融着。转型指的就是转网络小贷、或者消金业务,而这两者对应的就是小贷牌照消金牌照,至于二者的区别,不用太深究,记住消金牌照的业务经营范围更广就够了。

关于网络借贷信息中介机构转型为小额贷款公司试点的指导意见

https://p2p.hexun.com/2019-11-27/199454413.html

2005年央行批准组件的5个省试点的传统小贷公司,在P2P、互联网小贷、消金兴起的浪潮下没有任何优势。通常真正互联网小贷的源起,一般都公认为2007年由阿里和建行联合发行的e贷通,也是最早的助贷模式的开端。2010年3月在杭州成立的阿里小额贷款公司,但是传统小贷公司是有“不得跨区经营”的规定,然后就出来了可打破这一限制的网络小贷牌照。而全国第一张网络小贷的营业执照,查了好久不怎么可考,大概是2016年1月份上海自贸区给万达集团发放的(如有纠正欢迎留言给我)。沉浮十余载的小贷业务,在2017年11月,由互金整治办发布了暂停批设网络小贷公司的通知。网络小贷新规拉高了小贷门槛,大家又把目光转向了消费金融牌照

网络小贷十年沉浮:时代的机遇与代价

https://www.huxiu.com/article/391331.html

国内网络小贷公司研究分析:82张牌照 51家股东为上市公司

https://www.weiyangx.com/236831.html

消费金融的历史在所有这些形态中是历史最悠久的了,国内萌芽于1985年,从2009年的北上成三地试点到扩大多城市试点,再到2015年的6 7月份国家为“互联网消费金融”开闸,消费金融业务蓬勃发展,但是获批的消金牌照也不超过30家,中间也发生过消金牌照的暂停(约2017年1月)和复批(15个月后)。

除此之外,很多人不怎么了解的个人征信牌照,是一个更加难以获取的牌照。到目前为止只有两张,分别是百行征信和朴道征信,实质都是国家控制的多方联合机构。原因很简单,虽然类似阿里、腾讯这种巨头拥有海量公民数据,但是他们对于个人信息的保护、覆盖范围、征信的第三方独立性,都值得慎之又慎。至少2016年某宝推出的圈子,女性发帖,男性只能打赏评论,且芝麻分750分以上才能评论,就是典型的征信数据滥用。

从野蛮生长,到2016年的互联网金融强监管,和2017年的传统金融强监管,至今,国家对于金融市场合规整改的不遗余力,也是致力于打造真正金融普惠产品的同侪,所喜闻乐见的。

创新

创新从来不能以本身为目的,而金融的创新更甚。因为金融创新通常不够透明(也不想透明),一通眼花缭乱之后,金融产品的底层逻辑就被遮掩住了,你看到的花团锦簇背后大多恶臭熏天。

创新也从来不应该以革命、颠覆这种口号标榜自己,而金融的创新常常如此。且不说不少所谓的创新和诈骗无异,剩下的大多也不过是零和游戏,层出不穷的创新幌子也不过为了尽早尽快的套现离场。

耐得住寂寞、不断地打磨、不急功近利、以服务社会为理念的金融创新产品,才是金融真正的未来。

金融创新通常分为二类:金融产品/工具的创新、金融技术的创新

金融产品/工具创新

金融产品/工具的创新才是是金融创新的最重要部分,并不是金融科技动不动吹嘘的技术。比如P2P雏形的创造者是诺贝尔获奖者、小额信贷之父穆罕默德·尤努斯教授,他将钱以小额没有任何抵押的方式发放给贫困国家的妇女,来帮助他们摆脱贫困。教授的初衷是建设一个没有贫困的社会,使得儿童能够获得受教育的资格。原本用于构建和谐社会的金融工具后来变成了各种雷,如同四大发明的火药成为殖民者手里的枪械,违背初衷。

金融工具创新通常响应于金融市场的供需变化。比如余额宝就是在国民普遍富足,但投资渠道单一或者门槛过高的情况下,(被传统金融的不作为倒逼无奈下)诞生的。甚至打通资产(流量)端和资金端的助贷模式,也可以说是一种金融产品的创新。传统金融们出钱收息,平台们苦哈哈的去找流量赚息差。现在火热的供应链金融,打破单一的金融业务或产品,而是围绕一个核心企业,从原材料到制造到最终产品送到消费者手里,整个供应链条连成一个整体,全方位提供融资服务,这也是响应市场呼声的工具创新。

金融技术创新

互联网的主流新技术现在一般被缩写为 A(i) B(lockChain) C(loud) D(ata) I(oT),这些技术应用广泛,当然不是只应用于金融。金融技术的创新一般体现在这几个方面:提高金融效率、提升金融服务质量、减低金融风险、降低金融运营成本等。

我们大部分人应该都吐槽过银行柜台的“低效”,拿号、证件、复印、拍照、签字、密码等一系列操作,繁杂冗长,直让人骂娘。虽然金融监管让这一切必须如此程式化,但是金融科技的使命不就是从这些繁琐中寻找创新突破嘛?

比如远程的人脸识别技术可替代柜台面签,让开户更便捷;“上古时代”的网上支付需要跳转网银页安装各种ActiveX控件,已经被快捷支付给妥妥的碾压;人工客服的各种1-9入口被智能客服替代,更加的便捷与高效;大数据智能风控让海量数据建立起连接,挖掘出更多度数的社交网络,训练并识别出更多的风险变量;更别提中国的二维码无现金社会,让国外的同学艳羡不已;等等,等等…

当下的我们已经享受着金融科技大量创新带来的无数效率或服务的提升,如同乘坐在飞速行使列车上的我们,只有停站,才有可能看到车头上的无数鸟虫尸体。

回头再看上面提到的创新。作为人的重要生物特征(指纹、声纹、虹膜、人脸)之一,人脸数据是如何保证被有效存储的?至少某一日在某后台看到了我自己开户的人脸识别照片和视频,我是恐慌不已的。快捷支付也发生过CVV码泄漏事件。智能客服成了某些平台缩减服务成本的借口,也许与智障也差不多了,我在某互联网银行的客服功能里,曾经进入过排队死循环。先从100个开始排,终于到了的时候给一个系统错误,然后继续从200个重新排队,直到我关闭这个客服窗口。

区块链最火热的时候,除了陪着币圈的热闹,绝大部分组织把区块链当成一个“分布式数据库”来用。某宝的区块链跨境汇款,最难的地方你觉得是技术问题还是跨境链路上各大银行、清算机构的接口打通?当技术称为一种噱头,也许这就是技术创新的代价,至少先得引起市场的注意进而追捧吧。我本身是看好区块链的,只是看起来区块链单打独斗落地的可能性基本不存在,它必须与智能合约、供应链、多主体间信任等等做组合拳落地。

当浪潮褪去,你自会看到哪些“创新”在裸泳。

信用

特意想说下与风险强相关的信用这个话题。前面大约提到一点关于征信,会有人问征信和信用有啥区别,很简单,前者是动词后者是名词。吴晶妹教授对信用的构成有个三维论:诚信度(信用主体的道德文化、行为准则)、合规度(遵守规定、规则和管理的能力)、践约度(履行约定的能力)

传统金融机构的数据沉淀这么多年是海量的,但是这些数据也有缺陷,比如以金融交易数据为主,用户画像比较单一,难以建立多样化的信用场景,信用的私密数据让传统金融不敢轻易包装信用产品等。不过传统金融机构这些年在金融科技上的不断发力,已经在迅速补齐这些短板。

信用的具象化,最有代表性的非 芝麻信用分 莫属了。你是怎么看待这个信用分的呢?

它是数据的收集共享还是隐私的侵犯泄漏?

它在信用评定上有持中守正么?(能刷分么)

它在信用应用上有节制受控么?(某圈750分男性才能评论,信用分PK)

它的应用场景到底是个人信用的体现还是信用背后机构的信用背书?(租车免押金是认的个人还是某宝)

它的应用场景是否涉及信用歧视或者信用要挟?(750分能快速过机场安检通道)

我的矛头绝对不是指向这款产品,而是说信用之上这些问题本身就客观存在。

那么信用是怎么出来的呢?当然是靠各种各样的数据、证明、抵押、担保等等“科学计算”出来的。文首马CLOUD发言中批判的国内金融的“当铺思想”,也不过就是说的抵押问题。因为互联网金融通常为了授信快,会无限加大数据在这中间的比重,让用户端的证明材料、抵押物尽量的轻,甚至不需要。互联网巨头拥有的海量数据要玩转信用社会,感觉像玩儿似的。因为就算你啥也不提供,你的数据基本在他的系统里都罗列好了的,比你自己还清楚你自己。

那么问题出在哪里呢?

信用社会的形成需要全社会资源的努力,绝不是几个巨头就可以设定条条框框的。每个巨头都有他的利益所在,会不会为了自己的商城业务让你的信用波动起伏,也许随着社会的进步,企业的使命感会让他行的正,但是谁敢承诺。再者,信用社会容易走入极端,信用的马太效应会导致好信用的人可以获得更多的资金,进而得到更好的信用。而人是可以改过自新的,信用污点怎么清理呢。我也不知道,我只是个旁观者。


扯了太多了,戛然收尾。

谁不想在金融这块发点财,收点益,但金融科技助力和谐社会,这点美好的愿望我们这帮从业者还是可以保留一下的,您说对吧?

DàYé玩转数据战略Step By Step

Pexels By Pixabay

爷我天蝎座,打小不喜欢凑热闹,更不会强迫自己融入热闹,什么国庆长假,什么网红餐厅…只要是让我排队,就感觉是浪费生命,我是万万不会屈从的。
这个说不上毛病的毛病,或多或少也在影响我在专业领域的判断。比如,19年中台这股热闹妖风刮起来的时候,我基本是捏着鼻子远远躲开的。直到最近在调整组织战略,数据运营重新进入我的视野,落地却屡屡不得法时,不得不静下心来探究一番,热热闹闹的数据中台到底在说什么。
翻阅了不少资料,这里推荐下《数据战略-如何从大数据、大数据分析和万物互联中获利》《数据中台-让数据用起来》这两本书(部分内容也参考了它们),读罢获益匪浅。小标题里的关键字获利、用起来都是今天我要说的重点。

以史为鉴

我们先看看工业革命的演进路径,从1.0的蒸汽机时代,到2.0的电力、流水线和大规模生产时代,再到3.0的计算机自动化时代,最后是4.0的智能化时代

再瞅一眼互联网Web的发展路径,从1.0的计算机互联只读时代,以网络单向提供静态内容给人的方式出现;到2.0的互动分享社交读写时代,以人与人的沟通、创作、传播、协作的双向特征出现(如Facebook/Youtube,HTML5/CSS3技术);再到3.0的移动语义和物联 读写执行 时代,计算机可以智能生成、理解和分发用户需要的内容,更理解语义更通人性(如苹果Siri, 小度); 2020开始的4.0时代,目前还没权威定义,有云操作系统、去中心化区块链、共生网络等,下图的Web OS其实也只是形态之一罢了。

图自: https://medium.com/@vivekmadurai/web-evolution-from-1-0-to-3-0-e84f2c06739

参考1:从1.0到3.0的Web进化
参考2:万维网:从WEB 1.0到WEB 4.0和SOCIETY 5.0
参考3:万维网的进化: 从Web1.0到Web4.0

不管是工业革命还是万维网,它们的进化史都有惊人相似之处。蒸汽机只是让车跑的更快让机器更有力量么?你更应该知道火车进入运输业让印刷业极大受益,并带来知识的大范围传播。电力就不用说,催生出电视电话,更加速了资讯的传播。而且在整个工业或者信息链路上主导的能力越来越弱,随着连接(互联、物联)的不断发生,信息流转的速度不断加快,信息数据的量级也呈爆炸性态势,导致对信息处理效率和准确性的要求也持续增强。这种进化的本质是,我们不再满足于信息的共享和传播,而是更加关注价值的迅速转移。什么是价值转移,举个例子,外卖平台识别到糟糕的天气状况,智能延长外卖的承诺送达时间,让外卖小哥可以不那么拼命赶路,这就是从天气预报信息到外卖小哥交通安全的价值转移。而做到这一切的关键内核,就是信息,也就是我们今天要谈的数据。

而今各色公司都在喊的“数字化转型”“数据中台”“数据运营”“产业互联网”等等都是数据(中台)战略的不同包装或展现形式。数字化转型可不要与以前的信息化转型混淆,信息化可以简单理解成以前的线下手工操作变成了线上系统操作,信息存起来了却是零散的割裂的(即便是结构化的数据)。而数字化是在信息化之后的资源整合、数据连接后的价值挖掘和商业应用。

统一语言

开始之前,先跟各位读者统一下数据语言,防止出现理解偏差,顺便罗列一下我理解中的数据战略体系内容。

1. 术语

数据资产:能直接作用于业务领域,业务人员能阅读和理解的,可计量、可控制、可变现的数据,才能称之为数据资产。*数据湖**里的那些原始数据或者贴源数据,只能算是数据资源*。数据湖一旦维护不当就可能变成**数据沼泽

数据分类:数据的定义五花八门,不同场景有不同的叫法,甚至重叠度很高。我简单罗列了下自己知道的一些数据种类和名称,错误或者疏漏之处欢迎指出。

2. 四大体系

数据战略的落地规划一般要假设这三个体系:技术体系、数据体系、应用体系和监控体系技术体系无非就是平台系统、数据组件等的开发。数据体系是核心,就是专心把数据收集、汇总、加工这个形成数据资产的过程做好。而应用体系提供数据服务,在数据资产的基础上提供类似用户画像、信用评估、预警告警等应用服务。为了让前三个体系可以健康持续的运转,需要规范、流程、评估、优化、改进等一系列监督辅助性职能,这个就是监控体系

3. 五个环节

数据开发5个环节:数据收集 -> 数据汇总 - > 数据开发 -> 数据应用 -> 数据优化。

4. 五个关键步骤

梳理现状 -> 架构规划 -> 开发数据资产 -> 应用数据到业务场景 -> 运营及优化。

第一步: 动起来 & 用起来

horse.png

首先,数据战略行动一定是“一把手”工程,因为只有一把手才能推动数据战略的落地。然而,再强势的一把手,也有一拳打在棉花上的时候,毕竟执行力彪悍的团队可遇不可求,而且更多时候不是执行的问题而是组织的问题:令不出“朝堂”、政令不畅、部门墙、阳奉阴违,不一而足。

所以第一步,特别强调,务必从可实操、有价值、可感知的业务场景来切入,我在这一步上是吃了大亏的。而通常符合这个标准的业务场景,从业务运营团队的痛点中比较容易获取。

可实操,说的是技术实现、政策规范、组织协调等层面进行实际操作的难易度。想象一下,

  • 你想看PV/UV数据,系统连埋点功能还没有规划,实操性就很弱。后端规划数据上传和数据存储倒不麻烦,前端需要仔细设计如何埋、埋哪里、何时触发、耗电、权限、性能等等一系列,就不是个小事情。等把埋点实现好,App发版对外,用户更新完,之前的活动页PV UV需求可能都过去式了;
  • 风控授信需要大量数据支撑,资信数据、社交数据、行为数据、设备数据…有些需要用户的授权,有些授权也没用,因为政策上就不合规,更令人恼火的是即便用户授权了也会投诉你误导用户点击…这种数据的获取必须慎之又慎;
  • 当你的数据分析部门只有关系型数据库的技能,对Hive HQL语法、图GraphQL语法千推万阻之时,你能怎么办?

有价值,比较容易理解。没有价值的数据战略行动是没有生命力的,且不具备可持续性。它不应该满足某些个人的喜好,也不能是劳民伤财的政绩工程,而一定是数据的场景应用,可以应用于运营,可以是风控,也可以是市场,但尽量不要只是应用于老板的桌面。就我而言,判断一个数据项目是否有价值,需要重点关注4个领域:用户、市场和竞品、财务、运营

可感知,是对数据战略升级的一个特别重要的铺垫。直白点说,数据成果要能大张旗鼓的展示出来,让团队感受到它的价值和成就感。比如很多人当成政绩工程的**监控大屏**,就是能让团队感受到业务流淌的脉搏,感受到与用户面对面的呼吸,还有什么比这打出的鸡血更浓郁?

做到以上三点,这一步就算基本做踏实了。也不建议做多,做的越多落地周期就越长,你的数据战略也就迟迟不见踪影。总结下这个阶段的特点是业务驱动数据,不做高大全的顶层设计,够用就行。不追求完美的规划和架构设计,hard code都行。从独立的小项目切入,甚至多个小项目是各自为战的状态也别介意。至少你已经走起来了不是么?

提醒一点,先动起来不是说没有设计没有规划,而是不要追求完美和完整,这个度请自行揣度。
至少对于“先尽可能多的把全量数据收集起来”这一点,我是持反对意见的。埋点收集一堆用不上的或者垃圾数据,光存储成本就是一种成本浪费,更不要说垃圾数据可能造成的决策误导。有句俚语是:别让数据变成白色大象(White Elephant,代价高昂却一无是处)

第二步: 打造数据文化

打铁趁热,一鼓作气。

当组织感受到数据的甜头之后,就会想从数据中攫取更多好处。当然,随之而来的阻力也会更大。比如承载巨量数据资产的硬件成本是高的吓人的,无论怎么逼业务部门提出来的数据需求都不怎么像样,或者永远都是就是那几个无关痛痒的业务指标,随着数据战略的全面铺开,难度不断加大,玩不转打退堂的、想砸钱的、不想花钱的…各种冲突都会浮现出来了。

关于提不出来需求这个事,相信很多做过数据的朋友都会有共鸣。拿着一堆数据就好像知道了问题的答案,却不知道问题是什么。
正如科幻圣经《银河系漫游指南》里的超级计算机,对“生命、宇宙和万物”计算出的最终答案是数字 42。你却不知道这个42对应的问题是什么,这才是问题本身的问题。

数据文化的意义就是,让员工意识到数据的无限可能性,沉醉于数据的价值挖掘,并最终得意于数据的业务应用、商业决策以及经济利益。再概括浓缩到一句话,数据文化就是放大数据金矿的诱惑力,让员工趋之若鹜、甘之若饴。相信每个组织都有自己专属的文化特征,而数据文化,也并无不同。无非是将数据思想植入产品的全生命周期,Data Driven Everything。

这里还是从我自己的角度先给几点血泪踩坑建议吧:

  • 一把手一定得亲自参与数据文化的打造,在民主投票出现冲突时、推行卡滞时、优先级排序、方案评审时,这些重要时刻一定不能偷懒或者敷衍,一把手不认真,文化就不可能认真,这是第一原则;
  • 数据文化不能成为政绩工程,当数据的产出成为绩效的一部分或者吹嘘的资本时,必须提高警惕。就像写的代码有Code Smell,数据文化同样有Data Smell。比如数据体系(元数据/标签/数仓)这个地基都没打好,就说自己的数据服务-用户画像多么多么牛掰,这种头重脚轻的Smell特别普遍;
  • 数据建设需要专业人才,数据团队作为数据文化的智囊团和践行者,需要极高的专业度。从架构到工具,从模型到服务,从展示到安全,必须面面俱到;
  • 数据文化需辅以完善的规范和流程制度来护航,对于数据资产的管理除了靠人靠技术,就剩下靠制度了。规范制度是数据战略可以持续健康运作的必备条件,否则面对数据中台这种级别的航空母舰,一个历史包袱完全可以让你无法弥补。一个行之有效的“航母操作手册”,比苦口婆心的口水有用的多;
  • 文化的落地前期可能需要一些命令式操作,但是随着组织意识的完善,中后期不能让文化走偏成为一种约束。比如逢必谈数据,过于偏执于数据,可能会让决策过程复杂化,产品流程延长,更坏的情况是组织的数据能力不到位,给出错误的数据结论,那就糟糕了。所以相信数据的力量,但不能迷信数据的结论

这个阶段的重点是要打造较为完整的数据中台架构和组织,整合散落的数据,消除数据孤岛,规范数据的采集、存储和分析,所以规划、整合和规范是本阶段的关键字,剑指数据驱动业务。在上面“统一语言”章节提到的体系和步骤都是架构核心内容,你的数据中台不是在建设这些内容,就是在建设这些内容的路上。再解释一下何谓完整,比如容易被人忽略的“数据安全”,是数据战略的重中之重,绝对不能轻视和忽略,甚至延后再补都不能允许;组织上,数据团队的委员会、产品、开发、质量、模型、运维工程师都不可或缺。

第三步: 数据优化和可持续

说实话,我们也正在这个阶段的河里摸着石头的人。

当你在天量的数据源上又沉淀出海量的数据资产时,没有人可以保证这些数据资产的质量如何,价值难以评估,安全性未知或者堪忧,数据的管理可能也浮于表面,更多是为了业务应用而仓促成形。另外随着组织战略的调整,一些历史性数据对整体数据中台的冲击和负担,也应该同步清理,抛弃历史包袱。这些都需要治理、监控、优化和升级的。

先说数据治理,这个概念也历史悠久了,甚至理论体系都有好多,像 DAMA、CMMI、DGI等等。基本上数据治理的目标有这几个:提升数据质量、构建统一的数据标准、组织内达成一致的解决数据问题的方法、透明完善的数据管理流程、数据的可持续运营。而数据治理的发展趋势也各有选择,有采用AI来提升数据治理效率的,有采用元数据为核心的分布式治理,我们采用的是后者。

元数据Metadata是什么?描述数据的数据。抽象的定义…它一般分为技术元数据,如表结构、字段约束、字段字典,业务元数据,如业务指标、业务术语,管理员数据,如数据Owner,数据安全等级等等。
元数据的应用场景很多,常见的如ETL程序做数据转换时需要知道源数据的结构和字典,通过数据血缘分析发现改一个字段的长度,会影响哪些系统,都是特别典型的。

再说数据质量,它的高低直接关系到数据决策的对错。所以要对源头数据质量、加工过程质量和使用价值质量进行全方面的评估和改进。简单展开下,源头数据的准确性、时效性至少你得确认清楚吧,1年前的用户资信数据你敢用么? 加工过程的质量更不必说,生成的标签数据,也是有准确率、时效性、覆盖量等,比如不是所有用户都登记了性别的,那男女标签覆盖的只是用户登记过性别的群体而已。加工所需要的模型也是需要不断调整的,以前是你看尿布给你推荐尿布,现在是你看尿布给你推荐啤酒。使用价值的质量相信不太好理解,其实像某个标签的使用量,越多业务部门使用,说明这个标签越有价值;某个高频使用的标签价值可以很低(用户姓名),低频使用的标签价值可以很高(用户信用评分)。

然后说点数据成本的优化策略吧,线上常见的有重复计算、冗余计算导致资源浪费,上面说的低价值的计算却耗费了大量计算资源,不合理的任务调度或者逻辑实现导致并行成了串行,数据资产的产出频率过于密集导致明明日报就行非得小时报刷新。这些也是数据运营的重要策略,而评估数据运营的两个关键维度就是 投入产出比 + 数据质量及安全

最后对于可持续性就提一下数据安全,因为数据安全关系到数据的全生命周期(产生-存储-传输-使用-共享-销毁),脆弱的安全体系甚至可以瞬间摧毁一个组织。这个我是真的不怎么专业,只知晓一些基本的,如安全认证和权限管理、资源隔离、加密、脱敏、容灾备份等等。这里面还隐含一个数据来源的合规性、合法性,数据本身就是不安全的,当然你在此基础上搭建的任何数据应用就更加的不安全了,极端点就是你的人身安全。

这个阶段基本上就是在迭代优化的路上不断持续运转,技术面、组织面、制度面都是需要跟踪的,如何保持数据文化长久的生命力,将是核心话题。

而我们将要长期走在数据铺就的这条路上,不断成长…

市面上谈中台的文章,开篇通常都是从芬兰的supercell公司说起,无趣的很。今天看到一个有趣的史料说法,中国东汉的中枢机关尚书台,号称中台。唐朝的三省六部制,尚书省也是中台,辖六部。当然,此中台非彼中台,权当一笑。

参考文献:
《数据中台-如何从大数据、大数据分析和万物互联中获利》

《数据战略-让数据用起来》
《中台战略-中台建设与数字商业》

知道MVP, 不知道PMF

发现很多做产品的人只知道MVP(Minimal Viable Product, 最小可行产品),

不知道PMF(Product/Market Fit, 产品符合市场需求,我经常戏称为”怕麻烦)。

其实可以简单这么理解,

MVP是针对问题或者市场的产品解决方案

而PMF就是验证用户是否愿意为你的这个方案埋单

金融科技的碎片化思考(上)

从事金融科技行业已久,也一直想写写金融科技相关的文字,又惶恐间,深觉如此大的话题hold不住而贻笑大方。偶然翻开束之高阁多年的《蚂蚁金服-从支付宝到新金融生态圈》,惊喜之余亦将自己碎片化的那点浅识愚见串联起不少。行文仓促,些许是经历,些许是总结,些许是念头,唯恐扭头就忘,权当流水记账给自己看也好。

又不是何样大家,可以著书警示世人,无须给自己压力,写到哪儿便是哪儿吧,看官您也担待一二。

金融是什么?
科技是什么?
合到一起的金融科技又是什么?
让我们剥开浮躁的表面直指内心。

科技是第一生产力

先说科技,也就是科学技术,是第一生产力。科学是理论,技术是应用。作为生产力,科技理论上可以应用于人类已知或者未知的所有领域,而金融领域不过是科技可应用的领域之一而已。当然可不仅仅限用“应用”,还可以“驱动”“赋能”“普惠”“整合”“协同”、“数字化”“互联网化”“智能化”“生态化”、以及“金融3.0”“VUCA4.0”“工业5.0““通证经济”“数字经济”“ABCD”等等 (金融科技领域不会用词,OUT一半!)。

对于大国来说,军事金融是两个最最核心的支撑力量。而通常来说,最尖端的科技也是始于这两个领域。 比如计算机最早是发明出来计算弹道的,手机也是战地移动电话发展而来。诞生于08年金融危机后并不断火热的比特币,其底层的区块链技术,也因为它独特的去中心化、不可篡改、智能合约等特性,逐渐进入了人们的视野。

金融的本质

金融就是价值的流通。而金融的本质,个人还是推崇黄老的那个精准表述,说到底就是信用、杠杆和风险三个词。此刻你可掩卷沉思一番,是否就是这么回事?

支付宝,担保交易模式的发明者,底层逻辑就是信用,依托于这个信用体系搭建出它的许多上层应用,如花呗、芝麻分、免押金产品…等等。吴晶妹教授有个著名的信用三维论来说明信用的构成,即诚信度,合规度,践约度。诚信度一般说的是信用主体的道德文化、行为准则等基本的诚信意识;合规度指信用主体在社会活动中遵守社会行政管理规定、行业规则、民间惯例等的水平与能力;践约度即言出必行,表现为遵守交易规则并履约的能力,比如天经地义的借钱还钱。

有些人对杠杆比较陌生,在我们日常生活中,其实可以把杠杆简单理解为负债。你的房贷是杠杆,手机分期是杠杆,借钱炒股(融资融券)也是杠杆…杠杆会放大风险预期和投资结果(无非更多收益或者更多亏损),以物理上的杠杆撬地球来形象的类比,就是以小资金博大收益,做好了是投资做坏了就是投机。所有金融危机的共同之处就是杠杆率过高(如2008年的美国次贷危机)。风险就很直白了,信用风险、欺诈风险、政策风险、流动性风险等等,风险管理和控制一直是金融业的重中之重。

诺贝尔经济学奖得主、耶鲁经济学教授罗伯特·希勒曾提出过这样的理念:金融不只是为了赚钱,而是为了推动实现良好(见仁见智的形容词)的社会。 现下却是,金融和铜臭味的金钱基本是划等号的。

金融现状体验

曾几何时,中国老太太和美国老太太的故事,影响了多少涉世未深少男少女的消费观。故事续集无须再编写,信用社会的美国在2008年用它的次贷危机狠狠的教训了一票“透支未来”的青春们。世事好轮回,苍天饶过谁。金融玩家总会找个时间,卷土重来、改头换面、千方百计地拿走你兜里的钱。

历史从未改变,从学校毕业后刚工作的你,自从有了信用卡、开通了花呗或者白条,月光、下月光甚至半年光是否成了常态,刚发的工资手里还没捂热,就得先还债去?!

我的年轻时代买个昂贵点的手机,得不吃不喝攒好几个月。也庆幸那时候的新手机发布不像现在这么频繁,不然等攒好钱再去买的那款几个月已经变成老款了吧。现在上万的iPhone,银行等金融机构直接给你免息的半年或者一年的分期产品,每个月还千把块钱的负担不成问题。看似这些金融机构不挣钱赚吆喝,且不说他们可以从商家那边收取佣金,用户似乎也着实赚了便宜,那这个金融产品到底在玩什么?抛开那些新兴金融机构的获客营销因素,金融玩家们提前半年甚至一年锁定了你口袋里的那部分钱,等当你口袋里没钱的时候,可以让你选择继续账单分期,再次加长你的借贷周期,而且这次当然就不是免费的了。某种程度上这加快了消费市场的产品更新速度,PUSH你换新的手机、新的相机、新的笔记本。还有更快的,贷款没还完,手机被偷了…(我身边可不止一例)

如果你的收入只是用来还贷,那必然没有额外资金投往投资理财渠道,你的资产其实就是在缩水。

有人开始动歪脑筋了…分期的产品想办法套现去买个高息理财…

虽然这点钱也挣不了几个铜板的利差,但,整个社会的金融杠杆就是这么被加上去了!

其实这里最恐怖的是什么呢?很多消费者在不断透支的行为中迟钝于金额数字的变化,透支第一笔无压力后继而透支第二笔第三笔,透支成为了习惯,然后日常收入演变成自动还款,直到入不敷出,个人资金断裂。这是一个可怕的潜移默化的消费行为养成。在这款金融养成类游戏里,你成了那个“金融宠物”。

频繁的P2P爆雷让多少投资者血本无归,当余额宝成为一个现象级的理财产品,大大拉低了普通民众理解和进入理财的门槛之后,各种各样的高息且打着银行、保本旗号的理财产品如雨后春笋般出现,人们蜂拥而至,一如抢购黄金的中国大妈。中国人的文化是相对保守的文化,在消费上就可见一斑,为何现在整个社会的消费观都开始变得越来越激进?理财观也随之激进起来了呢?高收益等于高风险,捡钱的事给你你敢要,只能说明金融理财市场的参与者,已经成为了一群群体无意识的“乌合之众”

若然金融玩家们就是想不断的吸食这些“乌合之众”,那这些玩家就是水蛭,就是要被国家打击和监管的,这不是金融该有的样子。把合规、正确的金融服务提供给社会群体,让他们明确的知晓风险和收益情况,才是正道。

FinTech Or TechFin

马大大烙印下的蚂蚁金服在金融变革上一马当先,造词功力那更是一流。在金融和科技谁先谁后的问题上,很多人或组织还没搞清楚的时候,蚂蚁已经提出了TechFin的概念。

在这之前,互联网科技从业人员多以变革者甚至颠覆者姿态切入金融领域,看不起传统金融的那一套,一门心思让科技驱动金融、颠覆金融。忽然有一天,传统金融准备联合起来(打小报告也算)对这帮不知天高地厚的“变革者们”动刀了,“变革者们”才发现自己完全不够个儿,主要表现在比如对风控的无知、对政策的漠视以及对金融产品设计的忽视等等,这是其一。其二,金融业可追溯到公元前,如此悠久的历史让金融体系的内涵和外延如此庞大,科技想一口吃下来,不啻于痴人说梦。不懂金融却宣称颠覆金融,很可怕。

其实,科技并没有改变金融的本质,最多改变了金融信息传递的速度、距离、时间等等因子。科技可以重塑金融的形态,助力金融更好的服务于长尾客户,最后两者你中有我,我中有你,互相融合才是终态。所以Fin & Tech谁先谁后,孰优孰劣,Who cares!

那么,互联网金融科技公司到底给社会带来了什么呢?在很多人眼里这些公司不过是金融水蛭,附着在金融体系这条大腿上不断吸食穷人的那点鲜血,没有任何价值。这观点当然过于偏激了,让我们辩证一点来看。金融科技在很多交易场景里带来了很多的便利性,也可以给资产和资金搭建了更快速安全的平台(比如余额宝、P2P、助贷平台、智能投顾等)。要注意的是,随着资金和资产的瞬息转换,这给金融监管提出了难度更高的命题。资产证券化、债权转移、洗钱等等都藏在这海量的金融交易中,如何监察呢?在很多金融交易场景中,传统金融机构沦为了金融科技公司背后的资金方,海量交易行为和金融数据都被金融科技公司给截留了,传统金融不可能甘心藏于幕后,看着金融科技起高楼宴宾客,即便自己转身较慢,但一旦转过身可能就不会给金融科技什么机会了。

金融科技的出路

上文也或多或少提到了,科技颠覆的不是金融的内核,而是金融的外在形态。金融也不仅仅是只为富人或者大型企业服务,也应该为更多的普通人和小企业服务,所谓的普惠金融就志在于此。我理解金融科技的出路就是,用科技让金融更好地服务和优化商业活动和经济生活。二维码支付、人脸支付、征信链,小微贷、消费贷、智能投顾…这些技术和产品就在我们身边,服务于支付、信贷和理财等场景。

让我预测金融科技未来的话,内核一定是“服务”二字,只要服务好社会助力好金融,收益会随之而来都不需要刻意逢迎。任何只盯着如何用科技在金融行业赚钱的组织或个人,不出意外最后都得吐出来。在合规监管体系下的金融科技必须要看清楚自己的位置,与天斗其乐无穷,与金融斗死无全尸。

接下来就是考虑如何切入金融“服务”这件事上来。更好的服务切入通常意味着目前存在糟糕的体验或者痛点,比如基于社交网络的反欺诈,传统的关系型数据库在两度的社交网络中表现得已经捉襟见肘,无用说实现更多的度;图像识别技术给远程开户、活体检测提供了比人类肉眼更快更精准的鉴别能力;决策引擎的出现给风控业务人员更灵活、更安全以及性能更强劲的风控基础工具;区块链技术给了征信透明、资产溯源以及清结算等提供了更多的思路…

发现了么,这些技术解决的问题基本都是金融行业固有的一些痛点环节或者糟糕体验,很长一段时间内这个方向不会有太大变化。恕我能力有限,不排除真的有颠覆性的黑科技出现,但我想它一定是要举全社会之力才能实现的吧(比如鼓吹了很久很久的区块链征信)。

以上,只是金融科技从业者的喃喃自语。

给程序员的错误找个台阶

题图

2020这个人生最漫长的寒假,翻了一些书,记下不少名人趣事。百无聊赖间把这些小故事做了个分类,再把平日所见种种对照落入其中,遂成此短文。

我工作中常常以错误零容忍自居,对团队的错误”颐指气使”,想来也是让人极为厌恶的。人非圣贤,高人亦如此,何况吾凡辈。有些错误换个角度反而是一种美,那我们就从递台阶开始吧。

01 管杀不管埋

台阶:大名鼎鼎的J.U.C并发包

程序员皆知J.U.C包的造物主是并发大师Doug Lea。在jdk5之前对于线程同步使用的技术基本就是synchronized、wait、notify这些(用过jdk1.4或更早版本的老古董可以文末举个手,大爷我从jdk1.3入坑)。这时的并发控制不够优雅,性能也差的很,直到Doug Lea把JSR-166号提案提交到JCP组织(https://jcp.org),而这个JSR-166就是J.U.C的技术规范。

更牛掰化的是,在提案之前Doug Lea早就写完了基本类似现在J.U.C的整套原型代码,并已经使用它长达3年之久了,我们真该庆幸老李没有藏起来自斟自饮。

参考 The birth of J.U.C
https://programmer.help/blogs/the-birth-of-j.u.c.html

即使如此牛掰,我们也要鸡蛋里挑骨头。当使用 synchronized 关键字使对象阻塞时,通过线程dump能够看到被该阻塞的对象信息,方便问题定位。而jdk5里面的Lock等并发工具却遗漏了这一点,致使dump线程时看不到阻塞对象的信息,因而不得不在jdk6中的LockSupport新增了含有阻塞对象的park方法。

老李这种神人可能压根不需要dump文件,就可以盲分析出线程问题所在。但是这可苦了我辈Javaer了呀,因为代码不仅是给人用的,还是方便给人修的,不然很多数码家电都有厚厚一本操作手册可不是当摆设的。

不过这个锅到底是不是老李的,历史过于悠久,搜遍Google亦无从考证,遂作罢。老李背不动总得有jdk的某个人背。

管杀不管埋,个人觉得,是程序员群体特别容易掉进去的一个错误陷阱。它像不像写代码不写注释的你,像不像通篇大段逻辑代码却没有打印日志或者打印无脑日志(无助于排障)的你,像不像应用上线没有接入日志系统或者监控系统的你…现在,台阶已奉上,供君拾级而下。

02 绣花枕头

台阶:Homebrew的作者谷歌面试被拒

平时用macOS做开发的同学一定对Homebrew这个软件包管理工具不陌生,这个广有知名度的软件的作者Max Howell某一天去谷歌面试,面试官让其在白板上徒手写个反转二叉树的代码实现,这位大神说不会,然后就没有然后了,再然后就有了上面的twitter怒怼,再再然后LeetCode上架了这个算法题并标注为Easy级别…

此热门事件当时在程序员圈迅速发酵,引起正反两派的激烈辩论。但双方不管怎么互怼,大部分人应该私下都偷偷的去把反转代码撸了几遍,然后像模像样的再把非递归的比如队列算法再撸几遍,顿时,感觉自己要超越世界级大牛了…至少在反转二叉树这块…

说绣花枕头略有些过,毕竟任谁都会有一些知识死角。反过来说,还是看我们怎么定义这个问题,到底是不可避免的知识死角还是过于薄弱的基础能力。扬长避短是一种人生,那查漏补缺未尝不是一种更积极的人生态度

03 玩物丧志

台阶:Unix本是用来玩游戏的

现在我们开发环境所属的操作系统无非Windows, Mac(Unix BSD分支)或Linux(类Unix),除了Windows其他两个的内核鼻祖都是Unix。那么当然地,作为Unix的发明人 Ken Thompson 和 Dennis Ritchie,必然是鼻祖级的传奇人物,更不用提他俩一个是B语言之父,一个是C语言之父了。

何曾想,Unix的诞生只是因为一个叫Space Travel的游戏在当时的MULTICS系统上运行太慢,要迁移到一个更精简的操作系统上。然后有了Unix,和它收割世界的故事了。

Space Travel游戏真身
https://en.wikipedia.org/wiki/Space_Travel_(video_game)
https://www.uvlist.net/game-164857-Space+Travel

有人因为游戏开发了外挂,有人因为游戏开发了Unix…看来玩游戏并没有那么不堪,换个角度,游戏确实也是用来放松和激发想象力的有效手段,只会机械的编程与咸鱼有何分别?那么,工作中有些小伙伴玩心重,建议也不要急切的下定论。

依然记得当年公司的编程规范考试,我找了个开源的PHP考试系统简单修修改改后,部署发布在了公司内网。考完后的阅卷原以为平淡无奇,直到发现有人在编程题里注入了XSS代码,具体的弹窗内容已经不记得了,我只记得他当时错了蛮多题,理应过不了考试,但是我依然给了他过,不只是因为有趣还因为作为小鲜肉程序员有如此的知识厚度很难得。此时的我并不想拿规范考试束缚他。

恩,足够牛逼的人走到哪里都会有特权,就是这么回事。

附一个很有趣,Star高达38K的Github项目
https://github.com/kelseyhightower/nocode

04 砍材不误磨刀功

台阶:写算法我最优,但写书我得慢

我们要再提一个神级大佬Donald Ervin Knuth, 中文名叫高德纳。

不少人以为是Donald的音译,叫人家高纳德,以人家自己的首页为准
https://www-cs-faculty.stanford.edu/~knuth/

称他为算法之父毫不为过,因为我们现在用的数据结构、算法复杂度、算法分析符号啥的都是他发明的。当然更为世人所熟知的是他的巨著《The Art of Computer Programming》,简称 TAOCP,中文名 计算机程序设计艺术。原本出版社只想跟老高约一本关于编译器和程序设计方面的书,结果老高四年没写完,手稿倒是写了一堆,憋着劲要写一本传世之作,算来算去得整七卷。意料之外情理之中,刚刚写完第三卷,就被计算机界奉为神作,ACM的评委们也坐不住了,迫不及待要给老高颁发图灵奖。所以至今,老高(当时36岁)仍旧是最年轻的图灵奖获得者。

历史继续滚动,故事却刚刚开始。拿到图灵奖后不久老高就宣布搁笔,理由是排版工具太差,不能忍了。紧接着,说江郎才尽、见好就收的非议如期而至,人老高神人怎会在乎尔等凡人的屁话,说搁笔就搁笔,一搁就是十年之久。期间老高可没闲着,陆续创造了文字排版系统TEX(大名鼎鼎LaTeX的雏形)、字体设计系统METAFONT和文学化编程Literate Programming。再拿起笔写完第四卷已是2008年,距离第三卷过去了30多年。

你说30年,用再烂的排版系统怎么也可以捣鼓出来一本书了吧?话是没错,但这和写代码不复用不抽象,就是CopyPaste有何区别呢?

笑话一则
当年Linux之父Linus说:上帝在梦中告诉我,我做出了最优秀的操作系统。
高德纳回答说:我可没这么说过。

程序员的工作目标从来不是最快而是最优,工作内容从来不是重复性劳动而是创造性工作。若因为蹩脚的工具、繁冗的流程、糟糕的设计不能忍而影响了自己的交付进度,不用怕,程序员就该有程序员的样子!

以上,共勉。

我也曾对架构师的力量一无所知

是不是觉得这个标题似曾相识?

没错,就是致敬韩寒的那篇《 我也曾对那种力量一无所知 》。全文主旨就是业余玩家自嗨可以,但千万别狂妄到企图挑衅专业选手。否则,下场就和当初的 松江新区·奥沙利文·韩寒 一样,在潘晓婷面前只有开球的份儿。

镜头后的导演韩寒

虽说我和韩寒同年,但也算是“看着他长大”的。韩寒成名于新概念作文,而后不断开挂,在作家、赛车手、导演等多个角色上都游刃有余且扮演的相当成功,如此色彩斑斓的人生一直让我艳羡不已。而我,一介码农,初时随波逐流,醒时已亦步亦趋在架构之路上,艰苦非常。

因为,架构师的力量,我也曾一无所知。

代码执念

每个程序员对美的代码的认知不尽相同,但大多有个共识,那就是,架构师设定的各种条条框框简直是对美的亵渎
其实,你可能对架构师的执念一无所知!

表面看到的:架构师成天没事找事,发布代码规范,设定评审标准。执着于代码的洁癖,分层的固化、API的标准化、中间件的抽象化…

实际发生的:光秃秃(没注释)的形似被混淆过(儿戏的命名|对不齐的段落)的千行代码,事务的注解可能在每一层都出现过,逻辑代码散落在Business/Service/Dao各层,只是因为不喜欢Hibernate所以选择MyBatis,只是因为谷歌脑残粉所以选择Gson/Guava…

随心所欲的代码会带来维护的困难和各种技术债,不统一的技术框架会引入更多的学习切换成本和升级优化成本,评审口径不一致会导致团队聚焦散乱各自为战…架构师作为团队的一个辅助型英雄,着实操碎了心。

架构师的执念,就是尽最大努力,在低位面减少技术熵增,高位面寻求技术突破

通过规范指定的标准都是低位面,不需要你在低位面上浪费任何时间扯犊子。而高位面一定是无法给出规范标准的,任你创新和发挥。

同样是打印Hello World,就是有人会多渲染个ASCII字符画,让控制台输出不那么冷冰冰。
figlet字体
Console输出

第一次看到架构师写出下面这种条件表达式的非常规写法时,

1
2
3
if ( 1 == iCount ) {}

if ( null != response && "SUCC".equals(response.getCode()) {}

年幼无知的我曾经“嗤”出了声:“写个等式都要颠三倒四,整噱头博眼球么?” 直到我写出了如下错误,

1
2
3
4
if ( iCount = 1 ) {}   
//漏了等号,永远为真
if ( response != null && response.getCode().equals("SUCC")) {}
//少写判空导致的空指针异常

这种代码的反差犹如龙门客栈的老板娘金镶玉,看似风骚泼辣杀人越货,实则纯粹坦荡z至情至性。

张曼玉版金镶玉

当你傻傻的写乘/除2的N次方时可还记得骚气的位运算…骚气的try-with-resource…骚气的Lambda…骚气的动态字节码…比比皆是。

这么些年我总结下来,架构师对代码的执念就是八个字:稳中带骚,骚中求稳

Python之禅 收个尾:
The Zen Of Python

造物主思维

只活在IDE里写代码,是成不了架构师的。

某个风和日丽的下午,公司里一个小伙伴到我面前说:他申请在一个月内重写消息网关系统(承载短信、微信、邮件、App推送四大渠道),原因是目前的系统太难用了。我的第一反应是 “WOC,我一直盼望的那个救世主终于出现了么?!” 其实吧,那个消息网关系统曾经是我和架构组兄弟花不少力气设计的,本身并没有什么大问题,最多就是随着消息数量的指数级上升,需要做一些性能优化,比如 分库分表数据归档 就能解决大部分问题,而这些升级所需的扩展性在设计初期就考虑过。我生怕表现出对这位“救世主”的质疑而显得不礼貌,就小心翼翼的试探了两个问题:

“如何平衡上游业务的洪峰和下游消息通道的最大承载,最大化单位时间内的吞吐量?”

——微服务体系的流量控制

“个人交易消息和全局活动消息,如何存储和查询?”

——时间和空间的抉择

结果我得到的回复只是线程池、异步化和缓存的泛泛之谈,离真正的落地还差的很远。除了上面2个问题,还有同步异步、时效、延迟、通道隔离、信息补偿、环境开关等的实现同样很重要。

造物思维就是从0到1需要的思维,这个1可不简单,它必须包含进化到100所需要的一切基础铺垫。女娲抟tuán土造人只存在于神话中, 而架构师就是可以从0到1创造系统的“上帝”,只是翻船事故时有发生而已。不要轻视任何从0到1的创造性活动,这里所包含的知识或技能体量远超你的想象。

为了解释这个过程,请你单从数学的角度,告诉我 (0, 1) 这个开区间之中到底有多少个数

  • 如果是无穷,那么二进制的计算机如何运算这无穷的数字呢?有同学回答,计算机是使用离散的浮点数来表示这些小数的。是没错,而本质上,浮点数在坐标轴上也就只是很密集的点而已,根本就不是连续的线。
  • 既然全是点,更加疑惑了,计算机怎么画线呢?到这里就可以结束了,因为显示器的像素本就是人肉眼无法识别的小格子,足够密集的点足以呈现出线的效果。
  • 继续刨根问底,那得了解下什么是定点数了,才可以让密集的那些点更加的密集。

希望你能静下心来读读这篇浮点数,
读完你至少可以了解“取值范围”和“可表示的个数”之间、浮点数和定点数之间的区别等等。

《格物致知-Floating Point》

我想我应该从一个理科男的角度,说明白了创造需要的是什么:足够密集的知识点和它们之间的连接。也有人把它包装成了“**知识体系**”,说到底,一个意思。

创造本身已然不容易,如何创造更加五花八门。架构选型其实就是选择如何创造
同样是索引化的数据存储,Kafka是索引文件和数据文件分离,MySQL InnoDB却是索引和数据在同一个ibd文件里。都说多线程吞吐量高响应快,Redis却选择了单线程模型(Redis6已经加入了多线程实现,主要用于处理网络IO上。命令的执行依然是主线程串行执行)。孰对孰错?
所以创造从来都不是千篇一律,也不是一成不变,而是量体裁衣

高明的架构师心里藏有无数的架构设计方案,但对于不同的场景,他会选择最合适的那个来实现。因为架构更像一种艺术而不是科学。你只看结论的话,或许最终方案并不怎么出色,甚至很普通。但是它是经过N个方案PK胜出的The One,对其他你以为更好的方案所面临的未知,你可能一无所知。

面对未知的勇气

我有深海恐惧症,许多人都有。因为面对黑不见底的海水,我们充满了对未知的恐惧。

百度有时也挺人性的

IT行业的未知每天都在发生着,经常让我们手忙脚乱。何谓”未知“?它可以是诡异的生产故障,可以是全新的技术,也可以是模糊的未来业务形态, 而架构师的核心职责之一就是从容的解决未知

就,对大家来说一样都是未知,凭啥架构师就有勇气从容应对?傻孩子,架构师的身后哪里还有人?不得死撑哇!当然我是在开玩笑。许多诡异的生产问题有重启大法,但让习惯了SSH编程的你,使用Reactive来实现一套响应式服务端系统,这种未知领域你会如何应对?连产品经理都看不清的未来业务形态,你又会如何设计系统的扩展性呢?

草木皆兵

问:你这一生碰到过的最严重的生产事故是什么?
答:抱歉,从未碰到过。

你会如何评价此人?架构师生而从容,不仅是做到泰山崩于前而色不变,更是因为严重的事故甚至细微的事故苗头都早已被扼杀在摇篮之中。海恩法则指出:每一起严重事故的背后,必然有 29 起轻微事故和 300 起未遂先兆以及 1000 起事故隐患。

几年前有段时间我开车总觉得方向盘有点松动,一直没当回事,觉得可能车老了或者自己平时方向打太紧了。某天预约做保养,车店老板小马哥把我车开走没10分钟,就给我来一电话:

“你的转向柱可能出问题了,方向盘有点松,你之前有发现么?”
我知道的,可能车老了吧,也没当回事。
“你小子,转向问题很吓人的,我都不敢开了,到店里马上帮你检查看看。”

后来结果你们也想得到,真的是转向柱断裂!幸好在事态严重之前,小马哥凭借专业素养发觉了这个隐患。所以这到底是是我的无知无畏还是小马哥的小题大做?开车的同学都知道车的制动、转向是性命攸关的大事,但是你自问对 车跑偏、刹车异响、刹车发抖、转向沉重 都足够警觉么?其实,架构师在评审会上表现出的“草木皆兵”亦是一种执念,他所看到的“尸横遍野”,你可能一无所知。

知道自己不知道

给你100W让你实现一个数据库,这活敢接么?就说这活本身,先别忙嫌钱多钱少。把你所有的与数据库相关的知识拿出来,你看看能凑出下面哪些模块出来?先搞清楚“知道自己不知道”的是什么,才有办法将未知变已知。解决未知就是不断的转化已知的过程。这也是为什么竞品软件都在造轮子,但是侧重点迥然不同,就是已知不同。这个“已知”可以是商业产品、开源产品,也可以是论文报告,还可以是业务、技术痛点,不一而足。RocketMQ当初参照了Kafka,在牺牲了部分性能的情况下优化了投递时效、消息顺序、消息轨迹等;TiDB 是基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库;开源调用链如Skywalking、Pinpoint都是基于 Google Dapper 论文实现的;界面简洁、容量大、搜索强的 Gmail 横空出世,面对众多传统邮箱的狙击,依然成为人们最爱的邮箱品牌,顺便激活了半死不活的 javascript

未知? 不过尔尔。

架构师的天赋

只有天才的程序员,没有天才的架构师。

架构师靠的不是天赋,而是勤勉,要靠大量时间进行实战操练和经验积累。身边水货架构师这么多,也是因为国内的技术氛围略显浮躁,留给架构师成长的那点可怜的时间和空间,时刻被公司项目挤压着,拔苗助长,不得不水。热门吵架题目“架构师要不要写代码”,理性点的人会把架构师做个分类,摘出个比如 业务架构师,说可以不用写代码。但是他不可能从石头缝里蹦出来,若没有对业务浸淫多年的历练(编码只是一个历练维度),如何能设计出合理的业务架构来?所以别再问这种傻X问题了,何苦给自己的偷懒找借口还如此冠冕堂皇?宁愿换个题目讨论,“架构师的门槛是写多少行代码”

技术密度

程序员起步阶段的技术能力,通常是“蜂窝”状的,也就是存在大量的技术空洞,而这些空洞需要通过勤劳的采蜜,累积一点一滴的“蜂蜜”来填满。科学爱好者都知道中子星的密度堪比黑洞,类比将地球压缩成中子星,直径只有22米,普通的原子都没办法在中子星附近停留,会被撕碎、经过引力坍塌后进一步压缩。架构师就擅长这种吸收并压缩知识的套路。硬要我给架构师的天赋定一个指标的话,那就是技术密度的高低。初二物理都学过 密度 = 质量 / 体积。对应到代码,同样质量的一个功能,你写一页,架构师寥寥几行,这就是高技术密度的直观体现。

有效练习

再来,假如已经部分交付如上图的一个“蜂巢”系统,现在需要你实现更多的“六角蜂室”以扩充这个蜂巢。

这个工作乍看起来像不像重复劳动?

其实不然。
首先为什么选择六边形? 不是圆形不是三角形不是正方形?经测量,六边形蜂室的所有钝角都是109°28′,所有锐角都是70°32′。曾有法国数学家研究过,如果要消耗最少的蜂蜡,制成更少间隙、更大容积和更坚固的容器,就只有这个角度的六边形。

其次蜂巢是倒挂的,为何液态的蜂蜜不会流出? 因为蜂蜜本身含水量不到18%,流动性比水要低得多,但低流动性不代表不流动。所以蜂巢要保持9~14度左右的倾斜,进一步防止蜂蜜流出。

实际结果是,你的“蜂室”交付了,但是你对角度,一无所知

我生来觉得自己是个愚人,即使学习成绩一直算优秀,也会全归于自己的勤勉。因为身边的天才好像真的不需要努力。我能成为架构师,也是走上程序员这条不归路的不得已之选。架构师之路漫长且艰难,而今我也只是摸到些许门路,大多时候对于自己的“不知道”依然惶惶不可终日。

你是否也曾对架构师的力量不屑一顾过?不管是立志成为架构师或已然成为架构师,都请谦虚并努力起来。谁也不敢妄言自己掌握了架构的终极力量,因为

架构之路越走越无知,一如人生路。
尊重架构师的力量,一如尊重未来的你。

JIRA自定义一个优雅的可多选下拉列表

公司PMO最新发布的规范,需要在每个JIRA故事里输入涉及上线的应用系统名称,最开始就是自定义了一个最简单的文本框,让Owner自己填写,多个系统逗号分隔。后来在数据统计的过程中发现系统应用名每个人写的千奇百怪,难于对齐。所以考虑将所有的系统应用名称导入到JIRA中,让Owner直接选择减少出错概率。但是JIRA内嵌的几个标准自定义控件,实在是不好用。

自定义字段的路径是:右上角的“JIRA管理” ->“问题”->“自定义字段”->”添加”,可多选的字段类型如下:

  1. 多个checkbox的复选框,对于我们上百个的微服务系统,全部陈列到一个页面,那简直没法看,故而放弃。

  2. Select List(多选)是个带垂直滚动条的多选框,这个控件也有问题,若上百个系统在里面滚动,多选需要按住Ctrl来多选,而且在滚动过程中,如果不小心没按住Ctrl,之前其他人选择的系统名称,可能就丢了,不直观。

  3. Select List(级联) 场景不合适,忽略。

  checkbox 和 多选列表效果如下图所示。

那么有没有一种更优雅的方式,可以在下拉列表中多选,而且每次选择后可以有直观的提示我选择了哪些呢?当然有!而且只需要简单的几行代码。步骤如下:

**1.**继续之前的路径,在自定义字段界面,仍然选择Select List(多选);

2.**名称随便输入一个你想要在Issue编辑页上显示的名字,比如我这里是叫”**Related Applications“;

**3. **描述文本框留空,本文最关键的几行代码就是要存到这个“描述”里;选项先随便填入一个,确定即可;

**4. **进入JIRA的数据库中,运行如下SQL,找到这个ID,比如是12000;

1
select id from customfield where cfname='Related Applications'; //cfname就是刚才你自定义字段的名称

5.**复制如下的代码,将里面的替换为上一步从数据库里查询到的ID,比如
**customfield_

 替换后变为(注意不要不小心加入空格啥的)

customfield_12000

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<script type="text/javascript">
(function($) {
AJS.$("#customfield_<cf-id> option[value='-1']").remove(); //Removes the default value "None"

function convertMulti(id){
if (AJS.$('#'+id+"-textarea").length == 0){
new AJS.MultiSelect({
element: $("#"+id),
itemAttrDisplayed: "label",
errorMessage: AJS.params.multiselectComponentsError });
}
}

AJS.toInit(function(){
convertMulti("customfield_<cf-id>");
})

JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function (e, context) {
AJS.$("#customfield_<cf-id> option[value='-1']").remove();
convertMulti("customfield_<cf-id>");
});})(AJS.$);
</script>

6. 从JIRA管理重新进入”自定义字段”,选择”编辑”,将上一步全局替换完毕的代码黏贴到“描述”中,保存;

7. 退出继续对自定义字段“配置”多个可选项,手动一个一个添加吧…

我曾经试过直接在数据库表 customfieldoption中插入,后来会引起ID冲突,全部回滚了。如果真的太多选项,你可以网页抓一下network找到那个jspa接口,自己写代码调用接口也可以。反正尽量不要直接操作数据库。

优雅的下拉列表

大功告成!!!

欢迎关注我的公众号

写给工作5年的年轻程序员的一封信

“准大牛”兄,

见信好。

希望你不会反感我给你的这个特别称号。我们程序员中的大部分工作到5-6年这个节骨眼儿,不出意外可以称为“准大牛”了。此时的你技术研发能力正在成熟或已然成熟;架构设计能力初现峥嵘;创新能力让新奇想法层不出穷;管理能力正在路上以寻求角色转变;总之你正在打磨自己专属的个人标签和风格。这个时点是个小高峰亦是关键转折,此信写予你,乃近多与此段位朋友聊天的触动所得,权当小叙寒暄,建议也好警示也罢,老年人难免絮叨,还忘担待一二。

自知者明。

老子说:知人者智,自知者明。识人知人已然需要莫大的智慧,而更高明的人还需要做到“自知”,即知晓自己的长处和短处、优势和劣势。而通常情况下“目不见睫”,自己是看不到自己缺点的。这个阶段的你比刚毕业走入社会的迷茫的你并好不了多少,此时的你有了相对扎实的技能和功力,面前的岔路会更加的多样化,会更难以取舍。自知是你以后拥有自信、自律、自尊和自强的根本。自知很容易发生如下两种极端,请甄别后尽快调整。

第一种倾向于自我能力的否定,有个专有名词叫“冒充者综合症Impostor syndrome”,形容的就是这么一群人:或者觉得凭自己的能力无法取得成功;或者即便成功了,也会归结为其他因素(如侥幸)。这种心理的形成分两类:一类是因为过于追求完美,生怕破坏完美,继而产生否定,一类是因为甚少得到肯定,从而对自己的能力产生了质疑。我自己就是追求完美导致自我否定的那类人,比如写篇文章都会推敲纠结好久,生怕写出什么漏洞被人耻笑。后来在公司推行知识共享文化的时候,发现我不是一个人…很多团队的小朋友其实能力不错的,但是让他写篇文章好像要了他的命了,非遍稽群籍不敢投稿。精益求精不是错,但还没到大牛的档位先拿大牛的标准否定自己,这是病,严重点会演变成自卑,得治。治疗方案很简单,适当放低自我标准,有进步空间但不会压迫感十足的那种。

第二种反过来是高估自己的能力水平,也有个对应的专用术语叫“达克效应”,通俗点的说法就是“无知者无畏”,达尔文也说“无知要比博学更容易产生自信”,确实,盲目的自信可以让人无所畏惧。很多人包括我自己有时候都没意识到自己在无知中让人贻笑大方,我这里罗列几种典型的行为特征供你参考,很可能你已经在品尝无知造成的恶劣后果:

a. 在他人发表意见的过程中频繁打断对方,而且并没有认真聆听他人的表述;

b. 周遭四处弥漫着你的反对声音,而且并没有提供更有效的解决方案,仅仅是吐槽的反对;

c. 保守,难以接受新事物,展现出比较强烈的抵触情绪;

d. 激进,恨不得一股脑全部重构。觉得历史的代码都是垃圾,自己分分钟写出更好的作品出来;

e. 团队合作用较负面的情绪、烦躁的语气交流,比如被无端打扰时;

f. 觉得身边没有什么值得学习的对象,通常对公司内部培训的建议是非请阿里P9大牛不可得,基础培训从不出席,别问,问就是觉得出席这种太Low;

g. 眼高手低,逢评审必谈高并发高可用,但最简单的CRUD连个事务、异常、监控处理都没有考虑清楚;

如果你有上面的两条就得小心提防了,就算你不是真的无知,但是你是真的飘了,特别特别危险。

重拾谦卑。

当一个平时多仰视之人突然有一日可以俯视他人之时,特别容易滋生自负情绪。而你现在的时点正好是有机会俯视他人,想一想你看待工作1-2年的小鲜肉这也做不对那也做不好时的心态几何?你或多或少陷入了沾沾自喜,眼高手低,停滞不前,单兵作战不喜团队协作,自由散漫不喜规范束缚的幻象中。把你从膨胀的幻象中唤醒一时,不难;但让你完全清醒过来,却不容易,过来人给几条建议:

  1. 找一位真正的大牛,找机会与他做几次思想碰撞,让自己深刻领悟到什么是井底之蛙和天外有天。“准”与“真”之间的距离可以放得下一个马里亚纳海沟,你的这点小成就在真大牛眼里自然不值一提,你自己更不应该因此自我满足。胸中有丘壑,立马镇山河,你的未来是星辰大海,永不停歇。

  2. 自负会让你在职场中处处受挫,而谦卑会让你受益。认真听取他人发言,仔细斟酌他人建议,虚心采纳他人意见,乐于合作并帮助他人都是谦卑的表现。而当你无时无刻都想通过为了反对而反对来展示自己的与众不同,当你肆意挖苦他人的不成熟或错误,当你视制度如无物深觉那是无能人士才需遵守的线,当你对合作不屑一顾只想自己单干…那你已经在自负的路上了。请重拾谦卑。

  3. 能够客观评价自己这5年的沉淀,到底是通过夯实基础技能、构建知识体系、突破思维局限带来的成长型积累,还是经年累月的熟能生巧和混资历带来的?多吃几年饭造成的“领先”,并没什么了不起,分分钟可以被人超越,这样说会让你更清醒一点么?

升级思维。

初入职场的人经常吐槽的对象是直接或者间接上级,特别讨厌他们只会发号施令,放嘴炮不办实事的样子,这个阶段的人是执行者,是打工者,是眼界局限者。而你现在已经是工作5年的“准大牛”了,上级已经不可能还是吩咐你做一件件很具体的事务了,更多的是需要你主动往前走一步,可能没有参照,需要从0到1给出解决方案,你看待上级要做的事情也远远不是简单的执行。你的思维模式再不升级就晚了:

  1. 领导思维。“领导”翻译下就是:带领一群愿意跟你拼的小伙伴,一起攻克难关。这句话千万别理解成只要我自己足够牛逼,就可以拖着团队干成大事。这句话的题眼其实是如何让团队“愿意跟你拼”,并不是你有硬实力就一定有魅力,你的沟通软技能、你的规划统筹能力、你的赏罚分明公允性、你的驭下和向上管理…都是你让团队有凝聚力和执行力的重要元素,等你哪天可以说出“带团队好辛苦,真不如以前闷头做任务来的轻松”,这时你可能已经准备好接受挑战了。

  2. 业务思维。程序员崇尚技术第一本无可厚非,但很多人把业务能力放到了技能鄙视链中,就着实走偏了。我问过不少这个阶段的架构师未来的职业规划,他们的回答无一例外,还是想专心钻研技术。当我再问你现在在钻哪一块时,回答高并发的有,网络协议的有,开源框架源码的有,算法的也有…但也仅限于有,真正钻研深入进去的凤毛麟角,现在的你有点浮躁哦,其实你得承认,你已经耐不住寂寞啃技术大部头了,你对很多知识也不过是浅尝辄止,给自己营造一个未来还要搞技术的空中楼阁,不过是自己骗自己。老老实实把业务短板补齐,架构从来不能够脱离业务,再好的技术也是为业务服务的,不要本末倒置。

  3. 组织思维。这里的“组织”是名词,是说要从整个组织的视角来考虑事情。当一个任务来临的时候,你有能力把它以不同团队的职能范围来拆解。比如你是后端研发团队,你的思维视角不应该仅仅是完成编码,还应该有测试、运维和产品等一切影响组织交付的因素。这个其实是老板的视角,当你学会从老板的角度思考,你就有了一定的组织化的思维,当你设定的目标与老板基本一致,你的路会越走越宽。大局观并没有那么容易形成,凡事从自己的角度思考是一种人性的自我保护和利益驱使,你要做的可能就是把自己融入到这个组织,比如当成家,不妨一试。

找回好奇心。

人的锐气和冲劲容易被时间所消磨,但磨掉的应该只是稚嫩和毛躁,你的好奇心应如同儿时,请务必保持新鲜。

当你一次次的期望用新技术、新框架、新版本、新特性来一展宏图而被泼冷水的时候,我希望你能仍能坚持你的初心。任何一个组织的终极目标一定是赚钱,你的任何技术追求都会受制于这一点,除非你的新技术可以带来更大的利润,否则不要大动干戈,可以把这些新技术小范围落地试水,没有人会刻意打压你的热情,这种无奈你要学会去理解。

当你一次次的新奇想法被HOLD住,不要激烈反抗和吐槽团队的无能。这个世界毕竟还是由“大多数”人组成,你的新奇想法需要验证,不要犹豫,请把它转换成原型、DEMO来佐证你的想法,否则你的想法永远只是想法,你的新奇也仅仅是新奇。也许大多数人还无法领悟你的先进,他们需要的只是你的一个更直观的引导。

当你在某个技术或者业务领域有足够的累积,你的知识体系其实也在折旧。当团队有新的思想、新的技术碰撞出来的时候,请保持聆听和好奇。先尝试理解这种新鲜,切不可用你略显陈旧的知识体系居高临下的批判,不敢接受新事物是你要老去的信号,而好奇是让你保持进步的绝佳佐料。

洋洋洒洒废话写了不少,其实我就提到了自知、谦卑、思维和好奇四个点,我也懒于找寻他们的内在关系,至少我或者我看到一些朋友曾经在这些上面吃过亏,如此应该足够了吧?

恕不一一,

成天瞎操心的曲大爷
2019/12/2

DàYé首席路 | 10.24条程序员生存法则

笔者曲健,1024生人,天选程序员,浆糊人送外号“大爷Dà Yé”,目前在奥琪科技担任首席架构师一职。

彼得德鲁克的经典之作《卓有成效的管理者》里提到,知识管理者必须学会自我驱动、自我管理,而动力取决于工作是否卓越有效,是否有所成就。程序员就是典型的知识工作者,本文就是细数一下程序员的生存之道,或者说自驱之道。

00 优雅的命名

程序员生存法则Number One, 无出其右者,且不接受挑战。

务必记住,程序员的第一武装不是格子衫不是脱发,是代码! 如果把代码比喻成人体,那么逻辑(指令)是经脉,数据是气血,而命名就是穴位。

大家想想在阅读代码的时候,不管是变量名、方法名、类名还是系统名,都是用于辅助理解逻辑/功能的特别重要的标识。我可以负责任的说:程序员命名能力的高度基本决定了他/她未来的高度。命名绝不仅是名字本身,它更可映射出作者的思维框架、知识外延、逻辑推理、语言能力、创造力、想象力等等,所以是不是瞬间拔高了?

可以参见我之前关于取名技巧的一篇文章《IT范儿 | 你是个会取名儿的人么?

DàYé啰嗦

# 长点心好好补补英文,程序员阅读各种英文文档需要词汇量自不必说,如果你每次命名都需要翻译软件,不自知的取最生僻的那层含义,或者各种拼写错误,往大了说特别容易引入BUG,往小了说实在丢人丢份。

# 同一代码块/层级/工程中一定不要出现过于相似的名字。由于相似导致写逻辑的时候把自己整乱的大有人在!每每评审看到这种代码吾必痛心疾首。

userVo, userDTO, userBo, userPo… 
userAddedList, userAddedLists…
getUsers(), usersQuery(), getUserList()…

# 切不可文不对题,切不可“百转千回”。何意?比如说判断一个人是否是注册会员,变量名被定义成了 notRegisteredUser,大家想想在写各种if条件组合的逻辑判断时会有多酸爽。

01 想清楚再动手

我经常跟团队的人强调慢动手脑先行,可惜能领悟到精髓的人真心不多,其余的通常会以项目进度为由,将“先码起来”列为第一要务,殊不知灾难就是这么悄然来临。

书法看筋骨,代码亦如此。

代码的“筋骨”无非就是分层、结构、逻辑、抽象、封装、模式…曾经大行其道逢人必谈,到现在感觉都没什么人提起了的GoF 23种设计模式,其实就提供了23种“筋骨”范例,大家依葫芦画瓢就行。

代码没有编译成机器码之前,都是给人读的。业界戏称的衡量代码好坏的指标就是“阅读该代码时说脏话的次数”,我们骂的通常就是代码“筋骨”。

要“想清楚”就是想办法练好“筋骨”。TDD测试驱动模型的话,考虑应该怎么设计逻辑控制?DDD领域建模的话,考虑应该怎么建立领域实体?BDD老板驱动的话,考虑迅速翻翻老板以前写过的代码、说过的话、下过的KPI,当然这是玩笑。

曾有多少次,我们怀着一颗要求完美的心,骂着前人写的狗屎一样的旧代码,不得不妥协着项目压力,不断降低着那条曾经的标准,敲出自我放逐的同样狗屎一样的新代码,附上那句可能永远无法兑现的“以后重构”的承诺,最终进入一个不断偿还他人和自己技术债的死循环里…

DàYé啰嗦

经典的《Java编程规范》里开篇总则里的“第一次就做对”,听起来轻飘飘的一句话,背后深意满满。带脑子有思考的编码,想第一次能做对都不是那么容易,别说没动脑的了。这里罗列一些身边实际发生过的错误行为模式,供君一品:

# “初期没多少数据量的,我循环着一条一条Insert没什么问题,等哪天数据量大了,我再考虑批量插入吧!” 请问批量插入很难么?还需要以后?

**# **“这个代码是我从另一个项目里拷贝过来的,他那边运行的一直没有什么问题。” 然后某一天出现了内存泄漏,因为两个项目的流量完全不对等,不求甚解不动脑,搬砖型码农这里体现的淋漓尽致。

**# **“为了测试环境方便联调,易于排障,我每个关键点都打印了Info日志。” 实际上打印的都是无脑的不携带任何参数线索的trans begin/trans end类日志,在分布式日志平台里看到的各种无法上下串联的孤岛日志,我常常边心疼着磁盘存储和索引计算成本,边碎碎念着这些系统真的可以做好线上运维排障么?

**# **“某些逻辑点我hardcode了一些代码,用来触发某些特殊逻辑分支方便测试,等上线的时候这些我都会删掉。” 等真的上线了,这些hardcode被带上去的不在少数。

**# **“系统有兜底的全局异常拦截器,就算有些异常没catch, 最终也会被拦截器包装成标准报文返给前端的,所以有些类似空指针异常我就无视掉了。” 结果就是APP用户不胜其烦的看到各种“系统未知异常”的弹窗。

**# **“Service层就是简单的数据库CRUD,Business层这么多业务逻辑,保证数据一致那就让事务的边界扩大一些,直接把事务管理放到Business层不就完事了。” 结果就是事务里面包裹了各种耗时数据IO、逻辑计算甚至更耗时的RPC调用,导致事务整个被拉长,资源被锁住的时间也加长,最后就是各种阻塞直至雪崩。

02 动手能力

东北大兄弟说:能动手就别BB。

程序员的基本工作除了前面说的动脑,紧接着就是动手了。这里需要做一下澄清:基础的编码仅仅是动手能力的一部分,而真正的动手能力远不仅于此。

身为一个程序员,可以搭建一个完整的网站,可以开发一个桌面效率工具,可以编写一个Excel的VBA脚本,可以根据官方文档部署和定制开源系统,可以根据API实现自动化偷懒…

以上才是我想说的动手能力。

大家都知道人和动物的区别是“使用工具”,而程序员群体是更加需要善用工具、甚至创造工具的一类人。当然不要本末倒置,使用工具不是目的只是手段,是为了提高效率、保证质量、降低成本等的手段。

那么最牛逼的工具是什么唻?

Quora有个回复很带感:“A web browser, with Google as its default opening page.” 一个默认打开首页是Google的浏览器。

隐晦的表达了我们程序员很多时候是面向搜索引擎编程的尴尬…

程序员应该跪谢这位大神,Larry Tesler, 就是他发明了Copy&Paste。

这是如此伟大的一项发明,如此的基础和常用,以至于大家好像都忽视了它的巨大能量。

DàYé啰嗦

# “代码的搬运(Copy&Paste)”绝对不是动手能力,“搜索”却是。因为优秀的程序员必然善用搜索引擎、具备良好的搜索技能。

参见我之前的一篇推文《技术人如何高效搜索

# 承认Copy&Paste是个伟大的发明,但是我还是建议能不用就不用,能手敲就手敲,除非是严重影响工作效率不得不C&P。历史上由复制黏贴引起的BUG还小么?

# 熟练IDE、操作系统、常用软件的一些快捷键。不使用快捷键,就和手机不用手势一样。先不说了,WIN+L锁屏,泡个程序员红茶去。

03 提问的艺术

程序员骨子里的孤傲时常会把自己定位成一个问题终结者,提问题似乎与此格格不入。我到现在都没太想明白这种孤傲源自于哪里,也可能是知识工作者特有的清高。其实吧,大家日不离手的搜索引擎,不就是一种另类的提问么?

卜学良 子曰

亮子的中心思想是个Why,Why的表现是,搞不懂就问人,搞得懂就答人,没有人懂还可以问神…要懂得推理要心存怀疑,要充满好奇要巨细靡遗,要打破砂锅问到底。

Come on everybody!

全套流程建议的第一步是先把自己的问题明确化,并耗费一定的精力去研究琢磨,直到卡滞;第二步是不耻上问/不耻下问, 敢于开口去提问,不要怕丢人,面子相对于知识不值一提;第三步将自己的问题、自己研究的发现等等一并列出,给解答者一个完整的上下文和尽可能多的线索,以节省双方的大量时间;第四步,不管最终是否解决,可以基于解答者给出的方案或者方向,自己在想其他办法去深挖,补齐自己的只是短板。That’s it.

心理专家亚瑟·阿伦有个著名的让陌生人快速熟悉的“36问”,就是好问题的模板,节选几个:

1、如果可以跟世上任何人共进晚餐,你会选择谁?
2、你会想出名吗?以什么样方式出名呢?
3、在打一通电话之前,你会先排演要在电话中说什么吗?为什么?
4、你心中最完美的一天是做哪些事呢?
5、你上一次唱歌给自己听是什么时候?上一次唱给别人听又是何时?
12、如果你明早一觉醒来发现自己获得了某种能力,你希望是什么能力?
30、你上一次在别人面前哭是什么时候?上一次自己哭是什么时候?
36、 说一个个人问题并询问对方的处理意见,让对方向你反馈,你对这个问题所表现出的态度。

DàYé啰嗦

以下的反面教材大家耳熟能详:

# 以他的能力和水平完全可以帮我解答这个问题,为什么他不肯帮我?

帮你是情分,不帮是本分,没有什么理所应当。程序员群体大部分时候是和谐互助的,当然前提是你的问题问到点上、足够清楚、有挑战、礼数到位或者红包打头阵,否则参见下面的细分场景。

# “大神救命啊,我用这个框架老是启动不起来。我可是严格按照手册一步一步来的!” 

然后就没有然后了。你的详细线索呢,你怎么排障的呢,你有初步的怀疑对象么?这种卖惨式发问只会给人一种感觉:你自己压根没分析过!我的时间可不是浪费来解决你分内事情的。

**#**“字符集是UTF8的Mysql5可以存储emoji表情么?”

这种简单的问题要不自己去试,要不去搜,顺便把这块相关的知识点都去阅读一下。你指望某个人给你个答复的同时,还能把整个知识点给你解释一番?

# 劈头盖脸的一堆问题怼出来,没有停顿、没有组织、没有循序渐进。

散弹枪式的发问极容易引起他人的反感,因为你把别人当成了答题人,而不是有来有往的虚心求教。适度且有节奏的发问才是王道。

# 发问前礼貌性的确认对方是否有时间帮忙,发问后不管是否解决都要表示感谢,礼数一定要到位。不要整成一次性买卖,毕竟因为一次不礼貌导致未来可能再难得到帮助,得不偿失。

# 有些人眼花缭乱的问题描述完全不在点子上,解答人若善于引导和抽丝剥茧,能从源头上帮忙解决,若只是纯粹的一问一答,那答案可能压根帮不上忙,因为问题本身的方向就错了。这种体现逻辑洞察能力或者沟通能力,下面会提到,要做到“直抒胸臆”不简单。类似的场景在程序员和产品经理之间也时常发生,聊的牛头不对马嘴,双方都找不到中间的那个契合点,冲突也就难免。

04 逻辑推理

程序员日常编码80%的工作除了想变量的命名,就是在写逻辑分支。而日常非编码80%的工作就是理解需求或设计架构,都需较要强的逻辑思维。

先玩个游戏:估算下中国有多少程序员(不严格定义边界)?

https://octoverse.github.com

基于GitHub的2018年度数据报告,目前一共3100万注册用户,20%美国本土用户,中国是仅次于美国的GitHub大户,打个八折,算出中国注册用户500万(无视不同程度的水分)。

https://www.idc.com/getdoc.jsp?containerId=US44363318

再按照IDC估算的全世界2200万左右软件工程师,按比例折算下中国码农群体 500万/1.4≈350万。

本人宣称对中国码农群体350万这个虚数负责到2019年年底。

参考链接:
世界人口(77亿):https://www.worldometers.info/cn/
中国人数(13亿,就业人数7.7亿):
https://www.ceicdata.com/zh-hans/country/china

以上是个典型的考察逻辑推理能力的小例子。《超级思维》这本书里面有更多奇奇怪怪的逻辑题目,都是让你感觉无从下手的。

其实,在拿到一个即使简单如APP登录的需求时,作为知识工作者的程序员就也需要展现出自身强大的逻辑推演能力,抽丝剥茧,将需求抽象为领域模型或者转化为系统设计。这方面有大量的方法论,比如奥卡姆剃刀,比如WBS,都不重要。重要的是你一定要沉心静气,不能是闷头苍蝇似的一通乱撞。要找到最适合自己、最适用当下的那个方法。是砍掉枝叶先看主干,还是抽丝剥茧层层拆解,都是逻辑推理的一种体现罢了。

DàYé啰嗦

APP登录过程究竟发生了什么,或者应该发生什么,是我面试时经常用来考察一个人逻辑思维能力的题目。除了是人都知道的用户名密码校验还有什么呢?

# 用户名的长度区间是什么?

# 用户名支持的字符集是什么?存储会乱码么?

# 密码的长度区间是什么?字符组合是什么?

# 密码的加密方式是什么?如何确保传输通道不会被中间人劫持?

# 用户名/密码是否含有非法字符(代码注入)、政治敏感、低俗不雅的文字?

# 密码最多可以输错多少次?超过后账户禁用多久?

# 是否支持用户多终端登陆?如果支持的话,账户在A终端被禁用后,在B终端的已登入态是否被踢出?

# 用户在终端的登录有效时长如何考虑的?

# 登录的错误提示有很多种,用户名不存在、密码错误、账户禁用,还有哪些?

还有很多没展开,如手机号/邮箱绑定,短信/邮件验证码验证,常用设备管理等等,可以继续推演下去,但是如果能在面试的压力环境下,有条不紊的罗列出用户名、密码、安全、状态、话术、用户体验面等等这些维度上的思考,那基本上没毛病。真实情况是不少人在这些维度上跳来跳去,没有条理性、延续性,想到哪儿是哪儿,只能说明逻辑推理上有所欠缺。

05 时间规划, 要事优先

我们身边不乏这种人:每日忙忙活活,勤勤恳恳,乐于助人,看起来是公司里最敬业爱岗的那个。实情却是大量任务一旦堆积到他手里就失去了进度,甚至因为同时赶很多任务,导致高优先级任务的质量不达标。这类人的典型问题就是做不好时间规划,分不清轻重缓急。

爱因斯坦老头的相对论告诉我们,时间是相对的。同样的每天8小时,有序、有效和高效的使用了这8小时的产出,可以比无序、无效和低效的产出高出2倍不止。核心点是什么呢?

DàYé啰嗦

# 让时间的无效流逝产生罪恶感

理解前先举个栗子。小时候暑假的前半段基本都是瞎玩,最后一周疯狂的写作业,连吃饭都觉得在浪费时间,如果吃饭的时候还在看电视,那时的罪恶感爆棚,时刻觉得我的作业还在等着我…所以明白了么,产生罪恶感的前提是我的任务是有优先级的,加上自己的责任感,一旦高优先级任务阻滞了,而我还在浪费时间在某个无意义的事务上,就会及时叫醒自己,阻止自己的继续浪费。

# 好记性不如烂笔头

曾几何时公司里的笔记本还是用来记事的,现在好像成了用来涂鸦的了。一般开会我都会要求大家都带笔记本,无他,我就是不信你的脑子记得住会议上的所有要点或者决议;而日常项目中有些重要的事项或者节点也都应该记录下来,项目上线前翻一翻确认自己没有遗漏;等等。当然上面说的这些你可能有其他的工具来实现,殊途同归罢了。

# 请学会拒绝

烂好人这种事情在职场基本是行不通的。因为你好,你的事情就会多而杂;因为你好,你的事情就都是高优先级;因为你好,流程规范就容易违反;因为你好,时间一长就成了理所当然,这事将永远粘着你;因为你好,任务积压到你手里,任务最终延期交付,你得背锅;因为你好,你就再也拒绝不了别人了,因为“雷锋”是不会也不该拒绝他人,会一直被道德绑架在十字架上。

06 心向自由, 遵纪守法

人是生而自由的,却无往不在枷锁之中。

– 卢梭 《社会契约论》

人生而自由,清高的程序员更加的心向自由。不喜欢西装革履,不喜欢一板一眼,不喜欢上班打卡,不喜欢规章制度…

每家公司都制定了各种各样的制度、规范、流程,这些东西经常被视为洪水猛兽,枷锁镣铐。只有不成熟的人才会把自由放在嘴边,成熟的人怎么会不知道

自由是要付出代价的!

  • 上班时间是自由弹性的,结果可能是开敏捷站会的时候少一个人更新进度,因为你没来,这个代价谁来支付?

  • 生产上线可以随意发挥,上挂了再上一次呗。如果一个面向C端用户的产品,你确定要让用户承担无法使用、公司承担损失用户的代价么?

  • 数据权限是自由的,这样查数据方便多了,谁来承担数据被导出打包卖的代价?

  • 开发私接需求,不走那套评审、设计和进入迭代的繁琐流程,测试不知道这块的回归内容,上线后出问题才发现,这个代价谁承担?

选择了自由,必须承担代价,也同时选择了责任。没有责任的自由只是小孩子过家家。所以在感觉自已被约束了之前,先扪心自问,自己是否有能力消解跳出框架的风险,是否有担当承担自由之后的代价。

07 羞耻心

有羞耻心的程序员才有资格清高,因为羞耻心是你的底气。一个成天写一堆低级bug毫无羞耻的程序员凭什么清高?自己首先会耻于不完美,做到无可挑剔,当然可以清高。

剖开羞耻的表层,本质其实是程序员对于自身的高要求。程序员对自己没有要求,和咸鱼有什么分别。这里还没要求程序员主动去提升自己这个层面,就是靠错误的羞耻感驱动自己提升这一层,很多人做的都不够好。出现BUG无所谓,上线失败问题不大,这是自我放逐到了如何野蛮的地步了?

DàYé啰嗦

现在的互联网应用相对企业应用,可以更快更轻更容错,给年轻人一种错觉好像出点错没什么大不了的,也导致现在的年轻程序员对于BUG, 对于生产环境没有太多的敬畏心

而从做企业应用那个年代出来的程序员,对于这些都是谨小慎微,一点点小错都了不得,感觉要死了,这或多或少与不同时代的程序员文化有关。

# 只要是BUG就是丢人的,不是拿来自黑和一笑而过的。

# 代码被评审出一堆意见来是丢人的,重复犯错更丢人。

# 系统上线漏了个配置是丢人的,就算你前面的开发测试再完美,最后临门一脚没做好,前功尽弃不羞耻?

# 系统上线后的问题都是客户报障的,自己的监控不到位,告警处理不到位,永远是落后客户一步,自己的系统自己HOLD不住,羞耻么?

# DaYe自己对于有些异常如NPE、越界、类型转换,一旦抛出来会觉得特别羞耻,会捶胸顿足为何写这部分代码的时候没有考虑清楚。你会么?

08 同理心

同理心Empathy,简单来说就是换位思考,懂得倾听,设身处地的共情共感。也是情商EQ理论里的专有名词。我觉得程序员在同理心方面做的奇差,也是程序员画像“智商高情商低”的口实之一。

程序员思维特别擅长把任何交流转换成技术语言来表述,程序员说的口沫横飞,其他人一脸懵逼。不会说“人”话这一点,一直是程序员的硬伤,缘由大概是大部分时间跟电脑打交道,导致的达尔文式退化吧。

程序员会说“人”话,境界必然升华。因为你若能把程序思维包装成一种非技术人也能听懂的语言,说明你已经脱离了程序员固有的思维框架,可以对等的用对方的语言来直接交流。就像我们在英语对话中,过程是对方的英语通过耳朵进入脑中,先转换成中文,然后想好中文的回答,再翻译成英文,最后用嘴说出来。都知道这是不对的,但碍于英文水平渣渣,臣妾确实办不到屏蔽中文切换环节,直接英文输入输出这种最优秀的交流方式。

当程序员开始用技术来碾压或者嘲笑对方的无知,这时候的交流一定会出现争执和冲突。要求我们立马停顿且站在对方的立场想事情,确实有点强人所难,但是我们可以从一个第三方不相干的人的立场来看这次交流,尽量保证客观,可能会发现另一种思路。

特别程序员在面对BUG和线上故障时的第一反应,通常也不是站在对方立场,而是下意识的抗拒。前线一线商务人员密切关心故障进度,一定会时不时的催促,而程序员思维这时经常会丢出来的一句话是“在处理呢,别催”,如果站在对方的角度来表述“我们已经找到问题的症结了,还需要大约一刻钟的时间,走个紧急审批流程,已在着手修复了,请再耐心等待一下”,将我们的努力过程表达出来,再给一个可期的未来时点,会好一些么?

09 近距离榜样的力量

有人说“我的偶像是Linus Benedict Torvalds”,这个事情对你当前的职场可能并无太多益处。因为Linus人家底子硬,可以怼天怼地怼上帝,而大部分愚钝的我们还差得远…

所以我标题里的重点是“近距离”和“榜样”。也就是在你当前职场环境下,离你最近的最容易效仿和咨询的那个榜样型人才,才是你需要当下尽全力追逐的。

比如自己的代码在最近几次评审里老是被提出很多评审意见,傻的程序员没感觉怎么样,每次提多少改多少,下次可能还犯;聪明的程序员会每次做好总结,保证下次不会再犯;而智慧的程序员,会直接找评审人聊聊他心目中的好代码的标准,找公司的代码规范checklist,翻阅有优秀编程能力同事的代码,反复的学习和实践,主动推动自己往下一个Level演进。

不管是技术、业务、产品还是管理,除非你一骑绝尘,公司范围内在你视野里已经Nobody了,否则每个维度都会有自己可以对标的对象,务必虚心求教,刻苦训练。

我不知道程序员是不是很容易看不上公司内部的一些分享课程,经常因故缺席。然而在收集想听什么课程的时候,又说分享少,最好请外面的一些大神来讲讲课啥的。我一直断言,有这种想法的程序员就不是为了知识,而只是为了有个接触所谓大神的机会,甚至最后能加个好友就有吹嘘资本了。且不说有些所谓的大神很水,就是真正的大神讲的那些干货,你先确定自己能接得住么?根基不稳、眼高手低,所以别怪DaYe啰嗦,先找近前看得见摸得着的对象,试试超过他看看?

10.24 拥抱开源

现而今很多国际顶级的开源技术都是国人搞出来的,不仅让世界看到了国人的技术能力,也让国内的信息化水平有了质的飞越。

开源这个大宝藏用不好,就是可耻的浪费。我经常提醒团队在造轮子之前可以先去开源社区,找找灵感找找思路,千万别一头扎进去,写出来一个残次品没人愿意用。

反过来,开源对于程序员还是比较神圣的一种认可,所以我也会推动团队做一些开源方向的努力。当团队在开发一个内部系统,被安上一个开源的KPI之后,大家的专注力和自我要求都会加强N个档位,毕竟谁也不想开源一个让人嗤之以鼻的软件,执行力、羞耻心和荣誉感会无限爆棚。

以上,是我心目中程序员安身立命的几条黄金法则。有人可能会说,扯了那么多,竟没提程序员的基本功,其实基本功就藏在这10.24条里了,自己去发现吧。

THE END

DàYé首席路 | 模仿之道

笔者曲健,1024生人,天选程序员,浆糊人送外号“大爷Dà Yé”,目前在奥琪科技担任首席架构师一职。

二零一八留不住,朱颜辞镜花辞树。

鄙人平素喜偶厌奇,以致现在对2019仍避之不及、兴致索然,更羞愧的是原本想对2018之前人生做的总结也憋到现在…

人这一生,有人从上半场甚至一开场已策马扬鞭绝尘而去,而有人混沌半生却依然摸索不到那道门。不才无甚特长唯虚活三十余载,终究有些人生阅历(通俗点叫失败经验)可与君分享一二。今儿咱们就说道说道“模仿”这件事。

# 谨”守”模仿天性

模仿是人类默认出厂设定能力之一,生而为人,始于“模仿”。父母的语言语态、行为举止都会成为孩子的模仿对象。孩童会因模仿到大人的一招半式而洋洋自得,成人却因“行与他人雷同之事”顿感不自在甚至羞耻,根源上还是把模仿对标成了另一个概念:

山寨!

山寨更多的是一种抄袭甚至剽窃,与作为有效学习手段的模仿不可同日而语。

这段充满刚正之气的名言论述是讲课用的。实情却是,模仿的第一步往往就靠无脑复制,严重点说就是抄袭。

如同没人会说孩童“山寨”成人,毕竟如此就有降维打击的嫌疑。在成人的世界里,很少有人会承认自己在低维空间,本就同维,我模仿你岂不掉价?更可悲的是一旦开始模仿,就很难不被人扣上山寨的帽子。

日货曾几何时是“质量过硬”产品的代名词,殊不知日本就是抄袭鼻祖。始自隋唐时代,日本已经开始大面积抄袭中国文化,一如茶道、剑道、花道等日本八道都是汲取中国文化后形成的自己特有的道,这些大家基本都知道的且抛开不谈。就说近代,二战后的日本经济萧条,百废待兴,为了重振经济,山寨成了日本选择的一条捷径。巧克力、漫画、家电、相机以及汽车等等,日本全部山寨过。而日货有如今的地位,与其后续一系列的改革创新、科技教育等手段是分不开的。

有兴趣可以搜索一下日本CopyCat视频,看完你会发现国内的那些极品山寨康帅博、大个核桃、农民山泉、粤利粤…大家山寨水平都不过尔尔。

而德国曾经也好不到哪去。1887年,德国制造”Made in Germany”耻辱性的进入了英国的商标法条款,被英国人用来区分“英国制造”的优品和”德国制造”的劣品。那时候的德国也是各种仿制和山寨,不过也仅仅过去十几年,德国人就把”德国制造”这顶代表耻辱的帽子摇身变成了金字招牌的代名词至今。您看,随便掀个底儿,抄袭黑历史俯拾皆是,谁也就别笑话谁了。

DàYé自述:

职业生涯冷启动菜鸟期通常会伴随着各种不期而遇的迷茫。当你这也不会那也不会,这也想学那也想学的时候,迷茫、无助或者焦虑就随之而来。还好黑夜给了我黑色的眼睛,我踏踏实实的用来找寻光明。

最开始使用VB6、PRO*C 编码的我,鬼使神差的选择了JAVA高手、TOP ? 程序员作为模仿对象(当时的我执着地确信Web应用才是未来趋势,也真是眼光毒辣),列举如下,不一而足:

特别说明:下述文字只是对本人当时的模仿行为进行陈述,并不代表它们是正确的,请自行甄别。

$ 编程风格:学习并效仿高手的代码风格。我的代码洁癖就是这段时间养成的,见不得格式乱、忍不了没灵魂。没有注释没有异常处理没有日志没有”断句”一口气写几百上千行的代码,注定是没有灵魂的流水账; 

$ 工欲善其事必先利其器:NetBeans/ JBuilder/ Eclipse/ MyEclipse之间的各种IDE鄙视(那时候还没有Intellij IDEA啥事),高手用什么自己就用什么,无须纠结高手纠结过的; 

$ 理论知识:购买并阅读高手推崇的一切好书,虽然很多没啃完,但是读书绝对可以加速知识体系的构建进程。现在很多IT培训机构流水线上组装的“速成”产品,就特别容易出现知识残缺、根基不稳,陷入盲目/机械/重复劳动的泥潭,却以为这就是常态的码农形态; 

$ 热点趋势:RSS(上古神器之一)订阅高手推荐的各类源站:技术热点/大神博客/业界资讯…学习成长路绝对不能闷头行进,必须学会抬头看路认清大势;

$ 动手能力:身为程序员不会搭建网站,不会做GUI小应用,不会 Excel 公式,不会搜索,不会 番羽 土啬 … 比小姐姐让你拆机箱擦个灰都不会还要恶劣。 现在很多程序员应该没见识过以前的企业应用本地环境的搭建、启动、部署和测试,那叫一个繁琐(现在对IBM WebSphere的那套产品仍旧心有余悸),曾经有些人从入职到离职都不知道这一套环境怎么运作的,安心做一名”流水线工人”。

$ 程序员的高傲:提交的代码被任何人读起来都应该是优雅的;交付给测试的功能点一定是自己反复验证过的,出现低级BUG丢不起那人;敬畏生产环境,上线脚本/配置/变量/步骤/困难全都罗列的一清二楚,上线失败如同过掉门将面对空门将球打飞,可笑又可耻。

$ 装逼套路:能用命令行绝不用图形界面,能用快捷键绝不用鼠标,IDE必须黑色主题,桌面墙纸必须个性,案头必备一本英文原版书(就算垫显示器),必须**盲敲数字键**(别笑,我不认为现在程序员有多少可以做得到或者做得6)

Google -> Creative Desktop Wallpapers

题图:浏览器选项里没有IE, So Chrome Or FireFox?

总之,在编程起步的这段模仿路上,从例行工作到三余读书,从照搬仿效到习惯养成,从实际行为(形)到思想境界(神),其实你会发现这模仿本身也是个成长的过程,只是这路不是你自己摸索的而是踩着前人的脚印。您再看,这个过程缘何我模仿的自得其乐?因为我把自己视作孩童,放低身段,**自降一维,**只求成长。

好的模仿必须找到对的对象

通常大部分人选择的模仿对象通常无非是自己的偶像、长辈、老师或者业界权威、KOL等等。有些模仿并不一定具有特别明确的目的性,就像有多少人因为乔丹篮球之神,23成为了自己的幸运号码。除此之外的大部分模仿一定带有某些目的性,所以一旦选错模仿对象,为此承担的成本可能会无比巨大。靠谱的“选择模仿对象”的过程应该是这样的:模仿者有能力对自身的基础优劣指标有基本的认知,知晓被模仿者的哪些特质、行为或能力是无害的、有益的、榜样的和相当一段时间内自己想要努力追逐的,双方综合评估后可得Yes Or No。

榜样 VS 偶像
就模仿而言,我希望是榜样的力量,而不是偶像的力量,这两者有本质区别。榜样是你还没达到但是想成为的人(或人的某种特质),偶像是你想接近但是不想成为的人。马云说过类似的话,”我没有偶像只有榜样”。大家可以品一品其中意味。

爱因斯坦有个经典的“司机”的故事,说爱因斯坦的司机长期陪着他各地演讲,听多了也就倒背如流了,就像灵山上听佛祖讲道瞬间成精的妖怪似的,自告奋勇申请代爱因斯坦去讲一堂课,结果这哥们确实滔滔不绝、有模有样的演讲完全程。最后不巧有个听众问了一个深入的相对论问题,这司机当然答不出来,却还算机敏地一指坐在后排的爱因斯坦说“这个问题很简单,我的司机就可以回答”。这个例子就是典型的对自身、对模仿对象都评估不足,对大部分的我们来说,爱因斯坦都绝对算不上一个对的模仿对象,因为我们穷究几辈子可能也踩不上他老人家几十年前走过的路…

模仿是个刻意练习的过程

刻意练习、一万小时定律我们都耳熟能详。写代码的手感和语感有时就是冥冥之中方可得,没有大量的实战,寄希望于看个视频读个文章就掌握,这种虚妄犹如似近实远的高山,看似咫尺实则天涯。

你还记得第一个 Hello World 带来的那种芥末味直冲脑门的欣喜么?然而写一万个小时的Hello World并不会让你有什么进步,刻意练习不是刻意重复,你必须从大量枯燥无趣的“有效”练习中寻求成长,其中的寂寞可以击退众多求进之人。

总结一下,住模仿这个人类本能,无须刻意割裂,在没有找到属于自己的路之前,模仿绝对是条不错的捷径。而标题中的**”谨”**字就是表达谨慎选择模仿对象之意,选对了就是成功捷径,选错了可能就是不归路。进入赛道就必须让自己跑起来并持续坚持。

# “破”除复制牢笼

如果把上阶段的“守”比喻成机械复制、没有自我的“无我”蛮荒过程,那么“破”就是要找到“自我”的文明养成过程:养成技巧、养成思考、养成创新以及养成习惯等。除此之外,这个阶段也要找出三个经典人生哲学的答案:

  • 我是谁? – 自我认知

  • 我在哪儿? – 自我定位

  • 我要去哪儿? – 目标规划

自我认知Self Awareness

自我认知指的是对自己的洞察和理解,包括自我观察和自我评价。好的自我认知,能清楚勾画出自己的性格、优点、弱点、潜能、思想、情绪和动机;做不到就容易成为别人口中的没有自知之明之人,而有些人终其一生确也无法认清自己。

自我认知会随着个人的阅历、思想、环境等不断变化,所以不是要求大家即可就看懂自己(当然也不可能),而是要掌握这项技能,让自己不断从中受益,所谓吾日三省吾身即是此意。自我认知严重影响着个人的成长、处事方式、情绪管理,比如: 看不到自己的优点就容易自卑,进而做事畏手畏脚;高估自己就容易傲慢,无法听取别人的意见而独断专行;内向型更适合主攻技术性事务,外向型更适合业务性事务,如此等等。

业界有不少可以对个人进行性格测试的方法论,也是一种自我认知的途径(不过更多的场景是Leader对团队,企业对员工的测试)。比如MBTI职业性格测试,9型/16型人格测试,DISC性格测试,NASA 4D人格测试

自我定位Self Positioning 

自我定位相对于自我认知来说,多了一个锚定物。此锚可以是自身或者他人的技能、薪资、岗位、职级、性格甚至背景,以此来分析定位自己所处的位置,是初级能力还是高级能力,是业务开发还是架构开发,是不善言辞还是能说会道…

自我定位和自我认知可视作基本相似的评估行为,只是认知是相对抽象的评估,而定位需要给出相对具体的位置线。

目标规划Goal Planning

在没有认清自我的前提下设定的任何目标都是无源之水无本之木,那么目标一定是因人而异的。那么问题来了,现而今知识共享、知识付费的时代,知识可以是听来的、看来的,大家表面看起来都很上进,购买各种课程学习,目标都是成为懂业务、懂技术、懂产品、懂管理、懂投资的共产主义社会全方位发展的全能型人才,只是,这种快餐路径拿来的知识真的被你吸收了么?你应该持一下怀疑态度…另外,这种“形而上学”得到的知识我把它定义为“口腹知识”,就是只能用在聊天打屁时口若悬河滔滔不绝,落地实施时除了懵逼还是懵逼。区别于经过咀嚼消化后被充分吸收的“心脑知识”。

回归本文主题,要在模仿学习中找寻自我,必须思考、挑战、辨别、领悟,直到知识技能融入己身,为我所用。

DàYé自述:

当意识到初期的机械式模仿最多也就是把自己变成别人影子的那一刻,我开始思考如何逃离机械式模仿带来的快感舒适区。因为盲目效仿实在不需要付出额外的心力,只须跟紧步伐,不费吹灰之力就可以逼近甚至赶超模仿对象,多可怕的错觉。

为了跳出行为和思维的双盲区,我是如此行之:

$ 个人标签:所有的模仿行为通过思考改进,形成个人风格,打上个人标签。简单如大家都写的注释,我一定是把时间、作者和备注说明用特殊符号拼接的行列分明、整整齐齐、强迫症般的赏心悦目,并没有为此多耗费什么时间却得到了不同的代码阅读体验和个人风格;同样是用IDE, 记住绝大部分的快捷键,引入更高效的插件,能高效辅助你达成目的的手段才能称其为工具,否则只能算作器具

  $ 知其然知其所以然:获得一项技能其实没什么了不起,闻道有先后罢了。技能是否真正掌握的评判标准很简单:可以把这项技能轻松传授给别人。别以为这个标准很简单。可以举重若轻把知识讲出来的人,绝对是吃透了背后原理机制的;反之当一个人讲的东西不够深刻浮于表面甚至闪烁其词,那他一定自己都是半吊子。

1
2
3
//等式判断时,先写常量,再写变量的写法很常见。
//到底有何好处呢?还是zhuangbility而已?
if ( 100 == score ) {

     return “一等奖学金”;
}

$ 思想边界:或理解为视野局限,一个人是无法想象甚至理解思想边界之外的世界的,这与努力程度无关。当日常工作的80%都是常态脑消耗(重复劳动),不需要启动全部脑力来思索创新,释放的信号就是你的思想边界将要停止延伸。所谓眼界决定一个人生的高度,而我的高度就是从脱离国企陈旧的体系和氛围,拥抱外企的自由开放文化开始的。

以防有人断章取义,需要解释下。我可没有表达外企就一定比国企高。不管国企到外企,还是外企到国企,都是边界的延伸。实际上,我那个年代,软件业的外企确实比国企整体上要正规和先进不少…

当时的外企对我来说就是最大的变化和可操作的最远边界,语言、文化、管理、种族、趋势、认证、体系等等对我来说都是新鲜的也是极具挑战的。面试外企前一年我是一直跟一位美国退休教师老大爷学口语的,入职第一个月仍旧是听的磕巴说的哑巴。幸好我的任务都有书面化的工作清单(请不要怀疑我的英语书面考试能力…考试,我是优秀的),第一个月我完全没怎么说话交流,就纯闷头写代码交任务,因为质量好效率高得了当月的部门优秀…我特么第一次知道纯粹的代码能力也可以被如此重视,擅长什么就尽力安排你做什么,发挥出你最大的价值,那感觉太美妙了。

接下来我从外企回归到体制内就是另一个故事了。大比例的企业应用相比互联网应用,有太多的死板和陈旧,初衷是BAT一类的互联网公司,后来因缘际会得朋友推荐,加入了招行的掌上生活团队,对互联网的技术、业务和产品的玩法才真正有了完整的认识。

你看,我的从国企到外企再到国企,从企业应用到互联网应用,从程序员到架构师,我在不断拓展自己思想和视野的外延。促使我跳出框框的一个重要因素开始是薪水,后来发现是成长性和反脆弱性让我不断的做出转变。

$ 反脆弱性:有一本叫做《反脆弱》(也是黑天鹅一书的作者)的书推荐给大家,里面的观点很是值得玩味。比如公务员相比出租车司机就是脆弱的,考虑公务员40岁失业,和司机40岁面对再就业时截然不同的处境。脆弱的反面不是坚韧,而是反脆弱。一个鸡蛋掉到地上,会碎,鸡蛋在这里是脆弱的;一个纸团掉到地上,不会破,纸团在这里只是坚韧的;一个乒乓球掉到地上,不仅不会碎还可以反弹起来,这个乒乓球就是有反脆弱性。让变化和波动成为促生蜕变的动因,附上此书的一段简介:

《反脆弱》
杀不死我的,使我更强大。
既然黑天鹅事件无法避免,
那就想办法从中获取最大利益。
每一件事情都会从波动得到利益或承受损失。
脆弱是指因为波动和不确定而承受损失。
反脆弱则是让自己避免这些损失,甚至因此获利。

  $ 不耻下问:所谓闻道有先后,在一个新的领域实行模仿学习的时候,模仿对象很可能比你小。这种时候一定要放下心里包袱,不能自卑轻易否定自己,更不能自大不屑于模仿求学。刚入掌上生活团队时,对于互联网应用的技术、组件、开源等了解并不全面,而同期入职的比我小的同事,却玩的贼溜,甚至在意识形态上我都感觉落后一个时代。此人江湖号称万真人,因为当时真有点高山仰止之感,让我想到了武学宗师张三丰,我给起的这个绰号深得大家认同也就很快传开了。最终幸好本人的反脆弱性还算强大,持续恶补、持续模仿学习,不然真差点整自闭了。

总结一下,我“思”故我在,第二阶段就是破开框框,找到那个“真我”。

# “离”开一招一式

上图是张三丰教张无忌太极拳招式后的一句话:
你忘记所有招式,就可以练成太极拳了。”

术和道的纷争软文已然烂大街,简单来说,术谓之技术,道即为道理。我们在长期的学习过程中,获得了大量“术”级别的能力,悟出的“道”却屈指可数。若我们花费大量的时间在技术的纯熟上,而没有沉淀下来领悟内在的运作机制和底层原理,这样是基本没可能练成太极拳的。

从无我到自我,进化成最终的忘我。忘我是一种态度,忘掉给自己带来虚妄成就感的“术”,进入悟“道”的超然境界。雄鹰经受击喙换羽之痛获得重生,即便它早以遨游九天为乐;王阳明格竹龙场悟道创立心学,直逼万物本源,即使之前他早已文武双全;诚然我们无法与圣人相提并论,但仿效其成圣之路,总有可达之处。

DàYé自述:

本人目前也在各种悟的过程中,混混沌沌间也无法给出具体的指导意见。要升级为高级别人才,勇于放下“固有成就”的包袱,补齐各维短板,潜心修习方可。说起来简单,悟起来真的不容易。

  $ 以结果为导向: 这是很多管理者挂在嘴边的一句话,但是执行者却甚少有理解到精髓的。

譬如

代码异常处都知道要打印日志,除了基本的堆栈信息,业务线索数据也应该打印出来。评审的代码中大家是否经常可见下面示例的第一种写法。道理很简单,结果导向,你打印日志到底为了什么,是为了你单机调试用,还是为了多节点生产排障用?

1
2
3
logger.error("user login failed", e);
vs
logger.error("user " + userid + " login failed", e);

异步消息组件处理消费失败时,一般都有重试机制,对于重试理解的透彻程度可以部分反映你“结果导向”这个道的高度。不展开讲解就列几个问题大家自己去思索:

  • 该消息的消费处理逻辑是幂等的么?这决定是否可以重试

  • 该消息消费失败后,是否有必要重试?有些消息体若必要参数缺失,你重试一万次也不可能成功

  • 该消息消费最终失败,导致的数据不一致怎么处理?有人说在最终失败时再想办法把这个消息持久化存储在某个地方就可以了。

  • 结果导向的问题来了:持久化存储的数据,你会多久去看一次?有主动修复的机制么?如何保证时效性?

  $ 设计模式:设计模式是程序员必修的功课,从背诵到实践到领悟到灵活运行到大道至简。我曾经看到过一个不复杂的微服务系统,被设计的七零八落,这一个helper那一个resolver, 左一个decorator右一个visitor中一个factory, 第一眼看到这个系统就有想躲开的冲动。设计者觉得我能把这么多设计模式融合到一起,是多么了不起的一件事情。殊不知,设计模式就是一种方法论,在你抓耳挠腮不知道怎么组合代码的时候,给你一种思路罢了,你却用来装逼。设计模式绝对不是让你堆砌设计,更不是让你增加系统理解和维护的复杂度。我所崇尚设计的第一原则是简单易懂,能把复杂的事情简单化才叫本事,把简单的事情复杂化就是熊孩子。你想,那些伟人对世界领悟的得多么的透彻,才能将复杂的自然规律抽象为如此简单美妙的一个公式?

image

  $ 管理和领导:从字面区分就很清楚,“管理”首先是个戴着竹帽子的“官”,“理”顺事情才能推动团队达成目标;“领导”则更多的是带领和指导团队,通过个人专业能力、人格魅力或者影响力来达成,不一定是权力。所以把自己定位好是管理者还是领导者,使用的方法论也不尽相同。我对自己的定位可能更多的是领导者,因为如果摒弃头衔给团队带来的权势压力,我仍能带领好团队,这才是我想要的团队氛围和协作模式。目前这块仍在悟,等沉淀到一定程度了再跟大家掰扯掰扯。

守破离

“守破离”源于禅学,兴于日本剑道,后被引入各类学科和理论工作中。模仿之道不好架空表述,遂以守破离为引直抒胸臆。本人也是从一名普通程序员一步一步的成长为管理者,其中辛酸同行之人应深有戚戚,而模仿不失为一把神锋利器,只是此招需要慎用,万不可走偏。

盼与君共成长

image