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