Thanks to visit codestin.com
Credit goes to github.com

Skip to content

技术漫谈 #18

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
zanminkian opened this issue Apr 18, 2023 · 2 comments
Open

技术漫谈 #18

zanminkian opened this issue Apr 18, 2023 · 2 comments

Comments

@zanminkian
Copy link
Owner

zanminkian commented Apr 18, 2023 •
edited
Loading

  • 如果不是JS内置了的async和await这两个Promise相关的语法糖，Rxjs其实比Promise还好用。如果JS以后能内置对Rxjs语法级的语法糖，那将会非常香。个人认为，Rxjs有一个失误是废弃了toPromise方法，虽然有lastValueFrom，但是一点也不函数式，除非JS的管道操作符能上Stage 3。
  • 函数式（FP）和面向对象（OOP）并不是对立的编程范式。Java8引入了lambda表达式和stream，Angular使用了大量的Rxjs。从这些例子可以发现，面向对象在宏观层面指导性更好，比如模块的划分、职责边界的确定；而函数式则在微观的代码细节层面，比如一个函数、一段循环上做到简洁清晰。
  • prettier的换行是真的难用，难怪antfu专门写了一篇文章吐槽。
  • 对于Node/FE工程，文件结构建议：需要手写的代码（js/ts/css/html/proto/thrift）都统一放在src文件夹里面，脚本自动生成的代码或拉取的代码，则放在src同一级的文件夹内（比如gen/idl）。
  • tsconfig中的verbatimModuleSyntax对CJS项目不友好，但是对于ESM项目开启这个选项就很香。期待以后所有项目都是ESM。Proposal: deprecate importsNotUsedAsValues and preserveValueImports in favor of single flag microsoft/TypeScript#51479 (comment)
  • 大概两年多以前（2020到2021），受到airbnb的风格影响，强制要求每个函数声明都要写上返回值。后来思考清楚后，其实这不是最佳实践。好的TS代码应该像写JS一样顺滑，同时类型能自动推断。声明太多的类型，不管是手动写的type或interface，还是函数的返回值，都有种画靶子然后打靶子的感觉。而且，函数要求声明返回值在函数返回的类型是外部库的类型时，还需要导入一遍，不仅麻烦，而且外部库可能不一定把类型暴露出来。总的来说，虽然我们写函数可以不声明返回值，但是作为开发，应该尽量避免返回复杂的字面量对象，比如return {a:1,b:'1',c:{d:true,e:['1',1]}}，这样ts的类型推断可能有点问题。并且在某些场景还是应该写明返回的类型，比如返回any的场景。
  • 关于八股和非八股，有些人面试时，只要面试官问技术问题，就认为是八股，这有点不妥。技术问题还是得区分八股和非八股，并不是所有技术问题都是八股文。有些技术问题在业务场景几乎用不到，了解了也不太能解决啥问题，就是纯纯的八股文，举个例子TCP的三次握手。但是有些问题和生产息息相关，经常用到，那就不是八股文，比如浏览器跨域相关的头大概有哪些、cookie的属性大概有哪些、HTTPS和HTTP的区别等。
  • 看了阮一峰老师的软件工程的最大难题，个人还是比较认同里面关于“团队解藕”。技术小组人数大于五人的情况下，组内任何一个人，包括TL，都不能追踪组内所有成员的工作进度，进而没有办法对技术实现细节了然于胸。你不真正理解系统，也就不会感到自己是代码的主人，这对有追求的技术人来说是个不小的打击。相对于有主人翁的感觉和意识，没有主人翁的感觉和意识的工作效率和热情减半不止。
  • React is a runtime library for writing html in js.
  • JS 发展到现在，有一些糟粕。同一种功能，有不同的实现，每一种可能有细微的差别，比如num.toString()和String(num)。这些糟粕和实现细节，初学者（甚至是用js工作了一两年的开发者）是不一定能体会到其中的弊端。这种情况下，有经验的资深JS工程师，通过ESLint配置，将不好的实现和糟粕的用法禁止掉，这对任何项目都非常有利。
  • 在中国，软件工程师一定要在支撑业务的前提下对技术精益求精。
  • 执行npm install时，npm默认会自动执行node_modules里面的npm包中的postinstall等script，这真不是好的设计。npm包的开发者应该尽量不往包的scripts里面写postinstall等语句，因为这些scripts这对使用者来说真tm不好用。https://blog.typicode.com/posts/husky-git-hooks-autoinstall/
  • 关于框架模块化的思考。midway启动项目时，遍历dist文件夹，将所有的Provider和Controller都放在一个统一的IOC容器内。这种做法类似于Nest只有一个AppModule，然后所有Provider和Controller以及第三方Module都都如在这个AppModule里面。这样简单粗暴毫无模块化的做法，对后续工程维护会有一定影响。好的做法应该是Nest推荐的模块化，每个模块拎出来都能作为一个闭环的微服务（甚至更细粒度），这样对以后做微服务拆分有很大好处，就算不做微服务拆分，将工程模块化，分而治之，本身也是更赏心悦目、更易于理解的方案。
  • Typescript 5.0 推出的新 moduleResolution: bundler 真不觉得是个好的设计。各个打包工具（webpack、rollup、esbuild等）不严格要求 js 代码遵循ESM规范，归根结底是打包工具应该去遵循规范的事，结果变成 TS 的妥协。
  • 软件工程引入的设计模式、封装继承多态等概念根本目的是为了让项目好维护。什么是好维护？仁者见仁智者见智。代码量多和维护性有关联但不绝对，单纯为了减少代码量（即复用），就做各种抽象和继承封装，反倒是对项目维护性是有害的。
  • lodash 对于现代 TS 项目来说是弊大于利的。有3个最大的弊端，首先是类型安全，这种库诞生于 TS 之前，对类型安全的支持不是很好，很多函数的入参和返回都是 any，即使不是 any，类型也不太准确。其次是提升代码的黑盒性，使得代码不容易预测，如果使用 es6 的特性，比如 map、reduce、展开符等，能比较直观知道这个功能是什么，也比较好预测代码的结果，但是 lodash 的部分函数不容易让人理解结果表现，比如 defaultsDeep 函数是否会合并数组类型，这个文档也没给出清晰的描述。第三是增加项目体积。最大问题是类型安全，与其用 lodash 的函数，不如找找有没有相同功能但是类型更加健壮，且更加易于预测的函数 npm 包，否则建议使用各种 es 新特性手写。
  • 一个库，如果侵入和你项目的方方面面，那么这个库要非常谨慎选择。比如react是是一个库，但是一个前端工程只要用了react，那么项目代码一定各个地方都是react的影子，无法剥离。如果一个项目用了nest，那么整个项目都是依赖注入，也无法剥离nest。一个项目如果了express，因为express只是简单的http路由，不太会侵入业务代码，那么从express替换成其他http框架就比较简单。
  • 如果一个变量只用一次，那么就没必要创建变量。同理，Nest 和 Midway 中的 DTO 大部分都只用在一个接口中，但是也必须先定义，然后再在controller中使用，从思维连贯性来说，这种开发体验不好。但是目前似乎也没有更好的办法，比如直接在参数装饰器里使用 zod，那么参数类型没法拿到，还是得先将参数装饰器内的 zod 抽出来，和当前先定义 class DTO 没有根本性改变（当然，zod 校验得到的是一个 plain object，体验比 class DTO 稍微好点）。除非参数装饰器能改变参数的类型，但是这需要 ts 的支持。
  • 前段时间看到一个美国著名老工程师（忘了名字，找到再贴上）说到了函数式编程的本质：函数式编程的本质是不定义变量，只要不让定义变量，函数式编程其他一系列特点都是自然而然水到渠成的手段。精辟👍。
  • 最近较多地使用 AI 编程，谈谈感受。如果是开发维护一个现有的软件，如果我对其使用的技术栈很熟，它对我的全天工作效率的提升大概是30%~40%，算上其他它不能替代工作任务，它平均对我每天提升我的效率大概是20%不到。如果我对该软件使用的技术栈和不熟悉，它对我提升的效率大概80%~100%。对于不熟悉的技术栈，AI 能让迅速我成为该领域的初级工程师，然而我们大部分工作是处理熟悉的技术栈。开发者每天处理最多的时间其实是梳理需求、编写技术方案，而不是编码，当 AI 能高效理解需求，并且从产品需求到开发测试一条龙开发完成上线，这时才有可能冲击开发者。只要还没一条龙自动化，其永远是程序员提升效率的工具，而不会取代程序员。越难理解的需求，AI 越处理不好，例如较复杂的后端。越初级越不触及核心业务的岗位，例如管理后台的前端开发，AI 对其冲击越大。如果前端只是薄薄展示一层，AI 应该很快就会替代前端很多岗位。总之，AI 对前端的冲击还是比较大的，前端开发者未来的护城河将会是全栈架构师或全栈个体，能快速理解需求并实现全链路开发。
@zanminkian zanminkian changed the title 我的技术朋友圈 技术杂念 Apr 21, 2023
@zanminkian zanminkian changed the title 技术杂念 技术漫谈 May 9, 2023
@waitingsong
Copy link

waitingsong commented Sep 6, 2023 •
edited
Loading

prettier 那帮家伙想控制一切，而不是如 eslint 那种提供一个运行框架以及默认配置根据你自己需要更改配置的灵活。
prettier 大括号后换行的逻辑实在别扭，不晓得现在改了没 prettier/prettier#3084 。
eslint 自带风格规则以及插件的风格规则已经足够用了。

@waitingsong
Copy link

强制函数返回类型声明对于团队来说是利大于弊的：输入输出强制声明类型可以很好地收敛变动风险，随便你如何修改函数代码（包括返回值），有出入类型把关即便没有单测也能保证质量。 如果依靠返回值自动推导类型，那就把风险传递到下游了。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@waitingsong @zanminkian