程序员的核心竞争力是什么?

我们都知道学习能力很重要,那么学习能力从何而来,除了去看书上课这种,如何在实践工作中学习成长?

我之前微博说了一个笼统的概念,什么是能力? 对待问题的态度,以及处理问题的思路和方法。

先说态度

你服务器偶尔出501错误,也许比例不高(知乎也出现过很多次),很多程序员,没错,是很多,假装看不见,不在乎,或者归咎于人品问题。 这就是态度问题。

再往后,负载高了或者其他什么原因,突然频繁出现501错误,不去追寻深入的原因,而是找各种借口, 什么IDC服务商不好,服务器品牌不好,操作系统不好,数据库不好,CDN不好,网络状况不好,web server不好,甚至,直接对Boss说我们被DDOS啦!(遇到过,帮他Boss找过多个安全专家会诊,最后发现根本不是DDOS,是程序员太烂。)

这就是态度,触目惊心,如果能对问题有敏感性,能知道对任何小的,轻微的问题有足够的敏锐度,你就有了一个快速成长的基础。对问题的敏锐度是非常重要的。很多性能或程序逻辑上非致命的bug,在不够敏锐的时候是发现不了的,但是一旦进入特殊场景就会骤然爆发,你多一点敏锐度,就会减少这种危机的风险。

第二个态度是解决问题的态度,有人对自己的解决方案信心满满,认为万无一失,但有的人就会多留一条后路;就好比你说我服务器要不要做安全加固,肯定要做对不对,要做到尽可能严谨和周全,但是你数据库保存密码的时候是不是还要加密?而且要随机salt,不就是防止万一依然有漏洞被人拿库怎么办么。程序也一样,以前写的一些服务端守护进程,有bug,会莫名其妙的终止,这个bug当然要定位,要修复,但是同时,写一个cron检查这个守护进程状态,一旦遇到终止给予自动恢复,这就是第二手准备,即便你多么不希望他执行,这个准备还是要做的。对问题 做两手甚至三手准备,也是优秀程序员,架构师的关键素质。

第三个态度是基于沟通与理解的态度,产品或运营提了一个不靠谱需求,一句话打回去当然很爽很威风,但是有没有仔细沟通分析过,这个需求基于怎样的实际诉求,这个实际诉求有没有更合理的实现途径,一句话“这个没法做,这个实现成本太高”,不是正确的沟通态度,而且,最优秀的产品,往往是实现了那些原本人们认为无法实现的诉求。

这样的态度,才有了一个持续进步的基础,下面说思路和方法。

优秀 的程序员和平庸的程序员,如果只看敲打代码的速度,我觉得是分不出来的,也许每人都可以一天写很多行代码,但是遇到问题后,平庸的程序员的解决效率,和优秀程序员相比就会有天壤之别。 所谓解决效率,不外乎对bug的分析、定位,以及 思考。

最基本的一条,看执行日志,看各种日志,web server的日志,数据库 的日志,慢查询日志,binlog日志,php的错误日志,等等等等,线上出问题瞎猜连日志都不看的大有人在。看日志不仔细不完整的也大有人在,你能去认真研究日志已经超越很多人了。

第二条,模块测试和断点分析,程序员一个坏习惯就是上来就写很大一坨代码然后再执行,不知道一个模块一个模块来写来测试,执行出了问题不知道设置断点,缩小范围逐步分析。断点分析非常简单,将整个代码中插几个中间输出,观察哪个环节出了问题,或者观察每个环节的系统开销,对调错和性能优化都非常重要,高手们大概认为这是ABC的东西,但是就这玩意我看到的大部分程序员都没有这个习惯。

第三条,错误信息 的理解和搜索,搜索引擎上有各种丰富的技术资料和技术问答,你所遇到的错误信息和错误提示,通常都能在网上搜索到,当然,搜索到后要结合你的场景认真思考,并理解透彻,而不是照猫画虎的去处理,否则可能这次运气好就蒙对了,下次运气不好又不知道怎么回事了。

第四条,不断总结归纳,对一个问题,一类问题,以及不同类型的问题,善于归纳整理,不断反思自己的问题,即便是不出bug的代码,你经过一段时间去回头看,也有很多思考不正确不合理的地方,有很多优化点,如果你觉得自己的代码一向牛逼,毫无破绽,那你一定是原地踏步,毫无进展。

关于 归纳总结,我说个案例

以前我们有个系统,请求量非常大,负载非常高,有个不错的技术经理来处理,他列了几个升级计划,都很靠谱,去执行了,效果非常好,然后我们跟进汇报的时候他来讲,做了几项升级,整体效果如何,然后我就批评了他。

我批评了什么呢?他是一起做的升级,然后一起观测的效果,那么这几个方案里,具体每个方案的实际效果怎样,对提升的帮助多大,他没有任何数据。所以对具体每个升级方案的价值和重要性,他没有任何概念。你正确的解决了问题,却没有认真的去归纳整理,你的收获是有限的。一起做升级不能说是错的,但是效果评估需要单独去做,而这个数据是非常有价值的,知识积累,不是你处理过的就一定有积累,而是整理过的。

大概就这些

最后重述一遍

什么是能力?

遇到问题的态度

