1

闲言碎语——第一期

 3 years ago
source link: https://blog.csdn.net/eclipsexys/article/details/115327627
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
闲言碎语——第一期_eclipse_xu-CSDN博客

最近看书学习工作,有一些心得体会,点点滴滴,闲言碎语。

最近面试了很多人,但是基本上都没招到什么满意的人,是Android开发都凉了吗,其实并不是,从简历的数量上来看,金三银四的简历还是很多的,首先我们从简历上来说,面试官都希望看见什么样的简历呢?

大部分的简历,都是罗列自己的公司经历、项目经历,介绍了项目大概的情况,好一点的,罗列下项目的技术方案。

要知道,对于面试官来说,简历是很重要的一环,这是对你的第一印象评价,很大程度上决定了你的面试成败。我在面试的时候,简历发给我之后,通常会看一眼面试者的项目经历,从而决定了我的面试问题。所以,项目经历上只需要写下面几个方面:

  • 项目一句话简介,说明项目的大体情况和规模

  • 核心技术方案,介绍用到的核心技术、核心技术方案

  • 你在项目中承担的角色以及贡献等

实际上有了这些东西,我基本上可以了解你的这个项目大概是个什么规模,需要用到哪些技术点,以及你应该有的能力范围,下面我就会根据你的这些项目经历来对你提问,由浅入深,可能先问你大概的技术方案,是否有更佳方案或者现在的方案是否有什么问题等,再深入问问技术的细节,看你的技术深度和广度。

除了项目经历,你的简历上只应该出现你的亮点,切记各种废话,什么精通Java,精通设计模式、数据结构,这些根本不能体现你的特点,这些东西应该结合业务或者架构,例如利用设计模式改进了技术方案的流程,通过数据结构优化了程序的执行效率。

另外补充一点,好的开源项目、博客等等,这些都是比较好的加分项目,但是...如果你的开源项目连readme都没,你的博客全是流水账,那就不要贴了,反而容易减分。

面试实际上是一个双向的过程,所以,一场好的面试,绝不是面试官单方面的发问,面试者应该引导面试官,把面试当作是一场技术讨论,一来一回,双方都能了解对方的技术实力,我相信,这样双方都会对这次面试满意,通过面试也就是自然而然的了。

说完公司的面试,再说一下经常有读者私信我的一个问题,那就是A公司、B公司,我到底该选哪个公司,首先我要确认下你是不是来炫耀的。

对于这个问题,其实也是有一个个人看法的,这个看法是我的主观臆断,可能很多人也不会这样想,这里写出来,大家轻喷。

首先,如果你是刚毕业的学生,我会建议你去小公司、创业公司,但是,是技术型偏向的公司,绝不是外包或者某个公司的IT部,为啥呢,原因很简单,刚毕业这几年,是你飞速成长的几年,也是你选择方向的几年,在这些技术型小公司、小团队里,你可以非常快速的上手各种技术,没有任何外部压力,团队小,大家通讯基本靠吼,不需要走流程、发邮件、约评审,这是大公司的通病——决策链太长,同时,你对自己的技术定位,在一段时间后,也会更加清晰。

在这之后,除非有一夜暴富的机会,就不应该在继续在小公司待下去了,这时候,一定要去大公司进行历练。大公司去干什么呢?其实很多大公司的技术并不很先进,代码很可能也很烂,但是你去大公司,就好像游击队变成了正规军,你要学的是规范和流程,小公司的这几年,让你的技术突飞猛进,但是却不成章法,大公司就是让你来沉淀技术的(这句话要屏蔽老板),大公司经营多年,技术方案早已成型,很多开发者进去也是拧螺丝,但是,你需要的是了解各个系统、各个平台的流程、优劣,做到心中有术,而不是心中有码,如果你是一个可造之材,那么经过这样两轮历练,我相信你应该是一个很不错的开发者了。

通过Flutter Dojo这个开源项目,我建了3个Flutter修仙群,里面有很多都是Flutter的初学者,经常会有人在群里提问如何学习Flutter,所以针对如何高效学习这件事,也有一些想法。

首先,学习这件事情,就是一个认知的过程,既然是一个认知的过程,那就不能以管窥豹,而需要站在一个全局的思想上来看,例如在学习Flutter的时候,没有必要精通所有的Widget,掌握常见的Widget之后,就应该去思考Flutter的绘制流程、刷新流程,了解这些,才能让你在全局角度上掌握Flutter的渲染过程,这比你掌握几个Widget更加有用。

