原本我因为以为《大道至简》这本书应该就是讲优化简化代码结构的书，但是在读了之后，发现并不是这样。初看这本书的页数很少，满打满算区区100多页，但是内容很多。虽然读的不算详细的收获还是不少。因为我还没有团队合作等真正的工作的经验，所以对这本书关于管理沟通的部分读完没有什么感触，但是对其他部分的内容还是有一些自己的学习理解。
首先就是对编程的理解，编程就是种把要解决的事情交给电脑做的行为。编程的本质概括：程序 = 算法 + 结构，代码并不是编程最重要的是甚至微不足道。这与我之前的理解很是不同。一开始我的理解就是，用代码来解决问题，对编程来说不就是码代码吗，但是我在读了这本书之后，我有了新的理解。对我自己的在一年多来完成作业的经验来看，书中说的很准确。单单码代码本身，就是一个简简单单的体力活。真正重要先把事情分析清楚，事件先后的逻辑关系和依赖关系搞清楚。在此前的作业经历里，我在完成一个可以输入成绩并完成相关成绩操作的程序作业时，一开始就是书所说的那种“一接到任务就开始 Coding 的程序员”，因为要求了文件导入导出，我一开始就直接就把数据写入了文件。在经过一段时间的编程来到按成绩为学生排序时，因为数据直接写到文件中了，我只能把它在提的链表里在排序，我这时就在想，为什么我一开始不用链表，这样就不会这么麻烦了。最后明明不算难的一个程序，还是花费了许多时间。如果一开始就好好根据需求好好想想在动手，应该很快就写完了。
再一个就是懒人创造了方法。原来我以为按到流程就能最简单的解决问题，读过书后，那些看起来最简单的方法可能是最耗时间的。首先整理书籍一样，整理方法知识，把最常用的找出来。有了基础在要跳出固有的思路，在对问题的思考中寻找创造比看上去最简单方便的方法更简单方便的方法。
对过程的进一步了解，起初我认为编程开发中过程很重要，一次开发需要那些过程是确切的，但是我现在理解了在工程编程中过程只是为了实现目的的副产品，简单套用那些经典的流程，过于专注于流程只会被被流程捆绑，没了创新和发展。专注于流程不如去思考过程为什么是这样——为了完成目的。为了完成目的所以流程是这样，而不是这样的流程才能完成目的。
作的重要性。我在读1.2章和后面合作沟通的章节的体验完全不一样。前面我感觉书的内容紧紧抓住了编程的实质，能引发思考，对此收获颇丰。对后面的合作沟通就没有什么共鸣，读完了感觉学到东西寥寥无几。后面有经验了有机会还要在读一遍。
还有许多小收获，更像是一些思路的小扩展，在这里就不在详说了。