IT外企那点儿事(5)：像系统一样升级

Posted on feb. 2 2014

IT外企那点儿事(5)：像系统一样升级

觉先

博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 :: 管理 :: 130 随笔 :: 0 文章 :: 544 评论 :: 0 引用 <2010年5月>日一二三四五六2526272829301 2 345678 9101112131415161718192021222324 25 26 272829303112345

公告

昵称：觉先园龄：3年7个月荣誉：推荐博客粉丝：560 关注：3

+加关注

搜索

常用链接

随笔分类

随笔档案

相册

IT外企那点儿事

阅读排行榜

评论排行榜

一、认识规律：道

做一个系统，首先要掌握此项目所需要的技术，如果相关技术没有使用过，则此项技术就是一门尚未认知的规律。在项目开始之前，必须要系统性的认知相关的技术，否则面临较大的风险。

做一个程序员，首先要掌握计算机方面的知识，对知识的掌握，同样需要系统性，否则职业生涯也会面临很大的困难。

系统性在此阶段至关重要。

如果在项目中，对相关的技术没有系统性的认识，则会造成以下后果：

设计出的系统不具有扩展性
应用了笨拙的方式设计程序
出现Bug时无所适从

不知道大家是否参加过这样的项目开发过程，由于时间紧任务重，项目组在没有一个人系统了解某项技术的时候就进行了开发，大家只好从网上下载一些Sample code来通过复制粘贴来拼凑程序，甚至连每一项配置或每一行代码都没搞清楚，就照猫画虎的拿过来用了，这样不但到了后期，系统几乎没有任何扩展性，并且任何不同于Sample code的灵活的改动都是一件十分痛苦的事情，项目组就像眉头苍蝇一样四处乱改乱闯，但并不清楚每一次改动的真正后果，这样要进行大量的尝试和返工，最后整的整个项目组很累，还没有效果，这个过程我称之为“盲试”，也即在不明白原理的情况下靠反复的体力劳动，逐一遍历所有自己认为可能的修改。

“盲试”是初入职场的程序员经常犯的错误，初入职场，信心百倍，情绪高涨，急于出成果是多数时候的心态，当一个任务下达到手中的时候，并不是系统的阅读文档，进行方案评估以及框架设计(这些其实都是磨刀不误砍柴工的事情)，而是急着上手来做，可能在项目的早期，能够很快的出效果，但是随着项目的进行，维护成本越来越大，经常加班，而效果甚微。而对有经验的程序员来讲，前期进行了良好的设计，后期添加模块，需求的灵活变动是相对轻松的事情。

其实也可以理解这种状况的出现，毕竟老板都是心狠手辣的，才不会给你那么多事件做调研，程序员总是有一种被皮鞭赶着走的感觉，从而根本无法系统性的掌握技术和框架设计。这也是面试了很多程序员，每每都号称做过A,B,C项目，分别应用了a,b,c的技术，然而往深入问的时候发现，他们对技术a,b,c的了解也就仅限于A,B,C项目中，对其他一无所知了。

没有系统性的认识技术，则可能写出很多笨拙的程序，丑陋的实现。因为你只知其一，不知其二，只知其然，不知其所以然，本来人家框架中有高效的现成的技术实现这一方面的功能，你不知道，于是根据自己了解的片面技术勉强拼凑成功能，自然也实现了效果，然而当自己开始看这方面的经典书籍的时候，不禁感慨：“咳，原来能够很简单搞定的，当时竟然笨笨的写N多的代码。”

没有系统性的认识技术，出现Bug的时候比添加新模块更痛苦，因为不明白原理，所以只能从表面现象去猜，然后又是进行“盲试”的过程。

因而对技术的系统性认识，实在是不但对项目负责，更是对自己负责的一件事情。如果老板是技术型的，在估计项目时间的时候，应该劝说其将这方面考虑进去，如果老板是非技术型的，则程序员也应该自己留下缓冲时间。不然你辛辛苦苦白天八小时给老板了，晚上再加班几个小时又给老板了，你自己如何进步呢？

