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

之前我们在 开发思想 – 代码的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个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

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

版权所有

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

爆栈之旅-.NET- C# – 数据访问

目录

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

 

 

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

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

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

版权所有

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

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

一技防身

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

全栈

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

那该掌握什么?

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

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

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

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

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

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

 

爆栈之旅

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

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

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

版权所有

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

学员问答精选 – 1 – 数据库表拆分

问题

有学员提问,说他在用一个数据库,里面有一个典型的ToDoList表:

  • id
  • title:标题
  • isFinished:是否完成
  • isRemind:是否提醒
  • remindDateTime:提醒时间
  • remark:备注

因为在用户长时间使用后,已完成的任务会很多,如果把两个表写成一个,可能会有比较多的不必要的检索。

所以,他把这个表拆成两个,结构完全一样,一个叫Undone(未完成),一个叫Done(已完成),Done里面的isFinished的值是true。

可是他后续写业务逻辑的时候,发现这样的写法,当切换任务是否完成的状态的时候,需要更新该任务的isFinish,并将该项从原来的表删除,再加入新的表。

因为该数据库没有提供能直接移动该项到另一个表的方法,后来他也想了想这个结构,感觉有点问题,可是他又说不上来是什么问题。

 

大家觉得这个设计有什么优劣点?你是否能提供更好的解决方案?我下面会提供我的建议。

 

阅读更多