开发原则

1. 思考

原则: 功能实现的同时保留扩展性; 解藕(高内聚, 低耦合)
方案: 可复用模块 --> 跨项目(平台化, NPM包) --> 配置化 --> 自动化/批量化(CI, Build.sh, Node.js)

2. 代码
   通用情况; 特殊情况; 错误处理; 兼容性; 默认值

学习原则

1. 自己当前用的到或者符合自己规划方向的技术,要仔细研究.比如: TS, React及其生态, i.e.React-Router,React-Redux,React-DevTools,React-Query和基础库Lodash
2. 跟当前工作关系不大的或者跟自己规划方向不一致的技术,只进行了解, 比如: Node.js;Vue;Babel

设计原则

1. 策略与细节

• 策略: 这个系统要做什么, 要解决什么问题?
• 细节: 数据管理方案是什么? 数据共享方案是什么?

数据管理方案是 useState,useReducer or React-Redux
Context Props

1. 系统设计

• 理解问题并确定设计边界
• 高层次设计
• 细节
• 总结

1. 亮点(沉淀/影响力)

针对这个场景,你有几种方案? 方案的优势和劣势分别是什么? 项目的痛点是什么,因此使用了哪一种方案
模块化| 业务组件| 通用组件｜布局组件

这个需求可以横向扩展什么? 做大做强!
总结出了什么规范, 可以指导下次开发!

成长原则

1. 正确重复, 专业
2. 思考模式, 框架
3. 安全专注, 饶有兴致
4. 技术推动,提效,开发体验,平台体验
5. 站在一个更高的角度来看这个问题

Technical Points

• Design first, write code later (设计优先, 然后开始写代码)
• The role of each line of code (每一行代码的作用是什么)
• Clean Code, Strong scalability, Low coupling, Extract common component (DRY)

Communication Points

• Listen completely first, output the complete sentence(先倾听,天大的事,先听人把话说完)
• Feedback in time(及时反馈)
• Notes Key output through words(白纸黑字,以防反水)
• No self-explain(不要自我解释)
• 预判

One Page

1. 通过前端架构和技术栈的升级,显著提升团队开发&交付效率

• 维护业务 SDK: Preview, Upload. 降低重复投入和体验不一致
• 自研 FormModule: UI 和 Logic 分离
• 一体化/配置化
• 批量化
• 自动化

2. 制定平台体验度量体系,提升产品体验

• Online Feedback
• Performance (性能体验)
• Error Toast CSAT （客户满意度）
• Creation Duration(创编时长)

3. 团队人才密度
   Leader 解决什么问题: 帮助团队解决业务,技术和人才问题.
   TechLeader 解决什么问题: 架构,跨端,体验&服务端.
   Poc 解决什么问题: 参加产品改进,帮助业务达成目标.

4. 流程机制:
   总结和规划: 年度,半年和季度
   不同范围的双周会议*4: 面向XXX, 做什么XXX
   团队分享

我的观点

• 只要你的错误不犯第二遍, 不管起点多糟糕, 你这辈子大概率都能爬到金字塔顶尖
• 业务项目上, 做事方法上, 沟通交流上, 撰写文档上
• 除了看结果外, 更关注做事的方法, 是不是真正能做到发现问题, 规划问题和解决问题
• 在现状下是怎么思考, 怎么规划, 怎么做的, 需要多少资源, 然后, 去争取, 去执行

组件化/模块化

• 组件定位
• 布局/逻辑
• 细节: 数据管理方案, 数据分享方案
• Props 定义

职业规划

先问是什么, 再说为什么

• 业务
• 技术
  • 稳定性
  • 性能 & 体验
  • 工程 & 提效

技术复杂性

1. 如何定义系统复杂度: 是系统的总代码量, 子模块的数量与依赖关系, 还是系统中的技术多样性？
2. 如何定义系统复杂度: 一从系统本身; 二从价值导向.
   这个系统解决的任务有多难, 解决得多好, 技术在其中的占比是多少?
3. 从三个大的维度来看一个任务的难度, 其中包括功能复杂性, 非功能性要求以及限制条件

框架:

功能复杂性

1. 功能点的数量:功能点越多越复杂.
2. 功能要求的模糊性:要求越模糊越复杂. 例如: 内容审核系统的要求是“将对用户有害的内容过滤掉”;那什么是“有害内容”？
3. 功能的可验证性:功能的正确性越难验证越复杂.例如: 大规模系统的容灾是复杂的,因为只有真正碰到实际的机房故障才能判断其有效性.即使是通过模拟故障来验证也是有难度的,且未必能覆盖真实情况.

非功能性要求

1. 规模: 用户总数,覆盖的地区范围,高峰期的访问量等等,规模造成的复杂性是大家所熟知的
2. 可靠性/稳定性: 系统是否可以持续稳定的工作,是否容易出错？可靠性要求越高越复杂。核心服务，金融、安全等领域对可靠性会有较高的要求
3. 性能: 系统时延、并发与吞吐等能力，性能要求越高越复杂

限制条件

资源: 包括人力资源,机器资源,预算,时间项目时间越短，难度越大
协作依赖: 上下游协作方越多,难度越大;协作方的可控性越低,难度越大
外部 & 内部技术服务: 可依赖的外部技术越少,难度越大

举例: Linter 自动化脚本
就结果&过程来说,专利的沉淀以及项目现状的思考,规划与执行. 每一步都是分析和解决问题.
我会把它分成功能复杂性和非功能性要求.
背景是小组解散,新组长说熟悉项目,可以看下《前端工程化》和复杂UI. 看到了规范的缺失/老旧.

• ESLint, Stylelint, Module 定义提示, Node Locker...
• 功能多样,模糊,可验证. -非功能 toD,可靠,性能 - 资源
  内部和外部资源很多仓库可参考,协作也okay.

Extend Readings

https://blog.farmostwood.net/854.html

A requirement walkthrough

PRD/UX/CR -> develop -> self-test -> joint debug -> pre-online -> online

Debugger

Enter URL -> Render Complete
DNS -- TTFB - - HTML CSS Static Asset Render -- A part JS -- BackEnd Data -- Render Complete