你是软件工程师还是代码民工

最近项目组要招人,领导让我负责面试。面了几十个人,在此谈谈在面试并且结合自己工作过程中的一些体会。

编程应该以兴趣为驱动

编程本身就是一件非常简单的事情,我们每天吃饭,走路,睡觉…编程的工作无非是把这些日常的事情’翻译’成计算机能读懂的语言。由于近几年IT培训行业的迅速发展以及一些夸张的书籍《7天精通XX开发》,这在一定程度上更加充斥这大众的视听:学编程原来如此简单,是不是去报个培训班出来就也可以拿高薪了?笔者曾经遇到过做微商并当了妈妈的朋友咨询我转行学编程的相关经验,我顿时感觉很紧张,又多了一个抢饭碗的人。即便如此,我告诉她编程这碗饭不太容易吃。首先,IT行业各种技术更新速度很快,项目中要用到越来越多的新技术,无论是在目前所在的团队还是出去应聘,程序员需要保持不断学习的激情才能跟上项目的步伐。其次,IT行业竞争很激烈,每年一大批大学应届毕业生涌向社会。人的年龄在增长,扮演的社会角色在增多,生活的成本在增加,对收入的要求也越高。但如果自己的技能不随着工作年限的增加而提升的话,做同样的事情,企业为什么不选择更年轻更有激情,性价比更高的小鲜肉呢?而且搞技术本身就是一个不断遇到问题,不断解决问题的过程。如果没有很强的兴趣驱动,即使开始入门了,但后面工作只会越来越觉得力不从心,渐渐的跟不上团队的节奏。笔者认识的优秀的程序员,他们对技术总是充满激情,孜孜不倦的研究,乐于分享。从早期混社区,到自己做开源,不断的帮别人解决问题,一边不断的驱动着自己去成长。

扎实的理论基础

在招聘面试的过程中,笔者遇到不少工作了四五年的程序员,跟他聊业务问题的时候说的滔滔不绝,可一聊到实现原理就摇头说不是很了解,知其然不知其所以然。笔者是个很注重基础的人,在我的认知里面,学习一个知识应该由浅入深,就像画素描,先画基本轮廓,再精雕细琢五官等其他细节。而且学习一项新技术的时候,要系统的去学习,不断的去丰富自己的知识体系,而不是单单依靠看了几篇公众号博文,就觉得自己已经掌握了。以开发一个即时聊天应用为例,如果缺乏这方面的经验,大多程序员会去github或者csdn去找别人实现的案例,通过修改化为己用。如果喜欢钻研技术的程序员,会看别人实现过程,会思考别人为什么要这样实现,然后去学习网络编程相关知识,学习tcp/ip协议族,scoket编程,如何收发数据包。如果是理论基础很扎实的程序员,即使是之前没做过这些,也可以结合自己所掌握的知识,按照自己的理解去设计实现出来。没有系统的计算机基础知识,遇到问题虽然通过百度复制黏贴代码解决问题,项目出问题往往不知所措。笔者就遇到过复制代码没动脑子的程序员,把别人代码的bug都复制过来了不知道,一个方法直接把别人的代码复制过来改个名。

追求极致的工作态度

笔者刚毕业那会儿做项目,由于只有一两个人开发,项目又赶,当时没有好好规划,心里想着“先实现了再说,等有时间了再好好优化”。实际上,越往后自己源源不断的有更多新的事情要做依然懒得改。到了真的要优化的时候,用户和数据量都上来了,老的代码又跑的比较稳定,想优化重构的话要冒很大的风险。所以项目前期规划,还有写代码的过程中追求极致的态度显得尤为重要。

稳定性

作为程序员,代码上线之后稳定不出bug是最基本前提,也是后面进一步工作的保障。如果项目时不时的挂掉,时不时出bug,身边的同事也会怀疑你的能力。优秀的程序员,在代码上线前后会想办法去保证自己代码的稳定性。比如上线之前单元测试,功能性测试,各种边界测试等完整的测试流程;上线之后,增加不同的报错级别的日志监控等。

