遇见sharon ’ 的文章存档

大规模运行MongoDB应该知道的10件事

MongoDB的首席解决方案架构师Asya Kamsky 最近发表了一篇文章,概括了大规模运行MongoDB需要知道的10件事。

  1. MongoDB也需要DevOpsMongoDB是一个数据库。和任何其他的数据存储一样,它也需要容量计划、调整、监控和维护。不要因为它很容易安装、入门,同时与关系型数据库相比能够更加自然地满足开发人员的范例就认为MongoDB不需要适当的照顾和喂养。开发时它能在小样本数据集上超快地运行并不意味着你就不需要良好的模式、索引策略以及产品环境所需要的正确的硬件资源了。但是如果你准备的很好,并且理解最佳实践,那么运营大型MongoDB集群就会变得很无聊,而不是令人非常头痛。
  2. 成功的MongoDB用户会监控所有的事情,同时会做好增长的准备。在任何数据库系统中跟踪当前的容量以及容量计划都是基本的实践,MongoDB也是如此。你需要知道集群现在能够支撑多少工作,最高使用率时它会处理哪些需求。如果你没有注意到服务器上增长的负载,那么最终会遇到没有足够容量的错误。监控MongoDB可以使用MongoDB管理服务(MMS),通过查看操作计数器(opscounters)图表可视化自己的操作:a1
  3. 你可能并不希望系统随着使用量的增长出现性能扩展障碍。 根据大量用户的部署经验,性能瓶颈通常是(按顺序):
    • 应用程序访问模式没有使用最优的模式设计
    • 索引不佳或者缺失索引,抑或有太多不必要的索引
    • 磁盘较慢/磁盘IOPS不足
    • 索引没有足够的RAM

    事实证明,在真正的大型部署实践中对性能影响最大的是模式设计与应用程序需求的契合程度。而缺少索引、索引错误或者索引太多则是影响性能的第二大因素。在模式设计非常完美,索引也最优的情况下,磁盘IO吞吐能力就成了下一个限制因素,尤其是写吞吐量。RAM不足会引发很多页错误,同时也会增加磁盘IO的压力。

阅读全文

惹毛程序员的十件事

程序员是一个比较特殊的群体,他们因为长期和电脑打交道所养成的性格和脾气也是比较相近的。当然,既然是人,当然是会有性格的,也是会有脾气的。下面,让我来看看十件能把程序惹毛了的事情。一方面我们可以看看程序员的共性,另一方面我们也可以看看程序员的缺点。无论怎么样,我都希望他们对你的日常工作都是一种帮助。

第十位 程序注释

程序注释本来是一些比较好的习惯,当程序员老手带新手的时候,总是会告诉新手,一定要写程序注释。于是,新手们当然会听从老手的吩咐。只不过,他们可能对程序注释有些误解,于是,我们经常在程序中看到一些如下的注释:

每当看到这样的注释——只注释是什么,而不注释为什么,相信你一定会被惹火,这是谁写的程序注释啊?不找来骂一顿看来是不会解气了。程序注释应该是告诉别人你的意图和想法,而不是告诉别人程序的语法,这是为了程序的易读性和可维护性,这样的为了注释而注释的注释,分明不是在注释,而是在挑衅,惹毛别人当然毋庸置疑。

1 r = n/2;  //r是n的一半
2 
3 //循环,仅当r- n/r不大于t
4 while ((r-n/r) <=t){
5     //… …
6     r = 0.5 * (r-n/r); // 设置r变量
7 }

第九位 打断

正当程序沉浸于编程算法的思考,或是灵感突现正在书写程序的时候,但却遭到别人的打断,那是一件非常痛苦的事情,如果被持续打断,那可能会让人一下子就烦躁起来。打断别人的人在这种情况下是非常不礼貌的。被打断的人就像函数调用一下,当其返回时,需要重新恢复断点时的现场,当然,人不是电脑,恢复现场通常是一个很痛苦的过程,极端的情况下可能需要从头开始寻找思绪,然后一点一点地回到断点。

因此,我看到一些程序员在需要安静不被打扰的时候,要么会选择去一个没人找得到的地方,要么会在自己的桌子上方高挂一个条幅以示众人——“本人正执行内核程序,无法中断,请勿骚扰,谢谢!”,可能正在沉浸于工作的程序被打断是多么大的开销。自然,被打断所惹毛了的人也不在少数了。

第八位  需求变化

这个事情估计不用多说了。只要是是程序员,面对需求变化的时候可能总是很无奈的。一次两次可能还要吧接受,但也顶不住经常变啊。据说敏捷开发中有一套方法论可以让程序员们享受需求的变化,不知道是真是假。不过,今天让你做一个书桌,明天让你把书桌改成餐桌,后天让你把餐桌改成双人床,大后天让你把床改成小木屋,然后把小木屋再改成高楼大厦。哎,是人都会被惹毛了的。那些人只用30分钟的会议就可以作出任何决定,但后面那几十个程序员需要搭上几百个小时的辛苦工作。如果是我,可能我也需要神兽草泥马帮助解解气了。

