「轻阅读」怎样才算得上合格的程序员?

时光斑驳了记忆 2019-05-29 13:32:46 ⋅ 731 阅读

本文版权归作者xybaby(博文地址:http://www.cnblogs.com/xybaby/)所有,欢迎转载和商用,请在文章页面明显位置给出原文链接并保留此段声明,否则保留追究法律责任的权利,其他事项,可留言咨询。

最近同一部门另一个项目组的一位程序员被“主动离职”了,虽然我未曾与这个程序员共事过,但是听过一两次他的内部分享,感觉技术还是挺厉害的。后来与一个消息灵通的同事聊天,才知道真正的原因是老大觉得A难以沟通,搞得其他程序、QA都怨声载道。工作这些年,身边的好多同事来了又走了,主动或被动,这不禁让我思考什么样的程序员算得上合格的程序员。

虽然大家都自称“码农”、“IT民工”,但我相信,这仅仅是自嘲或者自黑,大多数程序员应该还是认可自己的这个职业的,当然,我算不上一个优秀的程序员,因为我都不曾在开源社区贡献过代码、也不精通白板算法、对技术也不狂热、不geek。我的目标是做一个合格的程序员:把本职工作做好,对得起自己的薪水,在生活与工作平衡,996什么的我是难以接受的。

本文地址:http://www.cnblogs.com/xybaby/p/7531620.html

对于程序员而言,技术过关当然是非常重要的,这是硬实力。然而只会技术也是不行的,毕竟大多数的程序员还是要与人打交道,软实力也是不可或缺的。怎样才能算合格,我认为有以下几点:


扎实的基础

计算机领域是一个快速更新换代的领域,每隔一段时间都会有新的语言、框架、思想产生,追随每一个新技术很累。但仔细想想,事实上并没有那么多新东西。很多新东西只不过是已有技术的封装、或者借鉴的其他领域的技术。比如缓存数据库redis、memcached,其基本思想不就是操作系统中的缓存吗;分布式存储中的分片与复制集,不就是文件系统中RAID的扩展吗;还有Google的MapReduce框架,不就是来源于函数式编程语言的map reduce吗。掌握好计算机基础知识,能够更本质的看待新技术。

善用工具

磨刀不误砍柴工,打造好自己的工具集非常重要。

开发中会用到大量的工具,不管是编辑器、调试工具还是监控工具。大家都喜欢争论哪个IDE更好,然而这并没有多大意义,关键在于能够熟练的使用自己喜欢的工具,掌握各种快捷键,高度自定义,这样能够大大提高工作效率。而且对于日常中重复的操作,最好脚本自动化,这里推荐以下python,写小工具还是很快的。

另外,强调程序员必备的两个工具,那就是浏览器和VPN。后者大家都懂的,不多说,主要是有了后者才能发挥浏览器的威力。浏览器大家天天都在用,但是如何高效的使用,比如在指定网站搜索、通过标题、url过滤、选择合适的关键字 还是值得研究一下,对于程序员,要使用好浏览器,那还得具备下一个能力:英语

过得去的英语

不得不承认,在软件创新领域,国内还是落后于国外的,新的技术、一手的资料都是英文的。当新技术被广泛应用之前,我们在百度搜到翻译要么是machine translated,要么错误百出。看翻译的最大问题取决于翻译者本身的水平,即使翻译水平都很高,但同一个单次往往有不同的翻译,导致看文章的时候会有困惑,最好还是直接看英文原文。大多数原文,除去专业词汇、还是比较好理解的,而且,我发现很多牛逼的项目,都有非常通俗易懂的文档。

良好的编码习惯

代码是写给机器执行的,同时也是给人阅读与维护的。维护者可能是别人、也可能是几个月后的样子。良好的代码规范,必要的、清晰的注释可以让自己少被问候祖宗十八代。

对于代码风格,网上争议也很多,最重要的是保持项目内的统一。做为技术负责人,一定要在项目开启之初就顶号规范,当大量代码被堆出来之后就很难统一了,然后做好新人的review。


保持学习

程序员这个职业,相比其他职业,可能还是要年轻许多。特别是在国内,最老的一批程序员好多都转管理了,再过10年20年,我们会怎么样呢,没人知道。前段时间华为35岁程序员被离职的事情,给我们敲响了警钟,悲哀之余,只有尽力学习了,拼不过体力就拼能力与经验吧

学习这个事情说起来就复杂了,我觉得两点很重要:基础、学以致用。

独立思考

合格的程序员解决的是问题,而不是实现某个解决方案。产品经理(特别是知道一点技术的产品经理)的某个需求可能只是某个问题的解决方案,他认为这个方法可以解决他的问题,于是把解决方案当成了需求,而不是真正的问题。程序员应该主动沟通,多问几个为什么,了解真正的问题,也许能有更好的解决方案。

之前就有这么个例子,给到的需求:为每一个用户(用户有唯一的id标示)生成一个唯一的邀请码,同时也要为未来一段时间可能增加的用户预生成邀请码,保存到数据库。而真正的需求是老用户分享自己的邀请码,如果新用户使用了该邀请码,则老用户获得相应奖励。而我提出的方案很简单,直接用户的唯一id生成可逆的邀请码,这样就根本无无需数据库存储。

产品经理经常改需求这是程序员最头疼的事情,作为程序员应该也站在PM的角度思考,帮助PM分析出本质的需求,这也许可以减少需求的变更。当然,前提是得干一行爱一行,需要对业务有一定的了解。

先思考后行动

写代码的时候先想清楚了再下笔,而不是先写出一堆代码,然后在开始修bug。

休bug的时候,多看看上下文,搞明白为什么出bug,修改这个bug可能带来的影响,然后再修改。反面教材有两种:第一种随便改改就把代码改好了,但自己心里并不清楚为什么这样修改就修好了,撞运气,也许还有其他同样的bug也发现不了。另一种就是,头痛医头脚痛医脚,不仔细评估修改的影响,这样往往会引入新的问题。

程序员成长的一个办法就是修bug,修别人用不了的bug,但前提是搞清楚bug的缘由,这样才能避免类似的错误,有所收获。

顺畅沟通

不是巧如舌簧、也不是忽悠达人。需要的只是耐心倾听,然后清晰表达自己的意见。

现在的软件开发,已经不再是单打独斗的年代,大多数的软件、产品都需要多人、多部门的协作。而交流、沟通是非常耗时耗力的。沟通之前,先想好目标,组织好语言,尽量不要发散、不要跑题,对事不对人。对于重要的事情,保留沟通记录,最好有邮件,免得说不清。

沟通是门复杂的艺术,最基本是听明白、说清楚。


管理好自己的暴脾气

作为 一个程序员,要被PM怼、要被交互怼、要被QA怼,再变态的需求都可能有,QA给你提的BUG可能也不属于你。而且,还有猪一样的队友(自己在别人眼里何尝不是这样呢)和下属。不管谁是谁非,发脾气、吵架都一点用没有,吵完还是得解决问题。calm down,有怒火也得等个几秒再发作,也许这几秒理智思考一下,就能解决问题。


负责任

能力(技术能力)与责任心谁更重要呢,都重要。如果一个新人有培养的潜力,那么责任心就更重要。两个人,第一个技术能力很强,但责任心很差,对项目的事情也不上心;第二个能力差些,但责任心强,是自己的问题一定负责到底,即使自己不能解决也能主动询求帮助。我觉得前者对项目的危害更大,特别是项目紧要时期,因为能力强的人一般负责的是比较复杂、困难的功能,别人上手也需要时间,这个时候如果摞担子,bug也不修,那么就很为难了。

不负责任的典型表现就是扯皮、甩锅:这不是我的bug、不关我的事。有协作的地方更容易出现问题,比如前端与后端、各个部门之间。如果不清楚到时是谁的问题,不妨主动一点,帮助排查。

不要总是说不会

作为程序员,总有一些工作是以前没有做过的,也许来自产品人员的需求,也许来自项目自发的优化。我见过一些程序员,在面临未知的问题、挑战时,总是习惯于说:不会、没办法、不可能,这样的程序员就算不上合格的程序员。事实上,这样的程序员是给自己过早地留好退路,事实上问题可能并没有想象得那么困难,也许经过一番探索就能解决。如果习惯于对未知说不,那么在别人看来就是能力不行,影响个人形象与声誉,而且总是待在自己的舒适区也不利于自我成长。

当然,也不是说要盲目自信,急于拍胸脯保证一定能解决,这样往往是坑自己。

所以,面对新的需求,谨慎对待,既不轻易否决也不随意承诺,而是再理清需要先去研究一下,评估是否能完成,需要的资源与时间。

暂时就想到这么多,当然我也还不达标,比如容易控制不住自己的怒火,与君共勉吧!

---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦




全部评论: 0

    我有话说:

    阅读」最近程序员圈刷屏支付宝架构,分享给大家

    支付宝架构到底有多牛逼!还没看完我就跪了

    阅读」如何构建可伸缩Web应用?

    可伸缩性已经成为Web应用程序DNA!

    阅读」图文并茂带你了解分布式架构演进

    初始阶段架构初始阶段 小型系统 应用程序、数据库、文件等所有资源都在一台服务器通俗称LAMP

    阅读」亿级用户分布式数据存储解决方案

    分布式数据库和分布式存储是分布式系统中难度最大、挑战最大,也是最容易出问题地方。互联网公司只有解决分布式数据存储问题,能支撑更多次亿级用户涌入。

    阅读」推荐系统中信息增强小技巧

    实用推荐系统构建经验,如何进行信息增强。

    阅读」轻松理解 Kubernetes 核心概念

    Kubernetes 迅速成为云环境中软件部署和管理新标准。

    阅读」大众点评是如何分表分库

    原大众点评订单单表早就已经突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想

    阅读」“做完”和“做好”区别

    在工作中,“做完”和“做好”虽然仅一字之差,但前者只是完成了某项工作,而后者则不仅是完成了工作还有一个好

    阅读」移动端事件穿透原理与解决方案

    本文将带你了解事件穿透及如何在实际项目中选择合适方案解决事件穿透问题。

    阅读」分布式事务四种解决方案,成长需要尝试

    分布式事务指事务操作位于不同节点,需要保证事务 AICD 特性。

    阅读」为什么在做微服务设计时候需要DDD?

    设计蓝图里为什么没有看到DDD影子呢?

    阅读」移动端适配必须掌握基本概念和适配方案

    随着技术发展,移动设备越来越流行,并且不同设备间屏幕尺寸和屏幕像素差异,移动端开发面临着多分辨率适配问题。

    阅读】为什么越来越多系统在做服务化?

    脱离业务实际情况架构都是耍流氓,所以不是所有系统都必须服务化,也不要为了服务化而服务化。

    阅读」Mysql调优你不得不知细节

    多数时候数据库会成为整个系统瓶颈

    阅读」美团开源QPS压测结果近5w/s分布式ID生成器leaf调试实战

    大型互联网项目ID要保证全局唯一,一般不在用数据库自带id自增了,一般都会用分布式id生成器。

    阅读」4大服务注册发现技术对比

    架构设计中 CAP 和 BASE 理论

    阅读」如何设计移动端屏适配方案

    在众多移动设备中,前端开发人员如何在不同屏幕大小,不同程度高清屏下去百分百还原设计稿,从来都不

    阅读」Dubbo 如何成为连接异构微服务体系最佳服务开发框架

    要实现异构微服务体系间共存或迁移,关键点在打通异构体系间协议与服务发现,得益于 Dubbo 自身对多协议、多注册模型支持