软工读书笔记1——《人月神话》
第一次接触软件工程这门学科，也是第一次做IT类图书的读书笔记，我选择了《人月神话》这本书，一周的时间很有限我只是大致过了一遍全书，对部分感兴趣的章节进行了精度，我也就拣这些谈谈自己的感想吧。
文章一开头就用焦油坑这个形象的比喻诠释了软件开发行业的本质特征——惨烈，软件开发过程中遇到的各种问题就如同焦油坑，只有少数开发团队能够经受住考验，这样的开场对小白来说简直是个灾难啊。之后文章给出了具体的苦恼和乐趣，看着似乎舒坦了不少。
一方面苦恼在于需要追求完美，一般在我的认知中，追求完美会很累，但一定是优秀的，编程行业则需要处处追求完美，因为任何一个小疏漏都可能会被无限放大；另一个苦恼在于目标由别人设定，简而言之，软件开发者承担了相当大的职责却得不到与之匹配的权威，对于自尊心强的人这是无法接受的，只有在重压之下完成任务才能获得那所谓的权威，而且软件开发者苦于对别人的依赖却又无法避免，因为不可能所有的程序都出自一个人，所以必定会依赖别人的代码，而这些代码中可能存在的大大小小的问题就会很让人头疼；当然编程本身的枯燥就是一大苦恼，这里不再叙述，总之这是一个很辛劳的行业，我觉得经过这样的历练会让人变得成熟和强大，所以我还是欣然接受软工的挑战。
另一方面软件开发的乐趣也是无穷的，显而易见的就是创造事物的乐趣，尤其是可以服务他人的事物，记得之前做电设的时候，哪怕做出最简单的流水灯都能高兴一个晚上，何况是做出一款服务型软件呢？此外这也是一个学习的过程，学习如何使用高级编程软件，学习如何团队合作，学习如何写自己的博客等等。
在第二章作者指出很多项目进度滞后，以致最后削减计划来赶时间，这是因为他们缺乏合理的时间进度，他们误估了工作量和时间进展，并且抱着乐观主义的心态，种种原因导致了最后的失败。而且Brook法则提出，向进度落后的项目中增加人手，只会让进度更加落后，理解起来可以是这样：首先，进度落后肯定是有原因的，是有组员拖拉或是整体计划不合理，仅仅加人手的话那也只不过是把原有问题的规模又放大了而已；其次，新加入的人手无论有多么精干也必须先经过培训来进入这个项目，原计划分配的任务必定要重新分配，这就导致某些已完成的工作被丢失，系统测试被延迟；如此恶性循环，情况一定会越来越糟。
第三章让我感触很深的一个观点就是对于非真正意义上的大型系统，小型、精干的队伍是最好的，作者举了很多实例来说明，我的感触是小的团队不在于小，麻雀虽小五脏俱全，团队成员各司其职，项目进度井井有条，那这就已经是一个成功的团队了，至于成果，自然是不会差了。
另外，第七章提到了巴比伦塔的失败，提到了缺乏交流和组织对于团队项目的致命性，我想起了上学期的电设实践课，前半学期我们就是基本上做到哪算哪，没有详细的交流之类的，导致进度慢的离谱，好在最后我们意识到问题快马加鞭赶完了设定的任务，但还是觉得可惜，本可以做的更好，当然这是硬件项目和软工不一样，只是团队合作这块是相通的，故在此举证表达一下感想。
时间紧张，希望今后有时间精度这本书。