不过,这也正说明了,程序员并不懂得怎么和用户沟通,而用户也不懂得和程序员沟通,如果一个项目没有一个中间人(如:PM)在其中协调的话,那么整个项目可能就是“鸡同鸭讲”,用户和程序员都会被对方所惹毛了。如果要例举几个用户被惹毛的事情,估计程序员的那种一根筋的只从技术实现上思考问题的方法应该也能排进前5名。

第七位  经理不懂技术

外行领导内行的事例还少吗?领导一句话,无论对不对,都是对的,我们必需照做,那怕是多么愚蠢多么错误的决定,我们也得照做。程序员其实并不怕经理不懂技术,最怕的就是不懂技术的经理装着很懂技术。最可气的是,当你据理力争的挑战领导权威的时候,领导还把你视为异类。哎,想起这样的领导别说是骂人了,打人的冲动都有了。

其实,经理只不过是一个团队的支持者,他应该帮助团队,为团队排忧解难。而不是对团队发号施令。其实管理真的很简单,如果懂的话,就帮着做,如果不懂的话,就相信下属,放手让下属做。最怕的就是又不懂技术,还不信任下属的经理了。哎,这真是程序员的痛啊。

第六位 用户文档

用户文档本来不应该那么的令人害怕。这些文档记录了一切和我们所开发的软件有关的一些话题。因为我们并不知道我们所面对的用户的电脑操作基础是什么样的,所以,在写下这样的文档的时候,我们必需假设这个用户什么也不懂。于是,需要用最清楚,最漂亮的语言写下一个最丰富的文档。那怕一个拷贝粘贴的操作,可能我们都要分成五、六步来完成,那怕是一个配置IP地址的操作,我们也要从开始菜单开始一步一步的描述。对于程序员来说,他们在开发过程中几乎天天都在使用自己开发的软件,到最后,可能都有得有点吐了,但还得从最简单的部份写这些文档,当然容易令他们烦燥,让程序员来完成这样的文档可能效果会非常不好。所以,对于这样的用户文档,应该由专门的文档人员来完成和维护。

第五位  没有文档

正如上一条所说的,程序员本来就不喜欢写文档,而因为技术人员的表达能力和写作能力一般都不是太好,所以,文档写的也很烂。看看开源社区的文档可能就知道了。但是,我们可爱的程序员另一方面最生气的却是因为没有文档。当然,让面说是的用户的文档,这里我们说的是开发方面的文档,比如设计文档,功能规格,维护文档等等。不过,基本上都是一样的。反正,一方面,我们的程序员不喜欢写文档,另一方面,我们的程序又会被抱怨没有文档,文档太少,或者文档看不懂。呵呵。原来在抱怨方面也有递归啊。据说,敏捷开发可以降低程序开发中的文档,据说他们可以把代码写得跟文档和视图似的,不知道是真是假。不过,我听过太多太多的程序员抱怨没文档太少,文档太差了,这个方面要怪还是怪程序员自己。

第四位 部署环境

虽然,程序员们开发的是软件,但是我们并不知道我们的程序会被部署或安装在什么样的环境下,比如,网络上的不同,RAID上的不同,BIOS上的不同,操作系统的不同(WinXP和Win2003),有没有杀毒软件,和其它程序是否兼容,系统中有流氓软件或病毒等等。当然,只要你的软件出现错误,无论是你的程序的问题,还是环境的问题,反正都是你的问题,你都得全部解决。所以,程序员们并不是简单地在编程,很多时候,还要当好一个不错的系统管理员。每当最后确认问题的原因是环境问题的时候,可能程序员都是会心生怨气。

第三位 问题报告

“我的软件不工作了”,“程序出错了”,每当我们听到这样的问题报告的时候,程序员总是感到很痛苦,因为这样的问题报告等于什么也没有说,但还要程序员去处理这种错误。没有明确的问题描述,没有说明如何重现问题,在感觉上,当然会显得有点被人质问的感觉,甚至,在某些时候还掺杂着看不起,训斥的语气,当然,程序员基本上都是很有个性的,都是软硬不吃的主儿,所以,每当有这样的语气报告问题的时候,他们一般也会把话给顶回去,当然,后面自己然发生一些不愉快的事情。所以,咱们还是需要一个客服部门来帮助我们的程序员和用户做好沟通。

第二位 程序员自己

