程序员生存定律--成长路上常见的坑

> 程序员生存定律--成长路上常见的坑

  1) http://blog.csdn.net/offbye/article/details/36873073

  2) http://blog.csdn.net/offbye/article/details/36872505

国内互联网公司，纯技术路线不好走，做一个具备综合能力的人才往管理方向走更容易晋升。所谓的综合能力，就是除了技术，还要会装逼，忽悠，扯淡，圆滑（当然，这是我用不雅的词语来形容，是我个人偏见）。

> 截取的观点：

  在终端用户编程上，自己去写算法的机会非常的少，甚至可能没有。反倒是业务领域知识（会计知识）、OO、设计模式、甚至于估算这些知识都比研究算法更有价值。 既然如此，那么从务实的观点上看，为什么去学习不能在可见范围内创生价值的东西，而不是去学习立刻可以变现的东西。走极端的人会找出需要写算法的例子来反驳上述立论，但点不足以表征面，即使偶尔需要自己了解下算法，真就值得花那么多时间去学习么，为什么不尽可能借鉴现成的。

  从方法上讲，聚焦就是找到一个适合自己大小的区域，然后做深。才华横溢的不论，一般来讲，横向穿越和纵向穿越都不太行，除非已经基本穷尽当前的领域。纵向穿越是指从底层穿到上层（想想开发网络协议的和用网络协议的），横向穿越则指横跨太多的领域（想想从内核驱动跨越到信息管理软件）。

  有时候会看到这样一种现象：很多人自学的东西和工作中用的东西完全没关系。比如：一边用着C#做Web开发，一边自己学习着C/C++做嵌入式。这事并不一定不对，只能说非常危险，很可能会导致那样都没有高度。我们得承认当人生被错位的时候，往往只能这样来改变命运，这是没办法，也是正确的。但首先要认识到这样做是相当低效的，低效到一定程度后对的事情也并不一定有结果。

  解决艰难问题时，天分很重要；解决复杂问题时，练习很重要。所以软件开发的学习过程中，实践很重要，纯理论知识的权重较低，当然基本的算法复杂度还是要明白的。

  假设说一个人的学习已经聚焦，并且学习的内容和自己实际参与的项目也相吻合，那么是不是就没有问题了？很不幸，答案仍然是否定的，在任何一个子领域里，仍然需要进一步去考虑“博”与“专”的均衡。

  对于软件开发而言，设计是再常见不过，再简单不过的一个词了。可如果把视角拔高一点就会发现，单以设计而论仍然是一个不可穷尽的领域，我们可以快速扫描一下和设计相关的部分概念：
  面向对象分析与设计
  结构化分析与设计
  模型驱动开发
  契约式编程
  面向方面的开发
  基于组件的开发
  元编程
有些时候方法论也会和设计牵扯到一起：
测试驱动开发
敏捷软件开发

> 与此同时，把一个API研究的再透，也是低值人群，因为这种深入理解和单纯会用某个API相比，从创造价值的角度看，差别不大。

  这也就意味着对于大多数软件开发人员而言，要去寻找广博与精专间的均衡点：既不能闭上眼睛，也不能就用显微镜来看世界。而这一均衡点的价值则可用反木桶原理来说明：木桶原理说的是桶里的水是由最短的一块板决定的，但考量人的价值时却是适用于反木桶原理，即人的价值往往由最长的一块板决定。

  产品开发往往和公司的现金流绑定的更紧，能为现金流贡献力量的技术才是有价值的技术。而产品开发本身事实上对博和专的程度提出了最基本的要求，这种要求往往具有迭代的特质。

  在第一次跌代里，往往需要达到两个最基本的目标。第一个目标是可以为产品贡献自己力量，但代码质量普通。这个目标如果达不到，一个人会失去自己的存在价值。
  这时候最少需要了解某种语言（比如：C++)、某个平台（比如：Windows)、某个IDE（比如:Visual Studio)和某些业务相关的知识（比如：打印体系）。这个范围可以尽可能圈的小点，但用到的则要学透。比如：不管接触到那个框架，都要去了解它的内存机制、线程机制、异常处理组件构建和国际化处理这些全局性的机制，而不能只是了解某个接口怎么用。
  把事情做好，并能负担些层次更高的工作。这时候要比较深入的了解面向对象、结构化方法、设计模式、理解设计原则，并能把它们用好。至少要能判定，这个程序写的好，那个程序写的不好，同时面对需求能把工作进行下去。
  简单来讲越是没实践经验的人越不适合学习软件工程，越需要规划整体把握全局的时候越需要学习软件工程。
  软件工程中覆盖的元素非常繁杂，可以有管理、流程、开发模型、估算、分析设计方法等。这无疑会把知识面扩展的很宽，一旦没有根底，就很容易变成纸上谈兵，夸夸其谈。
  既然更加复杂纷繁的历史都可以总结出规律，忽视软件开发的内在规律无疑的对有志于成为管理者的人是不利的。真要学习软件工程，不太适合从抽象层次很高的教科书开始，而适合从《代码大全》这样与实际关联比较紧密的书籍开始。