复用性

高质量的代码讲究“高内聚,低耦合”。‘高内聚’的意思是代码复用率高,不写冗余的代码。‘低耦合’则要求各个不同业务之间要彼此独立,减少相互依赖。优秀的程序员看到冗余的代码会想着把它封装成公共的方法和模块去调用,这样就可以少做很多重复性的工作。而笔者接触过另外一群‘程序员’,则只会复制黏贴代码,有时候甚至都不明白别人为何要这么写也复制过来,反正测功能的时候正常就行了,两个方法相似度竟然高达90%以上,一个方法里洋洋洒洒写了几百行代码。在此笔者强烈推荐,在写类方法的时候,如果一个方法里面的代码超过100行,就要考虑一下优化封装。如果有两处以上的同样的代码,也要考虑封装成新的方法。

可扩展性

代码的可扩展性分为“横向扩展”和“纵向扩展”。所谓“横向扩展”是指当项目的业务数据量上来之后,可以通过加机器等可以实现分布式;“纵向扩展”是在同一个项目中增加新功能新模块,修改各个模块的代码不影响其他模块。以笔者早期做项目踩过的坑为例,最开始接到的需求,要做一个推广系统,当时的文档只有几句话,大概意思是“照着xx实现类似的功能”。当时笔者也缺乏经验,没考虑后期发展,市场的同事也没跟我说后期的规划。所以我设计了一个单库,单平台的系统。过了一段时间,业务发展的不错,要到其他新地区开拓新市场了,但新地区的功能,要求等跟原来的不一样。于是改,把项目由原来的但平台改成支撑多平台,把不同平台之间公共的部分业务代码做封装,各个子业务去继承。为了实现不同的业务模块之间解耦,进一步对项目实现代码分层,由原来的“控制器-逻辑-模型” 三层架构变成 “控制器-逻辑-服务-模型” 四层架构,这是笔者比较推崇的代码架构。再往后,数据不断增长,单库单表数据量越来越大,于是必须考虑分库分表。项目一旦上线并且稳定之后,再想去重构优化代码风险是非常大的。优秀的程序员从一开始做项目就会考虑这些,而“代码民工”则只会不断的堆功能,代码越来越多,项目越来月庞大,后期一旦想加个新功能,改几十个文件,周而复始不断做重复性工作。

统一的编码规范

一个项目在早期的时候,可能是一两个人在开发,所以写代码的时候通常是怎么爽怎么来。到后期,团队不断扩大,不断的有新人加入进来,如果一开始缺少统一的规范,在一份代码里,不同的人写的代码风格迥异。举个例子:有个新入职的同事接收别人的项目,开代码的时候看到一个函数命名“KFC”,他看了半天没明白“这个KFC”到底是干嘛的。有的人写if判断的时候,{ 喜欢换行,有的人喜欢写在同一行,但在看代码的时候,一会儿这样一会儿那样,阅读代码的人看起来确实非常奇怪。除了代码阅读性,如果哪天项目出问题,需要通过全局搜索去排查问题,比如要搜索 run方法,有的人调的时候喜欢写“ run()”,有的人喜欢在方法名跟(之间加个空格 “run ()”,如果有统一规范,搜索的结果也会精确很多。

快速解决业务问题

那些“大神”之所以能获得别人的认可和尊敬,身边人最直观的感知是他快速解决问题的能力。相信很多人都听说过阿里扫地僧“多隆”,神一般的存在,别人一个团队花一个月做的事情,他一个人花一周就搞定了。笔者身边也有很多这样的朋友,做事效率很高,他们很喜欢开发一些工具来帮助整个团队提高生产效率,比如单元测试,项目一键部署,性能分析,一键生成开发文档等等。项目遇到问题的时候,他们有很多调试,快速定位问题的技巧,如不同级别的日志和监控监控报警等。这些东西是需要经过遇到问题不断思考总结出来的。

 

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注