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

霰弹枪法

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

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

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

版权所有

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

软件开发思想-1-斩草除根

典故

古语有云:“斩草要除根”,这来自一个典故。往年,郑庄公请求与陈国讲和,陈桓公不答应。五父劝谏说:“亲近仁义而和邻国友好,这是国家可宝贵的措施,您还是答应郑国的请求吧!” 陈侯说:“宋国和卫国才是真正的祸患,郑国能做什么?” 于是就没有答应。君子说:“善不可丢失,恶不可滋长,这说的就是陈桓公吧!滋长了恶而不悔改,马上就得自取祸害。纵是挽救,何能办得到!《商书》说:‘恶的蔓延,如同遍地大火,不可以靠拢,难道还能扑灭?’周任有话说:‘治理国和家的人,见到恶,就要像农夫急于除杂草一样,锄掉它聚积起来肥田,挖掉它的老根,不要使它再生长,那么善的事物就能发展了。’”

所以,古代皇帝惩罚一个罪大恶极的人,会选择诛其九族,这样不会遗留祸害。

唐朝白居易名诗:离离原上草,一岁一枯荣。野火烧不尽,春风吹又生。说得就是这个道理。

 

软件开发

我们知道,一个系统,没有办法做到bug free。每个系统都有bug,或大或小,或明显或隐藏得很深。我们做bug修复的时候,关注点不是表象,因为一些时候,我们会陷入误区:只要呈现出来的问题不再被观测得到,那问题就是被修复。

或许大家听过Heisenbug这个词,以下是维基百科的摘录:

在程序设计术语中,海森堡bug(英语:heisenbug)是指在尝试研究它时似乎会消失或者改变行为的bug(程序错误)。该词汇是物理学家维尔纳·海森堡名字的双关语,他最先断言了量子力学的观察者效应——观察系统的行为不可避免地将改变其状态。电子学中的传统用语则是探针效应,指连接一个测试探针到设备将改变其行为。

类似的词语有玻尔bug(bohrbug)、曼德博bug(mandelbug)和薛定谔bug(schrödinbug),它们偶尔被用于指代其他类型的非寻常软件缺陷,但通常以开玩笑的心态使用。

很多时候,我们对bug进行排查、重现,这个bug就是不出现,或者更糟糕的是:随机出现。

所以,我们不应该只修复症状,而应该找到根源问题,并且修复之。

 

爆栈服务

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

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

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

软件设计系列-1-设计思想

DRY,就是don’t repeat yourself不要重复。相反的做法是WET:write everything twice,类似re-invent the wheel,重复发明轮子。

类似的思想如KISS(keep it simple、保持简单)、YANGNI(you aren’t gonna need it,你并不需要那些东西)。

大道至简,我们不应该over-engineering过度设计,但是适当的前瞻性设计是需要的。譬如扩展性等,否则产品一上线就遇到各种限制。

 

Related image

 

名言

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” 在编程的时候,我们一定要想象一下,以后维护我们自己的代码的那个人会成为一个暴力的精神病人,并且,他还知道我们住在哪里。
— John Woods
Think twice, code once。磨刀不误砍柴工,多思考,再写代码。
Good crafsmanship depends on use of the right tools.工欲善其事,必先利其器

技术债务

英文是Technical Debt。出来混的,迟早要还。欠下的债,也是要还的。做技术也一样,而且这个债一样会有利息,而且是高利贷那种,你的成本爆涨。最糟糕的是,债台高筑,你根本无法还:系统设计一团糟,性能低下,逻辑混乱,代码质量无法维护。

 

爆栈之旅

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

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

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

版权所有

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