惹毛程序员的可能还是程序员自己,程序员是“相轻”的,他们基本上都是持才傲物的,总是觉得自己才是最牛的,在程序员间,他们几乎每天都要吵架,而且一吵就吵得脸红脖子粗。在他们之间,总是被自己惹毛。

  • 技术上的不同见解。比如Linux和Win,VC++和VB,Vi和Emacus,Java和C++,PHP和Ruby等等,等等。什么都要吵。
  • 老手对新手的轻视。总是有一些程序员看不起另一些程序员,说话间都带着一种傲慢和训斥。当新手去问问题的时候,老手们总是爱搭不理。
  • 在技术上不给对方留面子。不知道为什么,程序员总是不给对方留面子,每当听到有人错误理解某个技术的时候,他们总是喜欢当众大声指证,用别人的“错误”来表明自己的“博学”,并证明他人的“无知”。
  • 喜好鄙视。他们喜好鄙视,其实,这个世界上没有一件事是完美的,有好就有不好,要挑毛病太容易了。程序员们特别喜欢鄙视别人,无论是什么的东西,他们总是喜欢看人短而不看人长。经常挂在他们嘴上的口头禅是“太差”、“不行”等等。

程序员,长期和电脑打交道,编写出的代码电脑总是认真的运行,长期养成了程序员们目空一切的性格,却不知,这个世界上很多东西并不是能像电脑一样,只要我们输入正确的指令它就正确地运行这么简单。程序员,什么时候才能变成成熟起来……

第一位 程序员的代码

无论你当时觉得自己的设计和写的代码如何的漂亮和经典,过上一段时间后,再回头看看,你必然会觉得自己的愚蠢。当然,当你需要去维护他人的代码的时候,你一定要在一边维护中一边臭骂别人的代码。是否你还记得当初怎么怎么牛气地和别人讨论自己的设计和自己的代码如何如何完美的?可是,用不了两年,一刚从学校毕业的学生在维护你的代码的过程当中就可以对你的代码指指点点,让你的颜面完全扫地。呵呵。当然,也有的人始终觉得自己的设计和代码就是最好的,不过这是用一种比较静止的眼光来看问题。编程这个世界变化总是很快的的,很多事情,只有当我们做过,我们才熟悉他,熟悉了后才知道什么是更好的方法,这是循序渐进的。所以,当你对事情越来越熟悉的时候,再回头看自己以前做的设计和代码的时候,必然会觉得自己的肤浅和愚蠢,当然看别人的设计和代码时,可能也会开始骂人了。

文章来自:http://www.cnblogs.com/ymind/archive/2012/03/26/2418627.html

 

提高Web程序员积极性的10种方法

和其他行业一样,Web设计工作其实也是比较枯燥乏味的。如果我们总是将我们所有的时间都用在工作上而忽略其他,反而会影响我们的激情和积极性。

a1

而,激情和积极性,是一种能促使我们全神贯注、专心致志工作、面对挑战也不皱一皱眉头的神奇力量。如果你想在这一行干得出色、干得成功,那么激情和积极性绝对必不可少。或者简而言之,这就像是一个反馈循环。

无论你对Web设计这份工作的喜爱程度如何,当然有可能你只是做一天和尚撞一天钟,每天只是随大流例行检查般看看电脑就算完事;又或者你森森地觉得只要不让你搞网站(甚至是看一眼),其他啥事都成。但是又因为有时间限制或者是目标设定,你会觉得你是在被迫工作。
阅读全文

20个设计模式和软件设计面试问题

不管是参加Java面试还是C#面试,设计模式和软件设计都是任何编程面试中的必问问题。实际上,编程能力和设计技巧是对彼此很好的补充。一个好的程序员通常都是一个好的软件设计人员。他们知道怎么把一个问题分割成一段段代码或者软件设计,但这些能力和技巧并不能凭空而来。你需要持续做大型、小型系统的设计和编码,并且不断从错误中学习。从面向对象设计原则 开始是一个不错的选择。好吧,这篇文章是关于一些在各种面试中频繁问到的一些设计问题。考虑到针对性和困难度,我把它们分成两个种类,分别针对初学者和有经验的人。

对中高级别的设计模式面试问题

这是一些和设计模式还有软件设计都相关的问题。这些问题需要一些思考和经验来回答。在大多数情况下,面试官并不是需要一个确切的答案,而是希望听到你的想法,你对这个问题是怎么考虑的,你能不能想通这个问题,能不能挖掘一些没有告诉你的潜在信息。在解决一个问题时你应该考虑什么等等可以使你经验大涨。总的来说,这些设计问题会让你动起脑来。有时面试官也会让你写代码,所以还是准备一下吧。如果你知道编程和设计技巧中的概念,例子和程序,你应该可以在这些问题中有突出的表现。

1. 举出一个例子,在这种情况你会更倾向于使用抽象类,而不是接口?
阅读全文

Java中弱引用、软引用、虚引用及强引用的区别

