关于新手成长的一些思考

关于新手成长的一些思考

慢慢发现,编写代码的过程中,最让人受挫的时段总是发生在遭遇糟糕的代码结构时。一开始,我以为是前端与后端的问题。编写后端代码,虽然也会有struggle、有挫败,但总体来讲,你是一名解码者。你的困难源自于谜题本身的精巧。于是,你可以进一步地加大投入和注意力,让自己完全沉浸其中、陷入心流,让时间在不知不觉中悄然消逝。而突然切回前端,会让人有一种回到原始社会的挫败感。你感觉进入了一片狼藉的城市,没有干净的街道,没有整洁的地下通道,也没有让人信得过的水源和电源。事实上,你对即将开始的基础建设工作感到深深的绝望,不知道能够在这堆烂摊子上面搞得出什么花样。你就像是进入了充满涂鸦和垃圾的地铁站,一切都让你小心翼翼,让你绝望和沮丧。

使用了Nodejs上的一些框架后,不得不说,情况改善了太多。似乎一下子,这个城市充满了支撑整个城市的法律和执行机构。一切不再任意妄为,必须被精心地设计和斟酌。一下子,你感觉你又恢复了活力与干劲,可以在干一段时间的工作,继续你的创造和建设。似乎前端,也并没有那么糟糕。

可我还是遇到了挫败,面对新手的代码,面对好心帮忙却不大懂代码结构人士的代码,让人沮丧不已。特别是,当这堆代码在前端游走,你既可以严格的现代框架,也可以使用古老的蛮力时,新手们一定会根据直觉选择后者。我并不是想要去痛斥新手的不对,事实上,这堆让我恶心的代码又让我有了些许的亲切感,因为它让我回忆起了我早年时候的代码模样。

先抛开这堆厌恶情绪不说,仔细分析novice的代码,几乎有着惊人的共性:近乎于被加密过的代码命名,如a, e, i, o, img,为了编写函数而编写函数,但同时又对散布在各地的重复行为视而不见。我感到很沮丧,为什么这些东西没有办法一开始去教会新手,让它们避开这不断重复的陷阱?

我想,一个重要的原因在于,很多的技巧背后的“道理”,是需要有实战经验做支撑的。例如,变量/函数命名这个事情,对任何一个局外人来讲,都难以理解其重要性何在。可同时,对任何一个经验老道的engineer来说,这是头等大事,没有合理的变量命名几乎会让人窒息。为何两者对待同一个东西的态度会如此巨大?鸿沟就在于“实践经验”。如果你尝试过阅读他人的代码,想要去搜索一个feature涉及到哪些部分时,变量的命名就变得异常关键。好的命名,能够让你的关键词搜索,准确地挖掘出相关代码,而不会将无用信息全部带出。而坏的命名,却会给你大堆大堆的信息,让你无所适从。名字的searchable,会让任何一个实践者畏惧、担忧。

甚至,你根本不用去阅读他人的代码,如果你自己项目涉及足够多的代码量,很多事情就会变得显而易见。当你在一大堆自己编写的垃圾代码中打转时,你会发现你几乎难以勾勒清楚一个整体概念。你没有办法抓出一条主线,可以清晰系统地修改、添加任何feature。相反,你会对增加一个feature头痛不已。先不提feature的实现,找到应该在哪些地方做出修改,已足够让你耗尽心力。你会慢慢懂得,什么叫做好的代码设计,什么叫做糟糕的设计。你会开始对前人的经验,点头称是。

可上述过程,并不容易为让novice习得。因为教科书里的示例和作业,都只是十几行的小示例,根本体现不出精巧设计的必要性。甚至,就算是你有了一大堆的shitty code,如果没有一个领路人去帮你做修改,为你点破那个你不知道的盲区、点破所谓的重构应该指的什么,你便无法顿悟精进一层。

解决上述问题的古老方法,当然就是多写代码、多读好书。在巨大的付出中、在颠沛流离的struggle中逐步细化自己的感受,从而领悟出更上面的一层境界到底是什么。但我想说的是,如今时代已经不再古老。从整体效率上来看,这简直是资源的浪费。新人们需要有老手去点明自己的问题,而刚学会技艺的新“老手们”,又需要通过修改新手的代码来进一步巩固和夯实自己的技艺。这其实仅仅是一个资源错配的问题,却没有一个平台去为这两种需求牵线搭桥。

