专才和全才

我之前在我的《爆栈之旅》课程里详细说过专才和全才的差别。

韩愈的《师说》中说到：“闻道有先后，术业有专攻”，意指所听到的道理有先有后，技能学术各有研究方向。

我大学的老师引用著名生物学家Thomas Huxley 赫胥黎的传世名言：”Try to learn something about everything and everything about something”（试着去学一切的一点皮毛，和某些皮毛的一切）。这是让大家尝试成为全才。

JOATMON 万金油

然而，并不是每个人都愿意、有能力、达成全才。英语里有一句老话：Jack of all trade, master of none（门门精通、样样稀松）。大概意思就是真正的全才难以达到，最后只能半吊子。

在中国，我们会称之为“万金油”，其实就跟瑞士军刀一样，难以样样精通。

级别

开发人员：初级程序员、中级程序员、高级程序员、小头目(Team Lead/Tech Lead)、首席开发人员(Principle Developer)

架构师：应用架构师(Application Architect)，系统架构师(System Architect)，企业架构师(Enterprise Architect – EA)

技术管理：研发经理、高级研发经理、技术副总(VPE)、CTO

这些我都在《爆栈之旅》课程里深入讨论过差异、需要多长时间、需要什么才可以逐步升级。

限制

一般开发人员，会在某个小组里做某个业务模块，因为业务范围限制，能使用的技术不多，譬如，你负责某个模块的前端，你就比较少机会接触后台、存储、分布式等等技术，没有这个需求，也没有这个机会。

某司，某个小组的技术元老，跟CTO进言：“我组的开发人员，一般就接触前端（Web）和桌面（WPF），没有什么机会接触到后台、数据存储等技术，我想送他们去参加那些付费的培训班”。

CTO马上说：“我们这是在做业务产品，不是给大家来学某种编程语言/技术的，如果他们愿意，可以自己回家去学。而且大家都去学得花多少时间和钱？”

我坐在旁边，颤颤抖抖地说：“我遇到过有这样要求的开发人员，说着这里只能学到某种特定的技术，其他的学不到，所以离职了。其实，我司用的技术挺多的，后台.NET、Java、Scala等，前端React、AngualrJS、Knockout等，数据存储SQL Server、PostgreSQL、MongoDB、Redis等，硬件设计/嵌入式等，大数据处理存储如Hadoop、Kafka、Spark、Elasticsearch、Kibana、Logstash，我们还有大数据分析、人工智能、机器学习等等，只是因为业务组限制，没有机会接触。要不，既然我们每个星期五下午都有一个小时的啤酒时间，就利用这个大家都不工作的时间，每周找个具体的话题，大家上去轮流着讨论，这样比写文章效果更好，而且可以录制视频，公司全球分舵都可以分享。”

CTO答道：“愿意学的人无论如何都会找到办法去学，不想学到人无论怎么创造机会都不会学，所以，我们没必要做你们说的。”

专家

经过多年钻研，把某一门技术做深做强，成为该领域的专家，已经是非常难得了。如果要成为更多领域的专家，那更加困难。

办法

所以，怎么办？业务模块未必提供足够的机会，当然，你可以：

• 去参加其它组的技术分享
• 可以回家去学
• 可以参加外部的技术分享
• 可以上网找课程
• 参与开源项目，多读优秀的开源项目的代码
• 刻意地通过去做新的东西来学新技术

但毕竟你没有足够的实战机会。

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

某司，同一天，有2个开发人员通知大家他们离职，其中一个还是做技术这块算是二号人物的元老。另外一个，和我谈过一些对他不公平的事情，对管理如何的不满。

工作中，我们会遇到各种不公平的事情。我的职业生涯中，超过10间公司，每间都有这样那样的不公平/我不满意的事情，譬如：

• 一些老油条把他们的任务强塞给你
• 你完成的任务，他们抢过去邀功
• 出现了问题，就说是你造成的
• 管理混乱，团队负责人纯技术出身，完全没有学过人员管理，老板为了挽留那些老油条而给他们升职，把他们放到不恰当的管理岗位
• 一些时候，老板给新来的人高薪，而一些确实贡献很大而且经验丰富的人，他们的待遇比新人还低
• 一些老油条，平时你请教他们，他们要么无视你，要么有意无意地只给你片言只字，让你无从下手。他们的思维，大抵是：
  • 老子多年前就是这么过来的，你们总得辛苦一下
  • 我总不能让你快速上手，否则让我这种不勤快的人很难堪
