今天的内容,和源码分析无关,但是从前两篇的软文中,受到启发,进行了浅思(在我骑小毛驴的路上)
在写此文时,总喜欢问大家几个问题,为什么要进行“源码分析”?我们的动机是什么?
当然了,今天我不讨论这些。我们来讨论讨论为什么如何进行源码分析,这就决定了你对一套系统的认知度,认知度越高就越能hold住系统,就可以随手捏来
情趣指数:★★★★★
驱动力指数:★★★★★
在我的定义中,兴趣使然是一个人阅读能力,求知能力最强烈的时候。大脑能力印象最深刻的时候
情趣指数:★★★★
驱动力指数:★★★★★
这种场景一般是,工作需要,进行的技术预研或使用,探究方式应该是很全面的,但是不知道
情趣指数:★★
驱动力指数:★★★
这种方式一般是学习特性,使用demo阶段;看看示例,增加技能
情趣指数:★
驱动力指数:★
这个层次,纯粹是了解一款产品,或是技术选型。对产品的特性特别在意,或同时对比多款产品
这里我探讨一下,我所了解的方式
这是最抽象的部分,架构图上的文字,字字是金,多一个显得累赘,少一个显得乏力。
一开始可能看不懂,只有你深刻体会之后,你才能理解;来我们再来回顾下elastic-job的架构
这个是重重之重,万变不离其宗的方法,比如elastic-job中的JavaMain
除了JavaMain,类似的还有什么Index之类的都是
这个就是咱们平常说的Debug模式;
打个断点放在那里,当程序运行到这里时,就可以看到调用链,调用链的深度体现了作者的思路层次,和规划控制能力。
这里的Test类,大家有必要看看。
从标准的软件测试中,只有自动的测试用例覆盖到100%时这才是生产中可用的软件,只有一个测试用例不通过,就是不能发上线的。当然这只是理论上,实际中,或多或少有些东西咱们是可以跳过的,比如不涉及核心业务的边缘测试,或是不涉及金融相关的边缘测试,这些测试用例都或多或少过去的。
来看看我在项目中的使用场景
我们来看下BaseTest这个基类,所有的测试类都要继承它
在更多的小公司中,这一环节都是没有,只要项目能上线就好。哎,他们也没有太多的人力来做这个,我希望看过这篇论文后,大家都把单元测试都加上去。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/spy19881201/article/details/61913922
内容来源于网络,如有侵权,请联系作者删除!