坐标北京，我同事没有北京户口，最近单位给没户口的办居住证，需要租房合同和房本原件，他租的房子没有房本（即使有可能也不借给租户吧），然后他就找我了，想和我借，说要交到人力审核。

我同事挺老实的，但是拿原件还是有点担心，怕有风险，但是又在一个办公室，实在不好拒绝，就借口说房本在老家，你再想想别的办法，实在不行我快递过来借你。

背景

自我介绍下，四年工作经验，头两年全栈开发，后两年专职做前端，目前已达到高级前端工程师水平，经历过三家公司。第一家公司，电商行业，做阿里 ISV 供应商，为淘宝卖家服务，也是我第一次接触百万 UV 级别的产品，在第一家公司呆了两年，由于达到技术瓶颈期，遂跳槽，第二家公司，航运物流行业，呆了六个月（工作强度对我来说，是真的高），身体不适，没有同意转正。目前这家，担任项目管理和前端组长，两个角色，目前呆了两年，做了很多东西，把自己的一些想法跟大家聊一聊。

入职时的环境

这是一家做保险和金融行业的公司，属于传统行业的科技公司，有点外包的性质，当然，也有自己的 SaaS 产品，由于是传统行业的公司，技术栈相对互联网公司来说，稍微落后一点。我刚来的时候，上一个前端要辞职了，然后做对接工作（告诉我，有啥问题，直接搜代码），我算是接盘侠，前任留下的屎山，其他的，大概有以下几点：

前端组 4 个人

其中一个归 CTO （做后端） 管，另外两个在广东，我入职的时候，也没有确认，到底要不要带人。我来的时候，就已经在了，后面我领导跟我说，要带下他们，我当时压根就没有带人的想法，也是个坑。

历史项目有很多个，都是基于一套从 GitHub 上弄过来的项目框架

• 没有前端工程化体系，开发周期长，开发质量差，维护困难

• 前后端混合项目，剥离前端代码没有剥离干净，后端很多文件都在，不知道重不重要，前端代码运行在服务端，每次修改一行代码，看效果，需要拖到服务器上进行编译，编译大概 1-2 分钟左右，非常痛苦。

• 完全熟悉该项目的人员已离职（技术和产品），项目交接没有处理好。

• 业务逻辑非常混乱，没有相关的产品流程图，全凭记忆。

• 服务器上运行的 Node 版本非常低，到现在还是 8.x，各种低版本的库都在，比如 Ant Design 用的 3.6.2，在项目开发中遇到穿梭框无法进行树状显示(代码一摸一样，在高版本 3.19.2，可以显示)。又比如还有这种 "translate.js": "git+https://github.com/MichelSimonot/translate.js.git”

• 尝试过升级库和卸载其他库，各种报错。

• 代码缺乏注释，一个文件几千行，对 React，Redux 使用，欠缺理解。

• 有过一次”爆炸”，此项目如果再继续迭代下去，随时可能继续”爆炸”，现在已经是在踩雷开发阶段。

  在 2019 年 10 月 18 号，24：00 发生生产事故，事故表现为，操作特定页面，浏览器崩溃，卡死。

  

  脚本执行时间非常长，后面经查，是由以下代码引起

  actions.getAgentListByPage({
      companyId: currentAgent.companyId,
      pageIndex: 1,
      pageSize: 20000,
      searchProvince: currentAgent.province,
      searchCity: currentAgent.city
  })
  

  页面很多地方存在请求 pageSize：20000 的情况，该代码是由前任前端编写，具体为何写出这样的代码，原因未知，处理方案给到后端解决，前端配合加入 workbench 字段，凌晨 1 点左右得到解决。

• 一套项目上，运行着两套系统。

• 打包出来的项目代码体积有 49.5MB，页面首次加载耗时 11.4 min

  

基于以上的原因，向领导提出过重构，没有同意，我认为可能有两个方面的顾虑，

• 从人力资源条件来讲，并不允许。
• 从公司战略角度来讲，能挣钱的项目就是好项目。但是，这并不影响我建设前端工程化体系。

