Nicky Lao
Nicky Lao
> 公司项目统一都使用 [angular-cli](https://github.com/angular/angular-cli) 来搭建工程环境，从 Angular2 到 Angular8 版本都经历了，老项目都基本升级到 Angular4、6，新一点的项目，ng 版本都是7、8了。许多项目构建的速度，一直都是正常的表现，某一两个项目表现的比较异常，这不得不采取相关改进措施。 Angular 生产环境构建打包 `ng build --prod` 是开启了 `AOT` （[为什么要AOT编译](https://angular.cn/guide/aot-compiler#why-compile-with-aot)），`ng build` 构建配置项也比较多，含义介绍见文档：[build](https://angular.io/cli/build)，常见配置属性设置如下： ```json "prod": { "optimization": true, "outputHashing": "all", "sourceMap": false, "extractCss":...
## Working Group - [React Native New Architecture Working Group](https://github.com/reactwg/react-native-new-architecture) ## 脚手架 - https://github.com/RootLinkFE/react-native-template ## 学习资源 * [ES6教程](http://es6.ruanyifeng.com) * [typescript](https://zhongsp.gitbooks.io/typescript-handbook/content/) * [搭建开发环境](https://reactnative.cn/docs/getting-started/) * [react-native-guide中文资源](https://github.com/reactnativecn/react-native-guide) * [How to use `create-react-native-app` with...
## Spec - [ESTree 规范](https://github.com/estree/estree) The ESTree Spec - [Babel AST格式规范](https://github.com/babel/babel/blob/main/packages/babel-parser/ast/spec.md) ## Articles - [前端要以正确的姿势学习编译原理（上篇）](https://zhuanlan.zhihu.com/p/36301857) - [对 Parser 的误解](http://www.yinwang.org/blog-cn/2015/09/19/parser) - [AST 与前端工程化实战](https://xiaozhuanlan.com/topic/6389721540) - [平庸前端码农之蜕变 — AST](https://github.com/CodeLittlePrince/blog/issues/19) - [AST抽象语法树——最基础的javascript重点知识，99%的人根本不了解](https://segmentfault.com/a/1190000016231512) ## Books...
## 什么是软件架构 > **软件架构** 是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件，组件之间的关系，组件特性以及组件间的特性。软件架构可以和建筑物架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础（蓝图），可以列出开发团队需要完成的任务。——[维基百科](https://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84) 和盖房子一样，对于软件开发来说，最初，设计出软件的总体架构蓝图，思考各个模块之间的关系，实施一系列相关的架构决策。然后，选择软件开发所需要的一系列技术栈、框架等，讨论关于应用的上线、部署等流程问题。最后，才能进入软件的开发阶段。在开发过程中，还需要保证软件的质量，才能设计出符合要求的系统。 开发人员需要怎样的软件架构？我们期望的软件架构，应该是贯穿在它被应用的生命周期里，应该包含： - 系统间的关系。明确地指出是调用还是依赖关系。 - 系统内关系。比如通信机制。 - 应用内架构。包含应用相关的框架、组件，并清楚表示它们之间的关系。 - 规范和原则。指导开发人员编码和构建设计中的架构。 ## 架构的设计 架构设计不只是一个技术工作，它包含一系列复杂的工作，其范围包括软件工程、开发实践、业务交付等相关领域。为此，在进行架构设计的时候，需要进行一系列技术及非技术相关工作。 - （1）手机利益相关这需求。倾听业务人员、项目负责人等相关者需求，进行用户访谈，收集相关的需求。 - （2）与相应的技术人员（如开发人员、测试人员）讨论，了解架构上的潜在限制。 - （3）寻找潜在的可行性技术方案。 - （4）整理出功能列表中的功能性需求和跨功能性需求。 - （5）找出会严重影响开发的风险点。 - （6）和技术委员会、利益相关者反复确认方案（可选）。...
微前端（Micro-Frontend），是将微服务（Micro-Services）理念应用于前端技术后的相关实践，使得一个前端项目能够经由多个团队独立开发以及独立部署，并且该前端项目可能是不同技术栈的结合。 ## 书籍&文章 - [《微前端的那些事儿》](https://microfrontend.cn/) - [精致化的微前端开发之旅](https://zhuanlan.zhihu.com/p/46284079) - [【美团】用微前端的方式搭建类单页应用](https://tech.meituan.com/fe_tiny_spa.html) - [微前端如何落地？](https://mp.weixin.qq.com/s/I2Y4N0hwugNV2d6Zk6AdMg) - [Serverless For Frontend 前世今生](https://www.yuque.com/egg/nodejs/sff-history) - [可能是你见过最完善的微前端解决方案](https://zhuanlan.zhihu.com/p/78362028) - https://martinfowler.com/articles/micro-frontends.html - https://micro-frontends.org/ - [微前端qiankun从搭建到部署的实践](https://juejin.cn/post/6875462470593904653) - [微前端学习系列(一)：微前端介绍](https://juejin.cn/post/6955341801381167112) - [微前端学习系列(二)：single-spa](https://juejin.cn/post/6955342063235760164) - [微前端学习系列(三)：qiankun](https://juejin.cn/post/6955342295998660615)...
# 开源的 Low-Code 项目调研 **`Low-Code`** 一词早在 2014 年就由 Forrester 提出了。（见 [wikipedia](https://en.wikipedia.org/wiki/Low-code_development_platform)）。 你 Google 搜关键词 **“Low-code development platform”** 可以找到很多关于 `Low-Code` 的内容。类似的词有** Pro-Code（纯代码）、Less Code（少写代码）、No-Code（无代码、自动化）**。Low-Code 应该介于 Less Code 与 No-Code 之间。 ## 什么是低代码平台（Low-Code)❓...
## 背景 XX项目有App终端，技术栈 React Native，本地打包，QA去打扰开发人员占用时间，打包费时，也受开发电脑配置影响，慢得可能要30分钟。电脑配置高也至少10+分钟，一天多次，断断续续打断开发的开发节奏，影响效率。 为什么不用Jenkins？ - 有服务器，但运维一直没帮忙装Android环境，导致App构建迟迟不落实。 - 服务器一般没有Mac OS的，需要支持iOS App自动化还得采购走申请，了解到以往平台那边的项目也不是自动化打包的。 为什么用 GitHub Actions? - Gtihub Actions 自2018年上线后，就被社区广泛使用，基本托管在Github的项目都会首选 Action，因为好用 - 社区共享了很多Action 插件，[市场上](https://github.com/marketplace?type=actions)可以搜到各种符合需求的Action插件，可做到拿来即用，节省时间。 ## CICD实现思路 由于代码是在公司的...
**单例模式（Singleton Design Patterns)**：一个类只允许创建一个实例，单例一般用来处理资源访问冲突、或者是表示一个全局唯一类。 ## 为什么说支持懒加载的双重检测不比饿汉式更优？ - 饿汉模式：类加载时提前初始化静态实例，不支持延迟加载 - 懒汉模式：支持延迟加载，但函数锁造成加锁解锁频繁，并发低，存在性能问题 - 双重检测：在函数内部进行判断加类就级别锁，静态对象实例化之后不再触发加锁解锁的情况，并发高 - 内部静态类：比双重检测简单。 在前端，由于js是单线程的，所以，不会存在锁的情况，不过也可以了解后端是通过锁来解决这个并发问题的。 ### 饿汉模式 > ts 代码 ```ts class SingletonEhan { private id: number = 0; private static...
近期用 nuxt.js + nightmare 开发的爬虫工具，发布时部署 Linux 系统。由于 Linux 系统没有图像相关的 GUI 界面，需要安装一系列的依赖，所以才遇到坑。 CentOS 和 Ubuntu 系统都不一样的操作，遇到 docker 创建的各种坑（其实就是不熟悉），以及国内服务器 docker build 时下载速度慢，需要镜像更换等，从不会写 Dockerfile 到懂得使用 Docker 部署 nuxt.js 应用的过程，以下是一些操作记录。 ## puppeteer 镜像设置为国内 ```...
在工作6年的时间里遇过不少项目重构、项目重写的情况。有从PHP重写到Java，前后端一起重写；有App用 Ionic 重写，也有过同技术栈的老系统重构成新系统，更多的情况是老系统代码混乱，设计较差，业务变化时无法很好的扩展，使得代码在维护和改动时，开发成本剧增。 我认为一个软件的生命周期正常不应该低于3年，如果业务飞速发展，架构设计不够，只能撑2年也还行，这种是例外情况，毕竟业务飞速发展的情况下，软件设计的时候无法预想到更多的扩展情形，这需要非常有业务和技术经验才能做得好系统架构设计。 业务飞速发展也不是重构系统的借口，做好的话就可以避免重构的情况，要做的就是写代码的时候一直在不停的重构…… ### 为什么要重构（Why）？ 首先要理解重构和重写的区别，重构不是单纯的指重新开发，重新写代码，而是改进代码与设计。 直白的说重构就是改善现状，使得系统在扩展需求和写代码的时候更快更好、更合理。专业的定义：**重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低**。 重构的目的是改善代码质量，以便不至于让代码腐化到无可救药的地步。（程序员不愿意去维护的老代码，看到就口吐芬芳…）。项目需求在每日迭代演进，代码不停的堆砌。如果没有人为代码的质量负责，代码总是会往坏味道的方向走，味道变了，发出恶臭后（混乱），项目的维护成本就慢慢的高过重新开发一套新代码的成本，这时候要想再去重构，可能就做不到，做不好，不如重新开发一个新系统。 这时候可能就是重写了。 任何优秀的代码和架构，不是在着手写的时候就可以做好的，都是慢慢迭代出来的。我们无法100%预检未来的需求，也没有足够的精力、时间、资源为遥远的未来买单，这也是避免过度设计。特别是创业公司，应该以最快、最低成本的研发达到业务需求。所以，随着系统的演讲，我们再进行重构代码。 当我们真正遇到问题时，就应该着手重构，而不是说先这样，日后再改（重构），慢慢的就改不动了。重构代码其实对一个程序员的编码能力提升有很大的帮助的。有句话是这么说的：**初级工程师在维护代码，高级工程师在设计代码，资深工程师在重构代码。** （这里的级别不是职称，就是个能力的概念）。 ### 到底重构什么（What）？ 重构分为大型重构和小型重构。大型重构指的是对顶层代码的设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等。 小型重构指的是对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名、规范注释、消除超大类或函数、提取重复代码等等。 不管是大型重构和小型重构，都需要用到设计思想、原则和模式。 ### 何时重构（When）？ 把一个系统当做我们的健康身体，我们不能等到代码烂到一定的程度（身体出现问题）之后才去重构（锻炼、改善饮食、不熬夜）。当身体出现大问题，就不能像健康的身体那样能承受日常生活的压力，日久就会加剧，而锻炼和端正作息的行为的目的就是让身体恢复到健康，这时候的目的就降了一个级别了。以前你身体也健康，也有理想去实现，现在理想变成梦想，理想变成了身体健康。所以，我们需要一开始就要保证身体健康，才能继续的去为了生活、未来目标、理想奋斗。重构就是身体健康的保证。 项目代码拉倒一定程度后，开发效率低，招了很多人，天天加班，出活率低，线上bug频发，领导发飙，管理束手无策，工程师抱怨不断，查bug难。这时候再重构也是比较晚的了，可能也无法解决问题。 和健康生活保障健康一样，日常就需要锻炼、不熬夜、按时吃饭。平时如果不注重代码质量，堆砌烂代码，实在维护不了了就大刀阔斧地重构，甚至重写代码，也不是一种可持续、可演进的方式。 何时重构的答案就是**持续重构**，日常迭代需求，修改代码的时候，顺手把不符合规范、不好的设计重构一下，这是最好的时机，因为之前的代码可能预想不到此时的业务需求，写得不够，当前需求完善的时候就应该改进该处代码，保证日后的可扩展性、易读性、健壮性等。 项目团队中要把单元测试、Code Review 作为开发的一部分，把持续重构作为开发的一部分，成为一种习惯，对项目、对自己都会很有好处。 ### 该如何重构（How）？...