这一周阅读了《人月神话》1，2，3章与《梦断代码》0，1章，发现2本书的作者都主要在感叹软件开发按时交付的难度之大难以想象，在《梦断代码》中，Scott用了自己身边实际的例子OSAF项目中发生的故事来展示在软件开发工程中软件及时交付困难，而在《人月神话》中作者Frederick P用论文般的方式论述了软件产品及时交付的困难，在开发过程中，遇到软件BUG是导致延期交付的关键。

　　这2位作者对于这个问题的感叹也引起我的共鸣。我大学就是软件工程的学生，在大学4年的学习生涯中虽然没有做过真的的软件产品，但是一些小项目还是摆弄过的。而BUG这个导致软件交付延误的罪魁祸首，我们软件开发人员最痛恨的存在，我也是经常遇到。在《梦断代码》中作者在0,1章用OSAF软件在开发过程中遇到的一个BUG——闪烁缺陷导致软件可能无法及时交付的实际例子来显示软件开发无法及时交付的原因以及解决问题的难度，《人月神话》的1，2，3章中，作者也论述了这个问题以及问题产生的原因，并提出一个外科医生团队的解决方案。而这2本书中对于导致问题产生的原因，我归结于一个词——乐观。

　　是的，我们在开发软件的时候都过于乐观了，我们过于相信编码的重要性，对于开始编码前的思考，设计，以及完成编码后的测试都太过轻视。我记得在我大一的时候，刚刚接触编程，晚上在机房上进行算法编程，学长们出一些包含了各种难度的算法题目，我们编程解决。刚开始的时候，都挺顺利的，但随着学习的深入，学长们出的题目也越发刁钻，很容易让人忽视可能会产生问题的地方。那时，我做这种算法题目，都是按题目要求直接编程，不去仔细思考问题的难点在哪里，测试用例应该选择那些重要的地方测试，然后在完成代码上传总是会得到一个run error，然后才开始思考自己的错误在哪里，这十分花费时间，而算法上机是有时限的——这与软件开发交付时间相似。我在学习了很长一段时间后，才学会在编码开始前细细思索问题，用笔在草稿纸上多次运算，编码这才开始。问题还是会有，但总归不会出现让人懊恼的小问题。还有一个令我记忆深刻的是大三为期14天的小实践——每年产生10W多个的教师学生选课系统。那年我和5位同学组成小队完成项目，我作为组长，与实践老师沟通完成需求文档，在开发过程中完成开发文档，还有最终的测试文档与开发报告。在得到需求分析后，我给各个成员分配各自的任务后，大家就开始了编码的工作，几乎占据了整个开发过程的80%，而且我们再也没有与老师进行沟通，每个小组成员都再埋头苦干，完成一部分就上传到gethub上，每天5点按时下班，乐观的认为就这样按部就班的做就可以了。最后到了结尾验收的前一天，我们对系统进行测试，出现了一大堆的BUG，如登陆异常，作业上传异常以及选课页面排列异常等，然而明天就要交付了，我们不得不从白天8点干到晚上10点。交付时，老师对我们的系统也不满意，因为他们的很多需求我们没有实现，我们辩解需求文档上没有，老师则说我们没有询问，告诉我们在实际软件开发中客户的需求是不断变化的，我们需要不断的与客户沟通才能做出满足客户需求的产品。我们最后的评分只是70分。

　　大学4年中，编码占据了我学习生涯的绝大部分，我也认为编码是重要的，编码能力高才是大佬。而不断的学习中，我又模糊地知道了编码以外的工作，在软件开发过程中也是重要的，但是为什么重要，还不甚清楚。但是在阅读《人月神话》与《梦断代码》部分内容后，我有些明了，产生了以上感想。记录下来，希望能与大家有所共鸣。