如果对于程序员，对计算机方面的技术没有系统性的认识，同样存在上述的问题。

你的职业生涯同样没有扩展性。如果不能够系统的掌握算法，数据结构，操作系统，计算机网络，计算机组成等基础知识，在程序员的初期可能不明显，随便培训培训也能写出不错的程序，然而当转换方向或者平台的时候，会面临很大的痛苦。而我们能够看到的身边的优秀程序员们，无论让他们做C,C++还是Java，无论是linux还是windows，他们都能够很快的上手，是因为基础好的缘故。

项目和程序员认识规律的方式，其实也无非读书，文档，及原型开发(对于程序员来说，实习阶段相当于Prototyping)。

总结：项目或程序员的第一阶段：悟道，关键词：“系统性”

#

二、道生一

当掌握了项目相关的道，也即技术的时候，就要真正的进入项目开发了。

当前的项目，仍然由一个进程组成的系统比较少了，由于数据量的增大，基本都会开发多节点的分布式系统，然而再复杂的系统，也基本是从单节点系统开始做的，也即所谓道生一的过程。

当掌握了计算机相关技术的时候，你就可以成为一个真正的程序员了。当然不可能让你一开始就管理一个项目组，此时唯一要管理好的，是你自己。

开放性和扎实性是此阶段的重中之重。

对于项目来讲，一个好的单节点系统，所谓开放，就是即便设计单节点的系统，也要站在设计多节点的系统的角度来考虑，使做出来的系统更加容易被扩展成多节点的系统。所谓扎实，就是单节点系统要麻雀虽小，五脏俱全，扎扎实实的实现大部分功能，并有相当量的测试用例来保证功能的正确。

否则会造成以下后果：

当做多节点系统时候，发现单节点系统需要大量修改，甚至等于白做，重新开始。
单节点不稳定，以至于多节点时Bug丛生，但不知道是因为错误出在多节点实现部分，还是单节点部分，较难定位。
没有足够的测试用例，当为了多节点进行修改的时候，不能保证的功能实现仍然行为正确。

假设做一个100个节点的项目，要100天时间的话，并非每个节点要1天的时间，而是第一个节点就需要30天的时间，当第一个节点做好之后，扩展后面是很自然的事情，然而如果第一个节点做不好，每天都做一个节点，每天都把昨天做的设计推翻然后重做，怕是100天也完不成100个节点。这个例子比较极端，然而在我们周围没有发生过吗？

对于程序员来讲，做一个好的螺丝钉，同样需要开放和扎实。

所谓开放，就是我们虽然仅仅是最最低级的员工，可能整个系统的架构根本轮不到我们，但是这并不表明我们只盯着自己的一亩三分地，完成功能了事，而是要经常站在整个项目的角度考虑问题。不想当将军的士兵不是好士兵，建议做一下几件事情：

在项目的各种会议上，经常站在项目经理和架构师的角度考虑问题，要是自己会如何设计，前辈们为何这样设计，然后多问前辈问题。虽然最初的想法比较幼稚，但可以不说出来，但是长时间这样思考，会发现自己的设计水平会突飞猛进的，慢慢的，你会发现你能够在会议中给出一些建议，然后你会发现能够发现前辈设计中的一些缺陷，然后你会发现你能够对当前的设计提供恰当的改进方案，终于有一天你发现你不再是一个单节点的普通程序员了。
除了完成自己的功能外，多看一看前辈们实现过的代码，用自己的方式手绘一些他们的架构图，记下不太明白的部分及觉得很优秀可以借鉴的部分。
尝试在自己的模块中(可能最初是很小很小的模块)尝试使用学到架构。
可以重读或新读一些经典书籍，争取能够用业界内公认的理论来解释自己接触到的设计及架构，使得从感性认识上升到理性认识。比如原来前辈们写这些类，用的是这种设计模式，它还有以下的优点和缺点，适合设计怎么样的系统。这样不但有利于我们在以后的项目中恰当的使用已掌握的设计，而且也有利于向他人准确的描述项目。试想在面试中，一个专业术语要比杂七杂八的列一大筐类更显水平吧。
可以在餐桌上，向自己的同学，朋友描述一下学到的架构，让你的朋友往细节里问，不确定的回去再下功夫，争取做到虽然你只是项目中的一个螺丝钉，但是好像你从头到尾设计了这个系统一样。

