如果按照以往的惯例,我会在标题前面加个词简单描述一下。但在写这篇文章时,我想了很久,都没想出什么词可以满足“简单的描述一下”。所以就不写了。
还是从工作先谈起,因为工作在我看来挺重要的。
今年年中的时候去了另一条产品线,做流处理的。想去的原因是因为好奇心害死猫——总是听到他们在聊一些感觉很酷很好玩的东西,有时还听的一脸懵逼,产生了许多疑惑。
去了以后,部分问题在实战和日常的学习中找到了答案。但有些答案引起了我更多的疑问,直到触碰到了我盲区,驱使我开始新一轮的学习。这就是下半年我技术博客更新频率降低的原因——我在花时间输入,而不是输出。
我在新的产品线中完成业务的同时也把一些自动化设施引入了进去。自动化测试work了,但覆盖率不高,因为需求方希望我们能快点出个“样品”,基本能用就行。
在明确确定这种“尽快出,基本能用就行”的情况下。自然而然只能加快步伐跟上——毕竟我们得先有(钱),再变得更好(的质量)。 但这笔欠下的技术债务,开发们迟早是要还的,而且越早还越好。
如果技术债务能够还上,这种情况还是可以接受的。让人感到心累的更多是一些“长期斗争”——需求方日常觉得这个很简单两三天就写出来了,而业务方思考的不仅仅是让这个功能work起来。显然,这里是有矛盾的。在这里,可以展开来说。
对于每个软件系统,我们都可以通过行为和架构两个维度来体现它的实际价值 。
行为价值是最直观的价值纬度——开发的工作就是让机器按照某种指定方式运转,给系统的使用者创造或者提高利润 。 开发们为了达到这个目的,往往需要帮助系统使用者编写一个对系统功能的定义,也就是需求文档 。 然后,开发们再把需求文档转化为实际的代码 。
当然,当机器出现异常行为时,程序员要负责调试,解决这些问题 。
大多数开发就是这么想的——他们仅仅看到了软件这一层面的价值。显然这是有问题的。
软件系统的第二个价值维度,就体现在软件这个英文单词上 : software
。 的意思是“产品”,而 soft
的意思,不言而喻,是指软件的灵活性。
软件系统必须保持灵活 。软件发明的目的,就是让我们可以以一种灵活的方式 来改变机器的工作行为 。对机器上那些很难改变的工作行为,我们通常称之为硬件( hardware )。
为了达到软件的本来目的,软件系统必须够 “软”一一也就是说,软件应该容易被修改。当需求方改变需求的时候,随之所需的软件变更必须可以简单而方便地实现 。 变更实施的难度应该和 变更的范畴 ( scope )成等比关系,而与变更的 具体形状 ( shape )无关 。
需求变更的范畴与形状,是决定对应软件变更实施成本高低的关键 。 这就是为 什么有的代码变更的成本与其实现的功能改变不成比例 。 这也是为什么很多公司第二年的研发成本比第一年的高很多,第三年又比第二年更高 。
从系统相关方 ( Stakeholder )的角度来看,他们所提出的一系列的变更 需求的
范畴都是类似的,因此成本也应该是固定的 。 但是从研发者角度来看,系统用户持 续不断的变更需求就像是要求他们不停地用 一堆不同形状的拼图块,拼成一个新的形状。整个拼图的过程越来越困难 ,因为现有系统的形状永远和需求的形状不一致 。
我们在这里使用了“形状”这个词,这可能不是该词的标准用法,但是其寓 意应该很明确 。 毕竟,软件工程师们经常会觉得自己的工作就是把方螺丝拧到圆螺丝孔里面 。
问题的实际根源当然就是系统的架构设计。如果系统的架构设计偏向某种特定的 “形状” ,那么新的变更就会越来越难以实施 。 所以,好的系统架构设计应该尽可能做到与“形状”无关 。
那么,究竟是系统行为更重要,还是系统架构的灵活性更重要?哪个价值更大?系统正常工作更重要,还是系统易于修改更重要?
如果这个问题由业务部门来回答,他们通常认为系统正常工作很重要 。开发们常常也就跟随采取了这种态度。但是这种态度是错误的 。下面我就用简单的 逻辑推导来证明这个态度的错误性。
当然,上面的逻辑论断可能不足以说服大家,毕竟理论上没有什么程序是不能修改的。但是,现实中有一些系统确实无法更改,因为其变更实施的成本会远远超过变更带来的价值 。 你在实际工作中一定遇到过很多这样的例子 。
如果你问业务部门,是否想要能够变更需求,他们的回答一般是肯定的,而且他们会增加一句:完成现在的功能比实现未来的灵活度更重要。但讽刺的是,如果事后业务部门提出了一项需求,而你的预估工作量大大超出他们的预期,这帮家伙通常会对你放任系统混论到无法变更的状态而勃然大怒。
另外一点是我在今年招人时变得更佳严苛了。我认为,一个好的程序员能不能顶上两个普通程序员不好说。但是一个差的程序员一定会搭上两个好的程序员的精力。背后的心酸事迹就不说了。如果代码规模再上去,这个比例还会被放大。不过今年还是从V2上招到一个聪慧皮实的小伙子,真是太好了!
关于技术上细枝末节的就不多说了。就说一点吧,今年我成功的把Kotlin引入了产品线,能让产品线的开发们更愉快的写代码,毕竟Java还是偏verbose的。同时我也感受到了函数式编程的精妙之处,并对编译器产生了兴趣。最近还在用Go写一些小玩意儿,不得不说学过Kotlin以后切过去还是挺舒服的。
今年学的东西还挺聚焦的,就两块——钱和专业技能。
“钱”这个字说的很俗,不过很实在,因为我就是为钱才去学的。不过无论从学的过程还是结果来看,既满足了我目的,也满足了我的一些好奇心。总的来说,挺好的。
“钱”一个字,也说的很泛。实际上,我看的是一些宏观经济和理财相关的东西。并结合实际情况,运用到了自己的理财中。今年基金定投部分的理财收益率为6.9%,所有资产的理财收益为6%个点。
但今年以来沪深涨了37.95%,简直是天差地别。这有三个原因:
关于第三点。避免这种问题以后再发生的方法就是多买几只鸡分散风险了(分散基金经理脑抽的风险)。有人可能会说指数型基金才是最好的balabala。但事实并非如此,我国的股市并不成熟,散户较多(较米国)。就目前来看,主动型基金是能跑赢指数型基金的。
在11月的时候,我趁着结账行情买入了一些股票。与此同时,我开始研究如何了解一家公司。大致通俗的讲几个点:
这样就能挑选出一个好公司了吗?或许吧。但是好公司也有三种好公司,即:
这看起来似乎是个不可能三角。不过这得取决于我们屁股坐在哪里——如果我们是股民,我们当然要找对投资人好的(比如多分红,多回购);如果我们是员工,那么就得找对员工好的公司(比如钱多,给你平台成长)。
了解这些,对我职业生涯的规划是有一定帮助的。
专业技能,今年的趋势是逐渐往下沉淀——当然应用层的知识得满足现状。往下沉淀一部分是兴趣使然,一部分也是业务中有用到相关的知识。这样自然是好的,有动力,有反馈。
今年看的书不算多,就10多本。有两本对我影响比较大,一本是Robert C.Matrin的《架构整洁之道》,如果说日常的写代码和学习是在练基本功,那么看完这本书感觉就像被打通了任督二脉。
还有一本就是吴军的《格局》,书中的部分内容解决了我长期以往的疑惑,还有几个点我甚至从来都没有想到过,收获颇丰。
最后贴个年度概览吧。
极客时间:
得到:
话说回来,在翻得到和极客时间的年度总结时,还是让我有点小震惊的
说好的不熬夜呢?
先说一下健身的事,去年立的flag没有实现。体脂目前是16个点左右,体重快80了。原因是最近几个月做俯卧撑把上半身做壮了..
至于跑步,曾在状态好的时候想试一下半马。但跑多了膝盖有点不适,所以就及时停了。
今年跑过的最长距离是1.3w米,极限还是1.5w米吧。加上所有的运动项来估计(因为Keep的年度报告还没出来),平均每周的运动时间应该有300分钟以上。
作为一个对旅行无感的人,今年却走过了4个城市——看着一些朋友结婚。朋友圈里的同学们也慢慢到了结婚育子的阶段。而我也找到了能一起过日子的对象,大概这就是缘分吧。按照我原本想法,我想浪到30岁的。
望着可期的未来,我些许稳重了。
工作上,当务之急是先解决对几个开源组件了解不够深的问题(这使我们在踩坑时要花很长的时间来脱坑),以及自动化测试的落地,在此同时整个架构也松耦了。再对其他场景下需要的组件、逻辑以插件的形式灵活的加到项目中。团队方面的在这里不方便细说,就跳过了。
关于专业的学习,我还是希望保持现在的节奏——即对业务中使用到的技术进行挖掘,并寻找机会向下沉淀。其他方面,我会继续了解“钱”相关的一些事。另外,我还想看一些数学通识相关的书籍。
健身相关的,还是希望自己能够把体脂降下去,到14个点。早日练成半马。其他的保持现状就行。
活在2019年里的时候,总有一种时间过得时快时慢的感觉,但它已经过去了。活在今天看以往,那些事仿佛就一刹那。只有看看以前的照片,看看以前的博客,看看身边的人,才知道自己是这么活过来的。