《大道至简》读后感

En...这叫大道至简读后感。

在老师的建议下，我在暑假阅读了周爱民先生的《大道至简》。这本书仅有110页内容，读起来干瘪生硬。也正是如此，才能让文章内容言简意赅，不像那些云云之流写出一些拖泥带水毫无意义的东西。从这本书上，我没有学到什么招数，方法。但我从这本书上看到了闪烁着的独立思考的光芒。

 

在读这本书之前我其实很认同“一百万行代码是可以写在一个文件里的”，不敢自认为是程序员，但是编程的习惯的确难改。我就是喜欢把代码写到一个文件里面。就像书中所说的那个“勤快的愚公”，可惜我并没有愚公那么勤快，却又有他的愚笨，可我也深知做人是有极限的！在阅读之后，我也理解了这样写的弊端，当我的编程量足够大以后，查找一个函数/方法会变得费时费事。当然我也并不是没有解决这个问题，在C++/C的编程时，我会考虑使用多个头文件，虽然这样仍然未能彻底解决问题，但以我目前的知识储备来说应该足够。

 

通过这本书我也了解了所谓的沟通，不论是程序员与程序员之间，还是程序员与客户之间。

 

哪怕铸造了互联网，我们人类依旧是群居生物依旧无法简单摆脱人与人之间的关系。在程序员与程序员之间，我们要重视团队合作，认识每个角色的任务与责任，尤其是项目经理应该具有的质量与责任。在团队合作的结尾“更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常是极具风险的”这一句话我感触颇深，李元浩作为LPL的顶级中单之一曾因人手不足去到了上单的位置，虽然成绩并没有让人失望，但仍引起了不小的质疑声浪。以团队而言这种孤注一掷的做法太疯狂了，而如果在我们项目中有这种操作，则很可能引起崩盘。的确，明确分工是管理人的职责，而不是去做一个伯乐。工程中没有BOOOOSS。

 

在程序员与客户之间，我们更应该明白，写代码的程序不只是给自己看的，更是给其他程序员/用户去看的。更有大部分时候，客户会完全不理解你的代码，而这种问题的根源：角色的关注层面完全不同。因此注释与标准的变量命名都是必须的，在小学期的实践中，我初步学习了注释与变量的合法命名。以前我一般都是为了完成题目的测试点要求而简单用单字符设置变量，以后我会尽量完善我的编程习惯。

 

文章中提及不要整天专注于哪个语言的优劣性，不要以语言自命不凡，切记语言只是工具。虽然我目前学习到的语言甚少，无法理解，但我认为只要我记下这句话，一定会对我未来的学习产生帮助。

 

只有懒人才会找方法，而优秀的程序员就应该是懒人，要懂得会套模板，会抄代码，而不是所有的代码都靠自己敲。