MIT 6.031 - Software Construction闲话

关于为什么要开这个坑

网课时代到来了,这是天赐良机,要开始全面csdiy啦

至于为什么要选这个…

学术界当然也要讲究这个,不然写出来的是什么东西

以后不管走什么路,只要还跟程序打交道,终归是要开发重型软件或者大型系统的。现在在做的一些大作业或者自己的开源小项目虽然算不上重工业,但是多少也需要讲究一些基本原则,在平时的开发里就要养成规范的习惯。

之前工程经验为零,思维还停留在竞赛时代的小代码。在做慢慢开始动手小工程时由于各种操作不规范,耽误了相当多的时间,开发效率低下,因此非常有必要学习软件构建的原则和方法论。因此首选MIT\text{MIT}的这门课。MIT\text{MIT}出品,必属精品。

此外,这门课有相当完善的Notes和作业和Project,而且也不是很烧脑非常适合一边挂着腾讯会议听网课一边看Notes,这门课没有视频课,因此这是最快最高效的学习方法。作业啥的做不做是一回事儿,但是很多有用的闲话确实可以记录在此。

这门课使用的语言是Java\text{Java},当然,如果真要做,确实可以练手Java\text{Java},但是软件构建的要点对于几乎所有语言都是适用的除了根本不适合重型开发的语言

这个Blog\text{Blog}仅用于记录每一节我读到的很有启发意义的点,以一级标题列出每一节主题,以二级标题列出这些重要的点。

1. Static Checking\text{1. Static Checking}

这一节主要介绍了静态类型语言和动态类型语言的编译时检查和运行时检查。其实没什么特别重要的点,毕竟是有C/C++\text{C/C++}经验了这里列出来的Bug\text{Bug}都经历过只要记住动态类型火葬场就行

课程目标

以后随时提醒自己,写出来的项目一定要做到:

Safe from Bugs.

Easy to Understand.

Ready for Change.

好的程序员必须掌握多种编程语言

3. Testing\text{3. Testing}

及时准确的测试是提高开发效率的关键

测试优先

下面这种顺序是非常推荐的。

首先应该写好模块的规范

然后编写好测试程序

最后来写实现

而不是写完一大坨各种屎山代码然后一起跑跑出锅了再钻回屎山找Bug\text{Bug}

系统性地测试

正确,全面,并且规模小

因此要合理划分可能的问题域(并且写在规范里),在问题域的每个划分内取用例进行测试。

4. Code Review\text{4. Code Review}

其实这一节的很多老生常谈在《代码整洁之道》这样的书里也都讲过。。。

一个变量只有一个用途

变量不是稀缺资源,不要给同一个变量前前后后赋予多种含义。

不要用tmp, data这样的变量名

这说明你的设计是偷懒的。。。变量名应该更具描述性。

少写特判代码

不要一上来就先写特判,应该首先写出适用于大多数情况的代码,检查它是否能应对某些“特殊情况”,不能的话再改,使其更具普适性。本末倒置是不好的。

用原讲义中的加粗体来说,你应该主动抵抗想要单独处理特殊情况的诱惑

不要缩进

意思不是说你不能敲Tab\text{Tab},但是你的编辑器最好把Tab\text{Tab}处理成一堆空格,以免制表符在你的程序文本里被编译器啥的误解了。

9. Avoid Debugging\text{9. Avoid Debugging}

如果规范写得清晰,错误处理得好,很多时候只需要看代码即可定位bug的位置。

善用assert\text{assert}

assert\text{assert}在运行时检查条件,非常重要,但是不能滥用。

什么东西应该使用assert\text{assert}检查?

对传入参数的规范检查:例如取值范围之类。

对返回值的检查:也称自检。

条件语句和switch\text{switch}语句:为了防止你的条件没有覆盖所有可能的情况,用assert\text{assert}对不满足所有条件的情况做检查是好文明。

什么东西不应该放在assert\text{assert}里?

assert\text{assert}包围的表达式不应该有副作用,这是因为在Debug\text{Debug}模式下assert\text{assert}会启用,但是Release\text{Release}模式就不是了,assert\text{assert}内的表达式可能不会被计算。

增量式开发

一点点慢慢写,一点点慢慢测,不要写了一大坨然后一起折腾。