这里要提醒一下大家，并不是所有的上司都喜欢要当将军的士兵和老问问题的员工，适当把握火候吧。

所谓扎实，就是指对接触到的知识，都应该根据实践，结合理论，由点到面的掌握。在这个阶段，信息量是很大，要学的东西很多，往往对各种技术都接触一下，又对各种技术都浅尝辄止，最后形成样样通，样样松的局面，阻碍了自己的发展。面试的时候也经常发现一些应试者，掌握的东西仅仅局限于他做过的那个点上，相关知识的掌握非常弱，这自然会影响他从一个单节点程序员向多节点发展。因而每当在项目中接触到一方面的东西，除了上班完成项目外，下班后多看一些有关此方面的书，博客等，使得从知识点变成知识面，知其然，还要知其所以然，并了解存在的问题。当白天在MFC中拖完控件后，总应该读一些《深入浅出MFC》来了解其机制，读一下《windows核心编程》了解一下windows API及一些原理，最好读一下《windows internals》了解一下原理背后的故事，不然面试的时候如何向别人开口做过windows下的程序设计呢？总不能够创建过socket对象就声称会socket编程吧，至少看一下《UNIX Network Programming》。用过NFS怎么不把linux的filesystem的机制了解一下呢？

当然这样是很累很费时间的，然而刚毕业的我们，没有经验，没有人脉，没有资金，有的不就是时间吗？

珍惜刚毕业的这几年多多打实一下基础，等年纪大了，精力没这么旺盛了，很多事情要照顾了，还要靠这时候的老本啊。

总结：项目或程序员的第二阶段：道生一，关键词：“开放性”“扎实性”

三、一生二

对于项目来讲，当单节点系统足够稳定的时候，是应该向client/server或者master/slave结果扩展的时候了，也即一生二的过程。

对于程序员来讲，当你已经足够胜任个人工作的时候，是可以带一个实习生或者初级程序员了。

此步的关键即"communication"，沟通。

对于系统来讲，主要考虑的应该是节点之间如何通信，如何协作，采取何种协议。

通信可以是面向连接的，也可以是不面向连接的。可以是同步的，也可以是异步的。
通信是分层次的，不同的情况应用不同层次的协议，heartbeat用何种协议，内部数据块传输用何种协议，发布成service向外提供服务用何种协议，都是应该考虑的。
数据的内部结构就想接口一样是要通过沟通商定的，便于解析又易于扩展，rpc? serialized object? xml? json? protocol buffer? 还是自己定义的格式？
对于要经常访问的客户端，连接池是必须的，每次建立连接是很耗时的
服务器端应该有对连接总数的限制，以及请求的分发，拥塞控制(并不一定是网络拥塞，而是某个阶段的处理相对较慢)
通信模块在项目中不应该是任何两个需要通信的模块都要开发的，而是应该作为基础性模块，经过大量的测试后达到稳定，使得需要应用通信模块的人员能够集中精力在本身的逻辑上，当模块间协作出现故障的时候，不用担心是通信模块传错了的问题。

对于程序员来讲，同样要考虑和实习生或初级程序员之间的通信协议问题。

有的代码自己觉得写的很清楚，但是让新手上手的时候，如何能够准确的描述你的思路，想法，设计，遇到的困难呢？如何根据对方的反馈确认对方真实了解了你所表达的信息呢？有很多有经验的程序员，由于天天面对着电脑而疏于和人的沟通，可能会一肚子能耐却说不出来，非常可惜；而对于新人，他的回馈是懂了可并不一定代表他真的懂了，也可能是不懂又不敢说。

