转码工作一年了，感觉自己技术上没有什么提升，求前辈指导

入职麻长也一年了，觉得自己和new grad比，感觉自己好像没什么进步，可能我学习能力比较差，工作中最痛苦的是要看文档，看到几页的wiki和quip我脑袋就开始大，学pipeline，deploy tool之类的东西，不怕大家笑话，我到现在连git brazil apollo都没有搞懂，就是几个命令会用，但不知道怎么回事，可以说是完全shallow dive一开始做一些integration service，跟着写了一些design doc，但其实design doc里面就是讲怎么调用哪些API，输入输出是什么。然后转到AWS某个组，这个组就更痛苦，这个产品虽然说scope scale比较大，但是整体的架构我也听不懂，现在做的就是修些小bug（具体的内容还是在哪个地方加个东西，需要调用哪个API），但上手也不容易，因为每个包都是新的，看半天也看不懂，修bug都要几个礼拜，写代码也磕磕巴巴，manager给我分配了一个mentor，是其他小组的，开会的时候mentor会给我讲product的一些东西，我也问了该怎么提升技术，但mentor可能没有get到我说的是比如看懂东西，提高coding的能力之类，他可能意识不到我的tech有这么菜。
但我工作其实没有划水，写代码，写文档，做测试，debug，也每天要工作很久，也工作到很晚，可能自己效率比较低下吧，想请教下前辈，怎么才能让自己看懂文档，而不是一看到大片的文档就犯怵，怎么才能提高coding的能力，怎么才能让自己从修bug中提升自己的认知和架构水平呢？

作为一个从来没在🍌上过班的跳槽去了🍌的L5...来了大概5个月吧.

brazil: 我第一次遇到major version conflict去看了下brazil大概怎么管dependency的. 后来EMR runtime有些奇奇怪怪的鬼故事又去翻了下大概明白了, 你应该也遇到过类似的情况吧？可以这样切入去看看...
apollo: 本来是用不到的这玩意的，奈何遇到了native ec2 application...于是去被迫研究了下. 你可能没有结合实际deploy时候的log一起看.

新的package: 我一般是从entry_point和别人的use case里面切入去看，偶尔翻翻test code.

别人的设计文档: 这个其实还是挺容易看的，重点放在input/output, 还有就是留出的endpoint interface是否idempotent之类的

其实可以淡定点，我这几个月过的跟10/12/6一样...（老人跑了我一个新来的接了项目硬抗。。。BuilderTool, Wiki, CodeBase都快翻烂了)

楼主提到自己是转码，那我觉得你可能是基础知识上有欠缺。

需要补一下，不过你的首要目的是先存活下来。

比如你说的怎么调用API，拿到数据怎么用，先把这些弄好，保证能出活儿。

然后在其他时间补一下基础知识。

既然能过面试，我觉得楼主最起码对语言和算法是有大概了解的，需要补的应该是软件工程方面的东西。

像你提到的git, brazil什么的。都是版本管理，依赖管理，包管理这块的。apollo算是infrastructure 这块了。

我觉得你可以看一本书，Continuous Delivery，这本书里面说的东西应该会解决你对上面那些东西的疑问。

之后你就能明白为什么要搞versionset，git是干嘛的，brazil是干嘛的，apollo又是啥，AWS上面那些VM跟apollo的host有啥不一样。

有了那些基础概念后，你可以尝试跟着sde setup wiki(忘了叫啥了，大概就是帮sde入职的那么一个101 wiki)做一个小东西，走个全套流程，能帮你理解versionset brazil这一套东西。

等你这些东西都有概念后，可以考虑看看clean code, refactoring这些书，提升一下编码能力。

至于计算机专业的东西，你看自己时间吧，编译原理，操作系统，SICP那本书，这些东西算内功吧，可能无法马上体现在你的工作上。有比没有好。

我个人觉得软件工程方面的东西，能让你感觉到与工作关系紧密一些，属于变现快一点的知识。

毕竟公司里的项目是工业级别的，规模大，他就有好多跟刷题不一样的问题，为了解决那些问题，就有了好多工具和实践模式，这些东西在刷题中是没有的，所以让你觉得有点懵。

多看看，多写写就好了。


补充内容 (2022-03-10 14:19 +8:00):
万万没想到大家给加了好几个大米。

那我补充一下 =。=

