程序员的“横向发展”
在我小的时候,家长经常对胖孩子打趣说:哟,身体长得挺快,可惜就是横向发展了。看来在很多人的潜意识里,纵向发展是向上的,值得夸奖,横向发展则不是那么光彩的事情。但是我的工作经历和思考,却让我对“横向发展”有了新的认识。
程序员的发展,长期以来都是大家关心的问题。通常程序员的发展有两大方向,深度和广度。深度发展,就是精深自己的本事,研习新潮尖端的技术乃至学会“屠龙之术”,以绝招打遍天下;广度发展,就是拓宽自己的技能种类,比如学会更多的语言,以完成更多种类的任务。除去这两大方向,其它能选的发展方向似乎就只有“改行”了。
今天我要说的当然不是改行,而是除去深度发展、广度发展之外的第三维度,因为似乎一直也没有正式的命名,所以我干脆借用“横向发展”的说法好了。
什么是横向发展呢?举例子来说,我们写个程序,深度发展关注的是让它速度更快、资源消耗更少,广度发展关注的是让它更合适与其它模块交互,甚至用更合适的语言编写这个程序。横向发展,则是让这个程序成为真正能用的程序,而不是实验室里的玩具。换句话说,“横向发展”是让程序更加“工业化”而不是“技术化”的发展。
我刚开始工作的时候,有一天提前完成了任务,喜滋滋地去向项目经理汇报。不料他看了代码之后,却把我劈头盖脸说了一顿:你以为你还是学生呢,给老师写个程序算出正确结果就完?你看你处理网络连接的部分,对服务器返回的异常信息,包括网络传输的各种意外都没有处理,谁向你保证服务器总是返回正确信息的?谁告诉你网络传输不会意外的?万一网络断了,你的程序就一直死循环吗?……
我必须承认他说的有道理,但也一时无可奈何。虽然在学校的时候写过不少程序,但老师都只看大致结构和结果,从没有问过“网络断线了怎么办”,也没有哪本教材专门讲过这方面的知识,所以自己一直也没想过。但是没想过归没想过,项目经理说的毕竟有道理,确实只有学生才会写出在理想环境下运行的程序。于是我开始有意识地学习和思考各种异常情况的处理,觉得讲究挺多,思路也因此拓宽了不少。不久,还因为这方面的工作得到了项目经理的表扬,也深刻感觉到“横向发展”确实解放了自己。
后来换了份工作,我本来以为自己之前的经验可以被人赏识,却发现自己完全想错了。新工作对程序的要求更高、应用场景更严苛,只思考在程序内部怎么处理异常是不够的,还需要确保程序的持续运行,其运行状态持续可以记录、监控、分析,出现问题必须能在第一时间判断症结(而不是启动IDE去debug)……为了做到这一切,既需要专门开发程序去监控自己的程序,又需要让原有程序能够被方便的监控,还不能泄露不必要的信息,所以在设计时又有更高的要求——当然,这些知识仍然是书上没有的。我写到最后才发现,虽然核心的功能并没有变复杂,但为了保证核心功能的稳定运行,程序本身的复杂度却上升了很多。这种要求,颇有几分类似小朋友的“横向发展”——但是小胖墩的重心终归要稳一些嘛,所以我把对程序员的这种要求称为“程序员的横向发展”。
或许是从工作开始就有机会重视“横向发展”的缘故,所以我长期以来并不认为这是严重的问题。后来的见识却刷新了我的认识:曾经有朋友告诉我,国内互联网行业某新兴领域排名三甲的公司,竟然连自己的服务器上跑的哪个版本的程序都不知道,开始我还当是笑话,后来才知道事实当真如此。小朋友的“横向发展”不讨人喜欢,许多程序员也忽视甚至讨厌“横向发展”,觉得这是在给自己找麻烦,他们认为,把核心功能写完,代码提交,往服务器上一扔,自己的工作到此为止了。至于其它方面,那就是系统管理员要处理的了。
如果你认真回忆,一定见过许多这样的程序:完全不处理意外情况,各种异常一股脑交给操作系统去处理,我甚至见过默不作声把所有异常都吃掉,假装没事继续运行的系统。也见过很多这样的程序:自动发送邮件的程序,不知道自己每天发了多少封邮件,消耗了多少流量,等到用户收不到邮件才知道出了问题;备份数据库的程序,不会记录每次备份的开始时间、结束时间、备份文件大小,直到硬盘满了才发现已经很久不能正常备份了;抓取数据的程序,不知道抓取的成功率、速度、消耗的流量,非要业务部门说数据很久没更新了才知道抓取失效了…… 其实这些功能通常都不复杂,但完成它们的程序,不管什么平台,什么语言,就是做不到稳定。每次出了问题都不能预先知道,又因为没有详细的记录,又要消耗无数的人力物力去解决。在一些稍微复杂的系统里,不少程序员每天的工作内容就是这样的重复劳动,随之而来的是无休无止的抱怨,说工作毫无意义,没有机会学新东西…… 更糟糕的是,不少这样的程序员业余时间还在积极学习,希望在把语言工具掌握得更熟练,学会更多的语言和工具,却不知道问题的症结在于自己缺乏“横向发展”的意识。
我仔细回忆自己小时候,家长和老师会在一种情况下提倡“横向发展”,那就是要求身板像“豆芽菜”一样的同学多锻炼,成长结实一点。同样的道理,如果程序员觉得自己写出的程序像“豆芽菜”一样没有底气、不能放心,与其继续钻研新语言、新技术,倒不如抽出精力去“横向发展”一把。
From Life Sailor, post 程序员的“横向发展”
我目前遇到的问题是,貌似要横向到非技术领域去了…… 程序开发,实施,售前,售后,乃至催客户签合同签竣工报告……
问题来了,如何“横向发展”?
多问自己,此代码有优化可能吗?
有时候有些事情当时就是想不到,考虑不周全,该该如何避免?
多思考,多学习,尤其是钻研一些广泛使用的开源代码,会学到很多的。
文章写得好极了!非常感谢!
和之前Fenng的那篇——事情要做绝,意境相通。那篇说的是,即使是小网站,也可以考虑能不能加上监控,怎么样减少流量,提高SEO,把这些问题都做绝了,那小网站中也可以学到很多很多东西了。
我觉得这是中国教育的问题,把人训练为习惯解决封闭问题而非开放问题,所以问题总要归个类,然后通过反复训练让人习惯解决这类问题。这使得中国人总在某些封闭领导内追求提升。
美国人简单直接很多,只问什么能够创造更大价值。这是个很开放的问题,现在的瓶颈是什么就在什么上面追求提升,而不在乎那是什么以后别人是否认为它重要。
说到底,还是只会解决已经定义好的问题,而不是自己去完整定义一个问题。
趣胖的孩子好惨
所谓的“横向发展”问题是不是因为前期对功能和需求识别不清楚造成的问题啊。在前期、中期、后期的横向沟通是不是更重要一些?
不是,与功能和需求无关
既然另两维是深度和广度,这维不妨叫作「硬度」吧。在现实世界上,提高所编写的软件面对异常情况和攻击的耐受性。
我对 Erlang 和 CouchDB 有一种特别的敬仰,因为 Erlang 说「Let it crash」,CouchDB 教程开篇就说现实世界如何残酷,他们是如何使用「crash-only design」来设计软件的。
哦还有 UNIX 哲学中的「crash loudly」以及 Python 的「Errors should never pass silently. Unless explicitly silenced.」
不过要做稳定可靠的软件不容易,充分地考虑到各种意外与竞态、不同环境的行为确定、各种异常状态的测试、出现各种问题的处理策略,等等,都要耗费大量的时间和精力。而很多商业公司都不在乎那 1% 的用户的感受,况不足万分之一的意外乎!愿意花费 80% 的时间来完善那余下的 20% 的人太少了。
哈哈,我见到的情况是很多商业公司不在乎的意外情况尽然占了10%甚至20%,所以大部分软件其实是相当脆弱的。
感谢分享,今天代码就出现了一次因为网络情况不佳导致的报错。而自己在最初根本没有考虑好这种情况,
写的真不错,学习了!
这些命名,能否三维的各轴关联起来?
如:Z轴即为深度,X轴即为广度,那么Y轴呢?高度可以吗?
看您这篇文章的题目,本来以为讨论的是程序员的职业身份的横向发展,没有想到看完之后才知道讨论的是思考问题广泛度,虽然不是程序员,但是还是有一些关于问题认知的一个重新的认识,虽然这种认知还很朦胧!
以前,我一直以为程序员是一心一意写程序,关窗不闻窗外事的家伙,因为这样才能专心致志嘛,大家都这么认为。 逐渐的,我发现这个潮流逐渐的成为过去了,越来越不实用。
横向发展,不错的概念。但这会设计到多领域、多种思考模式,所以大脑也会倍加辛苦,但或许,这才是未来趋势——多向的思考模式。()