- 博客(13)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 小架构step系列12：单元测试
测试的种类很多：单元测试、集成测试、系统测试等，程序员写代码进行测试的可以称为白盒测试，单元测试和集成测试都可以进行白盒测试，可以理解为单元测试是对某个类的某个方法进行测试，集成测试则是测试一连串的方法。测试代码也是代码，即使要求测试代码逻辑简单，但写单元测试代码也是要花时间的，维护也是要花时间的，所以在写测试代码上也要有些平衡。单元测试的颗粒度比较小，最接近方法的业务逻辑，应该详尽的测试；而集成测试牵扯的方法比较多，就比较复杂，就挑重点的地方做测试。本文先了解单元测试。
2025-07-12 17:40:36
617
原创 小架构step系列11：单元测试引入
在还没有写什么代码之前，就引入单元测试，是要强调单元测试的重要性。当一套代码的生命周期比较长的时候，单元测试更加重要。生命周期长的代码，不管是产品人员还是开发人员，可能都会换了一批又一批，维护才是成本的大头。后来的人缺乏这套代码的历史知识，改起来就会bug频出，质量堪忧。如果有单元测试代码，则每次的修改如果有问题，就能够通过单元测试代码暴露出来，这样改代码会比较让人放心。但单元测试代码是一项做了则太平无事看不出作用的事情，但不做则经常要灭火而追悔莫及的事情。
2025-07-11 16:39:31
842
原创 小架构step系列10：日志热更新
日志主要是为定位问题使用的，日志一般分为5个级别：ERROR、WARN、INFO、DEBUG、TRACE，越往ERROR的方向问题越严重，越往TRACE的方向日志越详细、日志量越多，定位问题肯定是日志越详细越有帮助，但日志越详细其占用的磁盘空间越大，量过大也影响日志的检索性能，所以需要在中间做个平衡。生产环境偏向只打印ERROR和WARN级别的，最多到INFO级别，这样大部分问题都能够得到定位。
2025-07-10 18:23:28
259
原创 小架构step系列09：日志量控制
首先，要指定日志存储的位置，也就是存储在哪个目录下。 然后是一个日志文件不能过大，否则需要用的时候，想打开都比较困难，影响日志查看，需要设置一个单文件的最大量限制；既然一个文件不能过大，就必须对日志文件进行拆分，拆分后的文件名用什么格式命名；文件日志过多也不方便，在linux中一个目录下的文件个数也是有限的，需要对文件格式进行限制； 最后一个是对日志总量的限制，不管每个文件的大小和文件数量多少，总量不能超过指定的数量。2.2 原理2.2.1 根据文件名pattern初始化拆分文件的时间周期
2025-07-09 18:18:58
860
原创 小架构step系列08：logback.xml的配置
logback.xml配置文件的详细配置，很多地方都说得比较细，本文主要从几个重点来看一下原理，了解原理能够帮助确定哪些应该配置，以及如何配置。logback.xml是为打印日志服务的，打印的内容一般打印到控制台(Console)和文件(file)里，在生产环境中主要是打印到文件里，然后用扫描工具汇总到某个地方方便查询(如ELK)。打印的内容要符合一定的格式，提供足够的信息，方便进行日志查询和分析；
2025-07-08 21:29:54
653
原创 小架构step系列07：查找日志配置文件
日志这里采用logback，其为springboot默认的日志工具。其整体已经被springboot封装得比较好了，扔个配置文件到classpath里就能够使用。但在实际使用中，日志配置文件有可能需要进行改动，比如日志的打印级别，平时可能定的是WARN或者ERROR级别，如果出点问题，可能希望临时能够调整为INFO或者DEBUG，方便产生更加丰富的日志以定位问题。如果配置文件是放到classpath里，也就会被打包到jar包里，修改配置文件就需要重新打包、部署、启动等，很可能做不到只修改配置文件并生效。
2025-07-07 19:22:23
922
原创 小架构step系列06：编译配置
编写Java代码之后，需要经过编译、打包字节码、打包源码、生成文档之类的操作，这些操作里面的涉及到各种各样的工具和参数配置，这里仅介绍最基础的。建议这块能够简单就尽量简单，平时开发大部分的时间都会聚焦在开发业务功能上，这些编译打包相关的配置其实很少人会去搞懂它，经过一段时间人员的变换，可能里面的知识很容易就丢失掉了。如果配置过于复杂，做很多特殊的事情，那么如果出了问题或者需要调整，由于没多少人懂，那么维护起来就比较困难。所以总体的原则是简单到够用即可，能不用那些复杂的用法就尽量不用。
2025-07-06 17:15:40
460
原创 小架构step系列05：Springboot三种运行模式
前面搭建工程的例子，运行的是一个桌面程序，并不是一个Web程序，在这篇中我们把它改为Web程序，同时从启动角度看看它们的区别。
2025-07-05 16:45:27
962
原创 小架构step系列04：springboot提供的依赖
搭建的工程例子中，指定了spring-boot的spring-boot-starter-parent作为<parent>，然后在依赖中指定了spring-boot-starter依赖，里面没有指定版本，也没看到有指定核心Spring，却能够正常运行，这是如何工作的？
2025-07-04 21:40:12
770
原创 小架构step系列03：springboot与spring版本
可以看到1.x版本有65个，2.x有121个，3.x的目前有50多个，目前主要发展的是3.x，之前的版本基本已经锁定，大多不再更新甚至不维护了。1.x、2.x、3.x属于大版本更新，存在着不少不兼容的情况，更新一次并不容易，所以最好是使用3.x比较新一点的稳定版本。但一直不变动也是不行的，软件行业发展非常快，几年就大变样，说不定哪天就宣布停止服务了，客户听到停止服务就着急，不一定搞懂影响是什么，就强制必须升级。建工程的时候，涉及到SpringBoot的版本和JDK的版本，这两个版本是如何搭配的？
2025-07-03 16:32:42
770
原创 小架构step系列02：搭建工程
从上面可以看到，已经在<parent>节点选上了指定版本的springboot，在依赖<dependencies>节点中也加上了spring-boot-starter和spring-boot-starter-test，在<build>节点中指定了maven编译插件。建一个Java工程，编写pom.xml文件指定依赖，创建代码和配置文件的目录，建一个带main方法的启动文件，即可以完成最简单的工程搭建。对于一个简单的例子来说，上面三个可以选最新的版本都不受影响，一些详细的知识在后面的文章再详细介绍如何选择。
2025-07-02 16:38:13
620
原创 小架构step系列01：小架构初衷
自己实际经历的不少东西是历史沉淀下来的，历史的局限也在里面，要把它的一些局限更换掉，既需要对局限的内容深入了解，也要钻研一些新的知识，才能把这些局限更换掉，这需要花不少时间。在一家公司里，受限于人力有限和维护成本，从零建设架构的机会一般是很有限的，不太会每个项目都重头搞个不同的架构，这对公司的发展和维护是非常困难的。但也有个缺点，就是每次的迭代都是碎片化的，一个个知识就像一颗颗小珍珠一样散落到各个地方，总是感觉差一根绳子把这些零散的珍珠串接起来形成一个项链，也就是一个知识的体系。
2025-07-02 16:21:32
334
spring-framework-3.1.0.RELEASE-with-docs.zip
2012-01-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人