重要的问题的沟通应该是同步的，也即面对面沟通，这样除了语言上的反馈，还能通过表情得到一定的反馈。任何问题都要事先划分为若干阶段，最好脑子中有张拓扑图，后一阶段的理解会依赖于前一阶段的理解，一股脑把所有的信息放在对方面前，任何人都会晕。每经历一个阶段，都要收集一次反馈，作为信息的发送方，可以通过事先准备一些关键点的问题来检测对方是否真正了解，作为接收方，可以通过"你的意思是说。。。"等以自己的方式重复对方的表达来进行反馈。
注意拥塞控制，每一次的讨论争取一个小时内完成，再长效果会下降，接受者感觉信息被塞了满满一脑子，没有头绪，难有清晰的思路了。
每次沟通都应该至少有会议记录和部分结论，不然讨论等于白讨论，否则会发生团队经常开会，但是总在讨论同样一些问题，感觉上好像每次都在头脑风暴，其实效率很差。
对于重要的结论应该是面向连接的，也即书面(邮件，文档，wiki)告知，并有书面回复(ok, I am following the bug XXX)。
可以建立一些连接池，也即沟通的特定上下文。经过一定时间的团队磨合，可以下意识的创造或达成共识的一些词汇来代替一定的上下文，可以提高沟通效率。比如"明天甲系统出report"，则程序员明白要有单元测试覆盖率报告，QA明白要有当前bug的报告，性能测试组应该有甲系统性能测试报告。
沟通也是分层次的，最容易犯的错误的无论针对谁，写的文档，发的邮件都是一样的。其实针对不同层次的人，应该提供的信息不同，对于本团队人员，原理，架构，设计，测试，每步怎么做，结果如何，具体数据都应该说明，而对于其他团队的人员，具体的数据和每步怎么做就不需要了，对于项目经理，仅仅说明原理，架构，结论就可以了，对于高层来视察工作，原理加结果就行了。这也是为什么一篇文档有abstract, summary, overview, concepts, detail, appendix等等部分，其实是对不同的人员看的。

总结：项目或程序员的第三阶段：一生二，关键词：“沟通”

四、二生三

对于项目来讲，当Client/Server或者Master/Slave已经运行稳定，是应该开发一个Master多个Slave的时候了，即二生三的过程。

对于程序员来讲，当你能够很好的带一个实习生或者初级程序员的时候，是可以成为一个小的Team lead了。

此步的关键是load balance，平衡。

对于系统来讲，负载均衡最重要的是两个目的：

高可靠性：当一个服务器crash的时候，不至于影响对外提供服务。
高性能：多台服务器可以并行的做事情，提供服务，加快相应时间。

其实说到底，负载均衡采用的是Data partitioning(数据分块)或Data replication(数据复制)的方法。数据分块即按照某种策略，将某类请求全部指向某个服务器，比如说按照时间分块，例如邮件备份系统，可以将某个时间段的邮件全部放在一个服务器内，对这个时间段的查询全部指向此服务器；再比如按照地区分块，例如地图信息管理系统，将某个地区的数据全部放在一个服务器内。数据复制即将同样一部分数据复制多份，放在不同的服务器上，既保证高可靠性，又能将请求平均的分配给多个服务器，例如Google File system中将数据复制三份，大型网站的服务器也一般会将同一内容放在不同的服务器上。

对于程序员来讲，沟通同样重要，但是不再是局限于一对一的沟通了，不再是能把问题表达清楚就可以了，而是要在团队内部保持平衡。无论是工作压力，项目有趣程度，培训机会，成长机会都应该平衡。

也无非是两个目的：

高可靠性：项目不会因为一个人的生病，休假，离职而影响项目的进度。
高性能：整个团队的力量发挥出来，不至于一个人成为了瓶颈。

所采用的不过也是数据分块和数据复制的方式。