其实楼主的状况大概就是从刷题状态转到了上项目写代码的状态，有很多刷题时没有的东西掺合进来，让楼主觉得有点懵。

可以从一个小的项目开始类比，希望能帮助楼主理解。

比如上学时做的课程设计，过程无非就是定需求（requirement），写代码（coding），把写好的代码编译（complie）构建（build）打包（package）后，部署（deploy）到自己的机器上，跑起来看看，测试（test）一下，没什么问题。OK，交作业，完事。

因为这个阶段的东西规模小，所有的东西都是手动，也没什么关系，代码需要改的时候，那把文件拷贝粘贴一下，改个新版本，改坏了就把原来的文件拷回来，重新改。自己机器上需要的环境手配，跑起来就行。测试的时候就自己手点，有问题就返回去修，然后重复上面的步骤。直到没有问题。

但是到了公司后，你做的项目，规模要比前面说的大很多。还是用之前的手动模式，人就累劈了。所以，好多工具就出现了，帮engineer们解决一些问题。

下面说的可能不全，大概意思差不多，主要是帮助楼主有个对应，能大概知道自己天天用的那些工具，方法论是在解决什么问题。可能跟楼主所在的组不完全一致，不过大概意思差不多。

1. 需求（requirement）。

这个基本上不用自己搞了吧，应该是对应PM和senior的人去做。到了engineer手里，差不多已经确定好要做什么事情了。你需要做的事情，应该是切分成合适的task，在你们的sprint里计划好，这个sprint要完成哪些。有个规划，如果中途发现完成不了，及时调整。这里的sprint，以及你们管理task的那个SIM folder里面分的好几个不同的stage，都是agile methodology。算是项目管理的一部分吧。不要觉得engineer不需要项目管理，你自己如果能够合理的切分、规划task，对自己的项目能力有很大好处的。

   这块你可以去看看user story，kanban，scrum这类的书

补充内容 (2022-03-10 14:27 +8:00):
2. 代码（coding）

这部分应该是大家工作的重点了（senior和PE的应该不是了）。这里包含的东西很多，单纯写代码是一部分。

我想把前面说的compile，build，packaging和test都放到这个里面说。

coding本身不用说了，楼主肯定没问题。我觉得需要说的点就是在项目上coding跟刷题的coding不一样，你要注意的东西多一些，这部分看clean code，refatoring就可以了。都是好书。

然后就是test，不要想着test跟SDE没关系。test pyramid了解一下。这部分推荐一本叫 TDD by example的书。

等代码没问题了，理论上是要compile，link，build，packaging，你才能得到一个能用的package，对吧。
. Χ
barzil帮你做的就是这些事情。有没有恍然大悟，哈哈。

versionset里面包含的是多个你要用到的包，以及那些包的依赖，brazil会在这个茫茫包海中把各种需要的东西挑出来都给你编译链接构建打包好，给你一个之后deploy用的package，只不过你看不到而已。那个东西应该是VFI。

git是在你coding的过程中，做版本管理的。比如你需要更改某个地方的代码了，就直接改。改半截发现改坏了，直接git checkout完事。并且git能帮助多人协同工作，比如你做merge的时候，如果没有git，你怎么把别人的代码整合到一起。

.1point3acres好多小伙伴说以前不知道git被人鄙视，其实没什么，就是一个工具。有些地方就不用git做version control，有个古老的东西叫SVN，也是干这个事的。



补充内容 (2022-03-10 14:42 +8:00):
3. 部署（deploy）

之前手动的部署，拿网站类的东西举例子，其实就是把第2步得到的包给拷贝过来，放到server的指定位置，然后windows IIS或者tomcat啥的从那个地方读文件，你的网站就咔咔咔开始工作了。当然，前提是server上的各种东西你都配置好。

到了公司这个工业级别的项目，这么玩会死人的。那么多server，那么多文件，手动拷贝粘贴真的弄不来的。而且那么多server，你怎么手动管理呢？环境要一个一个配置吗？以前是，但是亚麻这点还是比较厉害的。都帮你弄好了。

比如你说的apollo，就是帮你管理那堆server的，你只需要点几个按钮，就有一个host生成了，你不需要手动去装操作系统，不用去电脑城买机器，不用自己剪网线，所有的东西都变成了点按钮。你需要的一些环境，也可以通过加consumer environment来实现，方便10000倍对吧。

