youzilong0 2020-06-09
分享给大家。注意,我们讨论的是走技术路线。
第1点是关于大公司、小公司的。
不要选择小微的创业公司,原因如下:
极不稳定,一年半载就死掉的占大多数,会导致你需要频繁换工作,而年龄会越来越大,找工作越来越难。
多数小微创业公司,目的是生存,偏向应用类产品,希望程序员能抗压、加班、一人多用、快速出活,它们不喜欢大龄程序员(除非你是技术带头人),因为你10年经验和3年经验,在这里干的事情差不多。
优先选择中型、大型公司,或者已有行业内优秀产品的小公司。在这些公司里,因为业务或服务发展的需要,因为构建竞争壁垒的需要,因为提升生产率的需要,因为降低运维成本的需要,概率上讲,会对技术更为重视。
第2点,分析公司是否重视技术。
即便选择中大型公司或有好产品的小公司,也要看看在这些公司里,技术部门的重要性,即要确认,公司是技术导向、市场导向还是运营导向。
选择的顺序是:技术导向、运营导向、市场导向。
因为在一家公司,技术越被重视,技术人员的知识、技能、经验等方面的积累也越被重视,也越能认可大龄程序员。
第3点,观察目标公司的年龄分布。
我们不能光听公司说自己欢迎大龄程序员,要看它现有技术团队成员的年龄分布。
欢迎大龄程序员的团队,里面一定有若干大龄程序员。
不欢迎大龄程序员的团队,除了负责人,基本都是小鲜肉。
选择那些团队中有大龄程序员的团队,可能更靠谱。当然,如果你是某方面的技术专家,可以忽略这条。
想要在技术之路上走得久远,有两点非常关键:
在某个细分技术方向上精研,建立标签,让团队内提到某个方向就想到你,提到你就想到某个技术方向,有问题都来咨询你。这样你就能凸显出来,影响力和重要性会增大。
如果足够有心,还可以培养提升更多维度的能力,如下图所示:
想要在技术之路上走得更久,要选择重视技术、认可大龄的、有稳定业务的中大型公司或有优秀产品的小公司,同时要在公司范围内树立技术标签,还要构建技术+业务等多维度竞争力。
阅读源码
程序员每天都和代码打交道。经过数年的基础教育和职业培训,大部分程序员都会「写」代码,或者至少会抄代码和改代码。但是,会读代码的并不在多数,会读代码又真正读懂一些大项目的源码的,少之又少。这也造成了很多错误看源码的方式。
那要如何正确的分析源码呢?
分布式架构
随着我们的业务量越来越大和越重要,单体的架构模式已经无法对应大规模的应用场景,而且系统中决不能存在单点故障导致整体不可用,所以只有垂直或是水平拆分业务系统,使其形成一个分布式的架构,利用分布式架构来冗余系统消除单点的故障,从而提高整个系统的可用性。同时分布式系统的模块重用度更高,速度更快,扩展性更高是大型的项目必不可少的环节。
微服务
关于微服务架构的取舍
1、在合适的项目,合适的团队,采用微服务架构收益会大于成本。
2、微服务架构有很多吸引人的地方,但在拥抱微服务之前,也需要认清它所带来的挑战。
3、需要避免为了“微服务”而“微服务”。
4、微服务架构引入策略?–?对传统企业而言,开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用,逐步探索及积累微服务架构经验,而非全盘实施微服务架构。
性能优化
我们不仅仅对项目要运筹帷幄,还要能解决一切性能问题。只有深入学习JVM底层原理,Mysql底层优化以及Tomcat调优,才能达到知其然,知其所以然的效果。除了性能优化之外,也能提供通用的常见思路以及方案选型的考虑点,帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。
并发编程
主要培养编程者深入了解最底层的运作原理,加强编程者逻辑思维,这样才能写出高效、安全、可靠的多线程并发程序。
团队协作开发
通过一小段描述信息来管理项目的构建,报告和文档的软件项目管理工具。用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。 可以有效、高速的处理从很小到非常大的项目版本管理
项目实战
要想立足于互联网公司,且能在互联网浪潮中不被淹没,对于项目的开发实战演练是不必可少的技能,也是对自身能力的一个衡量,有多少的量对等于获得多少的回报。看似简单的一个项目需求图谱,其中的底层原理,实现原理又能知道多少?
当你掌握上述我说的知识点时,相信你对于自己未来也已经做好了准备,那么就不要犹豫向前迈步走吧,不要浪费自己宝贵的时间。当你在犹豫的时候,别人已经迈步向前,那么差距也就会越来越大。
欢迎大家关注我新开通的公众号【风平浪静如码】,海量Java相关文章,学习资料都会在里面更新,整理的资料也会放在里面。
觉得写的还不错的就点个赞,加个关注呗!点关注,不迷路,持续更新!!!