关於除错这件事

发达的工具会剥夺人的能力,能力被剥夺後经验会开始狭隘,狭隘的经验则会让思维开始产生死角,有死角的思维......那不是文字可描述的。

(装模作样一下,讲些打高空不着边际的东西做为开场。)

因为IDE工具太发达,(哪怕仅仅是十年前的Eclipse,)Android工程师似乎都很习惯「一个Activity写完所有功能」。——因为IDE工具的介面会帮开发者快速浓缩排列程序码中的参数、函数、 内类别,不用物件导向也可以轻松管理大量程序码,进而导致所有的功能在物件导向上都做得很「随便草率」。
好的物件导向可以让程序逻辑好懂好看,毕竟物件导向的精神之一就在於:用人类习惯可以理解的「万事万物」概念去规划设计程序。
物件导向做得不好,程序就会不好懂,导致不好维护、或团队扩编人力失败。

除了物件导向以外,除错也是个经常做不好的地方。
物件导向程序不好除错。主要原因在於.......出错的地方在於程序的逻辑?或在於逻辑要处理的资料?
逻辑错误就直接修正逻辑,但资料错误则是要回头看「产生资料的逻辑是否有错」,如果有错就修正,如果没错就继续回头看然後「产生资料的逻辑所接收到的资料其产生的逻辑是否有错」,如果有错就修正,如果没错就......
传统的除错法其实就是「测试」。让人力、或某种简单可自动执行的程序去实际操作程序,然後期望可以找出「可能会导致错误的资料」、同时归纳出「导致资料产生的逻辑」.......
这种除错法的问题在於人力或自动程序的能力其实很有限,测试的结果只能保证一个最小范围的可靠性。像「90%的情况跟使用者可以可靠的操作」,然後...不管事前沟通再努力,一旦10%发生时,工程团队就只能集体被抓去献祭平息「高层的怒火」。
要应对这种情况,最合理的方式在於「用大量资料去测试逻辑」。
最好这大量资料本身也是用自动的方法、让电脑帮忙大量动态(乱数)产生。

但这种情况等同另外开一个专案去产生另一套程序用来产生各种资料、再另外产生另一套程序去模拟成一套「会使用到同样逻辑去处理资料」的程序并运作、然後还要再产生一组功能去记录和分析测试的结果,然後......不管事前沟通再努力,一旦时程时程超时、人力预算爆表,工程团队就只能集体被抓去献祭平息「高层的怒火」。
一想到可能要面对高层的怒火,其实没什麽人真的会走这条路,还是乖乖地走传统的「人力」「简单可自动执行的程序操作」就好吧......

当然还有另两条路,那就是使用「UnitTest」框架和重度依赖AndroidStudio的分析工具。
但分析工具看起来再强大,它只是把90%工作变得好像很轻松、做起来很帅气华丽而已。
而前者基本上很多情境跟任务中都不适用,很多时候依旧要仰赖使用UnitTest的工程师自己在里面设计出一套功能来产生各种资料、还要尽可能让UnitTest的运作真的能逼近「实际上处理资料的流程」...并不是说「UnitTest不好」,而是说要妥善使用它,依旧需要不少的人力成本与时间成本,偏偏这些都是很多专案团队当初规划时就否定的事情。(所以「凡事都要现成方案解决」这想法真的是「专案杀手」啊!)

除错不好做啊!


<<:  Day 01 前言

>>:  菜鸡的机器学习入门

## D21 - 彭彭的课程# Python 乱数与统计模组(1)

今天睡眠品质极差 整个人像殭屍一样实在是not my day 好今天是来看看这个乱数跟统计模组 感觉...

第52天~

这个得上一篇:https://ithelp.ithome.com.tw/articles/10259...

Day17 - Ruby 的阵列处理入门

线上 Ruby 编辑器:https://runrb.io/ Ruby Array 文件:https...

Day04:自我增进技术能力与观念的小方法

一、前言   上一篇文章的结尾有提到大家可以在职场上定时自我检视的小习惯,这边分享我自己维持几个月後...

Consistency and Consensus (3-3) - Total Order Broadcast

[Day 19] Consistency and Consensus (3-3) - Total O...