读书笔记第三周：人月神话
这本书主要讲述了如何管理一个软件开发团队的问题，其中如何提高团队的效率可以说是本书的重点之一了。感觉这本书地中文版翻译得比较晦涩，很多表达比较模糊，看起来有些吃力，因此下周我可能会考虑借一下英文原版来看。本周的话我看了前两章，我觉得重要的收获有四点
第一，作者与我们交流了一名码农的职业的乐趣，编程是可以创建事物的，而这有着纯粹的快乐，如同小孩子玩泥巴一样。其次，编程可以造出对他人有用的东西，这也是人的一种自我实现，实现自我的社会价值。同时，编程的精妙，将各种复杂的零件组合在一起，最终达到预期效果，给人一种成就感。最后，编程这项工作也要求我们终身学习，对我们个人的成长也是很有利的。
但是，编程这项职业也有很多苦恼：首当其冲的就是要把做事方式变为追求完美，因为代码中的一点小错，就会导致程序不可用。这也是我现在不太想从事码农工作的重要原因，因为我生来就是一个大大咧咧的人。同样是因为bug，编程人员需要花比编写代码更多的时间来调试，这点我深有感触。上学期数据结构大作业，写出来不麻烦，debug才麻烦。对于系统编程人员来说，还得看手册，这其实也挺痛苦的，尤其是这些他人的程序设计的不合理，表现拙劣，还得自己去研究和修改。
本书的第二章，也就是人月神话这章，则给我带来另外两个收获：
第三个收获：在估计和进度安排中，使用人月为工作单位是一种逻辑谬误。这个谬误隐藏了一个前提：那就是任务是可以分解的。事实上，对于无法分解的任务，增加人数是没有用的。而对于可以分解，但是需要沟通和交流的任务来说得任务，必须再计划工作中考虑沟通的工作量。这点可以说是刷新了我的认知，以前参加社团活动的时候，一直以为人多力量大。因为人不多的话活动办不起来。但现在想想，人过多也是个问题。
最后一个收获，大概就是我们软件工程的小组玩制定合理的计划。不能过于乐观主义，要正式我们能力的有限，以及可能出现的问题。因为一个小问题可能不起眼，但很多问题交织在一起，复杂度指数上升，最终会导致整个团队陷入焦油坑中。