项目人员能力较弱

• 测试同学报备 BUG，没有记录可复现步骤。
• 任务管理工具平台没有真正利用起来，相关项目需求，BUG 没有整理起来放在上面。
• 产品不理解大概的技术实现，没有把产品文档梳理，留存下来，不理解客户的真正需求，以至于技术实现比较鸡肋。

前后端接口对接，没有相关的文档

产品画的原形 和 UI 设计稿不规范

列举了以上的这些点，烂摊子太多了，好在有一个点，领导的支持力度还不错，看我是如何突围的。

明确自己的任务

前端技术建设的核心目的，是为了提高开发效率，保证开发质量，为保障项目高质量按时交付，同时兼顾考虑中长期研发实际情况，结合团队实际能力，为未来做技术储备，为业务发展提供更多的可能性，大概将自己的分为以下四类

• 基础架构设计，主要目的是从架构层面出发，通过流程化设计，规避常见问题，提高开发效率。
• 工程化设计，与代码强相关，主要目的是提高代码质量，增强代码的长期可维护性，降低开发时间和成本。
• 团队管理，通过合理有效的团队管理，提高团队人效比，为未来项目研发、技术发展，进行人才储备、技术研发。
• 项目管理，进行合理的项目管理，合适的工时排期和迭代计划，提高项目交付质量和效率。

如何解决

首先，要对现有的问题进行梳理归纳，按照问题的优先级进行排序，然后，分阶段性目标进行实现，对于上面的问题，我大概整理了一张表格

问题	优先级	成本	目标
如何打造前端工程化体系	p0	高	提升整个前端团队的开发效率、按时交付、保证交付质量。
如何进行团队管理	p0	中	进行人才储备，提高团队人员技术能力
如何进行项目管理	p1	中	掌控全局，知道项目下的人都在做什么，资源协调

团队管理

人员管理

• 初来乍到，首先就是跟大家一起聊聊天，了解他 /她的想法，以及个人情况、技术能力、兴趣爱好、性格特点等。

• 团建聚餐，经常请大家喝奶茶 /咖啡，不定时的组织活动，通常是聚餐（个人出钱），为下面的工作，好开展。

• 导师帮带，新人进来后，安排一个人带着他，答复常见问题，由简单的需求再到核心模块的负责，一点一点施展压力。

• 新人适应，负责安排新成员的发展方向，并在新人入职的前几周，了解项目框架和开发模式，再安排其做基于现有页面的优化，帮助其了解不同人负责的业务。

• 责任划分，明确团队里人员定位，并使其知晓，根据成员能力不同，态度不同，安排适合其的任务。

• 前端周会，每周一次，组织大家开前端周会，在这个会上，过下大家目前手头上的事情，有没有遇到什么问题，需要协调的一些资源，进度把控等。

• 技术分享，不定时的前端技术分享，主题不限，并把相关分享后的资料，上传到前端文档管理，方便日后的人员进行查看。

权限管理

主要是指代码权限控制，目的是确保代码安全，问题可控可避免可追溯

具体管理举措有以下几条：

• 公司仓库，代码属于公司财产，对代码进行权限隔离，启用内网 GitLab，默认关闭所有外网访问权限，针对每个项目，按实际需要给开发赋予指定权限。

• 提交权限，允许开发在自己仓库下提交，但涉及到公司仓库的合并，需要发起 PR，然后在组长进行 CR 后，才能提交到主仓库。

• 发布权限，对于将要发布到生产环境，权限给到组长，只允许组长进行发布。

前后端接口对接

前后端开发联调有一个严重问题，就是后端接口变动或者字段改动时，没有在事前事后通知相应前端开发，测试人员，导致效率底下，并且会出现各种异常情况。

因此，通过梳理开发流程，出接口文档，作为对接标准。

我们使用 apiDoc 来作为前后端联调标准。

但在实际情况中，还是会有一些接口文档和实际接口不符的情况发生，导致一些问题产生，这个我们也在思考。

前端工程化体系

