程序猿生存定律这系列的文件夹在这里：程序猿生存定律--文件夹
喜欢从头瞄的，能够移步。
-------------------------------------------------------------------------------
1． “博”与“专”上的迷失
假设说一个人的学习已经聚焦，而且学习的内容和自己实际參与的项目也相吻合，那么是不是就没有问题了？非常不幸，答案仍然是否定的，在不论什么一个子领域里，仍然须要进一步去考虑“博”与“专”的均衡。
对于软件开发而言。设计是再常见只是，再简单只是的一个词了。
可假设把视角拔高一点就会发现。单以设计而论仍然是一个不可穷尽的领域。我们能够高速扫描一下和设计相关的部分概念：
- 面向对象分析与设计
- 结构化分析与设计
- 模型驱动开发
- 契约式编程
- 面向方面的开发
- 基于组件的开发
- 元编程
有些时候方法论也会和设计牵扯到一起：
- 測试驱动开发
- 敏捷软件开发
假设感觉这个还不够多，那能够去Wiki上查编程的范式(paradigms )这个条目，那里列了47种范式，每一个都和设计多少有点关系。
上述这些还仅仅是说了设计，假设横向展开。那么在特定领域中必定还会牵涉到框架的选用、辅助工具的使用等等。
这也就意味着，从博的角度来看。即使是在设计这样一个看似狭小的领域中仍然是没边界的。
与此同一时候，把一个API研究的再透，也是低值人群，由于这样的深入理解和单纯会用某个API相比。从创造价值的角度看，区别不大。
这也就意味着对于大多数软件开发者而言，要去寻找广博与精专间的均衡点：既不能闭上眼睛，也不能就用显微镜来看世界。而这一均衡点的价值则可用反木桶原理来说明：木桶原理说的是桶里的水是由最短的一块板决定的。但考量人的价值时却是适用于反木桶原理，即人的价值往往由最长的一块板决定。
考虑博和专的问题不能离开产品开发进行考虑，前面以前提到过，产品开发往往和公司的现金流绑定的更紧，能为现金流贡献力量的技术才是有价值的技术。
而产品开发本身事实上对博和专的程度提出了最主要的要求。这样的要求往往具有迭代的特质。为了形象的说明这一点，这里举一个通用的样例来进行一点说明：
在第一次跌代里，往往须要达到两个最主要的目标。
第一个目标是能够为产品贡献自己力量。但代码质量普通。这个目标假设达不到，一个人会失去自己的存在价值。
这时候最少须要了解某种语言（比方：C++)、某个平台（比方：Windows)、某个IDE（比方:Visual Studio)和某些业务相关的知识（比方：打印体系）。
这个范围能够尽可能圈的小点，但用到的则要学透。
比方：无论接触到那个框架，都要去了解它的内存机制、线程机制、异常处理组件构建和国际化处理这些全局性的机制。而不能仅仅是了解某个接口怎么用。
这并不是是非常高的要求。没有这些就变成了“靠运气编程”。写完程序后还要祈祷他能跑起来。
了解这些之后就能够负担起部分开发工作，否则的话仅仅能做旁观者。没法參与到实际工作中来。
第二个目标是把事情做好，并能负担些层次更高的工作。
这时候要比較深入的了解面向对象、结构化方法、设计模式、理解设计原则，并能把它们用好。至少要能判定。这个程序写的好，那个程序写的不好，同一时候面对需求能把工作进行下去。
前两个目标是基础，一般来讲学校中基础打的越好，这个阶段越短。达成这两个基本目标之后就能够结合情境来做进一步的选择。能够觉得这是博与专选择上的第二次迭代。当然这时候也要谨记不要和实践分开。
完毕上述两个层次后，能够有两个方向可供选择。
- 能够进一步考虑专的问题，比方在特定领域里把知识深化下去。
做驱动就要理解操作系统的核心机制，做打印的就要了解页面描写叙述语言等。但这个时候要适当警惕边际效应。
边际效应是说。你让一亩地从亩产500斤添加到1000斤可能仅仅须要投入100块。让亩产从1000添加到1500可能就须要200块；让亩产从1500添加到2000则须要400块了。
一个典型的样例是对C++的学习，C++是公认的复杂，假设想做C++的律师，那么预计搞个10年可能够资格了，但问题是把时间都投在这个上，投入产出比可能不好。而停在那里合适则是个尺度问题。大致来讲是能够靠时间弥补的细节问题，并不适合专到最底层。
比方对于100万行的程序，预先花时间去了解每一处细节。就有点过了。
- 能够把博再推进一步，比方：熟悉专门领域的专业知识、熟悉多种既存框架的特性、熟悉提高用户体验的关键点。熟悉多种既存框架的特性的详细含义是：
设计某一种解决方式时，首先要考虑的就是是自己开发还是使用现有的模块。一旦决定使用现有的模块（包。框架等），那就要进一步考虑到底用那个。
做这类工作时，假设没有一定广博的知识，做选择的时候就会特别的艰难。
假使说如今公司内部要导入一套项目管理系统。那么做决定的负责人必须至少考虑全部以下这些事情：
- 自己从头造。还是用现成的做二次开发？
- 用现成的，是用开源产品，微软的还是其它公司的？
- 用微软的话，是用MS Project还是基于SharePoint，还是混合？考虑License费用的话真的划算么？
- 用开源产品。有这么多选项到底导入那一个?
- 假设自己从头造。那么是基于微软的技术。还是基于LAMP这样的技术？
- 使用什么框架？
- 假设要做，用什么语言？
一个人非常难精通上面全部的领域，但当做选择时。全然没有概念也是灾难性的。
此外。考虑博与专平衡点时似乎有一种特例。钻研特定算法的人，从一開始就仅仅往专的方向发展，并不会考虑其它。比方：钻研TTS的人。可能几十年如一日仅仅要专注于TTS就完了。
至于详细选择那个方向，则要依据自身情形来定。
总的原则是要以当下工作为根基，以有用为目的甄选各种知识，并追求平衡点。
大致上讲。期望做技术专家的更适合前一个方向，而期望做技术管理的则更适合后一类方向。
学习软件project的时机与必要性
简单来讲越是没实践经验的人越不适合学习软件project，越须要规划总体把握全局的时候越须要学习软件project。
软件project中覆盖的元素非常繁杂，能够有管理、流程、开发模型、估算、分析设计方法等。这无疑会把知识面扩展的非常宽，一旦没有根底，就非常easy变成纸上谈兵，夸夸其谈。
在众多软件相关的知识中，软件project绝对是非常特别的一个。
非常多人非常歧视软件project。说：我一看到软件project的书就直接略过；与之相相应，非常多人非常推崇软件project。会花非常大的心思去研究敏捷、CMMI等。
刚入职场的程序猿大致上是讨厌软件project的。由于这东西离自己的实践有点远。而且主要是加入束缚。但既然更加复杂纷繁的历史都能够总结出规律，忽视软件开发的内在规律无疑的对有志于成为管理者的人是不利的。
真要学习软件project，不太适合从抽象层次非常高的教科书開始，而适合从《代码大全》这样与实际关联比較紧密的书籍開始。
在国内软件project的落地似乎始终困难。软件project相关名词始终在不停的变换（ISO，CMMI。敏捷等），但实际能落地起作用的却不多。这终于导致了一种吊诡的局面：刚对一个绝望。就開始对新的一个报以希望，并在这两个简单的步骤上做无限循环。这样的状况或许有其更深层次的原因，比方生存压力过于强大导致project力量的长远价值被漠视，进而使方法论并不为解决现实问题而存在，而是为了证书而存在。
非常难据此就说软件project毫无价值。
2． 错过人生中的好时机
没毕业的程序猿或者刚毕业的程序猿往往感觉空余时间比較充沛，还非常苦恼不知道怎样打发时间，但实际上一个人一生中能够用于充电的时间远比想的少。一旦错过时机，往往悔之莫及。
对于大多数人而言，人生就像个模板，小处还有偏差。大处却基本同样。
20~30岁这个阶段能够讲是黄金时期。这个阶段里，家庭负担较小，能够自由支配的时间较多。当然撞到了非常特别的、须要疯狂加班的公司仅仅能另算。
30岁之后由于娃娃出生等，家庭上的时间开销添加。个人可支配时间变少。当中非常大一部分人还有非常大可能会面对电视剧里常说的婆媳矛盾，让你每天心绪不宁。
40岁之后。家庭琐事会进一步添加，典型的上有老下有小。实在运气不好的自己也会生点病---颈椎病、腰间盘突出、胃病大概能够入选程序猿的三大职业病。
50岁之后，时间上会再次解脱，但可惜的是自己也老了，时机不在。
假设把人生依照年龄画一条抛物线的话，40岁左右一个人能够达到的人生的顶点，未来再突破的几率则变小。
从历史人物来看。大器晚成的不是没有，但真的非常少。
用心观察就会发现，招聘启发里经常会注明年龄要在35周岁以下或者40周岁以下，除非是招聘高层。这反过来意味着假设没有到高层，人生会在40之前定型，之后有下滑危急（如遭遇不景气、公司倒闭等）。对程序猿而言，这样的风险尤其的大，由于非常可能你辛苦掌握的知识体系被更迭掉了。
学习本身无疑的是须要顺应这样的自然规律的。
非常多人非常大的一个错误在于，在黄金时期。没做什么积累，就顾得享受生活了，而一旦意识到积累的必要性时。却又受困于诸多琐事而欲振乏力，终于人生高度有限，并迅速走低。这就是现代程序猿版的“少壮不努力，老大徒伤悲”。
基本上讲。35岁以前要把须要花大量时间。比較硬的技能，学习曲线陡的技能掌握，具备工作所须要的全部主要技能，而35岁之后则主要关注知识的更新和某些软技能。
学习时添水战术效率真的非常差。每次点一根火柴烧水，一亿年水也烧不开一壶。同一时候。比較硬的技能（比方：Donald Knuth的《计算机程序设计艺术》)往往是须要大块时间投入的。但年纪越大时间越呈现为碎片化，越难搞定硬的知识---先天就easy造就添水战术。比較软的技能。则能够用碎片时间来学习，比方：提高PPT的制作水平。提高表达能力。
假设能够安排好自己的时间和软硬知识的关系。那么就能够在特定基础上做积累，小步前进。使自己的价值越来越高。从这个角度看，年轻绝对是一种债务，大多数人必须在他没全然结束前，还掉所欠的东西。
那么详细来讲那些东西是比較硬的，要在35岁前搞定呢？这因目标而异。但以下这些项目应该具有非常高的通用性：
- 精通一门最经常使用的语言
- 了解一个最经常使用平台的基本机制，比方：内存管理、线程机制等
- UML图和面向对象分析设计方法
- 设计原则，如：职责单一等
- 设计模式
- 《代码大全》里讲的一切
- 精读一个知名的，但有点规模的程序。这点上要感谢开源项目给我们提供了这么多优秀程序。但要谨防好高骛远，动辄挑战Linux内核，精读是关键。
- 累积一定的代码量，比方：独立的完整做过一个数万代码行的东西。
这里的关键是全然自己打造，一定不要拷贝粘贴。
- 掌握基本算法和数据结构（能够不自己写，但至少要知道其复杂度和区别）
- 养成一种清楚的编码风格
- 有自己的专业（金融、高并发站点，图像处理，TTS等）
学习英语的时机和必要性
总的来看，程序猿学习英语是一项投资回报率相对照较好的投入。从目标上来看，程序猿未必一定要口语流利，但最低要达到阅读英文资料没有障碍的程度。这里面有一个微妙的事情，一旦英语阅读问题较大。查找问题会习惯用百度。这天然会限制一个人的视野。
不是说百度自身有多不好，而是说英语的世界里有着很多其它更精彩的内容。无论喜欢不喜欢。我们必须承认一种现实，在IT的世界里英语是一种世界语，一方面是由于美国公司的强大。一方面则是由于开源选择了英语。这终于导致IT世界里的新动向、解决这个问题的小技巧、站点的架构等等都要到英语的世界里去找。在StackOverlow非常easy找到各种小问题的答案，在Quora则非常easy找到各种站点的架构。
从学习时机来看。这件事情特别应该在大学里面搞定，假设不行至少也要在毕业1~2年内达到阅读无障碍的程度。当然希望加入外企还须要额外的付出。
从学习方法来看。学习外语真没什么特别的窍门。坚持并投入时间即可。
3． 停止知识更新
对程序猿的增值而言。人生里最大的陷阱或许是为安全的假象所欺骗而彻底的放松自己。
这样的状况在生存环境比較恶劣的情形下不太会发生，但在垄断企业或某一领域中绝对率先的企业里则easy滋生。发现自己是否停止知识更新了并不困难，比方：一年一本书没看，一年一点新知识没接触。一年中工作负荷基本不满等都能够成为一种信号。
这真的是温水煮青蛙。一旦到了三十几岁，并在这样的环境中呆习惯了，那么再想跳出来，基本没可能。唯一能做的事情是。祈祷公司不要挂掉，公司也不要来场运动，进行人员的大换血。
孔夫子说：日当三省吾身，这是非常有必要的。至于认识危急后能否做点什么。那就是事在人为了。
- 技术人员的知识更新
接触一个新的岗位后，大致要经历一个学习并逐渐胜任的过程。这个时间段里大多数人的学习热情是非常高的。一旦基本胜任之后，事情就有了变化。
非常大一部分人可能会感觉，反正工作也就用到这么些知识，学习其它的也用不上，因此開始把自己封闭起来，不太看书，不太看技术新闻。
这事实上非常危急，由于这样的做法等于把自己绑死在当前这份工作上。而不论什么一个产品都有自己的生命周期。一旦一个产品的生命周期结束时，碰巧其所用的技术也已经过时，那么当事人就会非常尴尬。
由于产品能够结束，生活却还得继续。
这里面一个非常经典的样例是MFC。
微软的这款产品的历史非常悠久。从1992年公布到2012年几近存在了20年时间。随着90后程序猿的逐渐出现，立即这款技术就要变得比程序猿的年纪还要大了。
即使到今天，非常多桌面应用仍然是基于MFC开发的，这能够通过查看程序包的dll依赖来非常easy的进行验证。MFC是一个非常大的池子。有深度、有历史。
想把MFC的类继承关系、消息机制、框架结构、RTTI、序列化都搞清楚还是要非常花一点时间的。
如今我们假设一款庞大的企业应用是基于MFC开发的。一个程序猿也通过几年的努力了解了MFC，了解了应用本身，并能够负担起Bug修正。新功能追加等任务了。
接下来这个程序猿似乎没什么好学的了。由于MFC的更新差点儿已经停滞，因此对MFC的学习差点儿不须要花太多的时间了。现有代码也理清楚了，也不须要再花非常多时间学习了。现有程序也比較好的满足了企业的需求，推倒重来的可能性差点儿没有。
那这个时候这个程序猿不须要学习了么？答案一定是否定的。
这里面蕴藏着一个天大的矛盾。
从企业的角度看，一定是须要一个团队来维持这个程序的开发的。但从个人的角度看。假设把全部的青春都耗费在老技术上，那么一旦老技术退出历史舞台，个人该何去何从？
还是上面的样例。假设说一个人持续投入在这类开发上，当他45岁的时候，当前产品生命周期结束，世界变的仅仅有移动开发和云端开发。那么仅仅擅长MFC的他该何去何从？
假设真的如此。这个人就被逼到了死角里。人生非常可能产生巨大滑落。所以一定不能觉得所学足够而停止技能的更新与学习。
从详细应对措施来看，一是要參照知识的地图。横向扩展知识的广度。比方不仅仅要盯着代码，也要了解业务。不仅仅关注开发也关注一点估算；二是提升可流动性比較好的东西的掌握程度，比方：面向对象分析与设计，这样跨越到其它技术时就能够比較平缓的进行过渡。三是要争取轮换岗位，争取多种实践机会。
- 管理者的知识更新
到如今为止大部分人认同。管理者是须要懂技术的。从逻辑上看“懂”基本上是不瞎指挥的前提。所以这能够称为中国版的“现场主义”。预计争议不大。
那关键问题就是到底要“懂”到什么程度？
假设说两个人，一个选择了管理方向，一个选了技术方向。接下来要求管理方向上的人技术水平要和技术方向的一样，那么除非这个人特别天才，否则不太可能。正像前面所说，这是由于这两个方向的“Key”不同所造成的。
假设把目标设定为确保终于产品的成功。同一时候假设管理者有更高的决策权。那么管理者必须在以下这些方面有技术感觉。
从做产品来看，要想成功，有两个关键维度须要同一时候进行把握，一是产品的概念完整性的把握；一是用合适的手段去实现这个产品。
前一个话题非常老，《人月神话》就有提及，但实践中却总是被人忘记。好的产品必须贯彻某一种统一意志，iPhone、微信又又一次验证了这一个老的原则。 机械拼凑的产品尽管融合了非常多人的想法，但往往是平凡的，而且在项目运行过程中，往往是出错的根源。非常像是尽管有法律，但每一个人有自己的理解。各行其是这样一个状态。这样的概念完整性是管理者第一个须要有所把握的事情，其次就是解决怎样去构建产品这个问题。为达成这一目标在以下这几个方面上，管理者要有自己的理解，至少要有自己的原则：
以下简单列举几个比較关键的考量，这和前面论及的怎样往博的方向发展有点重叠：
- 使用现有产品还是自己开发
- 比方：那些模块适合自己搞定而那些购入就能够了。购入的时候要遵循怎么样的标准去选择。
- 使用那种平台技术
- 比方：是使用微软的技术。还是开源的技术。
- 现行架构能否够达成产品目标
- 比方：在硬件加软件能够同一时候支撑的并发数目。
- 代码可维护性怎样约束
- 这要求必须熟练掌握一些原则性的东西。比方：什么信息隐藏、正交分解、抽象是否充分等。以及一些无歧义指标，比方：圈复杂度，单元測试的收益平衡。
- 那些环节必须固化为流程，那些一定要团队自由决定
- 比方文档化要到什么程度才合适，不同阶段间什么是必须的输入输出。
- ... ...
假设说有人不这么觉得，而是在做了管理后。表现出足够的惰性，不再持续更新自己的知识体系了，那么会发生什么事情？
这时候会非常可能会管理倒置。
即管理者是名义上的上级，但基本失去对现场的把握。全部的决策全然依赖于下属。得力下属不在。各种决定就仅仅能靠瞎蒙，终于变成仅仅会沟通的管理者---即使被食人族吃了也不会有人注意到。由于存在价值已经被无限稀释。变成了一个象征性的符号。也可能会和下属爆发激烈冲突。
由于这类管理者没有自己的立场。上面有任务仅仅能下压。结果同实际情况偏离万里，不具有可实现性，这类管理者无法对自己的上司陈述，也就仅仅能向下转移压力。
无论是那种，一旦到这样的地步，事实上是趋于失败，仅仅能祈祷食人族不要来。
为什么中层管理者也要坚持知识更新？
在IT行业流传着一个非常有名的关于食人族的笑话，这个笑话说的是：
两个食人族的人应聘进了某家大公司。公司人事主管知道这两个这伙每天都要吃人，于是警告他们：“假设你们胆敢在公司吃一个人，你们就会立即被炒掉！
”两个食人族唯唯喏喏地答应，表示绝不会在公司吃人。两个月过去了，公司平安无事。
突然有一天，公司发现负责打扫公司卫生的清洁工不见了。
于是人事主管非常气愤。找来两个食人族怒斥，并当场炒掉了他们。出了公司大门。一个食人族立即对还有一个抱怨起来：“我一直警告你不要吃有在做事的人。你就是不听！我们两个月来每天吃一个经理，没人发现。
你看如今吃了清洁工，他们立即就发现了！
你真是个猪！”
这个笑话嘲讽的是某些大公司大企业病发作，人浮于事。大企业病的成因非常难一下子说的清楚，但结果却比較明显。一定会导致较多人成为中层管理者。假设说成功的企业天然有感染大企业病的趋势，那无疑的中层管理者也天然有着膨胀趋势。从个人角度看，成为被食人魔吃掉也没有人在意的经历并不是是什么好事，由于这意味着存在价值减弱，也不须要什么知识更新。
一旦面临裁员这类事情。这个人非常可能已经失去了面对残酷竞争的能力。
------------------------------------------------------------------------------
关于我自己的各种信息。在左边栏可找到。想了解下写这书的人是不是骗子和大忽悠的能够瞄。
最后希望感兴趣的支持V众投。感觉上这应该是国内最靠谱的生活购物等的问答社区了吧，都是朋友给朋友做的答案，同一时候实行一人一号。一人一票制度，想找什么答案关注公众号：vzhongtou（左側有二维码）即可了。