所谓数据分块，即不同的人负责不同的模块，比如一个负责前端，一个负责后端，或者一个负责开发，一个负责测试等，这能够带来高性能，因为每个人的专业化和经验会使得效率提高，但是同时带来的问题是高可靠性，如果转负责这个模块的人离开，换一个人将大大降低效率。工作压力也不能很好的平衡，往往一个系统的初期阶段，后端的开发十分忙，而前端相对较闲，而到了后期，前端开发非常忙，而后端已经稳定，因而较闲。况且，人不是机器，是有边际效应的，当负责一个模块时间一长，兴趣会大大降低，觉得没有成就感，成长也少了。因而数据复制的方式也是必要的，也即通过伙伴开发，Knowledge sharing，code review等方式，让不同模块的人之间相互了解对方的模块，从而带来高可靠性，也即一个人不在，其他的人可以较快的跟上，也可以在一个模块压力大的时候，其他人帮忙做一些辅助的东西，比如各种tool，测试用例，性能测试，甚至改一些优先级较低的bug，不仅平衡了工作压力，而且接触新的模块会使得员工有较大成长，也是工作更加有趣。

总结：项目或程序员的第四阶段：二生三，关键词：“平衡”

五、三生万物

如果道生一，一生二，二生三是质变的过程，则三生万物是量变的过程。

对于计算机系统来讲，如果一个master能够很好的平衡两三个slave，则可以很好的扩展到十个甚至百个，千个。但是原理是理想的，现实却是，当master管理的slave的数量达到一定的数目的时候，master就是一个瓶颈，master的高性能和高可靠性又成了问题，这时候可以用多个master进行数据复制从而负载平衡，也可以使得多个master每个管理一个group的slave，这时候就应该有master的master了，也即系统出现了分层。Hadoop的Multirack cluster就是这样的一棵树。

对于团队的管理也是同样的，每个人的直接管理精力在10个人左右，多于这些人，往往会有很多疏漏的地方，或者疲惫不堪，因而，当一个团队成长的一定的程度的时候，也是需要分层的。当团队增长的15至20人的时候，应该考虑从现有的人员中选出master，也即team lead或者至少是coordinator，使得组织也成为了一棵树装。

总结：项目或程序人生的第五阶段：三生万物，关键词：“分层”

分类: IT外企那点儿事

绿色通道：好文要顶关注我收藏该文与我联系

觉先关注 - 3 粉丝 - 560

荣誉：推荐博客 +加关注

0 (请您对文章做出评价)

« 上一篇：Lucene学习总结之八：Lucene的查询语法，JavaCC及QueryParser(2) » 下一篇：IT外企那点儿事(6)：管理路线和技术路线 posted on 2010-05-09 01:10 觉先阅读(6603) 评论(28) 编辑收藏

/#1楼 2010-05-09 01:29 Jianqiang Bao

下一章是离职吧：)

支持(0)反对(0) http://pic.cnitblog.com/face/u13430.jpg

/#2楼 2010-05-09 01:35 个人知识管理

太好了。我是一字一句看完后才写下。要是这样的资料能让更多程序员看到就好了。好的资料还是很稀缺的。但愿所有的人至少能看上三遍。反复阅读是最基本的个人知识管理的学习技巧。

支持(0)反对(0)

/#3楼 2010-05-09 09:21 Mainz

顶了~看完留名

支持(0)反对(0) http://pic.cnitblog.com/face/u28306.png?id=23214645

/#4楼 2010-05-09 11:01 李胜攀

太强了！

支持(0)反对(0) http://pic.cnitblog.com/face/26980/20130411124002.png

/#5楼 2010-05-09 11:29 o℃浪漫

一字一句，仔细斟酌过！谢谢总结！

支持(0)反对(0)

/#6楼 2010-05-09 12:04 Coki

和前四节文风和主旨好像有点脱节文章主旨似乎是在以软件工程的思路类比人的职业规划，但大量篇幅都是在讲软件开发的一些心得和要点，和职业规划没什么联动，对相似性的归纳描述不足。而且文章标题关键词是“升级”，按照这个文章系列的侧重，重点应该是个人自我能力的变化和升职的技巧，文章内容好像并没有什么关系。个人感觉这篇文章单独拉出来做一篇探讨项目管理心得的文章更好。仅本人一家之言，如有错误，还请谅解。