很早Java API就添加了弱引用(WeakReference)和软引用(SoftReference),但并不是所有的程序员都熟悉这两个概念。知道弱引用和软引用的概念与如何使用它们是两码事,引用类在垃圾回收工作的过程中有重要作用。我们都知道垃圾回收器会回收符合回收条件的对象的内存,但并不是所有的程序员都知道回收条件取决于指向该对象的引用类型。这正是Java中弱引用和软引用的主要区别。如果一个对象只有弱引用指向它,垃圾回收器会立即回收该对象,这是一种急切回收方式。相对的,如果有软引用指向这些对象,则只有在JVM需要内存时才回收这些对象。弱引用和软引用的特殊行为使得它们在某些情况下非常有用。例如:软引用可以很好的用来实现缓存,当JVM需要内存时,垃圾回收器就会回收这些只有被软引用指向的对象。而弱引用非常适合存储元数据,例如:存储ClassLoader引用。如果没有类被加载,那么也没有指向ClassLoader的引用。一旦上一次的强引用被去除,只有弱引用的ClassLoader就会被回收。这篇文章中我们将讲述不同类型的Java引用,例如:强引用(Strong Reference)和虚引用(PhantomReference)。

Java中弱引用VS软引用

Java中有如下四种类型的引用:

  • 强引用(Strong Reference)
  • 弱引用(WeakReference)
  • 软引用(SoftReference)
  • 虚引用(PhantomReference)

强引用是我们在编程过程中使用的最简单的引用,如代码String s=”abc”中变量s就是字符串对象”abc”的一个强引用。任何被强引用指向的对象都不能被垃圾回收器回收,这些对象都是在程序中需要的。弱引用使用java.lang.ref.WeakReference class 类来表示,你可以使用如下代码创建弱引用:

Counter counter = new Counter(); // strong reference - line 1
WeakReference<Counter> weakCounter = new WeakReference<Counter>(counter); //weak reference
counter = null; // now Counter object is eligible for garbage collection

现在只要你给强引用对象counter赋空值null,该对象就可以被垃圾回收器回收。因为该对象此时不再含有其他强引用,即使指向该对象的弱引用weakCounter也无法阻止垃圾回收器对该对象的回收。相反的,如果该对象含有软引用,Counter对象不会立即被回收,除非JVM需要内存。Java中的软引用使用java.lang.ref.SoftReference类来表示,你可以使用如下代码创建软引用:

Counter prime = new Counter(); // prime holds a strong reference – line 2
SoftReference soft = new SoftReference(prime) ; //soft reference variable has SoftReference to Counter Object created at line 2

prime = null; // now Counter object is eligible for garbage collection but only be collected when JVM absolutely needs memory

 

强引用置空之后,代码的第二行为对象Counter创建了一个软引用,该引用同样不能阻止垃圾回收器回收对象,但是可以延迟回收,与弱引用中急切回收对象不同。鉴于软引用和弱引用的这一区别,软引用更适用于缓存机制,而弱引用更适用于存贮元数据。另一个使用弱引用的例子是WeakHashMap,它是除HashMap和TreeMap之外,Map接口的另一种实现。WeakHashMap有一个特点:map中的键值(keys)都被封装成弱引用,也就是说一旦强引用被删除,WeakHashMap内部的弱引用就无法阻止该对象被垃圾回收器回收。
阅读全文

对于Linux系统管理员很有用的16个在线工具

1. ExplainShell.com 命令解释

a1

 

 

对于Linux用户来说每天都会写各种命令和脚本,那么你可以使用这个网站工具来查看命令式如何工作的,这样可以避免不必要的错误出现;也是一个很好的学习命令的方式
阅读全文

程序员生存定律-打造属于自己的稀缺性

假设说你想在江湖里谋求一定的地位,那么你可以练习独孤九剑成为超一流高手,也可以练习医术,成为绝世神医。这两者在江湖里都是有地位的,也都是稀缺的,一者是因为杀伤力,二者是因为人都有山高水长。

程序员也一样,增值也好,改善表达力也好,最终都要在某种环境下达成一定的稀缺性,这样一个人才有价值。稀缺性同时受两个维度上的力量影响:一个是自身的努力,比如前文所提到的增值和表达力;一个是大环境的变化以及对这种变化的适应。在这一章里主要关注的是后者。

稀缺性可带给你什么

既然稀缺性对个人有如此大的影响,那稀缺性到底可以带给一个人什么样的影响,我们来看一个简单的例子:

在日本曾经有这样一个故事。一个人在某电信公司负责一个大型系统的维护,收入虽然不菲,但时间一长,这个人就对薪资发展不太满意,因此最终选择了离开。结果他一离开,这大型系统立时跑的磕磕绊绊,无奈之下,这家电信公司只得以高职厚薪把这个人请了回来。可以想见为了达到这一目的,这家电信公司,无论在收入还是职位上必然都开出了让这个人无法拒绝的条件。
阅读全文

25种提高网页加载速度的方法和技巧

您希望加快网页的加载速度吗?了解如何通过缩短加载时间来改善拨号上网用户的浏览体验,在某些情形下,加载时间最多可缩短 80%。

