大道至简，道理其实很简单
说实话，翻开这本书之前，我以为软件工程讲的是一堆流程图、一堆文档模板、一堆我听不懂的专业术语。结果读完之后发现，这本书里几乎没讲什么技术，全在讲道理。而且那些道理，说实话，一点都不高深，甚至有点“这我也知道”的感觉。但恰恰是这种“我也知道”的东西，被我们大多数人忽略掉了。
书里让我印象最深的就是愚公移山的例子。愚公移山这件事，放到今天来看就是个软件项目。他有需求，山挡路了，出个门都不方便；他有团队，带着子孙一起干；他有方案，一铲子一铲子地挖。最关键的是，愚公论证这个项目能成的时候，讲的就是顺序、分支和循环。先这么干，再那么干，如果干不完儿子接着干，子子孙孙无穷尽也。
看到这儿我就觉得，编程好像也没那么吓人。说白了就是把一件事情的步骤想清楚，然后用计算机能懂的语言告诉它。如果连愚公都能明白这个道理，我一个大学生怎么可能学不会？我当初选这个专业的时候还挺忐忑的，怕自己脑子不够用，现在想想真是多虑了。
书里有个观点挺颠覆我认知的。大家从小被教育要勤快，愚公就是勤快的代表，天天挖山不停歇。但作者说愚公太勤快了，勤快得没时间想办法，而李冰很“懒”，闲得去看火烧石头，结果发现了“积薪烧之”这个更高效的方法。
我仔细一想还真是这样。中学的时候班上有个同学，每天最早到教室最晚走，笔记记得密密麻麻，但成绩就是上不去。而我同桌看着挺轻松，该玩玩该睡睡，成绩却一直很好。后来发现他花了很多时间在琢磨学习方法上，不是不努力，是不做无效的努力。
写代码也是一样。我写课程作业的时候就是个“愚公”，打开编辑器就开干，写一半发现方向错了，删了重来，反反复复折腾好几天。其实要是先把逻辑理清楚，可能两个小时就搞定了。积极工作和勤于思考都占时间，但后者花的时间值。
书的后半部分讲团队和管理，我一开始觉得跟我没关系。我一个刚上大一的学生，又不当项目经理，知道这些干嘛？但后来想想，小组作业不就是个小团队吗？几个人分工写一个程序，有的人特别积极什么都想自己干，有的人等着别人安排任务，还有的人压根不出现。最后要么是积极的那个人累死，要么就是几个人凑合交了个半成品上去。
书里说三个人的团队就要有明确的分工和角色，谁负责什么要说清楚。这道理多简单啊，但我们每次做小组作业都不好意思说，觉得说这些显得太正式。结果就是大家都憋着，最后憋出一肚子火。书里还说了个特实在的观点，项目出了问题不要急着怪员工，先看管理制度和组织结构有没有问题。这个我觉得放在小组里也一样，分工没明确之前，出了问题就是大家都有责任，谁也别说谁。
整本书读下来，我最大的感受就是：别只知道埋头干活，得时不时抬头看看路。作者说很多程序员一接到任务就开始写代码，加班的往往就是这批人。我写作业也是这个毛病，拿到题目就开始敲，敲到一半卡住了再想，浪费了大量时间在试错上。
软件工程说到底不是什么神秘的东西，就是先想清楚再动手，想不清楚别瞎动。这本书没教我具体怎么画流程图怎么用UML，但教了我一个更根本的道理：所有的工具、方法、过程，目的都是把软件做出来。忘记了“实现”这个根本目的，做再多流程都是走过场。
作为大一学生，我现在代码写得还不多，经验也少，但能早点读到这本书，至少让我知道了编程不光是学语法、敲代码，更重要的是一种思维习惯。先思考再动手，明白为什么比知道怎么做更有价值。这可能就是这本书说的“大道至简”吧——道理其实很简单，但真正能做到的人不多。
