软件开发项目中小白应该注意的一些地方——《人月神话》读后感上
在这学期之前，我从来没有参加过软件开发项目。在读这本书之前，我对软件开发的过程充满迷茫。囫囵吞枣般的读完这本书后，对于软件开发的过程有了一些零碎的认识，这里将有关论述摘录出来，并会相应的附上自己的思考。（这是我自初中以来第一次写的读后感，如果有人看到并有所吐槽的话热烈欢迎）
第一章 焦油坑
编程的乐趣
1. 创建事物给人带来满足感从而产生快乐。
2.开发出的劳动成果可以供他人使用，给他人的工作提供方便，会带来一种自豪和骄傲。
3.将语句组成函数，用不同功能的函数组成完整的解决问题的程序，建造堡垒的感觉使人满足。
4.IT行业技术的飞速发展，推动着程序员不断学习新的知识，摆脱单一重复带来的困倦。
编程的苦恼
1.追求完美要求很多细节上的东西要规范化，很多琐碎带来了一定的麻烦。
2.在团队项目中，自己的编程工作是被安排被限制的。
3.无论是哪个程序员，都应该写出适用于其他人的程序。可悲的是，自己所用的其他程序很可能粗糙充满bug。
4.排错是一个漫长又痛苦的过程，而且任何小的改动都有可能带来新的bug。
5.在效率低下的情况下，开发周期赶不上技术变化和需求变化的脚步。
自己之前并没有这么详尽的考虑过编程的乐趣与痛苦，只是简单的在程序顺利运行成功的时候哈哈大笑或是在排了一天错仍不能通过时愁眉不展。所以此处将作者的想法摘录下来，也好以后其他人问及相似问题时可以有所回答。
第二章 人月神话
一切都将运行良好的乐观主义造成的并不合适的估算，人员越多开发时间就会越短的错误认知，以及测试环节安排的较少的时间，会使开发团队拟定出不合理的进度安排。在扭曲的进度安排下，进度开始一点一点落后，盲目的增加人手，为了赶计划手忙脚乱的进行测试，最后导致项目的失败或者是开发出一个畸形的产品。因此，在团队项目中我认为要注意一下几个方面。
1.抛弃“一切都将正常运行”的想法，给自己的程序编写留出一定的margin，从容谨慎的完成程序编写。
2.团队应该实行有效的进度记录和督促，在每一个时间节点考察任务的完成度。
3.构建合适大小的团队，避免人浮于事的情况发生。
4.给测试过程留出至少一半的时间，不要过度自信。
第三章 外科手术队伍
Harlan Mills提出了类似外科手术队伍的开发团队构成。
外科医生：拥有丰富经验，定义功能和性能技术说明书，设计程序，编写源码，测试以及书写技术文档。副手：具备完备的能力，相对经验较少。管理员：负责人事管理。编辑：编写文档。两个文秘：给管理员和编辑。程序职员：维护编程产品库中所有团队的技术记录。工具维护人员：维护各种工具，保证其正常工作。测试人员：设计测试数据，搭建测试平台。语言专家：寻找简洁有效的使用语言的方法来解决复杂问题。
这个案例给开发团队人员的分工提供了参考。对于若干学生组成的开发队伍，大部分人甚至是所有人开发经验不足，团队合作意识也并不强烈，这样的结构似乎指导意义不大。我个人认为编程能力较强的同学（3-4人）可以做程序编写的主力，管理能力较强的同学（2-3人）可以负责文档的编写，各种记录工作以及项目进度的管理和绩效管理。
第四章 贵族专治、民主政治和系统设计
这一章节中，“概念完整性是系统设计中最重要的考虑因素”类似的关于概念完整性的论述被反复提及。而且文章指出，为了获取概念完整性，设计必须由一个人或者具有共识的小团队完成，并且需要有人控制这些概念。我不否认这种论述的合理性，我只是觉得作为初次进行软件开发的学生，很少有人能起到领头羊的作用给其他成员制定出来合理的方案，更有效的方式是由团队的组成人员开会讨论方案的结构和各方面细节。这里需要注明的是必须要提高开会的效率，不能犹豫反复中耽误进度。关于少数人的专政，我只能说我并不习惯，我向往高效的民主讨论。
第五章 画蛇添足
摘录几句对结构构建者的建议：
1.开发人员承担创造性和发明性的实现责任，结构师只能建议，不能支配。
2.时刻准备为所指定的说明建议一种实现方法，同样准备接受其他能达到目标的方法。
3.准备放弃坚持所作的改进建议。
第六章 贯彻执行
这一章中我get到了两个点——文档化的规格说明和小组会议前的准备。
每一个产品都需要一个清晰、完整、准确的规格说明，此规格说明应该包含对用户可见的所有细节的描述和规定。而且，随着反馈的增加，规格说明应该不断的做出修改。非常重要的一点是，做出的所有修改都应该标注出来做了哪些改动，以及修改时间。我觉得这个习惯不止适用于规格说明的修改，同样适用于程序的修改，整体计划方案的修改。详细的修改记录能够方便人们了解改动的进程以及改动的内容，从而不至于拿到新一版的手册时一脸懵逼四处询问。
另外一点，小组会议前应该将会议中要讨论的话题以及针对话题要提出的建议编辑成文档发给与会人员，这种做法能够极大地提高会议效率。我之前做过一个简单的硬件项目，开会之前告诉大家要想一想对这个问题有什么思路和解决方案。结果就是，几乎所有人都是开会时临时开始思考，导致会议进程变慢。而且会议上临时思考会出现思路受别人观点影响从而想不出好点子的现象。所以，我认为会议前将大家的想法思路整理一下给所有人是非常有必要的。
第七章 为什么巴比伦塔会失败
这一章提出了项目中交流沟通的重要性。
文中有一句话我觉得很有趣，“因为左手不知道右手在做什么，所以进度灾难、功能的不合理和系统缺陷纷纷出现”。在起初入门级别的时候，大家脑子里想的最多的可能就是如何高效的把自己这部分代码完成，至于系统整体性、不同部分代码之间的相合性这些至关重要的东西则抛之脑后。缺乏交流沟通同样造成动力的逐渐消失以及进度的逐渐落后。软件工程课的老师提出了一个很好的交流方法——“每日立会”，小组成员每天抽出10-30分钟的时间站在一起讨论一下出现的问题各自的进度之类的，以增强交流。这种做法是有帮助的，但是每天这样的频率有点高，我觉得每三天一次小会，每两周一次大会可能较为缓和一点也更容易接受一点。文章中也提出了一个减少交流问题的一个有效方法——项目工作手册。将项目进度，开发过程中遇到的问题以及解决方案等等详细记录，供团队成员查阅。这样便于每个人随时能够清楚任务进度，以及存在什么问题还没有解决，能够在一定程度上提高工作效率。
