看《大道至简》有感

翻开周爱民先生的《大道至简》，扉页上那句“软件工程归根结底是人的工程”让我陷入沉思。这本书不厚，却句句戳中我过去两年编程学习中的痛点。借着这次读后感作业，我认真梳理了自己的“前尘往事”。
说来惭愧，从大一学C语言开始，我就养成了一种根深蒂固的习惯——拿到题目就写代码。学C语言时，老师布置一个“学生成绩管理系统”，我第一反应是打开Dev-C++，直接敲#include<stdio.h>，然后边想边写，边写边改。变量命名随意用a、b、temp，函数动辄两三百行，全靠goto和全局变量硬撑。到了学C++，情况并没有好转——虽然知道了“面向对象”，知道有类、继承、多态这些概念，但我的做法依然是“把C++当成C来写”，只不过把printf换成了cout，把struct换成了class，本质上还是面向过程的思维。记得大二上学期用C++做“图书管理系统”时，我甚至没画一张类图，没理清任何对象之间的关系，直接在main函数里堆了四百多行代码，靠switch-case撑起整个菜单逻辑。当时还沾沾自喜，觉得自己“上手快”“能跑就行”。身边的同学也大多如此，谁画图谁就是“装样子”，谁写文档谁就是“浪费时间”。我们这群从C语言摸爬滚打过来的人，把“能编译通过”当成了唯一追求。
《大道至简》第一章就给了我一记响亮的耳光。书中说：“很多程序员从需求分析就开始写代码，这相当于没拿到施工图就砌墙。”这句话让我想起当初那个C++版图书管理系统交上去后，老师轻飘飘说了一句“加个预约功能”，结果我花了整整三天改代码，还改出了三个新Bug——还书时明明逾期了系统却显示“归还成功”，罚款金额计算错误，借阅记录莫名其妙丢失。原因很简单：我当初根本没有用类把“图书”“用户”“借阅记录”这三个核心对象的关系理清楚，所有数据全靠数组硬存，逻辑全揉在main函数里。
书中进一步剖析了这种做法的深层危害：混淆了“编程”与“工程”的本质区别。我过去学C和C++，本质上一直在学“语法”和“技巧”，却从未学过“如何用工程化的方式组织代码”。C语言给我的惯性是“面向过程、自上而下”，到了C++虽然有了类的概念，但我只是把它当成“带函数的结构体”在用，根本没有领悟到“封装”“继承”“多态”背后是为了应对复杂性的工程考量。书中引用《道德经》“始制有名”提醒我们：任何复杂系统必须先建立清晰的概念模型，才能实现稳定的功能。而我当初的行为，等于是用C语言的“野路子”思维去写C++项目——工具升级了，思维却没跟上。更可怕的是，书中说这种“上来就写”的模式会让人陷入“愚昧之山”，自以为效率很高，实则方向错了，跑得越快离目标越远。
《大道至简》给我的最大启发不是某种具体工具，而是一种 “先建模、后编码”的工程思维。结合书中“泛泛而谈的管理是无效的，必须落实到可执行规范”的观点，我为自己制定了三条硬性规矩：
第一，先画类图再写C++代码。 以后但凡用C++做项目，动手编码前必须先画出UML类图，理清每个类的属性、方法和相互关系。把“这个类负责什么”“那个类和这个类是什么关系”想清楚，用书中的话说，就是先“正名”再“行事”。
第二，杜绝“巨型函数”，坚持单一职责。 过去我习惯在main函数里堆几百行代码，书中明确指出这是“工程灾难”的源头。今后我强制要求自己：每个函数不超过五十行，每个类只承担一种职责，把C++的封装特性真正用起来，而不是继续沿袭C语言那种“全局变量到处飞”的陋习。
第三，每天留出“回看时间”。 每天编码结束后，强制自己花15分钟回看当天代码，问三个问题：这段逻辑能否复用？这个类是否承担了太多职责？如果需求变化，哪里会最先崩塌？这其实是在践行书中“迭代式精化”的思想，把大问题化解为小闭环，让错误早发现、早修正。
读罢《大道至简》，我最大的收获是意识到：从C到C++，升级的不应该只是编译器，更应该是自己的思维方式。 真正的简洁不是少写代码，而是让每一行代码都有其不可替代的位置。我打算把这份读后感打印出来贴在书桌前，提醒自己：下一次敲击键盘之前，先问问纸上的“蓝图”是否已经清晰。