《构建之法》读后感

总算是断断续续把《构建之法》翻完了。说实话，刚拿到手我真没当回事儿。那会儿我就觉得，学软件嘛，不就是敲代码，能跑通、作业能交，就完事儿。什么需求梳理、模块化设计，条条框框一大堆，我当时就觉得那是做大项目才要操心的，平时写个作业、自己捣鼓点小玩意儿，哪至于整那么复杂。结果整本书看下来，回头一想自己写代码那副样子……嗯，脸有点疼。

我写作业也好，假期自己试着搞的那个小游戏战斗系统也好，从来没做过什么提前规划。脑子里大概飘过几个功能点，觉得差不多能动手了，直接打开idea就开始莽。莽到一半就出事儿了，前面写的逻辑跟后面根本对不上。可是推翻重来？那之前花的时间不就打水漂了，太亏了。于是就在原来那团乱麻上缝缝补补，东改一下西修一下，最后勉强能跑了，居然还有点得意。现在想想，真不知道当时在得意个啥。

还有一个更要命的毛病，我老喜欢把代码全写完再来调试，运行，然后红灿灿的报错排着队来了，看着就心态爆炸。前阵子给那个小游戏加角色属性，就结结实实踩了坑。一开始图省事儿，没拆模块，就动了一小段代码，结果跟推倒多米诺似的，这边修好那边又崩，硬生生搞了我一下午才消停。当时真的，砸电脑的心都有了。

看完书我才慢慢回过味儿来。我这种“写到哪算哪”的野路子，看着是省事儿，坑全在后面等着呢。写代码本身真就只是一小步，前面花点时间把需求捋清楚，中间写一段测一段，比闷头堆代码重要多了。

模块没分好，代码就越缠越死，后面想改点啥都跟拆炸弹似的，小心翼翼的。所有bug攒到最后一起搞，小问题全搅和成一锅粥，查起来费老鼻子劲了。自己写着玩还好，搞砸了大不了删了重来。可是后面小组合作咋办？每个人都按自己那套来，风格五花八门、一点规划没有，肯定会把全组都拖下水。

所以我现在打算老老实实改一改，给自己定了几条小规矩：写之前先大概捋一下功能，拆成一块一块的；写完一小块赶紧测一下，不攒着；变量名起清楚点，再也不瞎写什么a、b、temp这种糊弄人的名字了；功能做完了，再多想几种边边角角的情况跑一跑。

这本书确实给我提了个醒。学软件工程，真不能光盯着代码能不能跑。代码说到底就是个工具，工程化的那种思考方式，才是得慢慢磨出来的东西。后面自己啃Java、刷算法题、写小项目的时候，我准备一点点把书里的东西用起来，改掉想到哪写到哪的臭毛病，慢慢让自己变得踏实一点。