爆栈思想 – 究竟怎样才能技术专家

专才和全才

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

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

我大学的老师引用著名生物学家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答道:“愿意学的人无论如何都会找到办法去学,不想学到人无论怎么创造机会都不会学,所以,我们没必要做你们说的。”

专家

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

办法

所以,怎么办?业务模块未必提供足够的机会,当然,你可以:

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

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

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

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

爆栈之旅

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

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

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

版权所有

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

爆栈思想 – 开发人员如何面对各种不公和不满

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

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

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

如果你遇到这样的问题,你会怎么办?

 

大家一般的做法是:

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

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

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

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

 

爆栈之旅

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

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

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

版权所有

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

开发思想 – 做软件开发和转行

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,不一而足。其实很多时候,要么你没有去追求,要么你因为局限于某个项目/小组的所需要的技术。

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

 

爆栈之旅

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

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

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

版权所有

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

开发思想 – 代码质量的追求

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

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

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

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

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

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

爆栈之旅

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

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

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

版权所有

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

开发思想 – 阿姆达尔定律、高德纳定律、Dane North定律

阿姆达尔定律 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大常用办法:

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

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

爆栈之旅

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

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

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

版权所有

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

爆栈之旅-.NET- C# – 中级语法

目录

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

 

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

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

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

版权所有

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

开发思想 – 墨菲定律、琐碎定律、散弹枪法

霰弹枪法

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

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

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

  • 咦,为什么这个不工作?
  • 咦,为什么这个又工作了?

 

Work, Programmer Humor, and Why: It doesn't work.... why? why?

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

墨菲定律

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

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

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

帕金森琐碎定理

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

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

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

爆栈之旅

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

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

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

版权所有

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

开发思想 – KISS/DRY、奥卡姆剃刀、重复发明轮子、过度工程/设计/YANGNI

重复发明轮子

每个开发人员都有英雄主义情结,这种情结驱动我们去做一些创造性的工作,严重的情况下,我们会情不自禁地重复发明轮子(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!),正如我在另外一篇文章里所说的:http://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),你并不需要它,也是这个意思。

爆栈之旅

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

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

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

版权所有

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

开发思想 – 代码的4重:重质、重构、重视和重用

重质

好的程序员的代码:前人栽树,后人乘凉。差的程序员的代码:前人挖坑,后人躺枪​。

问一下自己,我们有多少次,复制粘贴代码?数不清,是吧?

我知道有一些开发人员,读这个专业纯粹是因为当年火热,从事这个职业单纯是知道它赚钱,并不是单纯的热爱开发这个创造性事情。

我还知道,有一些开发人员,完全漠视代码质量,他们的想法大体可以总结如下:

  • 不管我写的代码质量多好,总会有人把它瞎改,所以,我没必要写好代码,犯不着!
  • 不管我写的代码质量多好,客户看见不见,产品也不会漂亮写,所以,犯不着!
  • 不管我写的代码质量多好,老板也不会给我加工资,给我升职,所以,犯不着!

如果你觉得自己鹤立鸡群,身边的都是猪队友,那更应该起带头作用,言传身教,把队友的水平逐步提高,你的工作也舒服很多,这样是双赢的。

代码质量决定了产品的性能、稳定性等等,有问题的代码,不但会影响用户体验,更加可能会对客户造成损失,而你的公司会可能因此付出代价,譬如口碑、市场、赔付等。

如果你真的水平过硬,帮助了队友、产品成长,你觉得老板不会器重你吗?

重视

某司,我给一个代码改动做审查,该改动包含了80多个新文件,总代码量不少,然而该开发人员使用的时间却是相对极短的,所以,要么这个开发人员是超人,要么这个代码是复制粘贴过来的。我随机打开一个文件细看,心想:”咦,这些代码怎么看着这么熟悉?我肯定在什么地方看过!“,再检索一下大脑这么多年来记住的那些代码,我确实是9年前在codeproject上看过这个代码。我当年每天泡各个开源网站看优秀的代码,看过不少优秀的开源项目,所以我肯定它就是我看过的诸多开源项目其中一个。打开codeproject一看,果不其然。

使用开源项目在这里不是问题,因为其许可是允许我们使用在商业产品中的,但是,许可明确指出我们必须:

  • 保留其版权
  • 发布版本中保留一份许可

这个开发人员完全无视了这2条要求,他把80多个文件里面每个文件头都有的版权去掉了,许可也没附带上。

而且,他还把代码直接签入到我们的核心代码中,而不是把这些代码作为NuGet包进行合理的维护,其实,这个codeproject上的版本是有一些问题的,GitHub上有其它网友Fork的版本修正了,还在NuGet上发布了类库包。

而且,该开发人员已经白发苍苍,50多岁,还是不懂得尊重别人的代码。

不管什么代码,我们都应该敬而畏之,不管是害怕它造成问题,还是当宝贝那样珍惜。

不管我们是什么水平,年纪多大,如果要别人尊重我们的代码,我们首先要尊重自己的代码,写高质量的代码,还需要尊重别人的代码。

代码的重构和重用

我们下一篇文章继续详谈。

爆栈之旅

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

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

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

版权所有

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

开发思想 – 不确定性雪糕筒、薛定谔的猫、海森bug、最不可能的可能

薛定谔的猫/海森bug

之前说过薛定谔的猫,在量子物理学中,这种状态叫纠缠态。在开发过程中,这叫做:“海森bug”,是开发过程中的不肯定性,具体参考这里:软件开发思想-1-斩草除根

 

不确定性雪糕筒

说起不肯定性,在开发过程中,我们对开发项目的估计,最开始的时候,是与实际情况偏离得最大的,随着开发的进度不断推进,这个不肯定性会不断缩小,到开发的末期,这个估计会和实际情况非常接近,这个过程,我们用2条曲线表示(正负误差),就是一个雪糕筒的形状,这就是不确定性雪糕筒(Cone of uncertainty)。

最不可能的可能

OCaml的主开发人员在给VIP客户做技术支持的时候发现一个诡异的bug,第一反应是CPU有问题,但是客户不配合验证不了他的想法,1年之后,Intel终于确认了其CPU有问题:http://gallium.inria.fr/blog/intel-skylake-bug/
一般来说,我们给系统排错,一般是这样的顺序:
  1. 首先是看某个具体的功能,可能性是95%
  2. 再看模块中各种类型/函数的调用,可能性是50%;
  3. 然后看整个系统的数据流转、API/服务调用关系等等,可能性是25%,
  4. 之后才会考虑可能是第三方的组件/服务的问题,可能性是10%
  5. 接着会考虑是系统的DLL/配置问题,可能是1%
  6. 如果上述都不是,我们才会考虑是编译器/解释器的问题,可能性是0.1%
  7. 如果还没有发现问题,我们才可能考虑是硬件问题,譬如磁盘、内存等,可能性是0.01%
  8. 如果这还没有发现问题,那我们只能怀疑CPU,可能性是0.001%
所以,你会发现,不管可能性有多低,排除了所有其他可能性,剩下了的,不管看起来多荒谬、多不可能,那也会是答案。

爆栈之旅

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

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

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

版权所有

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