刚入职的时候，由于上面的项目框架问题太多，之前也尝试过解决，但，解决不了，领导也意识到了这点，而且也有新项目进来，就让我重新搞一套项目框架。所以，我自研了一套基于 Webpack 的项目框架和工程化体系，做这件事的目的，就如我上面提到过的一样，提升整个前端团队的开发效率、按时交付、保证交付质量。

基础架构设计

Git 分支管理规范化

我们使用的是 Git Flow 分支管理策略

Git Flow 最开始是由 Vincent Driessen 发行并广受欢迎，这个模型是在 2010 年构思出来的，而现在距今已有 10 多年了，而 Git 本身才诞生不久。在过去的十年中，Git Flow 在许多软件团队中非常流行

分支命名规范

• master 分支：master 分支只有一个，名称即为 master 。GitHub 现在叫 main

• develop 分支：develop 分支只有一个，名称即为 develop

• feature 分支：feature/<功能名>，例如：feature/login，以便其他人可以看到你的工作

• hotfix 分支：hotfix/日期，例如：hotfix/0104

分支说明

• master || main 分支：存储正式发布的产品，master || main 分支上的产品要求随时处于可部署状态。master || main 分支只能通过与其他分支合并来更新内容，禁止直接在 master || main 分支进行修改。

• develop 分支：汇总开发者完成的工作成果，develop 分支上的产品可以是缺失功能模块的半成品，但是已有的功能模块不能是半成品。develop 分支只能通过与其他分支合并来更新内容，禁止直接在 develop 分支进行修改。

• feature 分支：当要开发新功能时，从 master 分支创建一个新的 feature 分支，并在 feature 分支上进行开发。开发完成后，需要将该 feature 分支合并到 develop 分支，最后删除该 feature 分支。

• release 分支：当 develop 分支上的项目准备发布时，从 develop 分支上创建一个新的 release 分支，新建的 release 分支只能进行质量测试、bug 修复、文档生成等面向发布的任务，不能再添加功能。这一系列发布任务完成后，需要将 release 分支合并到 master 分支上，并根据版本号为 master 分支添加 tag，然后将 release 分支创建以来的修改合并回 develop 分支，最后删除 release 分支。

• hotfix 分支：当 master 分支中的产品出现需要立即修复的 bug 时，从 master 分支上创建一个新的 hotfix 分支，并在 hotfix 分支上进行 BUG 修复。修复完成后，需要将 hotfix 分支合并到 master 分支和 develop 分支，并为 master 分支添加新的版本号 tag，最后删除 hotfix 分支。

提交信息规范

提交信息应该描述“做了什么”和“这么做的原因”，必要时还可以加上“造成的影响”，主要由 3 个部分组成：Header、Body 和 Footer。

Header Header 部分只有 1 行，格式为<type>(<scope>): <subject>。

type 用于说明提交的类型，共有 8 个候选值：

1. feat：新功能（ feature ）

2. fix：问题修复

3. docs：文档

4. style：调整格式（不影响代码运行）

5. refactor：重构

6. test：增加测试

7. chore：构建过程或辅助工具的变动

8. revert：撤销以前的提交

9. scope 用于说明提交的影响范围，内容根据具体项目而定。

subject 用于概括提交内容。

Body 省略

Footer 省略

这样做起来的好处，这个项目下：

• 对于分支，每个人在做什么，我看分支就清楚。
• 对于修改内容，看前缀就知道这个文件改动了什么。
• 对于版本迭代，看 Tag 都上线了什么内容。

总之，一目了然。

开发人员基本流程

在这个流程中，开发人员只对个人仓库拥有可控权，无法直接改变公司仓库代码，当需要提交到公司仓库下时，需要发起 PR 请求，经过组长 CR 后，将其代码合并到公司仓库下。

主分支代码和线上代码进行隔离，由组长将指定版本的 Tag 发布到生产环境，再通过运营人员直接从 GitLab 上拉取指定的 Tag，然后打包发布。

通过以上流程，前端代码能保证高质量，高稳定性的状态，运行在服务器端。

工程化设计