• 一些老油条，察觉到你对他们有威胁，诸多阻挠给小鞋穿
  • 我大学毕业第一份工作，因为我大学的时候就有工作经验，毕业后快速成长，部门经理隔三差五把我写的代码删除掉
  • 另外一家公司，我做出来的东西，在生产服务器跑，一个人先后多次把生成的数据删除掉，等我发现之后，就说：“你重新跑一下不就行了吗？”

如果你遇到这样的问题，你会怎么办？

大家一般的做法是：

• 尝试反馈，如果对方不改变，就找人力资源或更高的管理层
• 如果还没改善，走人

其实，人的性格无法改变的，即便他们表面上和你客气了，实际中还是会耍各种阴招。

英文说：If you can’t change others, change yourself。其实就是说，走人是上策。

不过，既然选择要走人，那没什么好害怕的了，把所有证据收集起来，走之前群发。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

George Bernard Shaw（萧伯纳）在《Man and Superman》（人与超人）中的Maxims for Revolutionists《致革命者的箴言》写道：“He who can does; he who cannot, teaches.” （有能者则为，无能者则教）。

大家不要误解作者的愿意，这个名言表面上看起来是说有能力的人才能做事情，没有能力的人就只能转行去做老师了，看着是在讽刺教师这个职业。但实际上，没有明确的考证这就是作者想表达的意思。

我引用这个名言，只是想引出今天要讲的话题：作为开发人员，如果对这个职业失去了兴趣，接下来会做什么？

我之前写过长篇博文，关于《大龄码农何去何从》，我还说过，一些大学刚毕业的开发人员，去到第一个公司，被严重打击了，失去了信心。又有一些工作几年的开发人员，在一家公司呆久了，有了”开发不过如此，真实糟糕“的幻觉，也失去了动力。

我在多年打靶的过程中，见过上百个猎头/中介，碰到过几个从开发一线退下来的码农，现在转行做了”有技术背景的猎头“，这种猎头起码比剩下的95%以上的猎头靠谱，毕竟他们懂开发，知道怎么考察应聘者的技术水平。

今天，一个码农朋友跟我说，他最近在面试，昨天碰上一个懂技术的猎头，搜索了一下领英LinkedIn，之前是做高级前端开发人员。我这朋友现在主要做.NET桌面开发，最近恶补前端尤其React，用它做了个个人网站，然后希望找份前端的工作。

我跟他说：“你这样是抛弃了过去几年积累的.NET/后台经验优势，你起码应该找份全栈的，保留后台优势的前提下，可以学习实战前端”。他说：“这个猎头告诉我纯前端收入更高。”

不过他后来又告诉我：”其实我最近研究React等前端，过度透支了我的兴趣，我现在看着前端就想吐了。我想我是做后台好些，不过我还是想学/做些不一样的东西。”

在某公司，一个码农离职，说：“这公司只能学到C#，世界那么大，我应该去学学别的语言。” 其实这公司使用很多的其它技术，Windows/Linux，桌面/Web/嵌入式，软件/硬件，.NET/Java，不一而足。其实很多时候，要么你没有去追求，要么你因为局限于某个项目/小组的所需要的技术。

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

之前我们在 开发思想 – 代码的4重：重质、重构、重视和重用 说过代码质量的重要性。

代码质量，不仅仅是性能，还有可读性、可维护性等等各种-ibility“性”。

一个开发人员今天说他们公司质量追求情况悲喜交织，譬如有些强人追求代内联优化（inlining），包括C#和SQL（没想到吧？），然而有些码农舍本逐末，譬如推崇jQuery而反对native方法，代码审查不给native过，这开发人员就说不服跑个分，性能一比较差jQuery差5倍，然后那个做审查的就不吭声了。