支持(0)反对(0)

/#7楼 [楼主] 2010-05-09 17:30 觉先

@Coki 谢谢您的建议，会在以后的写作中注意。

支持(0)反对(0) http://pic.cnitblog.com/face/u103165.jpg

/#8楼 2010-05-09 21:32 付晓强

好文章啊，很喜欢，如果转载了，不会说我什么吧。毕竟是好东西，开源一下吧。谢谢博主了。

支持(0)反对(0) http://pic.cnitblog.com/face/u131747.jpg

/#9楼 [楼主] 2010-05-10 00:31 觉先

@付晓强转载没问题，写明出处和链接就可以了。谢谢您关注

支持(0)反对(0) http://pic.cnitblog.com/face/u103165.jpg

/#10楼 2010-05-10 08:43 .COM 缺氧®

果断留名。

支持(0)反对(0) http://pic.cnitblog.com/face/u97502.jpg

/#11楼 2010-05-10 09:55 Jerry Qian

期待离职

支持(0)反对(0)

/#12楼 2010-05-10 14:32 别爱上哥，哥只是个传说！

为我2亿7千万人民币而奋斗.

支持(0)反对(0)

/#13楼 2010-05-10 17:21 老子不服

很有点哲学的味道

支持(0)反对(0) http://pic.cnitblog.com/face/u47315.jpg

/#14楼 2010-05-10 22:13 Leepy

写得不错，顶一顶！

支持(0)反对(0) http://pic.cnitblog.com/face/u18497.jpg

/#15楼 2010-05-11 12:57 chinese_submarine

不错，很受启发~

支持(0)反对(0) http://pic.cnitblog.com/face/u28698.png

/#16楼 2010-05-13 10:48 赵文星

好文章，是经验积累的结晶。

支持(0)反对(0)

/#17楼 2010-05-13 22:56 Likwo

好文。

支持(0)反对(0)

/#18楼 2010-05-14 00:54 Ken Wang

写得很好。

支持(0)反对(0)

/#19楼 2010-05-14 08:45 Gary Zhang

写得很细，这么走下来估计得个十五，二十年的时间吧。在这样浮躁的环境，急功近利的社会，不知道这样走过来的有多少人？

支持(0)反对(0)

/#20楼 2010-05-14 13:04 空逸云

LZ.很感谢你能这样分享自己的经验,作为一名即将毕业的学生.以前,我不明白为什么说一个程序员到了30左右逐渐就不行了呢?除了体力跟不上,原来主要还是时间.您让我知道了外企与国企(或者说民企)的区别.在这之前.一直想着该怎么学下去,原本以为.只要一直持之以恒,努力专研.net Framework就可以.花个4~5年时间做到熟知,善用的地步..现在明白.学习不是只学框架,而更该注重思想的学习.总之.很感谢您.或者说.最后这两篇文章都与外企没多大的关系.但是还是很喜欢看.看着其他的前辈做过的路.能让我对前方的路看得更加清晰.能未雨绸缪.THX.希望LZ能多写些有关于程序员成长方面的文章,更多的把自己的经历记录下来,好让我们这些后生多多学习.

支持(0)反对(0) http://pic.cnitblog.com/face/u88464.jpg?id=20154053

/#21楼 [楼主] 2010-05-14 13:22 觉先

@空逸云谢谢啊

支持(0)反对(0) http://pic.cnitblog.com/face/u103165.jpg

/#22楼 2010-05-17 13:23 东山飘雨，西关情

写的不错

支持(0)反对(0)

/#23楼 2010-05-22 17:00 Vincent Zhou

文章写的非常好，想问下楼主是在外企工作了多久才有这般体会的？

支持(0)反对(0)

/#24楼 2010-05-22 17:27 nbjkj

作为名刚入职场的程序员很高兴能拜读你的文章，很实用，理清了很多东西，谢谢！