爆栈思想 – 什么样的工作才是做得爽?

前言

我之前在《爆栈思想 – 开发人员如何面对各种不公和不满》里面说过各种不公对待,那么,大家究竟希望怎么样的工作环境,需要怎么样才能爽呢?

马克思说:“资本家害怕没有利润或利润太少,就像自然界害怕真空一样。一旦有适当的利润,资本就大胆起来。如果有百分之十的利润,他就保证到处被使用;有百分之二十的利润,它就活跃起来;有百分之五十的利润,它就铤而走险;为了百分之一百的利润,它就敢践踏一切人间法律;有百分之三百的利润,它就敢犯任何罪行,甚至冒绞死的危险。”

作为老板,他们的任务就是尽可能地压榨你的贡献,用最少的钱办最多的事。

在古代,那些在红楼卖唱的女子,被客人调戏,一般对白都是:“客观请自重,小女子卖艺不卖身。”

而当代,有个半调侃的段子:“只要给得足够多的钱,我不管你让我做什么!”

一些网友总结说:做得不爽的,说到底,还是老板给的钱不够多,只要钱给足了,哪里还有不爽呢!

钱能解决的问题,那就不是问题。问题是,老板未必愿意给你期望的待遇。

 

钱少事多离家远,
位卑权轻责任重。

 

自由

自由度要够高,做你喜欢做的事情,不是被局限于做重复性劳动。

对口味

用自己喜欢的技术,而不是被迫用一些很抗拒的技术。

升迁

努力后的回报是,老板根据你的贡献来给你加薪、升职。

学习进步

在之前的文章《究竟怎样才能技术专家》中说过,一个公司的文化和领导意志决定了你是否能在工作中不断学习进步。

团队融洽

没有混蛋,这是大家希望看见的吧?然而,每个公司都有这样的人。有人的地方就有江湖,有利益的地方就有冲突。没有人会踢一直死狗,如果有人对你不利,那是因为你潜在或者已经触动了他们的利益。

残酷的现实

你的愿景和实际是有差距的。所以要么郁郁不得志,要么离开。

 

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

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

爆栈之旅

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

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

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

版权所有

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

爆栈思想 – 水平高低、改进和重写

入乡随俗?

泰国要搞一个大型基础设施,找了中国的工程队去,当地的协会要求该工程队先考一个资格证,国王知道后,说:“你们就是自己做不了才找的中国的工程队过来,这说明人家水平比你们高,你还需要别人考取你们的资格证?这不像话。不需要他们考证。”

一些时候,新人进入公司,不管该新人背景如何,水平多高,就是把你当初级程序员那样用,即便过了一段时间该新人对业务系统已经有一定的认识,仍然得不到应有的重用,反观一些水平差不少、态度很差的老油条却不断升迁、加薪。

改进和重写

英文里,我们有evolution 进化和revolution 革命,一个字母之差,如中国古语说:差之毫厘,谬之千里。

一些老系统,如果要改造,主要考虑项目的大小和公司的资源,如果系统较小、资源充足、权衡利弊后回报合理,那可能选择重写。否则,应该采用进化的方式逐步改进。

我之前说过,开发人员有英雄主义情结,有些开发人员做得比较极端的是,看着系统不爽就说要推倒重来,主要心态是:

  • 我想学新东西,平时没机会,现在找这个做借口,练手
  • 老子自认天下第一,别人的代码都是垃圾,都得扔掉

Dependency graph of a Big Ball of Mud architecture

当然,也有可能是客观的情况:系统不行

  • 系统设计一团糟 (big ball of mud),无法维护和改进
  • 要么性能低下
  • 要么问题百出
  • 要么用户体验糟糕
  • 要么跟不上时代,如不支持各种移动设备,或者用户量上来了现有架构无法应付

其实,即便全面改造现有系统,也可以有序地进行,譬如垂直按模块来,分而治之。又或者采用所谓的lift & shift,改造底层架构,譬如本地服务器改成用云的分布式。

曾经有这样的系统,采用新技术重写,花了8年,仍然还是半成品。所以还没有交付,技术又落后了。

 

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

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

爆栈之旅

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

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

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

版权所有

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

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

专才和全才

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

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

我大学的老师引用著名生物学家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个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

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

版权所有

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

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

霰弹枪法

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

有一句英文谚语:“当你是是一个锤子,看见啥都是钉子(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个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

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

版权所有

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

软件开发思想-2-开发人员应该掌握什么语言/技术?

一技防身

每个开发人员,如果要做得好,都起码熟练掌握一门语言/技术。我们读书的时候学过:学会数理化,走遍天下都不怕。李永乐老师就是一个很好的例子,他的视频大家应该看看。

全栈

不是每个人都能达到全栈,甚至爆栈。

那该掌握什么?

生存和兴趣,你想选哪个?

如果是为了生存,那可以选择那些市场上热门、迫切需要的技术,因为这些技术一般意味着较高的薪酬,譬如最近比较火热的区块链、人工智能/机器学习等等。

如果是为了兴趣,那你可以尽情选择你喜欢的技术、语言。

单纯就语言来说,我觉得应该掌握以下三种:

  • 一种静态语言
    • 譬如C#因为高产开放和跨平台高性能
    • 譬如Java或者Kotlin
  • 一种动态语言
    • 譬如JavaScript因为前端现在是主流开发
    • 譬如Python/Ruby
  • 一种DSL领域专用语言
    • 譬如sql server的t-sql存取数据。

如果都掌握了,那就是初级的全栈:前端、后台、数据存储三个端。

 

爆栈之旅

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

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

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

版权所有

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