处理问题的思路和方法

这就是能力

补充1:善于提问,你能得到怎样的答案,取决于你提出怎样的问题。

你遇到问题,你应该知道,从哪里去问,去问什么。

我常见的一个测试题是这样的。

数据库目前挂了,我就是服务器,我不知道为什么挂了,你是一个优秀的分析师,现在我来做响应,你问我问题,你问一个问题,我回答一个指标,然后看你能不能定位问题。(当然,我会根据所假设的问题回答所有数据指标),比如你问我数据库连接数多少,问我系统i/o压力多少,或者问我慢查询日志里有什么,等等,善于提问的人就可以快速得到答案,而不善于提问的人,就会猜测一堆可能,最终却一无所获。

有个真实好玩的案例,有个兄弟公司(前段时间新闻出来,卖了好像十个亿的样子),开始的时候服务端数据库不够强壮,负载起来的时候会出现一些问题,就请我去把脉,我一看windows服务器,SQL server (不要猜了,那是几年前,现在应该改了),我说这个我不会啊,然后人家那么热忱当我是专家,只好硬着头皮上,我连基本操作都不会怎么办,我就坐在那里问问题,开始他们说是不是这样,是不是那样,我说你们不要盲目下结论,你们要是知道结论就别来问我了,我问什么指标,什么日志你们就给我查什么,我就一样样的问,他们现场操作去查数据,我问一个他们查一个给我看,查着查着,他们的工程师说,知道原因了!果然和他们开始的假设完全不同。 其实关键就是问问题的思路,他们一开始没有提出正确的问题。提出了正确的问题,他们很快自己就找到了原因。

补充2:善于划定范围,缩小问题区间。

前面提到的断点分析是一个非常常见的分析方法,但是很多场景,你甚至不知道是哪个程序出的问题,善于将问题范围化,也是一种归纳和分类的能力。

我曾在某个技术群出过一个经典测试,还记得以前微博上提到的一个经典面试题么。“从浏览器输入url到打开网页,中间经历了什么”,这是一个经典的综合认知的题目,基于这个题目,出一个更实战的场景测试是(这个场景其实90%的网站站长和游戏运营商都遇到过),”目前有用户反映网站或游戏卡,请问如何分析原因,以及当前优先级步骤。“。结果在这个群里,只有我徒弟说出了完全正确的答案(09年带过的)。优先级第一步是看在线用户数和当前访问数,对比历史,得到该问题目前的影响程度,来决定后续的优先级,以及减少分析范围。(这是意识问题) 分析思路,分成三大块,前端,网络层,服务端。当然这三块可以继续延伸下去非常多细节,但是至少,能先把问题分成三大块,然后基于一些显见的分析方式快速排除其中几个部分,再逐步细化问题,而大部分人只是从一个局部去思考,讲了很多局部细节却没有完整的纲领,所以这就是差距。

本文来自企鹅号 - Android攻略媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程坑太多

程序员反感(讨厌、不喜欢)什么?

PS:频繁改需求和临上线加需求。。。,总感觉是你金山取之不尽用之不竭,可是你自己痛苦不堪!

713
来自专栏张叔叔讲互联网

浙江省初中信息技术八年级(上)-张叔叔划重点

与初中信息技术七年级的教材相比,八年级的教材真正的开始接触了互联网概念。八年级上册重点讲的是互联网的基础之网络,首先介绍了计算机网络,让大家对网络有个基本的认识...

591
来自专栏纯洁的微笑

70后.net老猿,尚能饭否?

1422
来自专栏姬小光

用完我即走,何日君再来?

而作为开发者,最令人兴奋的莫过于可以以最小的成本,最快的速度上线一个自己想要的产品了。不过,作为个人开发者,如果没有公司资质的话,限制还是很多的。比如许多类目的...

513
来自专栏编程软文

程序员常用的六大技术博客

1207
来自专栏Java技术栈

有时候,解决问题比写代码更重要!

有时候程序员往往会陷入为了写代码而写代码的怪圈,没有意识到代码是为了解决现实问题的。当问题有更简便的解决方案时,写代码未必就是必须。记住:你不是别人花钱让你在屏...

903
来自专栏我就是马云飞

一个 2 年 Android 开发者的 18 条忠告

我仍记得2014年我决定做安卓开发的那天,这是我一生中做出的最好决定之一。到现在已经有2年半了, 最初的时候,并没有人告诉我如何做才是正确的。我犯了很多错误,浪...

2028
来自专栏java一日一条

一个 2 年 Android 开发者的 18 条忠告

我仍记得2014年我决定做安卓开发的那天,这是我一生中做出的最好决定之一。到现在已经有2年半了。

503
来自专栏FreeBuf

美国数据公司LocalBlox泄露了4800万个人数据记录

又有一个数据泄露成为头条新闻,再次被Upguard的数据泄露猎手发现。美国数据机构LocalBlox在网上暴露了一个不安全的在线AWS库,其中包含部分来自Fac...

601
来自专栏python开发者

Android和Linux应用综合对比分析

原文地址:http://www.cnblogs.com/beer/p/3325242.html 免责声明:     当时写完这篇调查报告,给同事看了后,他觉得...

2326

扫码关注云+社区