………这种关键词一般前后都要加空格的吧

可以从简单的库开始。

举个不恰当的例子，比如说 compiler ，要实现一个复杂语言的很复杂吧，但是简单的，LL(1)的文法解析，手写可能有点复杂，但用生成器的话基本上大家都会，一个只有 int 和最简单几个语言结构的，大概就是本科生大作业的程度。
那么，在这个基础上，就可以观察一下自己想要做什么方面的扩充，然后去针对性地学习和扩展功能，比如说，更多的基本数据类型、结构体、OOP 、类型检查、编译到特定的机器上，之类的。

像是数据库或者 pdf 库之类的，大概也是类似的内容吧。

而且如果把功能拆分开来然后逐个审视的话，op 也许会发现，其中有许多功能已经有别人做过了，比如说对命令行参数的解析，甚至连 pdf 解析这件事本身也是别人做过的。

那么就可以问一下自己，实现这个项目的目的是什么呢，如果是为了短平快，那么自然可以别的类库都用上，如果是为了学习，就可以自己去寻找各种材料，比如说 pdf 的 spec 或者一些简单的类似项目的代码，来参考学习。

这样的话，就可以从简单的开始，一点一点把项目往复杂里做，也可以先依赖第三方库，在自己写出了自己的版本后把这个库给替代了。

我觉得最重要的大概是两个能力吧，一个是「解决问题的能力」，看 op 的介绍，在这方面应该没有问题。那么第二个能力，就是，组合和拆分，也就是说，把一个复杂的问题拆分成许多小问题，再把小问题拆分成更具体的任务…之类的，把不同的知识点组合起来，然后形成一个可以去做的项目，这样的能力。

赋值语句长这样，感觉以后很难支持数据结构了

自从知道 b 站在热点社会话题（疫情、乌克兰、外国科技、资本家）上的态度后，就不再用了。

看到 lz 说 ICC 就觉得没什么好说的了。伪造工作经验把自己的 cv 给弄脏，值得吗。

毕业了还在学校里反复横跳，首先像样点的大学都不可能招你进去重复读，这种身份在职业市场上的价值可想而知。

还是为了那个印着星条旗的身份证，不管是过着多低贱的生活都是值得的？

这种纯业务 CRUD 的东西没什么开源的价值，不如找外包给个报价。

对猎巫行为感到十分反感。

个人的看法，对时区之类的细节，在 prototyping 的时候不会去特地考虑，毕竟首要任务是弄个 demo 出来。

但是到了 production 的阶段，这些细节都是需要解决的吧。除非在写的是应付学校的作业。

把.Net Framework 时代的东西称为「新的第三方不稳定 API 」也实在太典了。

说到设计模式的话……想到了小学时候的平方差公式，不知道这个比喻恰当不恰当。

大概是，在课本上会讲到，但是其实也不是多么复杂的知识，也许很多人在学到这个知识点之前，就已经自己摸索出来了。

但是反过来说，也不会有人整天写书本、课程或者是开会来教授「平方差公式背后隐藏了什么精神」之类的东西吧？

我对设计模式的理解大抵上也差不多……首先这东西在某些特定的场景是有用的，但是并不是什么绝对真理一样的东西，反过来说，不同人也可以通过自己的实践和学习形成或多或少的属于自己的感悟。

但是如果有人整天在吹「 Java 编程思想」、「 PHP 设计模式」之类的东西……还是离得远远的吧。

顺便提一下，有一些设计模式的存在，是为了解决在语言中缺少的语法结构而出现的。

比如说 Visitor 模式之于 Pattern Matching 。在 Kotlin 这种命令式语言里面不存在 PM ，所以只能用 Visitor 来模拟。

比如说 Strategy 模式之于 Lambda 和 HOF ，所以这种模式在 Java8 之后就没什么价值了。

比起死记硬背设计模式，不如尝试理解一下这些模式是怎么来的。

这背后涉及到的，Language Design Engineering ，还有 Functional Programming 里面的抽象和组合的概念，也许可以获得更多有趣的收获。

能做新项目最好还是尽量争取吧。虽然按照外包的尿性，既然招进来是维护 legacy ，那么应该不太可能转新项目。

