Architecture Internships Abroad因为我是看到tinyfool 《那些年我赶过的时髦技术趋势》，在赞叹的时候，也让我对我有好些回忆，所以想写一篇回忆贴，本来觉得回忆是件挺让人沮喪的事，因为是老了的表现，但我写着写着，就歪了楼。看来，我还不老，还在拼博。下面是很多我的唠叨，你喜欢就读读，不喜欢就TLDR – Too Long, Don’t 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，主要用低廉的x86集群进行大规模的并行计算，主要用于芯片设计行业，如：ARM和德州仪器，或是科研，如NASA，或是国家安全，如美国国防部的影像分析，或是3D动画渲染，如怪物史瑞克……从05年以后，发现很多用户开始从Unix迁移到Linux，于是开始更为关注Linux的Kernel知识。Platform有一套很严谨的软件工程体系，我对严谨的软件工程以及很多的基础的技术的认识在这里形成。
    • 2007年在路透做路透全球金融数据Real-Time网络的高性能调优（我在《性能测试应该怎么做？》一文中透露过这个公司的性能要求，是一个实时的数据网络，对于99.9%的网络传输在100K的tps下要低于1ms，技术挑战是很大的），在路透，我只干一个事，就是性能优化，我把我负责的几个系统的性能都提升了8倍到15倍的样子，09年年底的时候，我已把未来3年的优化的活都干完了。所以，这个时期，我也开始了我的经理生涯。我对性能调优，高可用系统架构，研发管理的很多是在这里形成的。
  • 2010年到今天，技术沉淀期，这个时间段，主要的编程语言是Java。
    • 这段时间，我加入了Amazon和Alibaba，也就是所谓的互联网公司。在Amazon干了两个事，一个是把Amazon全球的marketplace连起来，跨大洲的数据中心的通信，还有一个是第一次接触大数据和机器学习——用户需求预测系统。在Alibaba干过电商云平台聚石塔和阿里云，去阿里最主要的是经历双十一。
    • 这段时间，对我影响比较大的是Amazon，技术不再是我的瓶颈，大规模的系统，对我也不是问题，而让我收获最大的是，世界前沿的软件设计架构和解决方案，以及做技术的态度和工程的方法，我的眼界、脑洞和视野都巨大的打开，并且在技术管理、工程管理、产品管理、人员管理、公司管理等等管理方面的思维有了质的提升。这段时间，才是我真正技术沉淀的时期。

我的这个背景本来可以更好一些，只可惜运气不太好，本来可以走的更快的，无奈在最关键的时候遇到了两次金融危机，本来可以去硅谷更牛更好的公司见世面，无奈父母身体欠安，只能放弃。

经历决定思维方式

通过我的背景经历，大家不难看到，我基本上都是做一些规模比较大的系统和软件，而且，主要用C/C++/Unix/Linux这样比较晦涩的语言和操作系统。我们知道用C和C++开发，基本上要处理的错误都是和系统底层相应的东西，而上规模的系统和软件，又总是会遇到很多“稀奇古怪”的问题，这些问题，都会逼着我要去了解很多的操作系统、计算机系统、网络、数据库、中间件等等的各种基础或底层技术。

而且我经历的基本上都是非常严谨的软件工程，不能马虎，我有几次马虎的经历，给我造成了非常大的心理影响，比如，曾经被定性为不适合写代码，因为我的代码太烂，或是出了严重的故障，几乎要跑路去了。另外，全球gloabl式的oncall，经常让我在凌晨被电话叫起来解决问题，这个经历比较痛苦。所以，我的整个经历，让我养成了，在软件开发上必需也不得不严谨的习惯和价值观体系。