即便是这样，可能还是不够方便，因为有些机器可能需要配置一些相应的权限。往apollo的server去deploy的时候也不希望人去参与，所以有自动化部署脚本这个东西。这个在亚麻里没有写过，没有自己研究过具体怎么弄的。不过，在pipeline上能直观的看到，你点一个approve就帮你deploy啦。

这里提一嘴pipeline，他就是模拟工厂里的流水线这个模式的，你的代码写好，push到code base里，就会出发pipeline，它会根据你的配置做相应的事情。比如先build一下，然后跑一圈unit test，然后deploy到测试环境，然后再到产品环境。从一头流到另一头。

补充内容 (2022-03-10 14:43 +8:00):
4. 测试（test）

有一些组可能还需要找专门的QA去走一遍测试，这部分分手动和自动。具体情况看你们自己组怎么分配。

前面提过的test pyramid也会涉及到这里的。可以去搜搜看一下。

补充内容 (2022-03-10 14:47 +8:00):
大致上就是这么一个流程。

前面提到的所有server的创建配置，权限的创建配置，pipeline的创建配置，这些东西统统都可以手动做，也可以自动。我相信搂着肯定听过或见过LPT或者CDK这两个东西，他们就是把你的项目上的基础设施给代码化，从而可以实现自动化一切，并且可以把基础设施纳入到版本管理中。
-baidu 1point3acres
这就是所谓的Infrastructure as code

1，2，3，4以及最后这点，都在Continuous Delivery这本书里有涉及，所以强烈推荐看看这本书，对于你理解现在的软件工程非常有帮助。我相信很多组的pipeline上会有一个Full CD的标，那个CD，就是这本书讲的东西。

实际工作就是这样的，调调api，修修bug。你把马工想象成建筑工地的工人，就能理解了。
这是一种纯输出，无法有效积累经验的工种。
说好听点，这就是所谓的工匠精神，要用匠人的心态把细节做好。

匿名者 发表于 2022-3-9 15:21
作为一个从来没在🍌上过班的跳槽去了🍌的L5...来了大概5个月吧.

brazil: 我第一次遇到maj ...

谢谢前辈，有时候我get不到一些常识性或者概念性的东西，真希望有什么给小白讲解这个东西是干嘛的，比如我其实不懂apollo是什么，虽然工作也操作过，不知道是不是自己理解力的问题

我在中厂工作两年，ds/MLE, 有类似体验，每隔一段时间就要用个新东西，一直没有完全理解，但deadline压下来，东拼西凑也可以弄出来，同事水平参差不齐，请教效果也一般，一直稀里糊涂，如履薄冰。最近决定换工作，才发现网上资源很多也很好，你可以多看看，我这种懒人只有准备面试才能真正强迫自己高效系统学习。

keeptrying 发表于 2022-3-9 20:50
我在中厂工作两年，ds/MLE, 有类似体验，每隔一段时间就要用个新东西，一直没有完全理解，但deadline压下来 ...

大佬，可以推荐一些ds/MLE的网络资源吗？马上入职了完全没经验求教

匿名者 发表于 2022-3-9 16:05
楼主提到自己是转码，那我觉得你可能是基础知识上有欠缺。

需要补一下，不过你的首要目的是先存活下来。

谢谢前辈，拿小本本记下了，基础知识的确比较缺，自己工作之余又没有学习看书的习惯，干活就是让干嘛就干嘛，花了挺多时间做公司的任务，但是因为基础差，所以效率比较低下

keeptrying 发表于 2022-3-9 15:50
我在中厂工作两年，ds/MLE, 有类似体验，每隔一段时间就要用个新东西，一直没有完全理解，但deadline压下来 ...

嗯嗯，我也是这样的，任务来的时候东拼西凑，反正最后能跑或者有结果就行，但是做起来就很慢

diligan 发表于 2022-03-09 13:00:27
大佬，可以推荐一些ds/MLE的网络资源吗？马上入职了完全没经验求教

我还属于初学者阶段，哈哈哈，地里有很多介绍DS/MLE面试经验的帖子，搜关键词能搜出来能很多，多看几个就个大概了解，推荐学习资料overlap挺多的，关键看你对什么方面感兴趣。你找到工作要入职了，说明水平已经很不错了，加油。