写在前面
现在是2024年4月5日,我打算将我的学习笔记不断记录到CSDN上。
这个笔记用于我本人的复习,所以引用了很多东西。如果被侵权了请联系我,我会删掉,谢谢。:-)
写这个笔记,根本目的是希望我能养成做有效笔记的习惯,帮助我提高学习的效率。除此之外,我还希望能借由这个渠道来锻炼我书面表达的能力(因为发现上了大学之后越来越不会写文章了,偏偏又还有一堆文章要写 :-( )以及提取信息的能力。
说实话,不知道我能坚持多久,但是我还是希望我能一直坚持下去。
今天先从软件构造复习开始。
章节一 软件构造多维度
首先引入两个比较重要的概念:时刻状态与时段状态(自翻)
还有一个很重要的方格图,表明在不同阶段你的代码是什么状态:
如图,在一个确定的时间段,你的代码只会在以下三个方面应该引起你的注意:词汇层面、语法层面和语义层面
在这个阶段,我们需要关注的是代码可能发生的变动:如哪里哪里增加了一行、删除了几个变量云云。说到这个,我们后面要介绍到的版本控制工具(Git)可以将代码发生的变化更直观地显示出来。
项目的一个组件(Component)在一个瞬时表现出的状态应该是各个工程文件的的排布:html文件放在web目录下,测试文件放在test目录下,所有的源文件夹又都放在src目录下。
这里还引入了“库(library)”的概念。
Maven仓库的概念也是初次被提出,之后的web项目中我们会经常见面。
一些基本的事实:
1、编程时和build时,需告诉IDE和JVM在哪里寻找某些库;
2、库被拷贝进代码,并形成一个整体,执行的时候无需提供库文件
3、关于将库连接入项目的方法,有静态链接和动态链接。静态链接发生在构造阶段。
接下来继续分析之前见到的图表:
版本控制系统,即Version Control System (VCS)的概念初次被引入了,它的工作形态大概就像下图那样:
PS:顺便去查了下VCS的进化历史。
第一代版本控制系统被称为本地版本控制系统。通过加锁将并发执行转换成顺序执行。 一次只能有一个人处理某个文件。
第二代版本控制系统被称为集中式版本控制系统(Centralized Version Control Systems,CVCS),其对同步修改更加宽容,但有一个明显的限制,用户必须在允许提交之前将当前修订合并到他们的工作中。
第三代版本控制系统被称为分布式式版本控制系统(Distributed Version Control Systems,DVCS),其允许合并和提交分开。在每个使用者电脑上就有一个完整的数据仓库,没有网络依然可以使用。
不过我们更为应该熟知的应该是下面的形式(上面的形式好像是老式的VCS了?),也就是进化树
当你有小项目需要继续完善,那么可以把它单独提一个分支出来,等到优化完成后再把分支合并回去。如果你想要开发可能存在风险的新功能(不确定是否能够完成或是不能确定完成时间,同样选择单开一个分支,而它是不保证能够并回去的)。
还是回到那个表,现在来到runtime阶段
代码快照图的概念初次被提出,在我们后面理解数据的可变与不可变时他会排上大用场。
代码在runtime的表现,可实例化为UML中的时序图。
然后就是UML中的部署图。
最后是日志。
整个图最后的总结如下:
如果你的英文实在不好,后面还有中文版的图。
下面这张图很形象地表现了build-time和run-time的具体行为
现在我们需要介绍一个程序的质量指标:
1、Correctness,正确性。这是最重要的质量指标;
2、Robustness,健壮性。针对异常情况的处理 ,让程序出现异常时不要崩溃;
3、Extendibility,可拓展性。对软件规约的修改是否足够容易;
4、Reusability,可复用性。一次开发,多次使用;
5、Compatibility,兼容性;
6、Efficiency,效率。当然前提是正确性要满足;
7、Portability,可移植性;
8、Ease of use,易用性。这是对用户而言的,说白了就是你这个程序是不是容易学、安装、操控与监控;
9、Functionality,功能实用性。不添加太多不必要功能的意思?
10、Timeliness,及时性。
还有什么可验证性、完整性、可修复性......
前四个是最重要的:
最后给出那张表的一些中文表示,希望你至少能先去尝试理解一下那些英文:
还是那句话。知识是死的,这些东西还是需要到实践中去理解。
当然为了考试可能还是要死记硬背一下 :-(