引言

不是所有人都能够使用高速 Internet 连接。即使每个人都能够使用高速网络,也会因为各种各样的原因使您的 Web 应用程序看起来运行缓慢。在这个宽带速度不断提高的时代,您应当关注一下页面加载时间。将珍贵的页面加载时间缩短几秒,将更加珍贵的请求和响应时间缩短几毫秒。您将为访问者创造一种更好的体验。

阅读完本文之后,您将能够较好地了解网页加载时间优化的基本知识。您还能够使用工具和知识更好地识别和判断加载缓慢的页面部分和瓶颈。

先决条件

在理想情况下,您应该安装了 Mozilla Firefox。您还应该大体了解 Web 开发。本文涉及的主题并不复杂,但是如果您了解超文本标记语言(Hypertext Markup Language,HTML)、层叠样式表(Cascading Style Sheet,CSS)以及 ™ 编程语言等主题,那么在学习本文时将更加得心应手。不需要使用集成开发环境(IDE),只需使用您喜爱的编辑器。
阅读全文

用chrome浏览器实现手动“自动填充表单”

现在的浏览器基本都有自动填充表单的功能,可以极大的节约我们填写一些常见表单,尤其是登录表单的填写时间。

但是现在随着用户需求的不断发展,很多网页都是使用js来实时进行表单提交的操作,这些操作可能根本不涉及实际的submit操作,所以不会被浏览器截获并记录,这个时候面对一些需要反复重复填写的常见的表格就很郁闷了。

不过还好,这种情况依然是可以实现手动“自动填充表单”的,方法就是利用chrome浏览器的console功能。方法是在要填写表单的页面上按F12,点击console。
阅读全文

程序员生存定律-选公司前要干的事:分类

目录

  1. 给公司分类
    1. 分类的方法
    2. 具体类别的点评外包行业
    3. 具体类别的点评互联网行业
    4. 具体类别的点评外企
    5. 具体类别的点评受非市场因素影响大的公司

在武侠的世界里,帮派本身借助了个人的力量而成其威名,但反过来个人却又因为帮派的力量而被烘托的更高。如果我们把公司类比为帮派,把程序员类比为一众江湖人士,那么帮派和成员间这种异化、同化的过程就几乎在每一个程序员的身上都可以看到。

牛顿说过一句广为流传的话:如果说我比别人看得更远些,那是因为我站在了巨人的肩上。选择在什么样的公司里工作,几乎等价于选择站在什么人的肩膀上。再形象点讲就是选错了公司等价于输在起跑线上。

公司提供的岗位决定了你所接触的技术、人物,进一步决定了你的眼界、能力和人脉,也一定程度上决定了你履历的价值。这些都是对一个人至关重要的东西。

假设说一个人在大学里非常的优秀,以较高的薪资加入了一家做生僻技术的公司,5年后,这家公司倒闭了,这时候这个人可能会陷入困境,甚至变的不如很多大学里成绩比他差很多的人。这类事情往往并不是因为个人不努力,往往是因为选择不慎而把自己给憋到死角里了。

每个人要想争得选择权往往并不容易,大学四年的努力挣来的选择权却可能在一时不慎下毁于一旦。这种选择往往很难很精确,但有几个基本项目还是可以考察的。这些项目将在下面各节里逐步展开。

 

给公司分类

公司是一个含混的词,要想弄清楚公司对人生的影响,那么先要给公司分类。一说到分类大多数人可能首先会想到好公司或者坏公司,但其实这是分类的结果,在好和坏背后往往都有着一打的因素来支撑一个公司是好还是坏。不了解这些背后的因素,单纯根据一个笼统的好或坏实际上是很难判定一个公司是不是适合自己的。

 

 分类的方法

一个人要想做对选择,一要有选择权,二则要了解待选项。在这里待选项就是公司的类别。可以有非常多的视角对公司进行分类,这里主要列举和职业发展紧密相关的几个。

 

  • 分工所处位置的视角

 

帮派间是有食物链的,比如东方不败的魔教就凌驾在黄河帮之上。还不用东方不败或任我行这种大头目出来,只是盈盈就可以让这些帮派鞍前马后了。

类似的关系也存在于公司与公司之间,但这时这种关系则是有产业分工时公司所处的位置所决定的。即使我们不用心去做非常详细的调查,也可以看到iPhone生产背后的三层结构:苹果 + 富士康 + 元器件供应商。

这种链条的一个根本特征是上游的企业人少但分享的利润更高,当然其承担的创新风险也更大。

在这里无意对这种分工模式是否合理进行更多的探讨,想强调的则是,这是影响个人工作和发展的一个很重要的维度,不考察是对自己不负责任的。

