Press "Enter" to skip to content

Author: 建文

2020年终总结(上)——综述

年终总结记录人成长和发展的历史,而,人有肉体和思想,只有思想的进展,我们才算有进步,才有历史可言。

而人的思想分为「能力」和「态度」两个方面,能力创造价值,态度调配价值。只有将创造出来的价值「合理调配」,才能成为是一身心健康的人。我们一直以追求着这个目标,找到能力和态度合理的调配点,成为健康的人。

我是个“不健康”的人

在2019以前,我一直被认为是一个“不健康”的人(包括我自己都这样认为,至少是个非主流),主要原因,对照上面的历史哲学的结论,我的社会生产能力没有达到一个合理的水平[注]上,创造的社会价值很小;态度方面,我自知问题所在,态度还是不错的,但由于生产能力不足,无价值可调配,从主流价值上看,综合起来,我依然是一个“不健康”的人。提高实际生产能力水平,迫在眉睫。

注:什么叫合理的水平,和合理的调配点,依然需要进一步分析,例如我不是没有能力,只是我的实际社会生产力和我的年纪不相匹配,个中有很复杂的个人,生物,和社会原因。

如何写年终总结

写年终总结已经成了我一年一度的功课,自2008年起已经写了12年,但即使听起来很有写总结的经验,但对于写年终总结,我依然有一些困惑。主要有两个困惑,第一,要不要写,值不值得写,这个问题在今年年终我特别忙的时刻反思了好久;第二个问题是,有没有写作的技术。

要不要写年终总结

其实第一个的问题,我默认的答案是肯定的,所以我在12月第一天就提醒自己注意分配时间,因每年写总结都是收获巨大的,无一例外,但是我最近时间很紧张让我产生了犹豫,我需要更多确切的证据来说服自己写总结。

现在我已经把今年的年终整理下来了,我的新理据是,如果一年里「发散性探索」太多,不作一次综合性总结,那这些探索有可能白费。因为人会淡忘,下一年有下一年的任务,上下文切换成本很高,回看一下两年三年的年终总结和对应的研究碎片就会有体会(这里揭示了写总结的策略或技术,就是写什么,多久总结一次,后面小结)。这种自学经历有大量发散性思考的话,都需要有一次总结,不然自学不完整。一句话,收获过去,并以此为基础开展新的未来,总结是我们成长的成果,也是美好未来的基石。无论多忙,总结还是要抽时间写。

webpack与项目构建再认识

webpack 这个工具在前端社区异常的流行,以至于我在一年前就简单的研究过(看这里 ,和这里 ),当时发现webpack在无意中提出了「Web模块」的概念——任何web app组成都可以是模块(JS模块是一种),对其进行依赖跟踪,当在发布时可解释最新依赖后打包出最新版本。「Web模块」的概念确让人耳目一新,不过由于一直没有参加具体商业项目,对 Wepback 没有多少经验,也谈不上有太深刻的认识(包括本质和意义)。

最近正在着手做一些实验项目,开始触及项目构建。读了《Setting up an ES6 Project Using Babel and webpack》,发现 webpack 的目标就是 给现代JS项目开发引入 构建 一步( introduce a build step into your process),这个观点我觉得很关键,和深刻。

webpack 与 现代web项目开发流程

最初的JS项目开发是比较简单的,纯手工,开发和构建(编译)混在一起。但显然,当项目规模增大,手工需要转向自动化。 然而,什么东西需要自动化呢?这个问题针对JS项目(Web程序结构很复杂),初学者具有异常的困难。所以学习使用 wepback 一开始是不容易的。

首先明白一点,编译(将一种码转为另一种码)只是构建的一步,模块打包也是一步而已,而自动化构建的具体任务(WHAT)和过程顺序(ORDER),根据项目性质的不同,工作流(WORKFLOW)不同会有不同。例如,项目使用了不同CSS架构方法,那「CSS样式开发」的流程就会不同。

编程模式新解

我们爱有经验,尤其是丰富经验,包括生活经验,和工作经验。因为经验能扫除阴暗、未知和危险,能给人安全和幸福。然,什么是经验?丰富经验如何获得?最近的学习发现,原来 我们开发者社区常讨论的 「模式」 就是工作经验的一种表现。掌握某种作业模式,就是获得了某种经验。「经验」的元知识,转向了「模式」的元知识。

那什么是模式呢?我们可以从一些常见的「模式观」来看看当下的通识。

在开发者社区最流行的「模式讨论」莫过于 设计模式了。但是其实 设计模式 只是编程模式(编程经验)的一种,不代表所有。而且我发现设计模式的常识理解不够准确。这里,我们先从设计模式的一般定义开始,再经 代码模式,语用模式 等特例,尝试总结一下,什么是模式,从而了解获得编程经验的可能捷径。

如何选择TypeScript 或是 JavaScript?

JavaScript的基础打得够扎实了,开始关注 TypeScript。在读到一些对比文章和图书导论后,我的第一直觉是,TypeScript和JavaScript的关系就像,OOP和FP,CSS 里 flexbox和NP的关系相似,它们不是互相吃掉谁的关系,是完成同一种任务的两种特别设计的工具。也就是说,TypeScript不是替代JS,而是用来开发不适宜使用JS开发的项目。这里理解的关键是,编程语言作为一个工具(一种比 编程范式更高级别的工具)是可以如何被设计的,就像编程范式的两种不同设计思想,产生OOP和FP编程。

