本来看到和培训班相关，不太想评论，因为培训班出来的有特定的就业目标。但是看在最后一句话的“热爱”的份上简单说一下：

1 、如果你从天赋和能力上特别能卷，我不排除你会进大厂，拿 50w 年薪甚至更高（我真的不懂现在到底是能到多高），甚至将来进管理层，甚至创业成功。
2 、但是在这一切之前，你的简历反映出来“基础不牢，地动山摇”：基本上是调包侠，没有证明你有独立开发项目的能力，难以独当一面。“热爱”这两个字眼来的太轻易、太年轻，too young too simple ，sometime naive 。

如果你的目标就是去做廉价外包，做一点 CRUD ，做一点管理系统的业务治理之类的，那你技术上已经够了。无非是缺乏经验，或者现在就业环境要求你们卷起来而已。我不懂现在的就业环境，也不想被人抬杠，所以不评论。但是人都有年轻的时候，将来你热爱的东西会更加具体。这里就从你当下的简历和知识储备进行我自己的解读。

1 、用 redis 减轻数据库 90%的访问压力，那只能说明你开发的项目是一个读远大于写的网站，不是么？那用 redis 减轻数据库压力和用默认缓存减轻压力有什么区别？那为什么一定要用 redis ？如果你能说出来个 123 ，为什么不往简历里面去写呢？是否说明你对于自己的知识储备缺少思考甚至没有知识储备？

2 、看设计模式，恕我直言，这直接反映了你没有现实的实践经验和开阔的视野：就培训班的就业目标而言，绝大多数项目是所谓的“敏捷”开发，维持设计模式的时间成本老板是不给报销的；如果你认真研究，就会发现多数设计模式是要应用于长期、持续开发的特定软件，而不是特定互联网服务的。前者的案例国内可能是某种财务软件，国际上可能是某些工业软件；后者的案例可能是拼多多促销。

但是你的技术储备明显和前者无关——我的意思是你当然可以学，但是这就好像明明是个杀猪的，非说自己在练屠龙技。也许你需要先找到自己的猪。

以上，在这个波云诡谲的年代里，祝好。

以前有个现象是地方到北京的各个单位去跑，什么单位呢？比如××委下面的××中心，××委把它们的文件拿来改一改签字，就成为了政策。地方上去跟人家签合同搞“调研”，让人家“出谋划策”。这种既当裁判员又给运动员替考的现象，我只能说是有可能存在的。


当然，自从某年拍蝇打虎（案例：XX 不经请示擅自改变出差行程）以后，“调研”就不方便了。但是这个生态位得弥补啊，怎么办？
北京呢，有个科技成果转化政策，而这些政策机构多数都是某种“科研院所”，那就把自己的政策工具转化为“大屏应用”嘛。你买了这个大屏应用就可以签合同，而且还可以要求定制化服务。

这事儿很合理，一点毛病都挑不出来。

内啥……弱弱的给自己的项目打个广告，四月可能有重要更新：gradual typing 。
https://github.com/ufo5260987423/scheme-langserver

@charlie21 #27
1 、你跑题了；
2 、你对于函数式编程的理解我持保留意见。

@InkStone #24
我提一点，不是从历史沿革开始写，而是抓住最根本的问题，从工程直觉开始写。这就有几点要抓住：

1 、问题随时间演变，所以解决的方法也要变——但是工程直觉，所谓面多了加水水多了加面必须要写清楚，这样读者才能意识到，在直觉背后，自己缺少什么知识。

2 、工程直觉不能直接解决的问题，更多的呈现为某种技巧。不能假设读者自我发明这些技巧，而是要假设读者如何通过其他领域的工程直觉层层累积最后捅破窗户纸——这就要在叙述上有重点地去叙述。

3 、叙述上的重点包括应用场景、案例、以及思考过程的三个约束：逻辑链条长度，知识积累，和语言技巧。这里就响应了您关于“比喻”、“实践”和“细节”的问题。

以上三点的关系在于要把直觉放到第一位，能把握住更多的直觉，就能够降低后面特别是第三点的难度。

@yuruizhe #17 它们不是偏理论，它们只是没涉及工程直觉。
或者这么说吧，它们的关注点是帮你补充知识的漏洞，是告诉你怎么做，而不是告诉你为什么这样做。笑。
这是这类文章必然采取的形式，但是不是一种直接作用于工程上的好的形式。而我想要讨论的是后一种。

用了十年 ubuntu （ from2012 ）
工作环境其实用 wps for linux 够了；打游戏 steam 上的游戏大多数都够了。
很多人讲 windows 不可替代，在某些税务和办公系统的确是这样的，但是越来越少。
唯一给你一个建议就是，ubuntu 不要用最新的 LTS 版本，要用上一代的。折腾起来文档比较多。

