guiyumin 发布的文章

首先,Next.js是个好学校,啊不,是个好框架;
其次,Next.js的文档也不算烂,但确实有点简陋,好多都是undocumented

Next.js有个feature叫做file-system routing:

By default, Next will serve each file in /pages under a pathname matching the filename (eg, /pages/some-file.js is served at site.com/some-file.

你可以设置一个option来turn it off:

// next.config.js
module.exports = {
  useFileSystemPublicRoutes: false,
}

我今天谈论的重点是这个问题:当我在Components/SomeComponenet.jsx里使用router(不论是useRouter还是withRouter),都会报错,错误信息这样的:

- 阅读剩余部分 -

React做的SPA,非常快,然而,对SEO很不友好,社交分享更是不行。
所以就必须考虑服务端渲染了,就是所谓的server side rendering。
最近在做这个迁移工作,很久了,都没搞定。一方面不太熟悉nextjs,一方面工作量也确实不小,代码复用性不是特别好,所以应该从一开始就考虑ssr,而不是做到一半再迁移过去。

其实在上一篇文章里说的开关,有一个更正式的名字:Orthogonality,翻译为中文是正交

这个的细节以后再补充。

首先,编程本身是工程,不是科学。这就意味着条条大路通罗马,没有一个放之四海而皆准的东西。所以说,其实很多人争论的代码风格,哪个语言最好,哪个框架好,这都其实都是哲学问题,因为没有统一标准答案。

代码风格,纯粹是个人喜好,只要能通过编译,这些所谓的风格在编译后都会丢失。简单来说,编译器不在乎。当然,如果你非要抬杠说某种写法性能更好,那就是针对性能做优化。但如果无所谓性能,但着重考虑可读性和可维护性的时候,又是另一种看法了。

语言和框架更是,都是为了解决某个特定类型的问题而开发出来。你写个小博客,用不着C++,用又笨又重又慢的WordPress就挺好,杀鸡用不着牛刀。

尽管如此,在一般情况下,或者某些特定情况下,还是有最佳实践的。比如说,最近发现一个写代码的思路,就感觉很高明,非常高明,据说微软在用,而且也有v站网友提出来,感觉真的非常高明。

这个思维就是开关

也就是说,你新增任何一个feature,都要同时提供一个switch,就是开关,而且必须做好充分的测试,确保你的软件在这个开关的两个状态下都能工作正常。而切换状态就用配置文档,最后的结果就是一套代码 + N 套配置文件的方式,让不同的人按需获得自己的feature

这个高明的思维,首先是看知乎上有个问题,问的是为什么Office软件体积那么大,有人说Office要有开关的,而且做好了充分的测试,所以软件的体积大。当时我就觉得这个思路很牛逼,但是也仅限于感慨而已,因为这个是Office的开发模式,那我这小菜鸟能比吗?后来看到v站上有一个人提问,给一百多个医院写一套软件,但这么多医院,每个医院用不同的模块,而且对每个模块的具体功能的需求也不完全一样,怎么办?最傻的方式当然是复制N份代码,当然这后果肯定是灾难性的,无论是成本角度还是维护角度。然后就有不止一人提出用代码+配置的方式,也就是说,每个feature都是可关闭的。这样就完美解决这个难题。

其实这个思维方式,也应该用在很多其他软件上,比如有一个按理说应该很好的电商程序fecshop。这个fecshop或许真的很不错,但推广受阻,我自己也是勇敢的尝试了一次就再也没用过了。

不是这个电商程序不好,而且这个程序的定位出了问题。在第一次安装的时候,这个程序要装3个数据库,mysqlredismongodb。可怜我当年还不会用wsl,在Windows系统上装这三个数据库简直是不能更痛苦了。勉强跑起来了之后,感觉太强大了,不敢改代码。当然,也可以用docker来装,但到今天我还不会用docker。

所以问题出在哪里呢?定位。
第一,这是一个开源电商程序,必然会有各个层次的程序员来使用。考虑到95%的程序员都是CRUD Boy(我也是),这个电商程序的学习曲线未免太陡了。
第二, 还是定位。假如我就三个商品,比如Github这么大网站,也才3个商品,因为会员就三种,免费的,个人收费版,企业版。用得着这个吗?大量卖服务的小公司,就是5种以下的。
好,假如你是卖小商品的,比如,卖衣服的,就一个有点个性的小店,可能你的商品数量也就是一两百种,撑死三五百种,这样的一个小店,用得着三个数据库吗?
再次,就算用得着这么复杂的一套数据库,一开始用得着考虑性能问题吗?一开始MySQL一把梭,就可以解决问题,包括队列服务,都可以用MySQL。至于其他高级功能,就慢慢上呗,这个时候真的就需要开关这个思维方式了,每加一个新feature,就新增一个配置即可。如果一开始就是奔着大网站去的,注定是门槛太高,曲高和寡。
最后的最后,如果真的是大网站,为什么不用JavaMySQL够用吗?这些问题的答案是显然的。

好,说完了这个开关的思维,再复习一下UNIX哲学,其中一条是Do one thing and do one thing well。这个思维方式是第一个震撼到我的思维方式。