迷茫了， 2 年的前端到底应该具备哪些能力

[Gaays]

目前我会写后台管理系统那样的，简单的性能优化。vue 、webpack 、网络、浏览器都是会用，原理、源码不是很了解。
公司在要做规则引擎、低代码，我一个人从 0 开始调研了很多，但是做的说实话比较简陋，做的我非常痛苦，完全没有心情、信心做下去，我觉得是我能力问题，想裸辞在家里在学习一阵子，目前的就业环境又不好，又怕自己后面再也找不到工作了。各位前辈能否给点指点意见，谢谢。

[CEBBCAT]

两年还算是新人，让新人独立研发这些不应该，应该弄个主程带着做。很多时候职场人觉得痛苦，不是自己太菜，而是公司管理不行

[Hilong]

痛苦其实没关系的,也是你成长的一个过程,建议不要裸辞,现在这里苟住,提升能力可以在公司一边学一边应用市最快的.

[shanghai1943]

裸辞是不建议的。家里学习还不如在工作上成长。目前境况的解决办法是找领导沟通看看，让领导给意见，要是领导只管最终结果而不给个方向或者建议的话，就边工作边找下家。

[codewld]

找个开源的改？

[XSWJ]

我一个应届生现在也被拉去一个人做可视化编辑那种拖拉拽了，感觉以他们之前的代码成品，离主管的期望愿景差得很远，或者说很难实现，如果真要实现了，可能和实现个浏览器渲染引擎差不多了😂

[Hurriance]

正常要有人带吧。学习是个要建立在自己的基础之上有梯度的学习过程

[MuscleOf2016]

看公司什么性质了，要是国企这种自己做着玩，忽悠大领导的，随便做做，当自己学习项目就行了。
另外这不是你的问题，才 2 年，就算 5 年了，做不出来也不是你的问题。是组长、架构师、技术经理这些角色的问题。

[FallenMax]

Cons:
- 学习过程痛苦
- 亏

Pros:
- 能学到很多
- 简历++
- 公司的信任和 reputation

含泪做一下吧，多思考多请教

[YSMAN]

我工作好几年 也有这种困惑

[Gaays]

@CEBBCAT 项目组就我一个前端
@shanghai1943 大领导只管结果，前端技术这里不太懂
@codewld 产品需求可以说缝合了各家之所长
我现在做起来非常痛苦的一点：产品描述需求，我设计一套解决方案，适用于这一次的需求，下一次需求，可能就新增新的特性，我的解决方案设计不能满足这种新增需求，导致一直在重构代码。

[Southside]

看项目排期吧。如果给了足够的时间不急着催东西出来，倒是可以找个开源的项目在上面改。

[ChefIsAwesome]

没啥，典型的市场上那么多产品，肯定不难，我们也能做的公司思想。你也别想太多，别小看了低代码这类编辑器的难度了。

[weiwoxinyou]

@Gaays 不能满足需求就打补丁，重构的成本都由你承担明显不合理，能用就行

[renhou]

骑驴找驴吧，现在太卷了
我看牛客网上那些应届面试的，大厂就不说了，中小的面试题一时半会都想不出来
这还不算算法那些

[zhang77555]

两年算是个分水岭,痛苦是正常的,不痛苦说明在温水煮青蛙或者天生适合这一行
任务完不成不要有太大心理负担,平台级的产品你从 xxx 管理系统转过来做一开始不要想着能做的多好,做烂了才是正常的,做烂了也能积累经验
不要幻想裸辞后自己的学习效率就能突飞猛进,建议骑驴找马

[otakustay]

10 年经验的都不一定做得出规则引擎来

[freeminder]

1. 看下来你核心的问题是感觉自己设计能力不足，事实确实是如果你经验不足，不该由你负责。
2. 确定了 1 之后，继续做，那么你需要放下包袱，不要拿这个挫折惩罚自己，无愧于心就好，大部分人不是领域精英。公司雇你，你干活，公司觉得不行他想办法。如果大领导过分批评你，那是他的问题，不是你的，不要惩罚自己。
3. 确定 1 ，从“做的不好可能会低绩效 /开除”的角度，想要避险，可以换。
4. 确定 1 ，但是公司可能也不会有什么资源换你，从“如果在其他环境有带路人进步更快”的角度，可以换。
5. 对 4 你要总结一个很重要的点：“尽管做不出来理想结果，自己有没有提升”。如果完全没有提升，建议换工作，坚持就是白费时间，就没摸着门道。如果有提升，建议坚持，不要在意结果上的失败，职业越到后面越重要的是你独立完成了什么样的进步，这种独立摸索进步的经历是可遇不可求的（无论级别和环境）。其他机会可能会给你一个好的师傅，继续提升的能力可能会让你独立解决大问题时更加从容，但是这种场景是必然需要经历的。

补充：这种设计上的困难，需要看一些对应的材料，比如设计模式，领域驱动设计。看看网上一些业务引擎创新的总结文章（相对纯技术创新），从中看到对业务的思考和对应的总结创新。还有就是绝对不要裸辞，绝对不要裸辞，绝对不要裸辞，你想裸辞的理由可能有很多，那都不是大事。

[gloye]

楼上大佬说得对

[Gaays]

@freeminder 非常认同第 5 点，低代码编辑器我自己摸索出来一个勉强可用的，中间也学习到挺多知识。我时常感到痛苦的一点是感觉产品的需求最开始没搞明白，所以后面的迭代一直在为前面没想清楚的事情买单，导致我也一直在重构，所以感觉自己做的事情没有意义

[RealJacob]

同感觉很多时候比较痛苦，一年半
一个人主 r ，oncall 全套
对服务器知识很多时候一知半解，各种工程化配置什么的很耗时间

[freeminder]

@Gaays 感觉产品需求不清楚，后续迭代有浪费：是团队合作的常态问题，不同环境程度不同，本质是计划、沟通、工作方式、相关角色能力的问题。
这种就是提升你的影响力，不论是你带头，还是你能影响带头的人，至少是做到有效暴露问题（不是直接跟人家对喷）。这个是另外一些问题上的历练：能不能我们把问题聊清楚、能不能通过什么手段规范化版本迭代、等等。
在自己的实现手段方面，如果这个事情暂时不清楚，我建议在你的控制范围内，做最小化的补丁。这个时候的实现思路不能是“我要注意扩展性、健壮、抽象、优雅 xxxx”，而是“在不特别恶心的情况下把事情办了”。对恶心的 patch 代码做意图注释“因为这里和什么冲突了，所以只能 xxx”。间隔一段时间再总结重构，这时候你积累了很多理解，起码一次解决一大批问题。另外通过完成需求，积累自己的权威性；你的权威到位了，技术债小暴雷是你申请重构资源的机会，不要害怕技术债。总之一句话：不要过早优化。

另外我这个人提建议总是向正向提的，正向很辛苦，任何时候你都有 walk away 的权利。我写的内容是“如果你想要坚持，可能有什么方向”，而不是“这些是你应该坚持的理由”。

[Gaays]

@freeminder 感谢，原来是我对软件开发、团队协作认知不足导致的问题，看到这我有种豁然开朗的感觉！