今天看完构建之法，开始写最后一篇感想，在开始写对构建之法这本书的感想之前，我想先写一下对今天软件工程概论课上老师讲的话的一些感受。今天上课一上来老师就说我们离“人”还差很远，在听完之后发现还真是这么回事。那么，人是什么，人分为做事的人和不做事的人，而仅仅当一个做事的人就可以了吗？当然不行，做事的人又可以细分成做真事的人，做假事的人和假装做事的人，你想当哪种人呢？
言归正传，今天看了构建之法中有关软件发布这一部分，联想到自己团队也要发布bata版本，感觉还是应该仔细看一下的。在软件生命周期的最后阶段，对我们团队的考验更加严酷，你必须保证你的软件能上得了台面，不能已发布就出现各种各样的问题，但是如果在发布前期软件真的出现了bug了怎么办？这里有几种解决办法，一是设计本来如此，软件的功能与用户的要求有偏差，导致用户认为这是一个错误，出现这样的问题就比较严重了，要不不管，要不重写或重构；二是这个bug不影响这个阶段用户的使用，这个版本不修复，等到下一版本再说；三是推迟发布日期，加班加点的把这个bug解决掉。这些解决方法只是治标不治本，要想正真的解决这种情况，只有在最开始的时候就尽量避免bug的出现。在稳定阶段的初期，团队必须决定要修复哪些bug，而且随着项目进展和发布日期的临近，团队还要保证修改方案不会对软件带来负面的影响。
我们团队在进行修复bug时，出现了一些问题，有的成员说这不是一个bug，只是软件功能有没实现而已，不能算作bug，还有成员认为有些bug无关紧要，不用修改用户一般也能正常使用，在这里有些bug就是逻辑上的错误，要想修改很难，我们团队一致认为在bata版本发布时不用修改，留到以后再说。如果有些bug真的会影响到发布，而且现阶段无法修复，那么只能把出现bug的功能模块一刀砍掉。根据老师的说法，项目的修复bug是一个阻尼振荡的过程，我们在修复bug时通过画图真的发现这个是有一定依据的。