读《大道至简——软件工程实践者的思想》

初读《大道至简》，书的序言部分便让我产生了一些感悟，一味追求于内容的厚度只会让文章显得冗长乏味，至简至简，简洁恰当能让人以最快速度透彻的学会内容，而不至于过于拖沓导致人们或由于内容的枯燥，或由于碎片化时间地打断导致无法体会“作者原创经验精华”才是作者真正在书籍创作中应该追求的书本的厚度不应定义书本的价值。
只学习理论并不能真正的吸收知识，实践才是检验知识的唯一路径，就像在前两个学期的学习中，我发现即使在课上好好听课，感觉好像是学得很好，但是在写程序时“拔剑四顾心茫然”，无从下手，时间一长更是将理论也忘得一干二净，因此课上学习的内容，一定要尽快钻研，写程序验证。
正文第一章以愚公移山的故事类比编程，即使是像移一座山那样的大工程（一个很复杂的程序）也是由一个个小工程（简单的程序）组成的，有些事看着很复杂很多，但只要懂得拆分，事情也会变得简单。编程其实就是和说话的逻辑一样，只是把汉字转变为计算机语言的“文字”。
第二章的内容告诫我们要懂于变通，要善与学习和观察，举一个耳熟能详的例子，等差数列，从一加到一百，一个个加要加99次，要加很久，而人们发现第一个数加上最后一个数恰好是中间数均值的两倍，于是1+2+3......+100就变成了（1+100）*100/2=5050，这个跟李冰和愚公的例子很像，这种变通让工程变得更简单，第二个关于程序分层的例子我觉得很棒，所有程序写在同一个文件里根本分不清那个是哪个，程序分层不仅能使程序的组成更加鲜明（便于理解，从而可以将一些程序分工，更快速的完成工程），查找简洁（遇到出错时，那个部分出错，就在那个部分的程序找，不用通篇一个个找），变通真的是人类进步的法宝啊。
第三章讲的是团队管理，团队要按照团队成员的特色分清定位，不同的定位安排恰当的合作，这个分工应该由管理负责，管理不应盲目套用别人的体系，所谓一个猴有一个栓法，先根据团队特有习惯建立组织结构，再确定管理制度，这个管理很重要。
第四章沟通的目的是传递信息，而非追求形式。文中点出要求不懂技术的客户理解UML图，就像要求他们学习C语言一样不切实际。有效的沟通应采用对方能理解的方式，比如文中提到的“最简沟通”原则，即在有限的沟通次数中，通过精心准备的问题获取最大量的信息。我觉得这就是为什么大一上专业课的时候，老师一直要求我们写注释，老师们当时这个程序你可能刚写完的时候知道每个部分的作用，但是过一段时间别说别人了，你自己也会看不懂，写注释一是为了让别人知道你写了什么，而是为了让你最后反过来，嗯，复习算一个。
看见题目的第一眼我就想到了那句古话，“失败是成功之母”，但细看文章讲的是另一个含义，过程和结果的取舍取决于做这件事的，目的？比如文中这个例子，客户要的是一个贴合要求的项目，你做了一个完美的过程，耗费了更多的时间，结果达不到要求这不闹吗。常听程序员有个口头禅叫“一个bug是bug,两个bug是work.”,还有网上前一阵流行的那个，“不要问我这个程序为什么能实现，结果对了就完事了”。当然并不是说bug不需要修复，这章应该讲的还是要懂得变通，不要一味照搬前人经验，真正精华的是要做出我们自己的东西。
第六章跟前面有一个call back，算是都批判了对计算机语言评论高低的行为，语言只是工具，没有高低善恶之分，取决于使用者的能力。跟第三章也有一个call back，讲究团队协作，时代的发展让我们书写的程序越来越复杂，（当然现在时代发展已经进阶到AI可以帮忙写程序了，自己就可以做一个团队）不会有公司愿意等一个程序员花几十年完成一项工作，因此有了团队，第三章提到的管理者的关注点从技术细节转向组织、计划和资源协调（像后言里作者曾经的总经理P&J对管理、工程和决策上没有任何反思是不对的。），并需要理解甲方的要求。
上章讲到时代快速发展，程序变得复杂，这章算是说了一下原因，大公司之间的不断良性内卷推动着程序的不断发展，更新迭代，“从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了”。对于AOP和MDA等技术要理解本质“什么都可以“驱动开发”。”，不要盲目跟风。
最后一章再次强调了注释的重要性，以及管理者协调经营者和开发者之间沟通的重要性，还有一定要变通，不要拘泥于前人的经验，以前合适的不代表现在仍合适，都是有时限性的，不要死板，要灵活。
后言算是宽慰和提醒？重要的事情往往并不入时，总要有些妥协和取舍。
我的尾言：这本书真的很有意思啊，读起来十分有趣，也很便于理解，也让人对现实里一些微不足道的事有了不同的看法，而且就像我在序言里体会到的那样，作者（周爱民老师）真正做到了蒋涛老师说的“虽然不厚，却闪烁着独立思考的光芒”，充满着作者原创经验精华。