因为我是看到 tinyfool《那些年我赶过的时髦技术趋势》,在赞叹的时候,也让我对我有好些回忆,所以想写一篇回忆贴,本来觉得回忆是件挺让人沮喪的事,因为是老了的表现,但我写着写着,就歪楼了,看来,我还不老,还在拼博。下面是很多我的唠叨,你喜欢就读读,不喜欢就 TLDR Too Long, Dont Read!
自从 98 年毕业,到今天,参加工作有 18 个年头了,加上在大三的时候就为两个在外面接活的老师程序,到今天,写的程序被用到生产线也有 18 个年头了。
背景经历
要说明我技术上的性取向,还得我说说的我的一些背景和经历。
我这 18 年,大约分三个阶段:
1996 年-2000 年:入门乱来期,大三大四加在银行工作的两年。
用 powerbuilder/Delphi 在 WindowsNT/SQL Server 上做了好多个 MIS 管理软件,有酒店的,有送水的,有 OA 的。用 Java 的 Applet 做了一个 Web 的教学课件,用于在 Win95/IE3.0 中演示操作系统中的各种调度和算法的动画,得了个全国大学生挑战者杯的鼓励奖。给一些公司用 Delphi 的 ISApI 技术以及 pHp/ASp 给一些公司和大学做过几个网站。2000 年-2010 年:技术学习期,这个时间段,我主要的编程语言是C/C++。
前两年在银行用C语言在 Unix(AIX/Solaris/Sco Unix/Hp-UX..)写各种银行业务(用C语言写),用C写操作 SQL,操作界面,写业务交易逻辑,一切都用C,这是一个C语言的年代,当时,全国的银行都在做大集中,银行当时行业里最大的软件系统了,所以,我确定了C/C++/Unix 的技术方向,我当时的网上签名是,C/C++/Unix 才是大规模杀伤性武器。然后,2002 年在 platform 做一个全平台的(包括 Unix/Linux/Windows)高性能计算的软件产品,很像今天的 Hadoop,当时叫 Grid Computing,从 06 年以后,发现很多用户开始从 Unix 迁移到 Linux,于是开始更为关注 Linux 的 Kernel 知识。platform 有一套很严谨的软件工程体系,我对严谨的软件工程以及很多的基础的技术的认识在这里形成。2007 年在路透做路透全球金融数据 Real-Time 网络的高性能调优(我在《性能测试应该怎么做?》一文中透露过这个公司的性能要求,是一个实时的数据网络,对于 99.9% 的网络传输在 100Ktps 的要低于 1ms,技术挑战是很大的),在路透,我只干一个事,就是性能优化,我把我负责的几个系统的性能都提升了 7 倍到 15 倍的样子,09 年年底的时候,我已把未来 3 年的优化的活都干完了。所以,这个时期,我也开始了我的经理生涯。我对性能调优,系统架构,管理是在这里形成的2010 年到今天,技术沉淀期,这个时间段,主要的编程语言是 Java。
这段时间,我加入了 Amazon 和 Alibaba,也就是所谓的互联网公司。这段时间,对我影响比较大的是 Amazon,技术不再是我的瓶颈,大规模的系统,对我也不是问题,而让我收获最大的是,世界前沿的软件设计架构和解决方案,以及做技术的态度和工程的方法,我的眼界、脑洞和视野都巨大的打开,并且在技术管理、工程管理、产品管理、人员管理、公司管理等等管理方面的思维有了质的提升。这段时间,才是我真正技术沉淀的时期。我的这个背景本来可以更好一些,只可惜运气不太好,本来可以走的更快的,无奈在最关键的时候遇到了两次金融危机,本来可以去硅谷更牛更好的公司见世面,无奈父母身体欠安,只能放弃。
经历决定思维方式
通过我的背景经历,大家不难看到,我基本上都是做一些规模比较大的系统和软件,而且,主要用C/C++/Unix/Linux 这样比较晦涩的语言和操作系统。我们知道用C和 C++ 开发,基本上要处理的错误,都是和系统底层相当的东西,而上规模的系统和软件,又总是会遇到很多稀奇古怪的问题,这些问题,都会逼着我要去了解很多的操作系统、计算机系统、网络、数据库、中间件等等的各种基础或底层技术。
而且我经历的基本上都是非常严谨的软件工程,不能马虎,我有几次马虎的经历,给我造成了非常大的心理影响,比如,曾经被定性为不适合写代码,因为代码太烂,或是出了严重的故障,几乎要跑路去了。所以,我的整个经历,让我养成了,在软件开发上必需也不得不严谨的习惯和价值观体系。
大家想想,用C/C++开发一个几乎不能出故障的软件系统,你需要多仔细和多严谨的态度才能达到要求?因此,我的经历让我不能马虎,也不能应付工作,更不能对标准上有所妥协,所以,时间一长,我必然,会有如下的习惯:
要做到知其然,知其所以然。所以,只能不断的学习基础知识以及和这个技术关联的知识,就像 wikipeida 一样,当你进入一个词条的时候,就会伴随时一堆新词条,于是,当多年后,我看到 知识广度是深度的副产品这句话时,简直就是说到我的心里去了。要做到工业级的软件。从 platform 到 Amazon,软件开发上都会有 SLA 的要求。我认为,一个软件是工业级还是民用级的,除了功能正确之外,最重要的一个指标之一就是在性能和稳定性上有没有 SLA。绝大多数的互联网公司和开源软件都没有 SLA。所以,达不到工业级的标准。要达到工业级的标准,就需要花费时间和财力进行非常繁琐的测试评估。工业级的软件来自工业级专业人员和专业软件工程。在之前的《开发团队的效率》一文中,我说过你总需要在一个环节上认真,这个环节越往前就越有效率,越往后你就越没效率。要么你设计和编码认真点,不然,你就得在测试上认真点。要是你设计、编码、测试都不认真,那你就得在运维上认真,就得在处理故障上认真。你总需要在一个地方认真。
认真是痛苦和需要艰难的,也是对自己的一种挑战。老实说,我与很多人对认真的标准不一样,所以,产生了很多分歧,很多人说我太理想了。其实,我能理解他们,一方面是因为我的标准备比较高了,另一方面是他们只做过民用级的软件。
别外,在一开始,做惯了工业级软件的我极度地不适应于那些糙快猛的开发方式。不过,我也在调整自己,毕竟,世界不只一种价值观,有的是工业级的软件,有的则是民用级的,还有的只是个玩具,而 Java 这门语言非常有效地屏蔽了很多底层和基础知识,所以,也不可一概而论,我也在适应一些民用级的软件开发的方式。
后记
从去年我从阿里离开到现在 14 个月了,这段时间内,我给大约 40 多家公司做过相应的技术咨询和解决过很多技术问题,绝大多数公司都是因为性能和稳定性的问题来找我的,我给这些公司解决问题的时候,基本都是这样的 pattern:
一开始,发现都是一些技术知识点的问题,然后,马上进入到系统架构方面方面的问题,当我再往下解决架构问题的时候,我发现,已经是软件工程的问题,而软件工程问题的后面,是公司管理上的问题而公司管理的问题,结果又到了人的问题上人的问题,又到了公司文化的问题你看,很多问题,一环扣一环,最终都不是一个简单的技术问题。我倒不是说,我在抱怨这些问题,我更不是在说能解决这些问题,因为,无论你给什么样的解决方案都会有问题,没有问题才是不正常的。我能做的是,观察这个公司的业务形态、和相关的思维方式,以及现有的资源和相应的技术实力,帮助他们从技术到管理上缓解现有的问题。
所以,我基本上来说,这近 20 年来,我只在专研一个事如何做出一个性能高稳定性好的大规模的系统。在这个方向中,除了很多的基础和底层技术我需要吃透,我还需要在软件的开发工艺,软件工具,以及软件的线上运维,以及相关的管理,因为,只有技术、工具、工程、运维、人员这几个方面搞好了,才可能出现一个性能高且稳定性好的系统。
之前对于我来说,我一直在鼓吹先进的管理和软件工程以及技术和工具。今天,对我来说,遇到最大的问题就是,在没有这些所谓的先进的东西的时候,除了我自己上手外,我是否还有解决相应的问题?因为我已经完全 Scale 不了。
有问题就有挑战,我每天都在思考,如何在不完美甚至残缺的环境下,解决这些公司的技术问题。每个人都要给自己一个目标,目前,我给自己的目标是在残缺的环境下,能让用户不改一行代码,不动任何的架构,不改变用户很糟糕的软件开发的习惯,也不让用户作任何管理上的调整,能提升用户的软件系统的性能和稳定性。
因为我相信技术,我相信有更好的技术,可以为用户完全透明的提升性能和稳定性,我大致找到了相应的解,现在,我正在实践的路上,这也许是笔大买卖,所以我不知天高地厚地注册了自己的公司
济宁IT新闻