不要担心进新项目各种不会，op 换个思路考虑一下，如果继续维护 legacy ，那么几年后再转就更难了吧，毕竟到时候人家对你的要求更加水涨船高，如果现在 op 都觉得困难，那么几年后人家提出的要求，op 又该怎么解决呢。到了那种时候，legacy 的经验就是纯粹的负经验了。

而且说难听点，十年的老项目，还没有 spring ，估计也不会有多好的编程习惯和良好的架构或者约定。

做实习或者第一个项目，用人单位本身就不会对你的工作经验有太大的期待，Java 基础如果够扎实的话，其实就足够了。剩下的，都是边做边学慢慢积累。

但初学者很难知道他说的是正确的还是错误的吧。

我也有点好奇 op 的选择是什么，毕竟感觉不久之后就会遇到类似的问题……当然 op 已经有一个 offer 确实是很不错的条件。也有点好奇 op 是怎么拿到国内的机会的，还有 op 对欧洲的就业环境方面的理解，方便交流一下嘛。

我的选择大概是留在欧洲，大概基于这么几个考虑：

- 国内卷得实在太不像话了，Master degree 基本上没什么价值吧，在普遍内卷的情况下国外文凭反而可能是负分（例如思想自由散漫没有奉献精神什么的？）
- 因为众所周知的原因国内就业市场也很不景气，而且短期内看不到好转的趋势
- 我是想一边工作积累经验一边往理论和 Language Design 或者 Compiler 方面转的，在国内非常 pragmatic 的大环境下看不到有这方面的可能性，反倒是欧洲（巴黎、捷克或者英国等）在这方面的环境是不错的

不过留欧洲的话，感觉最大的问题大概是……欧洲的外包公司太多了。

一方面因为认识的人有不少去了外包做实习，另外一方面也有泡不同的社区和论坛看大家的评论反馈，然后整体上的感觉，大概比 ICC 好些但是估计是没什么让人向往的氛围的，对我想要去实现的目标也没有任何帮助。

op 提到的年包感觉也是个问题，因为我认识的人好像都是 3 字头的，我有问过有没有可能拿到 4 字头对方就不想回答了。5 字头我也不敢保证巴黎的公司能不能提供给刚入职的新人，大概率是不可能的。所以我也在考虑有没有可能去别的国家，可能签证也有难点吧……不过我觉得最难的还是找到一个愿意收人的好公司。

毕竟随便去个求职网站清一色的「 Digital Transformer Consulting 」的东西……不想吐槽了。

读博我觉得并不是一个多好的选择吧，毕竟欧洲并不是说像美国那样读了博才能保证拿签证，学校补贴很少，3 年的时间成本感觉比起直接工作慢慢积累经验来说没什么优势。
话说之前也有在学校实验室做过实习，然后的感悟就是，没什么特别的天赋和从小就有的学术背景，中规中矩地顺着本硕的路线读下来的话，在我想要做的那个领域基本上很难直接上手研究界的课题。所以我的想法大概是慢慢往那边靠然后看有没有机会在工业界获得一些经验再回过去读博了。

当然 op 做的方向是偏工程应用的，大概也不太一样，不过我觉得 op 可以想一下比如说三五年后的路线，是回国还是在德国比较有优势，然后如果说不想一直呆在大厂想有机会跳出来自己做的话，哪边更容易积累比较有用的人际关系和工作经验呢。

当然如果实在找不到理想的工作我是大概会考虑回国的，只是这个与其说是选择倒不如说是摆烂。

This person has a good problem solving mind and he can use modern information aggregating toolsets to resolve a certain problem.

符合对某站技术氛围的印象

@Mexion 同好奇+1 ，后台管理这种东西应该不需要多复杂的逻辑吧，如果说涉及到鉴权、权限管理和接入 api 的事情，一来这个库完全没提到所以应该是没有，二来我觉得敢用这个库做敏感数据处理的人心是真的大。。。

手写还是 OJ 还是指定机器？
光看描述感觉没什么难的……？看起来都是很基础的算法题。一道题 50 分钟，很宽裕了。当然也要看数据集怎么样，如果是类似 ACM 那种数据集的话估计还是有点压力。

期待基于乌俄战争的战略策略类游戏，类似 P 社的那种……毕竟感觉这场战争里面有很多经典时刻。

node_modules 这种巨量小文件的删除了应该是大概率会触发重建索引的吧。

感觉除了个别情况一般也是用包管理器来处理而不是直接删改 node_modules 里面的内容