@xiaoshenke 你说的没错，到了具体业务上的话，这就很现实了。

@asdfjklsc 我的方法是横向扩展，比如我一直做企业应用，最早是简单的架构后面引入了 DDD，接着在产品的完善阶段，我引入了 REDIS , MQ , SOCKET.IO 等第三方技术产品，每次引入的新的东西，都是一个学习和技术积累的过程。
不过这种方法，前提你公司或者技术主管允许你这么多，不然只能自己做刚兴趣方向的开源项目，在这些项目上去获取技术上积累。

针对某些人群，能动手的，尽量少说话，说多了，反而让对方觉得理所当然了~

跟你会什么语言关系不大，主要还是看技术积累。
技术不等于语言，这是我一直认为的，可总有人喜欢把技术跟语言混在一起，就这么杠上了。

被拒如果不是技术积累不够，很有可能是面试时候自我营销不当，导致用人单位错失你了。

工作不好找，换个途径看下，自己找永远没有别人推荐的那么容易被接受.

广度有了，深度还没有
所以静下心，来个深度探索，拒绝没有方向性的广度。

优先考虑在本职范围内创业吧，会考虑做些小众，垂直类的产品
如果真不干了，跟人合伙开家餐馆是个首选。

以前在班时候基本都是五点半就下班了，所以回家后写代码是常事。
像 LZ 这种情况，换成自己的话，肯定不想写，随便娱乐下估计都是快到十一二点的，哪里还有那个精力写代码，除非有自己的项目或者业务要维护

ERP 类企业应用准确说是基于流程和业务规则引擎驱动的。长的像不代表是哦。

好歹你还能在 github 上找到合适的代码，有抄的机会，估计还有不少人还不知道往哪里抄呢，(￣▽￣)

话说回来，程序员大军中“普通人”还是占了大多数的，咋不能怀疑自己，在程序方面也总有个点是你所擅长，别人“抄”你的点的

我想楼主想了解的就是怎么整合使用这些第三方组件，因为在很多时候，很多人能熟练单独使用却没办法完美的将这些第三方组件整合到一起，构建一个高可服用，高性能的系统！

我觉得最好的方法还是先从单个组件开始，先吃透了单个组件，了解它们要解决的核心问题和主要的应用场景。

然后在了解组件间的“合作”工作能解决那些问题，比如 redis+mysql，MQ+redis ,再比如 MQ+REDIS+celery ,等它们质检合作的能解决的核心问题了解了，接下来就可以尝试设想和构建一个自己梦想中的系统了

相信第一次尝试构建系统，总是不完美的

知道的都混的不会太差，集中四线城市及县城。看进什么单位，入什么岗吧。

人际关系也不会太复杂的，必要“社交”是需要的，其他的跟做程序员没太大的区别，就是别太认理，固执就好了

用那个很大程度都是技术主管说的，所以跟技术栈新旧没太大的关系，如果能推行 git 当然是好的

要摆脱干嘛？
我讨厌的是现在几个大厂做的产品，几乎都涵盖生活中的很多领域了，让我们这些没有背景的团开发出来的产品，想获取用户太难了 ╮(╯▽╰)╭

正如正文开头说的，大家都习惯了一个 APP 能解决所有问题就容不下第二个 APP

某度*总说过“中国用户愿用隐私换便利” ，虽然不爱听，但说的是实话，可惜大多数人不承认。

slim, 不过自己在这个基础上做了扩展，可以考虑下~

我有着一份相对自由的工作，却跟你有着同样的生活现状，做出改变需要很大的勇气, 不知道什么时候才能迈过自己这个槛

想的有点多了，在未来不明朗，感觉没前途情况还是把手上的工作做好才是最主要的，没准那天你的新生活就是从你这些努力的项目中开始的。

实在做不下去就就尝试开辟一块新的领土吗

后端不了解 SQL 优化技术，我能理解，不会 sql 有点说不过去了，除非是专岗，大多数没有配备数据库岗的公司，基本后端兼职 DB。 就算只用 ORM 的后端也不敢说自己不会 sql~

不过时代变了，现在编程不如过去了，以前是实打实的，现在基本是面向“搜索”，面向''QA ‘社区的编程了