还有网友问，代码的可读性和性能，哪个重要？我觉得：没有定律，但有些时候可以两全其美。如果不能鱼与熊掌兼得，那可以根据实际需要而追求之，如果没有特别要求，那可以两者平衡取舍。

举个例子，我们为了追求代码可读性，不考虑性能，那就是舍本逐末，比较产品的使用者是用户，用户不满意性能（体验差），那造成损失是不可避免的。

同理，如果我们写的是天书一样的代码，犹如自带混淆器，那如果这个逻辑有问题，相信别人也无法修改。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

阿姆达尔定律 Amdahl’s law / Amdahl’s argument

计算机系统运行的最大瓶颈，是那些不能并行计算的部分。

一般为了提高性能，我们会先采用多线程，这样可以实现并行计算。如果这个不满足需求，我们可能会支持多个进程。不管哪个，我们都要解决一个无法避免的问题：数据同步。而多进程的实现，还需要指出进程间通信（IPC），一般可以用命名管道（named pipe）、消息(windows message)、socket (没错，本机也可以用套接字)、内存映射文件(memory mapped file – MMF)等等。

如果多进程还不能解决问题，我们可以考虑分布式计算，这个时候数据同步/通信可以用scoket、队列（如Kafka等）、HTTP服务等。

不管哪种实现，性能瓶颈应该是整个业务流程中不支持并行处理的模块/功能。

高德纳定律 Knuth’s law (Donald Knuth)

Premature optimization is the root of all evils，过早的优化是万恶之源。

我之前说过不应该过度设计（开发思想 – KISS/DRY、奥卡姆剃刀、重复发明轮子、过度工程/设计/YANGNI），因为你现在不需要、短期也不需要。

但是，有些开发人员就利用这个做借口，懒于设计，最后做出一个刚上线就已经无法应付需求的产品，这是因为这些开发人员没有理解高德纳的原意。他老人家想说表达大家不要“过早”优化。那什么是“过早”呢？

举个例子，某个创业公司，技术负责人要高大上，所使用的技术都是业界最先进最强大的，技术团队折腾了2年，产品还没有出来，公司资金链断了，倒闭了。这是过度设计，他们臆想客户在短期内有这个需求。

再举个例子，某个系统的一个模块，设计人员考虑到可能用户量会很大，所以做成分布式的，用上了非常复杂的架构，上线之后，用户量远没有想象中的多，单机就能轻松应付所有请求。

实际上应该怎么样做？多次迭代，看菜吃饭。技术架构应该是不断变化的。

Dane North’s law

每一个决定都是有代价的。

大家应该知道计算机优化的2大常用办法：

• 用空间换时间：譬如缓存
• 用时间换空间：譬如压缩

每个功能都有其侧重点，譬如追求性能，或者追求内存/存储空间最小化，很多时候，我们只能在这两者之间做取舍、平衡。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

目录

• 第一讲-爆栈服务
• 第二讲-软件开发-基础
• 第三讲-软件开发-需求分析与规划
• 第四讲-软件开发-设计
• 第五讲-软件开发-编码
• 第六讲-.NET-基础
• 第七讲-.NET-进阶-如何读懂别人的代码
• 第八讲-.NET-面向对象与调试
• 第九讲-.NET-进阶-如何优化别人的代码
• 第十讲-数据存储-基础
• 第十一讲-.NET- C# – 基础语法
• 第十二讲-.NET- C# – 数据访问
• 第十三讲-.NET- C# – 中级语法

这是爆栈之旅的1对1私人定制授课的第十三讲，视频+讲义+问答+测试+代码审查等等。

是否想技术水平快速提升？是否希望快速成为公司的技术骨干？

• 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
• 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
• 解答各种技术问题
• 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

霰弹枪法

在开发过程中，有多少次，你遇到很难缠的问题，百思不得其解，因为没有正确的思路，所以，使用霰弹枪法，到处放一枪，这里修改一下，不行，再在那里修改一下，还是不行，继续换个地方打一枪。

有一句英文谚语：“当你是是一个锤子，看见啥都是钉子(nail)”，但是你迟早会砸到自己的拇指（thumb-“nail”）。同理，当你没有一个明确的目标，到处放枪，迟早要射到自己脚（shoot yourself in the foot）。

