读《大道至简》有感

《大道至简》，书如其名，乃是软件工程的至简之大道。作为一名刚升入大二的编程小白，我只学习过基础C语言，数据结构也只是堪堪入门，从未接触过真实的企业项目。我原本以为这种软件工程读物会通篇是复杂的专业名词，但当我真正读下去后，才发现书中没有晦涩难懂的专业术语，反而借用各种典故拆解行业的底层逻辑，使我拨云见日，每一章都在拓宽我浅薄的认知。
第一章编程的精义，以愚公的故事引出一个工程的概况，让我推翻了编程靠聪明和复杂语法的认知。从前我认为程序都是复杂高深的，认为代码都是约复杂的越好，考试也只会机械的套用，没有真正思考过程序的底层逻辑。这一章剖析编程的核心，只有顺序、分支、循环三类结构，以及核心公式“程序=算法+结构”，使我真正明白，现在的我不需追求高深的技术，只要吃透底层逻辑，能够梳理工程步骤，才能为以后的编程学习打好基本功。
第二章，是懒人造就了方法。这一章再次运用典故，李冰积薪烧石开山的故事再次推翻我的认知，曾经我写代码经常重复写一模一样的功能，写下来甚至觉得自己非常努力。但事实是这样的重复工作对自己知识增长以及效率提高毫无意义。只有希望工作简化的“懒人”才能找到能够高效解决重复工作的方法，归纳总结与创新才是程序进步的源泉。同时作者再次提出新的公式“程序=算法+结构+方法”，更是让人醍醐灌顶，让我明白学会封装拆分代码，简化重复劳动，才能成为一名优秀的程序员。
第三章，团队缺乏的不只是管理。这一章讲的是团队组织，但我目前还没有接触到团队任务，只是小组作业有一点相似，但规模远不及此。作者提出三人才有团队，要有分工、监督、权责，要有清晰的角色划分。ISO体系的失败更说明组织架构的完善、项目经理的责任、管理团队的方案都是大型团队不可或缺的一部分，没有合理的组织，再好的管理规范都是空谈。
第四章，流于形式的沟通。程序员最重要的能力就是把客户的需求转化为程序，以及把晦涩的代码变成客户能看懂的形式。作者提出“最简沟通”的理念，沟通时要提前梳理问题，带着明确目标交流，以及项目留存记录，给后续工作留下沟通渠道。这一章让我明白不必追求专业工具，清晰高效的沟通才是唯一标准。
第五章，失败的过程也是过程。很多团队做产品时都是照搬模型走流程，最后却无法交付合格产品。这里作者提出做过程与做工程的本质区别，流程模型只是实现产品的手段，而真正实用的可用功能才是工程的最终目的。现在企业多流于形式主义，各种认证，评审，文件，反而将核心代码开发搁置一边。作为学生的我也该明白，一味照搬流程模板那只是为了应付作业的摆设，绝不能为了遵守流程而牺牲项目本身的功能开发，要有依项目需求而变的能力。
第六章，从编程到工程。这一章给出了完整的软件工程分层逻辑，从内层程序向外依次是方法、过程、工程、组织，让我从只看代码的狭隘思维中走出来。作者通俗易懂的“牛屎图”更是让我清晰地了解了软件工程体系层次，极大拓宽了我的视野。计算机专业不只是敲代码的机器，更要懂得协作、组织、项目规划相关知识。
第七章，现实中的软件工程。这一章跳出理论，通过讲述诸多大厂的商业布局论述软件工程是商业竞争的产物，软件工程从没有万能开发模式。作者提出的项目需要考量时间人力等隐性成本，也是我之前未考虑过的角度。
第八章，是思考还是思想。这一章升华了“大道至简”的核心，各种理论与模型万变不离其宗，教会我学习万不可死套模板，灵活变通，不生搬硬套，这是我成为一名优秀程序员的基础。
读完全书，我不由得开始反思自己，复盘过去的学习陷阱。以前我盲目追求“看起来专业”，代码总是想写的复杂，最后却发现往往十几行能实现的功能我却写了近百行，还会死记硬背各种模板，以为掌握这些表面功夫便是学好专业的表现。但这种舍本逐末的做法无疑是错误的，忽略底层逻辑的复杂代码会导致难以维护，硬套模板写出来的程序经常不能实现功能甚至无法运行。为了避免这些误区，今后我会调整学习思路，写代码优先追求简洁高效的代码，流程图也要依题目灵活而变。
读完这本书，我的心态完全变化了。放下浮躁的心，把所有复杂理论拆分细化，追本溯源，看待行业也能褪其浮华，抓住本质，为我接下来的专业学习指明方向，这才是软件工程真正的“大道至简”。