要根据实际业务情况和团队规模，技术水平来做，关键是要形成一个闭环，所谓闭环就是从零开始到上线再到迭代的全链路，有很多节点，这些节点需要根据实际情况进行设计，避免过度设计。

定制 Webpack 项目框架

为何不是 create-react-app

create-react-app 是基于 webpack 的打包层方案，包含 build 、dev 、lint 等，他在打包层把体验做到了极致，但是不包含路由，不是框架，也不支持配置。所以，如果大家想基于他修改部分配置，或者希望在打包层之外也做技术收敛时，就会遇到困难。

为何不是 umi

umi 提供的功能很多，这也导致它太过于臃肿。而且你还要去学它的封装化配置，而不是学原生第三方库的配置，如果你只想要一些简单的功能，追求更高的可玩性，哪 umi 不太适合。

所以，我自己定制了一套脚手架，实现了以下功能：

• 快速上手，只要了解 React 、Mobx 、Webpack 和 React Router，就可以快速搭建中后台管理平台
• 路由系统，基于 react-router 实现的路由系统
• Loading，不需要重复写组件 Loading 判断
• 国际化，基于 react-intl-universal 实现的国际化
• 网络请求，基于 axios 实现的请求拦截
• 页面交互，基于 mobx 实现的数据交互方式
• UI，使用业界最著名的 ant-design
• 代码规范校验，使用 eslint 、pre-commit 、lint-staged 、prettier 、stylelint
• 模拟请求数据，基于 mockjs 实现
• 打包工具，目前最流行的 Webpack

解决了以下的问题：

• 约束开发人员代码规范
• 方便提供给其他开发使用标准的脚手架，并提供技术支持

完成整个编码过程的一个闭环：

• 编码前：编码规范，最佳实践
• 编码中：自研项目框架、代码校验
• 编码后：发布部署工具 JenKins，手动发布或 CI/CD

这些节点要视实际情况，以最小成本去做，然后逐步升级。比如编码规范，我们是采用业界比较著名的 Airbnb JavaScript 代码规范，搭配eslint 、pre-commit 、lint-staged 、prettier 、stylelint 去进行约束。

这套项目框架，目前开发体验非常爽，在我司多个产品线上，投入使用，并已开源，**框架地址**，演示页面比较少，大佬们觉得不错的话，可以给个 Star 🌟，也欢迎给项目提 issues ～

业务场景

我们是做 ToB 业务，存在页面上大量使用表单的场景，所以，把我们的表单页面做成可配置化，实现了大部分页面表单配置化，减少前端人力资源投入。

针对公司的实际业务场景，其他子系统不会特别复杂，页面也不会多，共享一套账号体系，这里采用的思路是只有一个项目，不分主从系统，通过 Webpack 配置多页面，不同的子系统进入的首页内容不一样，加载内容不一样，菜单导航，则通过后端对每个租户进行区分，来做到租户看到的菜单系统不一样。

如果子系统特别复杂，有主从系统概念，可以考虑使用微服务设计，这里不做过多介绍。

静态资源

除了业务代码以外，前端还会有一些公共静态资源，例如 React 资源，Ant Design 资源，BizCharts 资源，以及一些图片文件等。

对于这些文件，是所有项目所共享的，假如这些文件分散在各个项目里，既没必要，也容易导致不同项目依赖文件不统一。

我们是放在 S3 上，做 CDN 静态资源加速，然后前端项目通过引入url 来使用这些资源，这样可以减轻自己的服务器网络带宽消耗。

项目管理

• 任务分配，产品把相关的需求，经过讨论，可行性分析，通过项目管理工具，放到迭代计划中，录入开发工时，测试工时。

• 文档管理，采用项目管理工具自带的文档，要求做到文档可以团队编辑，可以查看到编辑历史。

• 项目周会，过大家手上目前的迭代进度，遇到的问题，需要协调的资源，风险控制等。

• 项目复盘，复盘首先是要做的是事实陈述，开始诊断、分析存在差异的原因，找出导致成功或失败的根本原因后进行规律总结。明白为什么会成功、哪些关键行为起了作用，这些行为有没有适用条件，对于提高后续行动的成功率有没有价值。

