Press "Enter" to skip to content

Author: 建文

编程模式新解

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

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

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

如何选择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,因为只有这种结合才是良性的。

JS闭包和构造函数对比研究

闭包(或闭包函数)的概念在JS社区讨论的频率异常的高,有人甚至 把闭包原理看作像是外语里语法的那样重要。闭包的确是JS开发的基石(之一),然而它的基础作用为何,可能还需进一步廓清。

有一定OOP基础的人一定会发现,闭包函数和构造函数(必须使用new操作符的JS函数)的性质和意义,有点相似。本文尝试分析它们的共通和不同的地方,以期达到深刻认识闭包的意义。

源起

最近半个月一直在为重新出山面试作准备,在完成Promise(异步编程)的研习后,我又回到了JS 的基础复习中,其中的研习主题都是围绕着闭包、高阶函数、柯里化,和函数式编程。在这个过程,我开始酝酿着一种新看法,闭包,高阶函数,柯里化这些概念或技术都是以 「函数是一等公民」为前提的,它们都是在 「把函数作值处理的 」技术(请将它和 以数据作值处理相比较)。这种现象应该是 函数式编程范式的表现,目前我还没有对这种 「把函数作值处理的 」现象总结出完整的结论(初步使用「功能编程」概括之),研习还在进行中,不过我已经将它们进行归类,并且辨识出它各自的意义:

功能编程中功能制造的种类
功能编程中功能制造的种类

这里有一类首先引起了我特别的注意,就是创建新的一类。

JS语言是不是面向对象的?(二)

最新的编程技术研究成果:2020-10-25

  • 第一,OO和FP都是 程序构造术,两种都使用了抽象,但不同的思想范型;
  • 第二,构造过程分为,功能编程,和结果编程两步;
  • 第三,(两种)程序构造术 都为解决复杂性,通用协作,和复用达到这个意义目标;

阐述的步骤

1 为什么要面向对象
2 什么是面向对象
3 面向对象的标准特征是什么,
4 JS有没有,以及如何实现这个特征。

为什么要 面向对象

1 针对 事务应用程序 (数据量大,代码重复率高)的程序特点而设计的构造术
2 特点是思维粒度适中,易编写和阅读维护

React 开发中的代码复用技术:继承、构成、装饰和混入

(本文略译自《 Reusable Code In React: Inheritance, Composition, Decorators and Mixins》)

React 是我用过的最好用的UI库,如果你能突破传统旧Web开发观念,并熟悉了 React 的观念和开发模式一定会同意我的看法。好用的最主要原因,是 React 支持数种 代码复用 技术。本文将介绍 React 如何支持 四种代码复用技术,我们以一个计数器(counter)UI作为例子讲解。

Inheritance

继承或类继承 是 传统面向对象构造术 的最主要 代码复用技术。对于像 有Java 背景的人来说,继承是非常熟悉的,但是对JS开发者来说,则是相对陌生一点。类继承技术的特征是,对 某既有的类 进行功能扩充,包括数据或方法[em]

React refs使用指南

(本文略译自《A guide to React refs: useRef and createRef》)

本文,我们将探究React的一个设计——全面抽象封装了DOM的操作,又开了一个小门给开发者直接操作DOM。

作为新的第二代UI库,React将DOM的操作进行抽象封装,引入了一种新的开发模式——SPA由一个个带状态的 View组件 组成,开发者将 交互功能 理解成 View的状态的变更 的结果[em],这个观念改变是突变的。

EM:View的状态(state)或形式(props)变更都会触发重渲染,都会产生 某种交互输出的效果(交互功能的实现),但性质完成不同。从名字上就可以看出来,一个是交互计算(state),一个交互辅助(props),例如用props去初化一个新子V,会产生交互输出的效果,但不是交互计算。

当我们习惯了这个新模式后会发现,过往的同样的任务(开发交互功能),使用View组件在 分析设计和实现 上都比较原来 DOM命中模式 更好。

不过,React团队非常的有远见,就像其它代码库作者一样,想到了:为特殊情况开一后门(逃生门),这扇“逃生门”就是 Refs。