读《构建之法》观后感

这本书是老师让读的，说实话刚开始我挺抵触。软件工程，一听名字就觉得是那种全是理论、全是图、特别无聊的课。结果翻了几章我就闭嘴了。
先说我大一写C语言作业的事。大一上学期的C语言课，每次布置作业，我都会在截止前打开电脑写。那时候哪懂什么模块划分，就一个main.cpp，从上到下，输入、处理、输出全塞在一起。变量名全是i、j、k、temp、cnt，因为敲起来快嘛。但代码一长，问题来了。我的temp变量用了七八次，很多时候temp代表的变量都不同。到后来我自己都搞不清楚当前这个temp到底代表啥，得往前翻半天。想改个名字吧，又怕改漏了编译报错，索性就不改了，硬着头皮往下写。测试就更别提了。我所谓的测试就是编译通过了，然后自己输两组数据，看着屏幕上出来个结果，就觉得自己写完了。有一回室友拿他的数据跑我的程序，输了本带空格的书名进去，程序直接崩了。我还来了句"谁会这么输啊"。说完自己都觉得这话站不住脚。软件写出来就是给人用的，人家怎么输是人家的自由，你的程序扛不住就是你的问题，跟用户没关系。
书里有句话我印象特别深，大意是代码首先是给人看的，机器只是恰好能运行它。我当时就想到自己那一堆temp、flag，别说给别人看了，放一个月我自己看也跟天书一样。有一次想复用之前写的排序代码，打开文件满屏的temp1、temp2、cnt，还有个变量叫flag_2，我瞪着眼睛看了快半小时，实在没搞明白那个flag_2到底是控制升序降序还是控制循环跳出。最后全删了重写。当初省那点起名字的工夫，后面翻倍赔进去，亏不亏。
还有一个事。我写代码从来是全部敲完才开始"测"，其实就是手动点一点。出bug了就硬改，经常这边修好那边又蹦出新的。有一次为了修一个数组越界的bug，折腾到凌晨两点，改完了一运行，又出来个段错误。第二天问同学才知道，我修bug的时候动了循环条件，导致后面的内存访问也跟着乱了。书上说bug拖得越晚修起来代价越大，因为各个模块已经绞在一起了，改一个牵扯一片。我这就是活案例，前面规划的时候懒了一下，后面通宵还债。
时间估不准也是老毛病。课设截止前一周，老师说还剩七天，我心想两天就能写完。结果前五天晃悠晃悠没怎么动，最后两天通宵赶，代码写得乱七八糟，注释也没有，函数名起得跟密码似的。书里说估不准是因为从来没把任务拆细过，也没记过实际耗时，永远凭感觉拍。我仔细想了想，确实是。每次都把"写课设"当成一件事，从来没分成"搭结构、写输入模块、写核心逻辑、写输出、调试"这些具体的步骤，当然估不准。
写到这想起来还有一个。我以前的代码基本没注释，觉得代码自己能说明问题。结果有一次要交课设报告，要求写设计思路，我对着自己的代码看了好久，愣是想不起来某个函数为什么那样处理边界条件。最后报告里写的跟我代码实际逻辑是两回事。书里说注释是写给将来的自己看的，我就想，那个"将来的自己"就是我啊，而且才过了一个月就不认识了。
看完这本书真没什么高大上的感悟，就是觉得自己以前挺蠢的。但知道蠢在哪了比一直觉得自己挺厉害强。
现在我就给自己定了几件特别简单的事，太复杂的也坚持不下来。写代码前拿张纸画几个框，把大概的数据怎么流动的理一下。花不了二十分钟，但后面顺畅很多，至少不会写到一半发现结构要推倒重来。每写完一小段就随手输几个数据试试，边界值、空值、乱输的，都过一下，不攒到最后一块崩溃。变量名老老实实打完整，studentList就studentList，borrowDays就borrowDays。顺手写句注释，哪怕就一行，告诉自己这是干嘛的。再就是开始记时间了，每次实际花了多久记下来，下次再估心里好歹有个数。
以后动手之前先问自己一句，这堆东西一个月以后我还看得懂吗。想清楚了再敲，不想再干自己坑自己的事了。