熟悉产品线业务

所谓技术服务业务，找产品了解现有的业务流程以及痛点，甚至未来要做的一些产品规划，好的技术架构，要考虑各种各样的业务场景，怎样才能结合业务的复杂度，设计出颗粒度更加细化的组件。

画出产品架构图

提升相关人员的能力

产品人员

需求频繁且混乱，决策摇摆不定、动辄推倒重来。市面上一个好的产品经理是很贵的，没个三四万是拿不下一个真正靠谱的能抗住复杂产品线的产品经理，但是很多公司老板是不愿意花这个钱，一般就会招个工作一两年的产品经理先过来，顶个位置把这个工具给做出来就行了。恰恰因为这样一个认知导致产品经理这一层他既没话语权，又不能让自己闲着，所以层出不穷的需求全堆上来了，而对于公司长久型的产品架构就把控不住，如果一个产品经理无法起到，上对客户负责，下对开发负责，不会对所有需求进行筛选，把需求只会丢给开发，不会进行工时把控和质量把控。甚至对现有产品有什么功能，都不了解，那么就不是一个合格的产品。

所以对产品经理的要求非常严格，因为一个公司，如果战略方向把握住了，那么核心是要看产品，能否把握住市场方向，非常关键。这样才能决定你是否能占有市场，由于我司是做一个 ToB SaaS 化的平台，所以，必须要求产品经理清楚的了解客户实际需求，需求背后的实际场景，提炼出来哪些是共性的需求，哪些是客户定制化的需求，然后再讨论，再进行落地实际的开发。

测试人员

对测试人员，尽量覆盖全所有场景，保证核心流程畅通，要求能找到复现步骤，提高开发解决 BUG 的效率。

设计规范

由于我司采用的是 Ant Design UI 库，所以设计标准，尽量都是按照 Ant Design 现成组件和样式来做，避免开发二次修改，参考这个链接 Ant Design 设计原则

某个列表页

普通的列表，和设计，产品都约定好，上面是筛选，下面是按钮，底部是表格展示。

某个详情页

详情页大量会使用到表单，所以直接使用 Ant Design 的 From 表单组件。

表单每行放多少个，都是以 Ant Design 组件来的。

这样带来的好处就是尽量避免定制化的开发，所有列表和详情都是按照这种风格来进行开发。

总结

上面这些，包含其他的，大概花了一年多的时间，建设完成，我们目前的基建状况如下表所示

前端人员的开发效率较之前，提升了一倍左右的开发效率，前提是完全熟悉我这套项目框架的开发模式。

项目管理，人员工时占比，资源协调，目前下来都还不错，平稳进行。

如果你觉得对你有帮助或启发，欢迎点赞留言。

QQ 和微信的文件传输实在不太理想，而且我感觉每次传输的文件都会被腾讯扫描，感觉很不自在。

如题，剧本或者逻辑、氛围、演技有感觉到不错的恐怖黑暗电影剧集类，有没有可以推荐的？

猫咪现在一岁多了, 已绝育, 每天早上五点会固定到卧室门口叫门, 吵得无法休息, 这个问题已经持续两个月了

最近还解锁了新的技能, 跳起来够门把手开门

早上起来莫名其妙身上多了一只猫, 本来这也没啥, 问题是现在换毛的季节, 实在不能忍

当然会开门的问题倒是好解决, 把门一锁就完事了, 一大早叫门这个实在是不能忍

叫门的原因应该就是太粘人了, 不是缺水缺粮的原因

所以求问一下各位猫主子, 怎么才能训练猫咪自己玩耍, 不要一大早扯着嗓子在卧室门口喊?

另外附一张自己家的主子照片

请教一下大城市该如何买房，杭州社保仅满一年，很怕杭州亚运会时的房价再涨了，所以在考虑是现在选择二手房还是等满两年摇号买新房。如果买二手房是 3w 一方左右的预算，想在西湖区和未来科技城附近看看。有没有 V 友杭州买过房，请教一下如何去选择房源。