> 对于大多数人而言，人生就像个模板，小处还有偏差，大处却基本相同。
20~30岁这个阶段可以讲是黄金时期，这个阶段里，家庭负担较小，可以自由支配的时间较多。当然撞到了很特别的、需要疯狂加班的公司只能另算。
30岁之后因为娃娃出生等，家庭上的时间开销增加，个人可支配时间变少。其中很大一部分人还有很大可能会面对电视剧里常说的婆媳矛盾，让你每天心绪不宁。
40岁之后，家庭琐事会进一步增加，典型的上有老下有小。实在运气不好的自己也会生点病---颈椎病、腰间盘突出、胃病大概可以入选程序员的三大职业病。
50岁之后，时间上会再次解脱，但可惜的是自己也老了，时机不在。
如果把人生按照年龄画一条抛物线的话，40岁左右一个人可以达到的人生的顶点，未来再突破的几率则变小。从历史人物来看，大器晚成的不是没有，但真的很少。

  很多人很大的一个错误在于，在黄金时期，没做什么积累，就顾得享受生活了，而一旦意识到积累的必要性时，却又受困于诸多琐事而欲振乏力，最终人生高度有限，并迅速走低。这就是现代程序员版的“少壮不努力，老大徒伤悲”。

  基本上讲，35岁以前要把需要花大量时间，比较硬的技能，学习曲线陡的技能掌握，具备工作所需要的所有主要技能，而35岁之后则主要关注知识的更新和某些软技能。

  学习时添水战术效率真的很差，每次点一根火柴烧水，一亿年水也烧不开一壶。同时，比较硬的技能（比如：Donald Knuth的《计算机程序设计艺术》)往往是需要大块时间投入的，但年纪越大时间越呈现为碎片化，越难搞定硬的知识---先天就容易造就添水战术。比较软的技能，则可以用碎片时间来学习，比如：提高PPT的制作水平，提高表达能力。

  那么具体来讲那些东西是比较硬的，要在35岁前搞定呢？这因目标而异，但下面这些项目应该具有非常高的通用性：
  精通一门最常用的语言
  了解一个最常用平台的基本机制，比如：内存管理、线程机制等
  UML图和面向对象分析设计方法
  设计原则，如：职责单一等
  设计模式
  《代码大全》里讲的一切
  精读一个知名的，但有点规模的程序。这点上要感谢开源项目给我们提供了这么多优秀程序。但要谨防好高骛远，动辄挑战Linux内核，精读是关键。
  累积一定的代码量，比如：独立的完整做过一个数万代码行的东西。这里的关键是完全自己打造，一定不要拷贝粘贴。
  掌握基本算法和数据结构（可以不自己写，但至少要知道其复杂度和区别）
  养成一种清晰的编码风格
  有自己的专业（金融、高并发网站，图像处理，TTS等）

>  在IT的世界里英语是一种世界语，一方面是由于美国公司的强大，一方面则是由于开源选择了英语。这最终导致IT世界里的新动向、解决问题的小技巧、网站的架构等等都要到英语的世界里去找。在StackOverlow很容易找到各种小问题的答案，在Quora则很容易找到各种网站的架构。
  接触一个新的岗位后，大致要经历一个学习并逐渐胜任的过程，这个时间段里大多数人的学习热情是很高的。一旦基本胜任之后，事情就有了变化。

> 技术人员的知识更新
  MFC是一个很大的池子，有深度、有历史。想把MFC的类继承关系、消息机制、框架结构、RTTI、序列化都搞清楚还是要很花一点时间的。
  从企业的角度看，一定是需要一个团队来维持这个程序的开发的。但从个人的角度看，如果把所有的青春都耗费在老技术上，那么一旦老技术退出历史舞台，个人该何去何从？
  如果真的如此，这个人就被逼到了死角里，人生很可能产生巨大滑落。所以一定不能认为所学足够而停止技能的更新与学习。
  从具体应对措施来看，一是要参照知识的地图，横向扩展知识的广度，比如不只要盯着代码，也要了解业务；不只关注开发也关注一点估算；二是提升可流动性比较好的东西的掌握程度，比如：面向对象分析与设计，这样跨越到其他技术时就能够比较平缓的进行过渡。三是要争取轮换岗位，争取多种实践机会。

> 管理者的知识更新
  从做产品来看，要想成功，有两个关键维度需要同时进行把握，一是产品的概念完整性的把握；一是用合适的手段去实现这个产品。
  下面简单列举几个比较关键的考量，这和前面论及的如何往博的方向发展有点重叠：
 使用现有产品还是自己开发
 比如：那些模块适合自己搞定而那些购入就可以了。购入的时候要遵循怎么样的标准去选择。
 使用那种平台技术
 比如：是使用微软的技术，还是开源的技术。
 现行架构是否可以达成产品目标
 比如：在硬件加软件可以同时支撑的并发数目。
 代码可维护性如何约束
 这要求必须熟练掌握一些原则性的东西，比如：什么信息隐藏、正交分解、抽象是否充分等。以及一些无歧义指标，比如：圈复杂度，单元测试的收益平衡。
 那些环节必须固化为流程，那些一定要团队自由决定
 比如文档化要到什么程度才合适，不同阶段间什么是必须的输入输出。
 ... ...