在读完《大道至简 —— 软件工程实践者的思想》后，我打破了之前对软件开发、软件工程狭隘的认知。过去我总以为学好编程语言、熟练写出代码就是程序员的全部，这本书让我明白：编程只是基础，软件工程的核心是抓住事物本质，拒绝流于形式，学会变通，也就是所谓大道至简。结合书中观点，我反思了自己学习编程过程里存在的诸多问题。
一、我过去是怎么做的
在学习 Java 程序设计、完成课程时，我一直有着很明显的坏习惯。拿到开发任务，我习惯立刻动手敲代码。需求没有梳理清楚，整体框架没有构思，直接上手写功能。遇到 bug 就临时修改，想到什么功能就往代码里添加，最后整个代码文件特别杂乱，各个功能交织在一起。同时，我十分热衷于学习各种新潮技术名词，盲目了解各类开发模型、专业术语，机械背诵流程规范，却不去思考这套流程出现的意义。小组合作写项目，打比赛的时候，我们还会照搬网上的开发文档模板，机械填充内容，很多文档写完之后再也不会翻看，沟通全靠临时线上聊天，没有留下任何项目记录。
二、为什么这样不好
书中提到一个核心观点：很多人学习软件工程只会照搬模型、走过场，做过程不等于做工程，实现目标才是最终目的。同时书中举例，不要盲目迷信 UML、各类开发流程工具，工具只是沟通手段，如果脱离实际需求、单纯追求形式，一切都会变成无用功。
对照我的问题来看：
第一，拿到任务直接写代码，正是书中所说 “愚公式的埋头苦干”。愚公不停挖山，却没有思考更高效的方法。我只顾着敲代码，没有提前梳理整体逻辑，到后期代码耦合严重，小小的改动就会引发一连串 bug，花费大量时间调试，效率极低。就像书中说的，有人习惯把上万行代码塞进同一个文件，只顾实现功能，忽视结构规划，最终只会自食苦果。
第二，盲目堆砌理论名词、机械套用模板，属于典型的流于形式。我只记住了软件工程的 “架子”，却不理解背后的本质。如果不清楚这套流程解决什么问题，强行套用，写出来的文档只是一纸空文，无法真正帮助团队沟通、推进项目。书中警示我们，只学外表框架，不理解内在思想，最终只会学得不伦不类。
第三，小组开发缺少完整记录、沟通没有规划。书中强调要为后续维护项目的 “不存在的角色” 留下沟通渠道，做好项目历史记录。我们小组缺少资料留存，一旦一名成员暂停参与项目，其他人很难快速接手他的工作，大量工作内容需要重新沟通，白白浪费时间。随意、没有目标的沟通，本质就是流于形式的无效沟通。
三、解决办法
针对上面这些问题，我给自己定下一套固定开发流程，用来规避旧习惯带来的麻烦：
今后不管课程作业大小，严格遵守先思考，后编码的原则。拿到需求之后，强制给自己留出一段构思时间。先用简单文字罗列全部功能，划分模块，梳理模块之间的联系，画出简易流程图，确认整体方案可行之后，再开始编写代码。拒绝一上来就敲代码。其次，区分 “形式” 和 “本质”。学习新的开发理论、流程模型时，先问自己：这套方法解决什么痛点？适合什么样的项目？课程需要文档、设计图时，以 “方便团队看懂、推动开发” 为目标，拒绝复制空洞模板。不需要生硬复杂的专业图表，只要能清晰传递信息，最简单的文字、草图就是最好的沟通工具，践行书中所说的最简沟通。最后，小组协作建立简易项目日志。每次讨论结论、功能改动、遇到的难题都简单记录保存。任何人随时可以查看项目进度，减少重复沟通。同时，开发过程中主动拆分代码模块，定期整理代码，及时删除冗余代码，避免代码无限膨胀。
总之，我感觉《大道至简》没有堆砌复杂的技术教程，而是引导我们跳出代码本身，学会思考软件开发背后的底层逻辑。大道至简，所有复杂的软件工程，本源都回归最简单的逻辑：顺序、分支、循环；所有开发方法，最终目的都是顺利实现需求。作为一名准大二学生，现阶段的我不必一味追逐眼花缭乱的新技术。学会抓住核心、拒绝形式主义、先谋而后动，学会思考优化方法，才能真正走出只会复制粘贴代码的困境，稳步提升自己的开发能力。