大家想想，用C/C++开发一个几乎不能出故障的软件系统，你需要多仔细和多严谨的态度才能达到要求？因此，我的经历让我不能马虎，也不能应付工作，更不能在标准上有所妥协，还需要不断地提高标准，所以，时间一长，我必然，会有如下的习惯：

  • 要做到——知其然，知其所以然。所以，只能不断的学习基础知识以及和这个技术关联的知识，就像Wikipeida一样，当你进入一个词条的时候，就会伴随时一堆新词条，于是，当多年后，我看到 “知识广度是深度的副产品”这句话时，简直就是说到我的心里去了。
  • 要做出工业级的软件。从银行到Platform到Thomson Reuters再到Amazon，软件开发上都会有SLA的要求。我认为，一个软件是工业级还是民用级的，除了功能正确之外，最重要的一个指标之一就是在性能和稳定性上有没有SLA。绝大多数的互联网公司和开源软件都没有SLA。所以，达不到工业级的标准。要达到工业级的标准，就需要花费时间、人力和财力进行非常繁琐的设计、测试评估以及运维管理。
  • 工业级的软件来自工业级专业人员和专业软件工程。
    • 专业的人员。为什么绝大多数的外国公司需要的是CS（Computer Science）背景毕业的工程师？因为他们要做的是工业级的软件，这是一门科学，即然是科学，就需要受过良好的科学教育的CS专业的人。
    • 专业的工程。工业级的软件需要有工业级的软件工程，比如，严谨的Design/Code Review，严格的测试，以及完备的线上运维。
    • 专业的工具。这个时候，你就会发现，要做到高级别的SLA，比如包括5个9以上的SLA，人肉干活的能力已经完全跟不上了，你需要大量的专业的与之配套工具。人类之所以聪明是因为会发明工具，所以，这也是工业级的另一个标准——你有多少现代化的支撑工具？

在之前的《开发团队的效率》一文中，我说过——你总需要在一个环节上认真，这个环节越往前就越有效率，越往后你就越没效率。要么你设计和编码认真点，不然，你就得在测试上认真点。要是你设计、编码、测试都不认真，那你就得在运维上认真，就得在处理故障上认真。你总需要在一个地方认真。

认真是痛苦和艰难的，也是需要苦苦坚持的，因为人太容易妥协了，这对每个人来说都是一种不小的挑战。老实说，我与很多人对“认真”的标准不一样，所以，产生了很多分歧，很多人说我太理想了。其实，我能理解他们，一方面是因为我的标准是比较高了，另一方面是他们只做过民用级的软件。

另外，在一开始，做惯了工业级软件的我极度地不适应于那些糙快猛的开发方式。不过，我也在调整自己，毕竟，世界不只一种价值观，有的是工业级的软件，有的则是民用级的，还有的只是个玩具，而且还有Java这门语言非常有效地屏蔽了很多底层和基础知识，所以，也不可一概而论，我也在适应一些民用级的软件开发的方式。

后记

从去年我从阿里离开到现在14个月了，这段时间内，我给大约40多家公司做过相应的技术咨询和解决过很多技术问题，绝大多数公司都是因为性能和稳定性的问题来找我的，我给这些公司解决问题的时候，基本都是这样的Pattern：

  • 一开始，发现都是一些技术知识点的问题，
  • 然后，马上进入到系统架构方面方面的问题，
  • 当再解决架构问题的时候，我发现，已经是软件工程的问题，
  • 而软件工程问题的后面，又是公司管理上的问题
  • 而公司管理的问题，结果又到了人的问题上
  • 而人的问题，又到了公司文化的问题……

你看，很多问题，一环扣一环，最终都不是一个简单的技术问题。我倒不是说，我在抱怨这些问题，我更不是在说能解决这些问题，因为，就像软件工程没有银弹一样，无论你给什么样的解决方案都会有问题，没有问题才是不科学的。我能做的是，观察这个公司的业务形态、和相关的思维方式，以及现有的资源和相应的技术实力，帮助他们从技术到管理上缓解或改善现有的问题。

所以，我基本上来说，这近20年来，我只在专心研究一个事——如何做出一个性能高稳定性好的大规模的系统。在这个方向中，除了很多的基础和底层技术我需要吃透，我还需要在软件的开发工艺，软件工具，以及软件的线上运维，以及相关的管理上不断学习和思考，因为，只有技术、工具、工程、运维、人员这几个方面搞好了，才可能出现一个性能高且稳定性好的系统。

之前对于我来说，我一直在鼓吹先进的管理和软件工程以及技术和工具。今天，对我来说，遇到最大的问题就是，在没有这些所谓的先进的东西的时候，除了我自己上手外，我是否还能解决相应的问题？因为我自己已经完全Scale不开了。

有问题就有挑战，我每天都在思考，如何在不完美甚至残缺的环境下，解决这些公司的技术问题。每个人都要给自己一个目标。目前，我给自己的目标是——在残缺的环境下，能让用户不改一行代码，不动任何的架构，不改变用户很糟糕的软件开发的习惯，也不让用户作任何管理上的调整，能提升用户的软件系统的性能和稳定性。

因为我相信技术，我相信有更好的技术，可以为用户完全透明的提升性能和稳定性，我大致找到了相应的解，现在，我正在实践的路上，这也许是笔大买卖，所以我不知天高地厚地注册了自己的公司……