GitHub是一个很好的开始,但它着实是一个更加宽泛和粗狂的平台。而这个设想,需要更加精巧的设计和机制,去保证在code review的过程中,既能够保证双方的技艺增长,又能保持平台的健康发展。或许一开始,你会认为新手的收益无疑会更多一些。可我自己的经历告诉我,当你审阅这些劣质代码后,你会对所谓的“好”有更加深刻的认识和洞见。正如John Outerhout谈到他在Stanford开设的软件设计课程,他坚持一份份地为每一个学生组,亲自做code review。Google的工程师们都为这个举动感到震惊,并询问是否有助教的帮忙。John Outerhout回答道,就他一个人。他很理解大家为什么会有这样的疑惑和惊恐,但他自己的经历告诉他,他为这些newbie programmer所做的代码审阅,为他自己带来了更多收益,让他对软件设计有了越来越多更精细的理解,进而写作出了今年的新书A Philosophy of Software Design。

这些行为和结果反馈,让我一下子想到了Coursera这样的公开课平台,花费了大量心血去精心打造每门课的讨论组。老师们的理由很简单,我要面对的学生不再可以容纳进一个教室,而是成千上万的来自世界各地的同学,我如何有精力和时间去处理这些问题呢?倒不如,让求学的同学们自己去相互探讨和学习。这一过程甚至在TED演讲中被仔细刻画过,授课老师也是抱着实验性的态度去做课程尝试。当他守候在电脑面前,试图解决一个困难的授课概念时,还没等他将自己的答案post出去,就看到论坛上的同学们已经开始一步步地去理清概问题的脉络。他们不是一下子给出了正确答案,而是先给出了稍微正确但实际错误的答案,然后被其他人反驳,又继续修正,一步步地发掘出最后的正确答案。这一过程让这位授课老师感到无比的激动和惊讶。

而作为用户的我来讲,我也经历过一些转变。一开始很不屑于去这些论坛溜达,认为不过是一群技不如人的学生互相抱怨的场所。可是,当我自己遇到真正的问题后,我转而去论坛搜索和求助,发现了里面充满各种洞见的评论和解答。如果你使用过LeetCode,你一定明白我在说什么。那些高超的算法技艺,在一个个的post thread中被展开和深化。甚至,整个Stack Overflow就是这么个让人激动人心的大论坛,不断地有人去贡献、深化各类问题。

由此,我得出的结论是,人们已经找到了用于资源整合、供需重配的方式:那便是互帮互助的公共平台。这点已经被无数的产品所验证。真正关键的问题是,你必须得根据你要服务的内容和领域,提供定制化的工具来服务这些讨论。例如,你要做设计的讨论,你的论坛和平台如果无法支持各种设计作品的格式、无法根据行业标准去提供约定俗成的工具,那会是让人沮丧的;如果你要做代码的讨论平台,如果不支持代码高亮、不支持可在线运行的代码环境,那同样令人沮丧。你必须深刻地理解你要服务的人群,知道他们的行业标准、知道他们需要什么,甚至去弄清楚那些他们未来会需要的工具和产品。

那么回到我们的问题,如果你要服务的对象是一堆不懂代码设计的novice,你应该提供哪些工具去整合资源、提高他们的学习效率?我想,首先他们需要一个能够很好地做code review交互的工具。GitHub的PR已经给了一个不错的范例,能够在代码的任意一行添加评论和注释,让大家可以对任何一个细节做深入谈到。其次,需要一个环节去解决一些真实的问题,一些无法用玩具代码就能够构建的真正的项目。对这个项目的构建过程,最好能够有一些跟踪和历史记录。用什么样的方式,可以真实记录、反应出一个人,在新手阶段如何思考问题,在成长中如何思考问题,在相对成熟时,又会如何思考问题。而这些记录,如果能够共享出来给其他人予以借鉴,就像互相阅读关于技艺成长的传记一般,将会是收益无穷的。如何设计这样的记录过程,是很考究的。记录过多,那不过是一堆废话和噪音;记录过少,你又无法知晓到底是什么导致了他们关键性的成长。

想要尝试去构建一款这样的产品。

 

 

近期回顾

探秘JS的异步单线程 (2)
JS的异步单线程
没有idea这把米,怎么炊熟创业这碗饭

 

如果你喜欢我的文章或分享,请长按下面的二维码关注我的微信公众号,谢谢!

 

更多信息交流和观点分享,可加入知识星球:

发表评论