商业社会中的公司所处的位置可以做简单理解:筹码多的,控制权、发言权大的在上端。比如:付钱的在上端,靠别人给钱的在下端。垄断的或接近于垄断的在上端,被垄断的在下端。比如说:公司A把业务分包了给公司B,那么公司A在食物链的上端,公司B则在下端。比如说:公司G直接面向客户,占有了市场份额60%,其他公司分享其他的40%,那么G在上端,其他公司在下端。在这个视角下可以把公司分为发包的公司,接包的公司。从分工的角度看,一个公司所处的位置越靠后,其利润空间可能也就越微薄。

与这类分工相关的场景还有很多,比如:母公司与子公司、发包的和接包的、做操作系统的和必配指定操作系统的硬件厂商、做电商平台的和各个产品制造商等等。

从选择公司的角度,应该尽可能考虑上游的公司,因为这种分工上的位置对成长空间和收入会有比较大的影响。

 

  • 行业的视角

 

在这个视角下,公司往往被分为电信、金融、互联网、ERP、游戏、嵌入式等。很难讲那个行业相对另一个行业具有绝对优势,但有两点需要额外注意:

一是软件是不是公司的主营业务对发展空间往往会形成一定限制。制造业的工厂里也做软件,但不太可能选几个做软件的去做厂长,金融公司里程序员也很难发展成为总裁。

另一点是有的子行业处在成熟期,发展相对平缓,而有的子行业则处在告诉发展期,发展很迅速。后者机会更多,年轻人尤其是容易在全新的领域出头。这是因为在全新的领域中没有既定的利益格局,所有人都在同一起跑线上。

从选择公司的角度看,无疑的要尽可能选选主营是软件并在高速发展子行业的公司。而之所以选择行业非常重要,根本原因是一旦选择了那个行业,那很可能一辈子就会干这个了。做金融的很难去做互联网,做互联网的也很难去做嵌入式。

 

  • 时间轴的视角

 

从生命周期来看,公司可以分为发展期的公司,成熟期的公司和衰落期的公司。

从选择公司的角度看,极力要避免的是衰落期的公司。识别衰落期的公司简单的办法是财务数据和市场地位。已经赤字的或市场地位已经排位靠后的都是相对比较危险的公司。

而选择发展期的公司还是选择成熟期的公司上,要依赖于个人选择。通常来讲选择成熟度较高,市场地位较高的大公司会比较好,便于做技术积累。

 

  • 核心竞争力的视角

 

有的公司是核心竞争力偏向于销售渠道,有的则是技术,有的则是两者并重。

比如对于信息管理系统销售渠道就比较重要。从这个视角看,有核心竞争力的公司总是比没有的更好。而在有核心竞争力的公司里,技术导向的公司无疑更适合程序员。前面曾经提到过,非技术导向的公司里,技术路径通常会短。比如说:只做信息管理系统的公司技术路径通常不会长。

 

  • 地域的视角

 

从这个视角可以把公司分为一线城市的公司,二线城市的公司。地域主要影响可流动范围。

在2012年曾经发生了一起很有点影响的事情:摩托罗拉移动因为经营的原因,关闭南京摩托罗拉移动,裁掉了整个团队,这个时候南摩员工联合起来,一起拒绝在离职协议上签字。员工和公司前后经历多轮谈判,员工方坚持不让步,其中的一个关键理由就是:500多人一起在南京找工作非常困难。与此相对应的则是,同样是裁员,但北京方面所有员工皆较快签字走人。

这一事请本身的是非很难去评论,但南京和北京员工的不同反应却可以一定程度上折射出城市(或者说地域)所带来的影响。

南京已经是非常发达的城市,但500人的队伍已经会担心很难被吸收掉,在北京恐怕这500人就掀不起什么波澜。这很好理解,一升水倒在矿泉水瓶子里,会溢出来,但如果倒在小河里,就几乎等价于不存在。但这种城市对人员的容量对可流动性、对发展空间却会形成一种刚性的制约。

当一个人选择了某个公司的城市,也就选择了其背后隐含的一切,对于大多数人而言与城市的关联度将会随着时间的流逝而越来越高(这体现在学校、房子等方面),所以适当对此进行考察是有必要的。

总的来看越是期望快速发展,越是希望开创一番事业,对自己越是有信心,越适合到一线城市发展;而相应的越是希望安稳,越是侧重生活和工作的平衡,二线城市就更适合一点。

 

  • 公司文化的视角

 

如果去翻阅管理相关的书籍比如《基业长青》,《赢》等,你就会发现公司的文化被放在一个非常高的位置上。极度优秀并可存续的组织无疑是需要一种共同的价值取向来镇压气运的,但这和现实其实有点远。现实中的很多公司更可能是规则和个人双重驱动,而没有什么明显的文化特征。所以这种分类视角被放在了最后。

很难讲那种企业文化一定会成功,但如果从负面来解读文化的话,有一种文化却几乎一定会使公司挂掉。这种文化可以叫做蠹虫文化。典型特征是:一盘散沙,所有人都一起糊弄工作,工作上的事情能推就推。这类公司几乎一定会比较快的走向毁灭,除非是有某些垄断性的因素可以确保其生存。

 

