你描述的还不够清晰，如果是一般性的业务需求开发，我可以概括为以下几个过程
1. 接手项目代码，熟悉已有代码对应系统的功能，大到项目结构，小到一个功能对应哪部分代码；运行当前项目，能顺利的 debug ；按自己想法如实对应的修改已有的功能，评估自己修改对应的影响范围
2. 理解业务需求，从业务上讲理解业务需求的场景和意义，理解为什么要这么做；从代码上讲理解需求对应的代码部分，理解具体自己要做哪里
3. 设计需求实现，可以列一个文档等方式描述自己如何实现需求
4. 和上下游沟通，包括但不限于后端、ui 、测试、产品，理解对方并自我表达，从接口交互、样式调整、需求细节等诸多方面完成团队上的合作
5. 代码开发过程，需求对应代码应该怎么写，怎么写会写的更好，是语法上需要提示、还是开发习惯上有问题、还是不理解代码执行过程、还是效率低不熟悉
需要确定自己是哪个过程、哪个点有问题，才可以明白自己欠缺的是哪里

外面情况也不好，这行业什么都缺就是不缺人，也不缺学历好的年轻人

就天津这恶劣的市场，没必要学编程换行业，你都考研了还何必认准计算机呢，30 岁出来都要失业了

很多人英文写的都没法读，规范是为了让大家更好的沟通，除非你的项目很国际化或者大家英文水平都很好，否则用英文做注释或提交记录才是真正的影响大家工作效率，总有人以为用英文就是上进，那么英文不好的团队或非国际化大项目就赶快逃吧，这些不适合这样上进的人

这点事情真的稍微做做调查就知道了，养宠物一点都不简单，比这些麻烦困难的事情多很多很多很多，宠物博主 /晒宠狂魔常常都只展示好的一面，背后的痛苦不会让你知道的，只有一种心态可以轻松养宠物，那就是这个宠物死活都无所谓

caps 和 ctrl 对调，tab 和 esc 对调，`~和 tab 对调，右 ctrl 和`~对调（使用频率很低），这样很方便 vim 式操作，大小写 shfit 或者 vim 的 u/U 来实现

简单来说就是天生在云，以容器、容器编排等云原生提到的基础性组件为默认组件，云原生应用天生接入这些功能，没了云就用不了

关注 CNCF 会告诉你答案
https://github.com/cncf/toc/blob/main/DEFINITION.md

折腾 vim 虽然上限很高，但是投入产出比太低，直接用 ide 省心省力，性能问题应该由机器配置来解决。

对于工业级产品开发，vim 最适合的是作为插件集成在 ide 中，而不是自开发个性版 ide

当然怎么做是人的自由

1. 好的开源代码尤其基础类库会写大量注释，包含如何使用、应用背景、关键依赖关系、注意事项等等
2. 差的业务代码可能注释得不到更新，看的人看到的都是过时的、错误的注释，这样还不如没有
3. 简单的代码一看都懂，复杂的代码没有注释、文档、流程图等确定真的可以自解释吗？

chrome 右键 tab 新建群组，每个群组左侧圆圈可以合并不展示

某些情况比如 rpc 需要 interface 、或低版本的一些实现方式，而且 interface 就算只有一个实现类的情况，可以起到 中高级开放人员编写 interface 交给其他人开发 的管理作用，或者更方便的看提供接口，直接看实现类代码量较大（虽然这个可以被插件或 ide 取代）

@Joker123456789 gson 并不比 fastjson 难用，上手极快

如果喝的是有糖可乐，那得去医院查查
有糖可乐的咖啡因、糖、磷酸不控制计量的话对健康显著有害

可以换语言，世界不止 js ，而且学 PHP 、Python 、Golang 不见得比学 Node 难

开发过程中，除了浏览器复制文本和 windows 文件操作以外，都不需要鼠标
windows 快捷键 + ide 快捷键、vim 插件 + 浏览器 vim 插件
如果你常用的键位找不到，可以考虑修改键盘映射，根据个人习惯定制化

前后端分离不是为了让前端不写库啊，不分离一样可以做到这种程度的安全

现在的就业形势和以前不同，不能以早些年的前端行业来比较现在的前端