35 岁危机，淘汰的应该就是我这种人吧？

补一下计算机基础不会花费很多时间的

第二条的确很致命。

第三条其实和计算机基础关系不算特别大，更多是工程实践能力方面有点薄弱。可以抽时间把公司项目（或者某个略复杂的项目）完整过一遍，边读代码边画架构图，理清各模块的关系（或者先把某个模块的工作逻辑画出来）

平时开发中，只能勉强完成功能，「勉强」具体表现为：

对于自己开发的项目，开发时说不清楚具体的逻辑

对于自己开发的项目，出现 Bug 或者需要做调整时，要花费较长时间才能解决


单从这 2 条来说，你怎么过的试用期？

@biu7 其实都没到计算机基础那个阶段，核心问题是「无法清楚明白完成一件事情」，但是现在的工作的要求不高，一般都是活动页面或者后台管理页面，所以甚至只需要达到第一个点就行了，第二三个点一般也可以完成，但是需要时间多一些

@iloveayu 对的，我知道这个问题

@mkt 哥 ，是因为工作内容的关系，我们的页面基本都是一次性的，或者一些后台管理页面，leader 一般不看，然后通过大量测试就能保证页面绝大多情况下没有问题

我怎么感觉这样连业务都写不下去

@MRG0 写的了，测试多了，就能上线，毕竟不是一点都不会呢，只不过对自己上线的项目不太放心

@feeeff 从我的角度看如果你做了大量测试，可能只是要等久一点，也能接受。如果是测试做了大量测试，那人家应该挺难受的。

@feeeff 所以我建议你先从绘制架构图/流程图开始练习一下啊。直接去语言描述一个逻辑可能会比较难，但如果先绘制成图表就会比较简单

「如果是测试做了大量测试，那人家应该挺难受的。」这个肯定会保证旧功能尽量不变，不需要测试人员重复测试的

@biu7 好的哥，说实话我是没有画过这个图的，

2019 毕业。如果是本科毕业离 35 岁起码还有 7 ，8 年吧？！
慢慢来吧，你有时间慢慢思考职业问题，甚至可以换赛道。

我也是跨专业的 ，但是感觉第一条不应该吧， 这个开发前就应该滤清逻辑才开始动手啊。
bug 这个主要就是基于第一个 弄清逻辑，并且有一定经验就比较好判断问题在哪。
接别人项目你自己的能力是一方面。前人留下的是屎山还是注释详细结构清晰的优质代码也很关键。
我计算机基础也很差，对于专科出来觉得很简单的东西我也不知道，但不妨碍我完成自己的工作。尤其是现在 Ai 这么普遍，对于我们这种专业性差又想吃这口饭的人来说是非常利好的。加油年轻人，

@BeforeTooLate 按目前的状态，这份工作没有的话，应该就换了

@yvyvyv 哥 咋说呢，其实一开始功能简单的时候，还是能搞清楚逻辑的，问题是随着功能变得复杂，在添加代码过程中，会让代码变得越来越乱，最终导致第二点和第三点问题出现

第一点，是思路不够清晰或记忆力不足，这无关基础知识。

第二点，是逻辑推理能力不够，找原因慢，也找不到恰当的修复方式。

第三点，是理解能力不够，不能很快读懂别人的设计和意图，只能从局部绕过问题。

这几个问题，其实对 35 岁危机影响不大，因为完全没这几个问题的人里，也只有少数能度过这个危机。

一言以蔽之，自己做的东西讲不清，别人做的东西看不懂，没有项目上的全局观

@feeeff #17 追加功能尽量少改动原有代码，也尽量少往原有方法里加。尽量封装一个方法来实现追加部分的功能，这样能清晰很多。如果要改动原有功能，那就要衡量一下改动的成本，变化不大就直接改了就好。变化程度已经和之前设计的逻辑背道而驰了，就别硬改了，推翻重写吧。这样逻辑重新梳理能清晰不少。
别每次来变动都往一个代码块里塞，最后一坨谁改都不好改。
改动写好注释，或者提交时写好备注，因为什么改的方便追述。
多说一点，有时候还是平时太懒了，比如每次改动都要在方法加一个参数。感觉加就加了 也不把参数改成对象。最后能弄出几十个参数。有些名字还相近 xxx 状态、xxx 类型的。最后也是一大坨，自己负责的部分自己多梳理代码，弄得整洁点，日后方便很多。
ps：我也懒的重构。