家里介绍了个女生, 我真挺喜欢的

她 160, 挺白的, 性格很可爱, 本 985, 留学日本东大, 父母双老师, 独生女, 会做饭, 还会乐器, 刚毕业去上海某 tier2 咨询公司 我 170, 长相被女同事夸像明星, 双非一本, 父母老师+做生意, 有个已婚姐姐在银行, 省会有房, 一线首付应该没压力, 家里开 7 系, 毕业后自学编程, 也是不断努力才跳到北京某大厂

都是 95 年, 生日就差个 2 天, 主要是我们是初中同学, 还是前后桌, 然后高中断了联系, 有 10 年没联系, 双方家长是同事, 我妈还教过我俩, 在她妈撮合下我们才重新联系上

想问问 v 友: 1.我这条件真的比女方差很多吗, 讲道理我个人感觉我条件也不差吧, 但遇到这么优秀的女生, 这次真的有点自卑了哈哈哈 2.这种优秀的女生一般怎么追啊? 目前基本在微信聊, 吃过一次饭, 饭后女方她妈给我妈说, 她说我比较健谈, 大方, 挺成熟的, 这算不算有戏

大家可以跑一下 Geekbench5 测试一下，性能下降明显[狗头]

注：没开省电模式，多核分数正常应该是 4000 左右。

老房子 装修的时候只有 2 楼有拉网线 1 楼没有网线

1 楼没人用电脑 只有手机 平板 但是经常断流

现在放了个路由器无线桥接 效果不佳

有没有更好的办法？（少点钱最好啦）

就跑个 jb 的 ide, 终端直接用 windows terminal，似乎现在用 windows 开发对我来说没有什么障碍了

天天被大家 m1 真香洗脑，早上照例上 apple 官网蹲 m1，看到更新了好多 m1 官翻库存，一激动都下单了

后来网上冲浪看到 wslg 的消息，立马把 insider preview 改成 dev 通道升级系统，升级 wsl 一气呵成

进 ubuntu 安装了 jb 的 ide 试了试，操作比 win 本地稍差一点，可能我电脑配置还不错所以并不会觉得卡。

重点是再也不用忍受一个 git 命令读盘半天的蛋疼体验了，感觉一下子就解决了一机开发+办公+游戏的需求，完全不需要什么 vmware 、mac 、docker 啥的，全部都放在 wsl 里。

这样既有了贴合生产环境的开发环境，还能有接近 windows native 90%的 IDE 使用体验以及极大提升的命令行工具，还买啥 m1，立马取消订单了（省的钱准备拿去买排骨吃 /狗头

我们花时间学最新的库，最新的特性，写的时候代码优雅注释清晰，这是为了什么？

写几个无脑的 for 循环，无脑的 if 判断就可以搞定上线，让老板赚钱。因为无论你用什么东西写最后的目的就是能用能上线就行，你写的再 nb 再高端，也不会升职加薪，老板也不懂，甚至因为看不懂你的奇淫巧计而批评你。

而且有时学习新东西用新写法还会耽误自己的时间，自己的的 nb 代码，仅仅在写完的时候让自己爽了，其他人都不在乎，只在乎能用就行，其他的意义还有什么嘛。为了面试吗？如果下一家公司还是这样不就陷入了循环之中嘛。

有回老家的打算，跨几个省，有点远了，只能选择快递，去顺丰网点问包丢不包损，强行寄的话真怕到家只能卖支架了

显示器是戴尔 u2720q，窄边框的在运输途中损坏的几率还大些，买过这款显示器都知道内部包装是硬纸板，并不是泡沫，难道比泡沫更安全么

各位大佬有什么办法么

买 70 平的房子，房价 3 万。就是 210 万。贷款 70%,30 年。利息估计 130 万。
合计 210+130 =340 万。
假如房子能住 50 年。一年就是估计 7 万。
一个月估计是 6 千。

自己租房，每个月 2 千。一年房租加一百。租 40 年后，房租就是一个月 6 千。
感觉每年能省好几万。

所以是租房香还是买房香。就单纯的算买房和租房费用。