具体类别的点评:外包行业

 

很难笼统的讲外包行业好或不好,有前途没有前途,因为外包也有很多层次。

假设说一家公司把一款手机从设计到制造的所有环节都外包给一家公司,只是最后自己进行贴牌,那么对于承接这种外包业务的公司而言,单纯从技术角度看与自己进行产品开发并无差别。

假设说一家银行把需求之外所有的业务都外包给一家公司,那么对于承接这种业务的外包公司而言,就更像是银行的IT部门。

上面这类外包与特定企业的核心业务相关联层次是比较高的。与此相对应,外包业务的层次可以逐级降低,比如:同样是银行业务,在外包过程中也可以把基础设计都完成之后,把量较大,但没有技术难度的编码工作外包给其他公司。这类工作往往是由成本控制而触发,所以在分工链条上所处的位置越低,工作越容易辛苦,且收入较低。

这点上可以看一点数据,当前国内最大的外包公司是文思海辉,根据公开数据,文思海辉在2012年总计有员工23270名,总收入是3.59亿美元,大致是22.7亿人民币,平均每人年创造不到10万元的收入。与之相对应,腾讯2012年总计有员工24160名,总收入438.9亿人民币,平均每人年大约创造181.6万元。这种数据大致可以说明从分工链条的角度看,国内的外包公司仍然有很大的提升空间。

那究竟加入外包公司是怎么样的一种选择?

这不能说是很差的选择,但如果让我来排个顺序则首先是知名的独立软件开发商(ISV),其次是前景比较好的独立软件供应商,接下来才是做高端外包业务的公司,做低端外包业务的公司大多时候不是什么好的选择,因为对个人成长不利。

 

具体类别的点评:互联网行业

如果说IT行业是朝阳行业,那互联网绝对是朝阳中的朝阳。在这个领域中我们看到了门户网站,看到了搜索引擎,看到了社交网络,看到了各种云平台和大数据,但故事应该远未终结。未来究竟出现什么样的产品很难预测,但未来的产品会和互联网紧密相关这点错的可能性很低。

所以在行业选择上加入一家以互联网业务为核心的公司是不错的选择,从发展的角度看很同等条件下要比加入通信、金融这样的行业更有优势一点。

假如一个人想创业,那这就更是一种必然选择,互联网是智力密集型的工作,需要一定资本,但对资本的要求并不高,几个人拉到风险投资后,假设网站开始创业怎么也比研发路由器开始创业更适应于一般人一点。

这里面在分类上有一个微妙的地方需要注意,搜索引擎、大数据、社交网络可以认为是互联网,但挪到互联网上的ERP也还是ERP,不能算是互联网行业,这个差别很大,考察公司的时候要注意。

具体类别的点评:外企

按国别来区分企业,误杀的几率很大。但毕竟同一国家的企业还是有些共通的特征,因此这里择取两个视角做一个简单的分析。一个视角是透明天花板的高低;一个则是规范程度。

什么叫透明天花板?职业路径被封死在某个高度以下,但这种封锁在可见制度层面又不存在,这就是透明天花板,往往是做到一定高度的人对此感受的更为清晰。平心而论,透明天花板在那里都有,本身倒不一定就具有贬义。但不同企业中其高度确实不同。如果要排个次序,那就是是国内企业高于欧美企业,欧美企业高于日韩企业。

理论上讲一个人在国内企业里的发展是不受高度限制的,可以想见联想,阿里巴巴未来的接班人还是个中国人,空降个黑人或白人CEO的可能性不大。而欧美企业相对开放,至少在大中华区,高层人士里还主要是华人,但想再往上走则很艰难。这可以从李开复老师的自传里读出些端倪,李老师无疑非常优秀,但从自传里绝对看不到成为微软或者Google CEO的可能性。高晓松老师在优酷上做了个很有意思的节目叫《晓说》,里面更是很直接的谈到这一点:在好莱坞就是犹太人升迁快,华人虽然收入高,但就是有天花板,要很辛苦工作来维持自己的收入。

在日韩企业这点上就收的比较紧一点,各个子公司的负责人基本上会选本国人。

所以假如说你认为自己非常优秀,并且期望无限的发展空间,那么优选本土公司(也许注册地不是中国)是对的,虽然它们的CEO没准也是美国华裔,虽然它们可能会有一些负面的报道,虽然不管怎样成为CEO都是一种可能性非常低期望,但至少存在着这种可能性。

顺道说一句,从这个角度上看,我们真有理由希望这个国家和对应的企业强大,只有如此,大多数和本土的优秀人才会有更加光明的未来。