编程语言作为一种工具,它有一个类型系统(typing)的属性,这个属性影响你以何种方式编程(编程算法的分析和表达),这个工具属性影响你编写程序(任务)的效率和效果,包括设计,分析,开发和维护等任务。

我觉得这篇文章(《TypeScript vs JavaScript: A Fight for the Web》)比较精简,略译出来。

前端开发者的专业任务涵盖什么内容?

工程就是由专业分工不同的工程师协作完成的,每个专业都有自己的专业技能要求,和专职任务。那,我们平时常说的前端开发者,他的专业技能是什么呢?又负责怎么样的专业任务呢?这个问题非常重要,它对求职者准确定位自己的学习目标,和面试官准确锁定合格候选人都有重大意义。

源起

写作前文《不参加工作获得“三年经验”的一些策略》的契机,是我花了很长时间为前端开发打下基础,结果却被一个“缺乏项目经验”拒于门外后,反思如何获得所谓经验,并且开始发现那两本书很有参考价值,故作一分析和推荐。不过,那两本书虽然很薄,消化读通并不容易(后续会写文章介绍)。而,更关键的问题,那两本书的内容在丰富我们的开发经验上起到怎样的作用,这还要进行一步的分析和归纳。

关于面试官想要的“经验”,我在前一文给出一个初步的定义,还给出一些没法参加工作情况下获得与“三年经验”相当能力提升的策略[em]。然则,前一文其实还没有探讨完毕,例如 面试官想要什么样的经验,什么叫三年经验,经验可以用时间来衡量吗?

其实面试官要求所谓“丰富经验”是指,你作为专业开发者,能完成甚至最好高效高质量的完成自己的专业任务,只是由技术岗的困难而出现种刁难求职者的现象。所以,核心问题还是说,辨清前端开发者的专业任务,和完成它的专业技能。在有了这个前提之下,我们才有评估“丰富经验”的可能性。

不参加工作获得“三年经验”的一些策略

求职需要求职者具备一定的经验,这是常识,因为商业公司不是培训机构,更不是慈善机构,个人和公司是一种互惠的合作关系。但是,对于刚入行(例如大学生)的人说,不参加工作就没有实际经验,又怎么拿到公司的offer呢?本文是写那些(和我现在一样)转行的,刚入行,或是非科班出身的求职者看的。

源起

十月底我自觉重新进入职场准备的差不多后,慢慢开始投递一些职位申请,每天三两个申请。一周多了没有接到面试电话,有朋友看了我的简历后说,我的简历里最近三年的空白是硬伤,没有项目经验会处处碰壁。听了后,我才正式思考「经验」这个问题。

在没有工作的前提下如何获得“TMD经验”,不只是一个笑话(看这个图),对刚入行的人(包括像我这样的转行的,或非科班出身的)来说是很现实的问题。但反过回来想想,经验不也是知识吗?亲身经历只是获得知识经验的一种方式,不是唯一方式!间接经验,抽象经验不也是经验?可见,有关什么是经验,如何获得有价值的经验存在认识混沌。

如何使用偏函数技术提高代码的可读性

对刚接触JS的人来,「偏函数」是一个让人困惑的概念,其实「偏函数」指代的不是一个特殊功能的函数,而是 一种有目的函数式编程(功能编程),这个目的可概述为,将一个目标函数 Fo“偏化”(什么叫偏化,本文后面会讲),简化对Fo的调用(Fo功能的使用),从而提高代码维护质量。

与偏函数一样高度相关的,同样让新手困惑的是,柯里化函数。它们的相关在于,都是对一个目标函数Fo进行某种改造,只是改造的目的不同。

理解偏函数和柯里化函数的实质 需要很多基础,偏函数是柯里化函数的理解基础(例如参数application),而「高阶函数」是它们的基础,更基础的是「函数式编程」,当然还有一个终极的基础,「编程」是什么。

函数式编程 是一个很大的题目,不容易讲清楚;「编写高阶函数」是 函数式编程 的重要特征,同样高阶函数也需要很多解释。但是,我们可以从以他们为基础的应用技术——偏函数技术——的实例,比较具体的了解函数式编程的实质和意义。

关于偏函数技术的应用例子,我自己不写,略译此文《How to use partial application to improve your JavaScript code》作为引子。

有效评估JS开发者软实力的十条面试题

为了顺利的再进职场,最近一个月来都在做有目的训练,训练自己的实操能力(因为这是我的一个弱项——前端项目经验薄弱,加上在特长上,编码和分析更倾向后者),而不是任意的自由的学习。然而,在具体的学习主题上,除了参考和对比常规面试题,找出一些基础主题外,对什么是“最有价值”的学习主题,我没有指引。

其实我一真很相信自己的直觉,但是难免有盲区,和价值冲突,我不清楚明天面对面的考官他希望我具备什么能力。我的担心不是没有原因的,因为软件开发技术岗位向来都是既难招亦难找,企业不知道怎么考核应聘者实力,求职者不知道学什么最重要。

这里边有一个推理,在面试和通过面试的情景里,假设把企业,和求职者分两类:

  • 企业 分为懂得评估技术岗位(C1),和缺乏评估技术的企业(C2)
  • 求职者分为有实力但不懂求职技巧的(P1),实力很弱但是刷题是高手(P2)

那么会出现四种面试情况:C1P1 C1P2 C2P1 C2P2

如果假设成立,那么通过面试的只有 C1P1 和C2P2,但是真正算成功面试只有C1P1,因为只有这种结合才是良性的。