所以你们会发现有一些开发人员经常性处于一种思考状态：

• 咦，为什么这个不工作？
• 咦，为什么这个又工作了？

那究竟应该怎么做？首先，捋清思路，明确业务逻辑/流程，从到到尾走一边，看看问题在哪个端/层出现，再逐步缩小范围，直到定位具体的代码行。具体的例子我再写文章。

墨菲定律

该发生的事情，不管几率多低，迟早会发生。

开发过程中，我们会遇到一些难题，解决不了，譬如某种异常，我们中有些开发人员会尝试把这个异常吞掉，以为这样就天下太平了，但事实上问题在不断产生，造成或大或小的损失。

尽管我们目前无法把这个问题的根本原因找到，解决不了，那最起码的，需要把错误自动记录下来，尝试对堆栈和运行时状态、业务值等中找到规律，从而帮助我们找到问题根源。

帕金森琐碎定理

核发电厂的设计中，包括核反应堆和停车场，其中对停车场的设计，大家都很热衷地讨论给建议，但对核反应堆的设计，大家都不发声了。

这个定律，是说开发过程中，一些重要的架构，懂的人不多，所以也不会多少人敢参与讨论，相反，一些界面的元素摆放、大小、颜色等，大家会议论纷纷。

在代码审查(code review)过程中，假如改动只有10行代码，我们可能会挑出10个问题来，但是如果改动有5000行，我们看着看着就累了，所以直接就让过了，挑不出问题。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

重复发明轮子

每个开发人员都有英雄主义情结，这种情结驱动我们去做一些创造性的工作，严重的情况下，我们会情不自禁地重复发明轮子(re-invent the wheel)。

譬如，我们发现JavaScript里没有方法方便我们对一个数组进行快速操作，我们就动手开始写了，或许，你应该先看看Underscore或者更好的Fork版本Lodash。

譬如，大家用.NET开发一个游戏，发现没有脚本引擎类库，打算自己写一个，或许，你可以考虑一下DLR (Dynamic Language Runtime)支持的那些Iron系列，譬如IronRuby、IronPython等等。

譬如，大家用Xamarin开发了iOS/Android手机App，希望采集一些运行时信息，譬如用户的使用情况、程序产生的错误等等，所以打算自己写一个，其实，微软针对Xamarin开发了一个手机app管理平台：Mobile Center （ https://mobile.azure.com ）

所以，我们不应该重复自己（DRY），不应该WET（Write Everything Twice），要KISS（Keep It Simple, Stupid!），正如我在另外一篇文章里所说的：https://kayow.com/2018/06/softwaredevelopmentthoughts1/ 

过度设计

极端情况下，我们会实现一些现在、短期甚至中期都不会用到的功能，这就是over-engineering（过度设计）。

譬如，我们设计一个内部使用的系统，现在公司员工数量有100个，我们预计并发用户数是50，根据公司的发展规划，接下来5年人数不会翻倍，所以我们的设计完全可以按照75个员工并发进行。

为什么不应该过度设计？譬如要达满足95%的需求，我们花了95%的时间，剩下了的5%，我们可能需要2倍的时间去实现，而要做到120%，我们可能需要5倍的时间。

而且，就像乌鸦喜欢收集一些闪亮的小玩意那样，我们热衷于研究那些很火热很炫酷的技术，这样才能显得我们特立独行，比别人优异。严重者，会不顾一切把这些技术引入现有的产品中，譬如一些Web项目原来是用angularjs编写的，因为react火，所以我们就用react重写了前端，那这个耗时的工作除了满足了开发人员的虚荣心和膨胀的ego，究竟带来了什么实质的产品收益？并没有。

所以，时刻告诫自己，每增加一个新功能之前，都应该问一下自己正：是否真的需要。若无需要，勿增实体，这就是奥卡姆剃刀理论。YANGNI（You Aren’t Gonna Need It），你并不需要它，也是这个意思。

爆栈之旅

薛定谔的猫/海森bug

不确定性雪糕筒

最不可能的可能

爆栈之旅