301
社区成员
发帖
与我相关
我的任务
分享在本单元中,我的正向设计方法为:
进行本单元架构设计时,由于经过了长期的训练已经可以较为成熟地形成一个较优化的架构。

UML模型与代码始终保持了一一对应,不再赘述。
经过从先导课程到正式课程以及其它一些课程的一系列训练,我在架构设计、测试思维上均有改进心得,总结如下:
初入OOPRE时,我学习了一些设计模式、良好架构知识等等;而现在经过了巨大的训练代码量的堆砌,我越来越有这样一种体会:没有长期和代码耳鬓厮磨的过程,没有接触足够的底层代码的细节,是无法对这些顶层的架构原则有深入的理解的,因为这些顶层原则其实都来自对底层细节的提炼总结。借用曾经看过的一本《代码整洁之道》中Bob大叔的话,我们所有的设计其实都是和各种“代码坏味道”作斗争,那些封装、继承、多态以及更多原则所解决的问题,都是实现过程中切切实实会让你眉头一皱,会觉得这段代码如此写很“丑陋”的问题。
这样的感受在这最后一单元的架构设计权衡过程中尤为明显:显然这架构并非唯一,而我当时也在几种可能的设计选择中纠结良久。例如,对上图中类似“书容器”的类,是使用一个接口并让所有人实现,还是使用一个抽象类“书籍容器”并让大家继承自他?最后我选择第二种,并且甚至发现所谓的抽象的“书籍容器”与书架的功能完全一致,他甚至不需要是一个抽象类了。做出这一选择,是由于我先前总结的一点个人原则:当你不确定如何设计某个部分,就让它符合本身事物自然的逻辑,这样往往会多出少量不必要的层次和工作量,但是既不容易出错(因为符合其本身的逻辑),又便于扩展,还容易进行修改优化。
另外,作权衡的过程中,当你看到图中的架构,能自然联想到相应的代码实现,并且该种实现的代码“味道”马上能够冲击你的头脑,那么就比较容易做出合理的选择。我惊喜于这种训练带来的“第六感”在我作设计选择的过程中始终伴随着我,让我敏锐地察觉到每种方案的优劣,并且在此基础上(也基于个人的一些喜好)进行选择。经过良好设计的架构,经过适当的逻辑层次设计,让这三次作业的架构修改基本稳定,均是在原先预留和预计的可扩展位置进行的少量扩展。
实际上,由于其他课程的压力以及其他同学的dpo测试器出现,我仅在第一单元写了自己的测试器。然而,经过对测试的理解的发展,我逐渐认识到:测试当然不仅仅包括自动测试这一手段,自动测试也不仅仅包括黑盒测试这一手段;测试思维实际上可以说是一种开发思维,它在我们企图保障自己开发的软件的正确性时,或者是企图寻找一种不容易出错的开发方法和流程的时候,就体现出来了。
就个人而言,我的大部分测试工作,其实在开发阶段无意识地完成了:开发目标被划分为不同的、可以进行测试的阶段和模块,怀着某种功能预期,实现一个模块就测试验证该模块的正确性。这里往往是通过手工测试的方法,但是对每个模块的功能的预期以及实现过程中察觉到的可能出现的问题,都使我在实现期就思考和积累了一些手工测试样例,并且这些样例的功能非常精准。在第二单元的首次作业中,我对这一情况的印象十分深刻:完成整体作业后,我凭借对实现细节和可能出现问题的印象手写了不到十个样例,但是每一个样例都精准命中了至少一个bug,并且不同的样例命中的bug是不同的。也就是说,实现过程中潜意识里积累的薄弱点,以及基于实现细节对薄弱点的猜测,确实是非常精准的。
感谢OO!