更加通用的,我们平时应该尽可能的拓宽自己的知识广度,这样才能让你的眼界更加宽广,就拿Flutter来说,总有一些敏感词喷Flutter,Flutter能不能火我不知道,能不能推广我也不知道,但是我依然学了Flutter,而且还建了3个群,这是为啥?因为通过Flutter我学习到了一种新的跨平台思想,一种区别于现有的命令式编程的编程范式,一种全新的改进渲染流程的方法,掌握这些,我觉得比单纯的讨论阿里是不是不再用Flutter了更加有用。

学习,永远是一个认知碾压的过程,不断接触新思想、新技术,才能让自己有更加敏锐的认知洞察力,就好像学了Flutter,你会发现Compose好像也是一样啊,SwiftUI好像也是啊,从更高的眼界上去看这些东西,其实本质上,都是一种思想,现在的社会早已不存在信息孤岛,学会将信息链接起来,才是高效的认知方法。

井底之蛙永远跳不出去井,也永远别用阿里是不是还用Flutter这样的事来限制你的认知,就好像三体人用质子封锁了地球的科技进步,可悲。

怎样才算是一个优秀的程序员

有一次跟朋友讨论到这个问题,朋友很羡慕那些做算法的程序员,觉得那些才算真的程序员,其实不然,计算机科学一直都包含两种优秀的程序员,一种是研究计算机理论的程序员,研究算法,研究理论,他们尽自己所能拓展技术的深度,而另一种,是研究计算机系统的程序员,研究的是如何将这些计算机理论赋予实际的应用目的,这两者的极致者,都是优秀的程序员。

对于我们大部分的应用开发者来说,很少有能够实现对计算机理论的拓展,更多的时候,我们是研究如何利用某个技术来完成一些更好的任务。包括我自己也是,不能说这样的开发者就是「画图仔」、「API搬运工」,研究计算机系统的开发者,也是可以成为很优秀的开发者的。

一个做计算机系统的开发者,一定要学会在架构时「见风使舵」,做系统不比研究理论,所有问题必须完全吃透,从来没有一个人说,我做的系统是完美的,一个在有限时间内完成的项目,一定是有瑕疵的,而一个优秀的系统开发者、架构师,需要做的就是学会取舍,该简单的地方,就不要设计一堆抽象,该复杂的地方,就需要花大力气进行优化,编程只是解决问题的一种方法,但不是仅有的方式。

在大公司一定要吾日三省吾身,千万不能贪图安逸,一个技术用十年,你也只有一年工作经验。

永远不要上手就写代码。

这句话我们从小就听——不要上手就写作文,先想好提纲。编程也是如此,除非胸有成竹,否则绝不一码十行。

当我们拿到一个需求进行开发的时候,一定要先在大脑中推敲推敲,这个需求的每个方面是否都是完备的,是否有异常流程,这个需求的每个技术点,是否能够胜任这个需求,这个需求的流程,我是否完全都清楚了,这些东西都想不好,那就不是在编程,而是在「拉屎」,而且你拉的这些shit,很可能会把后面的开发者「淹没」,造成一场信任危机。

所以,写一个好代码的时间一定比烂代码花的时间更少。

不过,面对日益压榨严重的资本家们,可能经常不太会给够一个好代码的开发时间,这个时候,就需要对代码进行取舍了,或是找轮子,或是改轮子,总之,要把精力花在刀刃上,一个最佳的原则——make it work, make it right, make it fast,我认为,这是一个代码最佳的生命周期。

对产品的所有需求来者不拒,绝不是一个好的技术经理该做的事。

技术经理需要对技术风险进行合理的管控,技术经理需要在产品和技术之间,建立起完整的信任关系,全盘接受产品的各种需求,长期以往,总会产生风险,而一次风险,就很有可能让你多年建立的信任轰然倒地,所以,学会风险管控,才能让技术经理为开发者建立一个可信任可依赖的高大形象。

不战而屈人之兵,不码而完成需求。

技术经理的另一个重要职责,就是经营自己的工程师文化。

工程师文化并不是说有「工程师」,有「文化」就可以了,它是一种团队内的精神。我举几个简单的例子来说说看我认为的工程师文化。

  • 工具化:能用工具解决的,绝不使用人来解决,人是最不可靠的动物

  • 框架化:或者叫平台化,将一系列的问题的解决形成框架,搭建平台,从而让更多的人拓展,这才是良性循环

  • 重构:make it work, make it right, make it fast

  • 技术氛围:团队内部要有探索新技术的Sense,而不是整天炒冷饭

第一期先写到这里,后面再补充新的思考。

向大家推荐下我的网站 https://xuyisheng.top/  点击原文一键直达

专注 Android-Kotlin-Flutter 欢迎大家访问


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK