由于自己刚学习编程一年之久，对于《大道至简》中的项目管理可能理解较浅，在本篇博客中主要阐述自己读完后对编程的思考和感悟。
所谓大道至简之义，即是大道理（基本原理、方法和规律）是极其简单的，简单到一两句话就能说明白。正如“真传一句话，假传万卷书”所述，大道理不是著书长论，而是短小精悍，道理的本质往往可以用很简单的一句话来解释，应用到编程（或者说软件工程这个专业术语）来说更是如此。不论是多么宏大的工程，其模块和单元都是由循环，条件，逻辑等基本结构按照某种组合组成。这个道理起初自己并不理解，直到自己亲手实践做一个学生管理系统，文件的导入导出，人机下棋（以前自己从未想过，也不敢尝试），自己才明白，原来一个复杂的程序并不是自己想象的那么难。只要将一个程序分解为若干个小程序，小程序再分解为自己所熟悉的循环，条件等结构，这样便可以做到以大化小，以繁化简。
举一个具体的例子，当初自己编写一个简单的日历程序输出，当时的自己只想着要通过某种方式去访问电脑的日历并且调用，从而实现日历的输出。自己尝试了好几天，最后还是放弃了，自己想的太高大尚，太复杂，以至于忘了编程的精义。后来问了下自己的同学，同学只说了一句话：只需要判断年份是否瑞年，月份是31天还是30天呗。
书中对语言的描述确实是真理（当你学习了多门语言后你就会明白）：通常而言，语言的差别主要表现在适用范围上。一些语言适合做数值处理，小数点后可以精确到原子级，而小数点前则可以表达到宇宙之无穷；另一些语言则适合做图形处理，它的底层函数库比其它语言可以快上十倍或数十倍；还有一些语言则适合于做网页，要用它来做一个通讯薄软件都将是史无前人的挑战。比如说C灵活的指针，C++类的封装性，java的跨平台的优势。成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。不但是悲其一叶障目，更要悲叹于那种大愚若智的自得心态。
我学习编程一年之久，说实话，对于编程还是似懂非懂，直到读到这本书后方才有所悟，自己应该把学到的知识分类归纳整理一下，正如摆放图书一样，让知识有序的摆放在自己的大脑中，并认识到所学的知识应用到哪个位置，而光整理归纳还是不够的，还需要自己在项目中不断地磨炼。
世界是由懒人推动的，同时方法也是由懒人创造的。你可以像愚公一样勤快，也可以像李冰一样烧火碎石，然而人的精力是有限的，一个简单而快捷的方法对于工作效率至关重要，因此一个好的方法是必要的也是必需的。一百万行的代码写在一个文件里的时代已经不存在了，转而代之的是模块化，单元化的思想，然而如果你是超级大师，或许我说的毫无意义。
同现在教科书所认可的“程序=算法+数据结构”所不同，这本书阐述的是：程序=算法+结构+方法。方法，是历经岁月的发展人们日益在编程经验的总结，也可以说是一种自然的沉淀。方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。只不过，有人 归纳、抽取、提升了这些行为的内在规律。你需要通过编程来感悟，来体会。
编程不能仅仅拘泥于格式，更要了解它的原理。只有理解了原理，才能活用编程，写出只属于自己的优美代码。如果只知道照编程模式编写，永远只能止步在编码的格式中，从而落个“知其然而不知其所然”的结局，程序员和大师的区别或许就在此吧。
接下来便谈下自己对项目的感悟。
随着软件需求的不断扩大，软件规模也在不断扩大，随之团队取代了个人，更有了过程，方法，对象等概念。随之一系列问题也随之到来。team之间的沟通交流协作也成为了重中之重。对于一个软件开发来说，实现是其目标。而与客户的交流沟通是以后分析需求，设计的前提。然而对于公司来说，客户不懂C同时也不会学C。所以公司必须采用两者都能理解的沟通渠道，并且结合实际。UML未必就是最好的沟通方式，而甲骨文或许更能起到更好的沟通效果。对于一个项目的确立，不仅要建立详细的执行计划，还要考虑项目的成本。一个项目的成功不仅来源于团队的每个人的努力，还来源于对于项目的取舍，要求高低的协商，整个项目的合理组织。
知之，好之，乐之，方能领悟编程之道~