技术选型随想

决定即将开始的项目的技术栈,其实可以是一件激动人心的事情。面对早就已经过时,甚至“爬满青苔”的技术和工具,我们不得不强忍每天凝视它们的不适。而现在,我们可以在积极地思考客户和业务允许的限界下,从琳琅满目的技术雷达推荐区里,寻找可能让问题更容易得到完美解决的选项。这里有平衡和抉择之美,甚至可以“像对待你的金融投资组合一样对待技术组合”。

这是一段在推介ThoughtWorks技术雷达的文案。我四处张望,目之所及,竟然没有发现在市面上存在另外一份对等的涵盖了同样诸多技术主题的指南,开发者们对技术的选择,好像更多服从于来自社区媒体,或者道听途说的吉光片羽。在人云亦云下,我们会迫不及待把它们应用在自己手头上那份厌恶至极的系统中,然后自满于学会了一种新的技术和工具,或者只是为了得到一份对旁人潜在炫耀的谈资,虽然最终结果可能多半是差强人意。

我也看到了一些开发者在本能上排斥新的东西,毕竟学习是痛苦的过程,而周围有太多可以吸引注意力的事物,沉浸以及钻研,多少都会变成一件不“与时俱进”的事情。但是这在越来越快速的技术跃迁下,故步自封反而不是对自己有限精力的保护,对变迁充耳不闻最可怕的恶果,不是错过优雅和高效,而是会导致自己僵化的思维方式,以及越来越逼仄的视野空间。这就变成了一件如此“不合时宜”的事情,毕竟不会有人会对自己在井底的境遇欣然自得。

YouTube上有一份关于《Reducing risks in picking a new tech》的视频,演讲者为观众演示了在面临技术选择的时候——如何选择一个类库或框架时,如何做出更加理性的选择,这份框架在尝试定义问题的级别之后(简单、确定性、随机、不确定性),如我所预期的那样,在性能、扩展性、可测试性、简洁性、可读性、活跃度、学习曲线(还有更多)这些不同的维度上,对那份类库的清单做了仔细的考量,这考量不仅涉及了在网络上可以调查到的客观事实,还把道听途说的经验囊括进来,输出物是一份通过加权平均的分值排名表,从而指向最后那个能够说服自己的最优选择。

我惊叹于演讲者的专业下透露出的缜密,虽然我曾经和同事做过类似的技术选型评估,涉及同样的维度,但是却没有细致到整体的综合度包括加权评分。对于上述的视频,每一位有幸观摩到演讲者的分析框架的人,都会有瞬间被武装的感觉。毕竟,一份经过“包装”的选型文档,不仅看起来专业,而且增加了面临问题的不可挑战性。

但更让我感兴趣的是,演讲者在设计这样一个思考框架的动机,或者说初衷会是什么?在视频并不起眼的开头,她面临选择的多样,反而陷入选择的踯躅,相对于多数开发者面临问题会涌起的迫不及待的“Solve it”的冲动,她后退一步决定“Make it irrelevant”,一份细致而全面的分析框架自然呼之欲出。我反而觉得正是这样从盲目的不知所措中跳脱出来,思考自己真实要解决的问题,要远远比快速从一份清单里面选择谁的要求来得更为急迫。如果开发者不自觉地被炫目的技术和工具胁迫下,反而激起对期待被解决问题的反思,这反而是件好事。

当然,我认为还有个同样重要的问题,就是如何知道有哪些可以提供的选项?我想上面我谈论到了这一点。不仅可以阅读技术雷达,道听途说,还可以对感兴趣的技术热点的持续追踪,但重要的不是这些渠道,而是对新鲜感和效率持续的热情。

只是我对这一点的认知基本是悲观的,以我所见的现实,这个行业里面真的喜欢并且愿意投入专注和热情的人寥寥无几。所以,对技术栈的选型,毋宁说是个人视界的反映,是个人内心和生命力的折射,是对碌碌寻常的循规蹈矩,抑或还是对未知和可能的向往。

关于技术选型,最后一个可以谈论的问题是,在选型以后会发生的事情。毕竟,有吊诡意味的是,对于软件架构和需求的定义等诸多问题的意识和理解,会在技术选型早就结束后,随着开发的进程逐步完善,甚至发生颠覆性剧变。这时,我们会发现我们对错误的选择总是敏感又质疑的,因为它们终将以问题暴露出来,伴之以我们的悔意。越是涉及到基础设施的改变,越伤筋动骨而所不能。

但仍然可以乐观的是,我们总可以从这样的反复和震荡中,习得我们特有的经验。更重要的是,这并不妨碍我们时刻保持对技术栈观察的心态,并付出努力,专注于挖掘藏匿于表面之下的真实问题,才能做出当下最后的技术选择。

0 Comments

Leave a Reply

邮箱地址不会被公开。 必填项已用*标注