从规范程度来讲,越是本土企业,反而可能会越差一点,这也符合知己知彼百战不殆原则,虽然有点黑色幽默。而跨国企业往往是些大公司,在规范性这点上都会非常的注意。我个人倒是感觉,只要没滑落到无赖公司的地步,稍微有点不规范也是可以接受的,犯不上刀兵相见。所以说单纯的希望成为优秀的工程师,那么优秀的外企仍然是个不错的选择。

具体类别的点评:受非市场因素影响大的公司

非市场因素影响大的公司是个诡异的类别,完全是我杜撰出来的,这个类别的公司特征是可以因为特别的机会(某个大单或某项特别资助)在短时间蓬勃发展,但接下来又很可能会在短时间轰然倒下。在IT业中最典型的例子托普,有点年纪的IT人应该还记得这家公司。

我个人倾向于认为应该规避这类公司,因为这类公司通常并不会把精力放在产品的开发上,而会放在非市场因素的经营上,这对个人成长并不是很有利,尤其是走技术方向的人。一旦公司出现危机,那么个人反倒可能会因此陷入困境。

上面的文字有点含糊,为了把事情说的更清楚一点,我们来看一个历史上的故事。

中国人里面不知道胡雪岩的恐怕不多。胡雪岩出身不高,几近于白手起家,先后得王有龄、左宗棠之助迅速成为显赫一时的红顶商人。百度百科上对这段往事的记载是:

他从扫地、倒尿壶等杂役干起,三年师满后,就因勤劳、踏实成了钱庄正式的伙计。正是在这一时期,胡雪岩靠患难知交王有龄的帮助,一跃而成为杭州一富。

王有龄,字英九,号雪轩,福建侯官人。在道光年间,王有龄就己捐了浙江盐运使,但无钱进京。后胡雪岩慧眼识珠,认定其前途不凡,便资助了王五百两银子,叫王有龄速速进京混个官职。后王有龄在天津遇到故交侍郎何桂清,经其推荐到浙江巡抚门下,当了粮台总办。王有龄发迹后并未忘记当年胡雪岩知遇之恩,于是资助胡雪岩自开钱庄,号为阜康。之后,随着王有龄的不断高升,胡雪岩的生意也越做越大,除钱庄外,还开起了许多的店铺。

庚申之变成为胡雪岩大发展的起点。在庚申之变中,胡雪岩处变不惊,暗中与军界搭上了钩,大量的募兵经费存于胡的钱庄中,后又被王有龄委以办粮械、综理槽运等重任,几乎掌握了浙江一半以上的战时财经,为今后的发展奠定了良好的基础。

 

胡雪岩之所以可以迅速倔起,除了得益于王有龄之外,另一个人也起到了重要的作用,这个人就是左宗棠。1862年,王有龄因丧失城池而自缢身亡。经曾国藩保荐,左宗棠继任浙江巡抚一职。左宗棠所部在安徽时晌项已欠近五个月,饿死及战死者众多。此番进兵浙江,粮饱短缺等问题依然困扰着左宗棠,令他苦恼无比。急于寻找到新靠山的胡雪岩又紧紧地抓住了这次机会:他雪中送炭,在战争环境下,出色地完成了在三天之内筹齐十万石粮食的几乎不可能完成的任务,在左宗棠面前一展自己的才能,得到了左的赏识并被委以重任。在深得左宗棠信任后,胡雪岩常以亦官亦商的身份往来于宁波、上海等洋人聚集的通商口岸间。他在经办粮台转运、接济军需物资之余,还紧紧抓住与外国人交往的机会,勾结外国军官,为左宗棠训练了约千余人、全部用洋枪洋炮装备的常捷军。这支军队曾经与清军联合进攻过宁波、奉代、绍兴等地。 胡雪岩是一位商人,商人自然把利益放在第一位。在左宗棠任职期间,胡雪岩管理赈抚局事务。他设立粥厂、善堂、义垫,修复名寺古刹,收硷了数十万具暴骸;恢复了因战乱而一度终止的牛车,方便了百姓;向官绅大户劝捐,以解决战后财政危机等事务。胡雪岩因此名声大振,信誉度也大大提高。这样,财源滚滚来也就不在话下了。自清军攻取浙江后,大小将官将所掠之物不论大小,全数存在胡雪岩的钱庄中。胡以此为资本,从事贸易活动,在各市镇设立商号,利润颇丰,短短几年,家产己超过千万。

 

没仔细考证过,也许上面的描述与历史有所偏差,但其崛起与左宗棠有紧密关联这一点,大致不错。胡雪岩成功的快,败落的也很快。败落的原因很多其中关键的一条就是在李鸿章与左宗棠的内斗。从发迹到败落前后大概20年。但在现代这种变化节奏因为某些原因变快了,往往不要20年,托普走完这条路用了10年左右,未来就可能会更短。从这个角度看,这类公司是不适合纯粹的工程师的。

文章来自:http://blog.csdn.net/leezy_2000/article/details/38377735