@mumuy #67 哈哈那应该用一堆小种语言来写项目

@andyJado #22 一个文件有几万行……用 vscode 打开都没法语法渲染了吧……
1 、我现在是按照文件更新的；
2 、如果一个文件几万行，且 10 个函数，那一个函数平均几千行代码，笑。
3 、我不能确定你的修改是否只对函数内部的语义有影响，如果你确定的话，把更新索引的粒度下降到函数也是可以的。

笑，你的困难我都遇到过，还是前置知识缺课的缘故。
以及，如果你以后想要进一步研究 static analysis 的工程实现，可以 github 看我的 scheme-langserver ，master 分支前天刚推了 deductive inference system 上去。笑

@BrodyYoung #64
计算机领域很庞大，具体学习哪个方向你要自己找，找的时候遵循几个原则：
1 、兴趣为王而不是挣钱为王——大家都想挣钱，但是能让你挣到钱的是你的独特的价值。尊重你自己的兴趣，在长达十年的时间里面不要放弃，一直投入，总能有一点起色的。
2 、多看看别人的好的项目，你看的多了，自然就知道什么好什么不好。
3 、国内的开源很多是产业和资本为王，但是当下的裁员潮已经证明了他们的道路走不通。回归程序员自身的需求，回归人民的需求是很重要的一个出路。具体怎么做，自己去想，不想和瞎想都是死路、邪路。

我自己现在注重的领域是计算机语言学（区别于计算语言学 computational lingua ，英文好像是 Computer programming language ？），这个领域在国内据说只有清华和南大有专业方向，一方面说明就业市场小，另一方面也说明门槛高。但是我自己觉得里面的知识工业化应用其实也就那样，挺简单的。2010 年的很多博士论文其实很简单，现在我们仍然可以追踪发展进度，并且把一些东西产业化。而且，产业应用中的一些东西在学术界思考的比较少，还有很多可以突破的方向。

我自己曾经研究的领域是 NLP ，emmm 也就是几篇论文而已，可以灌水养活自己了反正。
------
计算机语言学的话，可以送你几个思考的方向：
1 、如何用逻辑编程减少 bug ，这方面可以从 miniKanren 那边学习一点歪招。如果能通过比较麻烦的编程，减少 bug 和 debug 的精力，对于很多领域是有用的。比如汽车和飞机，总不能一边飞行一遍 debug （笑）。
2 、一些 api 系统的 request 之间是有语义关系的，比如必须先执行某个 api 再执行另一个，这是一个 DSL 的系统。也可以做一点小小的工作。

@dnsjia #62 给大佬点赞。

@BrodyYoung #60 囧，你这个 github 表演痕迹太重。
给你几个关键词，楼上请自己翻一下：
1 、没 fork ；
2 、弄了一堆 spring ，netty 之类的东西，点开一看，就一个 initial commit 或者“整理代码后提交”——这™有 50 多个 star ？可见你项目的 star 的质量就比较低。
对于一些经历和我类似的面试官而言，repo 来自 v 站的浏览量与 github star 的转化率大概是不到千分之一。你的项目可能有一千人访问过么？我觉得不可能；
3 、你的 readme 完全没有一个对大家开放的思维，连简介都称不上。没有开放的思维，很多情况下就是肚子里没有东西。
4 、我看到了很浓重的培训班痕迹，这是我的臆测，也许你只是参考培训班建立了自己的知识体系。但是对于搞开源的人来说，我们恰恰最不需要的就是那种体系。

我这话说的比较重，因为我也做后端（但是我不用后端程序员定义自己）。从我的角度看：表演式开源要不得。笑。

@dayeye2006199 #58 2333 你这样说，我老脸一红。

@moonrailgun #55 向巨佬致敬。您的项目完成度很高，您关于“通过解决开源项目遇到的问题，这种解决问题的思维我想才是真正的加分项”我完全赞同。
实际上简历上所有的东西都应该有这样的倾向：怎么解决困难，关键点。而不是罗列项目经验。但是很多时候我看别人的简历，都没有这个意识，奇奇怪怪。

@SonnyBoi #51 你这样的话其实等于……没有对你 folk 的代码做出贡献，明白我意思吧？
就是你用了人家代码，但是你的修改不是在人家的代码基础上，这其实是一个单向获取过程。这个过程我无意评价。
不过你做论文用到人家代码，如果论文能公开并且标明用了哪些代码的话，其实我觉得简历效果会更好。

@boris1993Jr #49 感谢你的回答。果然我还不是自宅警备队一员，完全不懂什么 A 岛 2333

@mumuy #35 仔细一看你这太大佬了，66666 ！
你们前端 star 太多了，我们这个小门小户的领域也就是搞搞 Program language 的解析啥的，不能和你们比。

@lyhiving #39 怼的漂亮 23333 ，强势插眼等待更新。