11 2012 档案

摘要：今天中午，我们小组开了一个会议讨论了下项目测试的工作，我们进行了工作分配：（1）刘宇翔和潘学：测试search of this site部分，用各种边界条件和各种可能的情况进行测试，最后写出项目测试文档；（2）李忠、张孝祖、陈伯雄和苏若：找128篇文档来测试UploadContent和DownloadContent的部分的功能正确性。以上是今天进行的工作分配，我们的组员都已经开始了工作，争取下周一的展示的成功。fighting！！！ 阅读全文

摘要：软件工程就是一门实践的课程，我觉得没有什么技巧，课堂说再多的理论都没有学生自己动手做个项目来的实际，所以我给SE教学的一点建议就是注重实践。另外我觉得老师课堂上光讲怎么设计软件，还有一点重要的没有教到，就是“我们该如何有一个好的想法，怎么知道我的这个想法是否有把它实现的意义”，这个也许就是所谓的创新的来源吧，我们很缺乏这方面的能力，希望老师能够给点经验 阅读全文

摘要：我觉得SE和CS是不同的两个概念，但是SE应该是依赖于CS的，即CS是SE的基础，软件开发需要有计算机科学的知识，有这个基础设计出的软件效率才能更高，比如软件工程的开发中，有没有学过数据结构是由本质的区别的，算法分析也是软件性能提高的很重要的因素。 但是软件工程教学方式和计算机科学的教学方式应该是不同的，软件工程应该是更偏向于实践的，所以教学时候应该多实践；而计算机科学，作为一门科学，我的理解是这应该是一门理论科学，应该它已经有了很深厚的理论基础，所以计算机科学的教学应该是侧重于理论的教学，让学生真正知道计算机的原理，计算机是怎样工作的，我们该怎样设计一个计算机。 北航计算学院的理论教育我觉. 阅读全文

摘要：已删除 阅读全文

摘要：在大伙都在吹捧“市集”开发软件的方式的大浪潮下，作者看到了其中的不当之处，发现其中有许多的问题，因此写下这篇文章给予吹捧“市集”的人一个提醒，甚至警告。 在该文章里，作者认为“市集”里的“农民”不可能建造出和“大教堂”一样宏伟的“建筑”，那些“市集”里开发软件的人，会把软件搞得一团糟，“代码越重用，浪费越严重”，作者觉得这种局面应该改一改了。 我觉得作者在文章里的观点有些偏激了，不能一味的吹捧“市集”也不能否定“市集”，不能小看那些“农民”的能力，互联网的时代，“市集”是必然的，现在不是流行叫“地球村”，一个村庄里，不能只有教堂，还要有市集。不能说“农民”基础不行就不让人家卖“农产品”了，“. 阅读全文

摘要：我们的团队项目没有像林纳斯托瓦茨（Linux核心的创始者）那样将代码放在因特网上让很多人来检查，虽然这样可以让错误无处可躲，但是我们目前这个项目规模比较小，我们觉得大部分问题我们能在组内就解决，大部分时候有不会的时候就组员之间讨论，或者上网查找相关资料，或者在网上提问。 不过使用“市集”方式开发建造软件，我还是觉得是一个很好的方式，因为一个小组甚至一个人的力量，是不能匹敌全世界的所有程序员的力量的，大家一起改造软件，同时可以互相学习，是应该好好利用互联网这个平台，世界变得不再那么大。 阅读全文

摘要：总结了一下，产生大泥球的主要原因有下面这些原因：（1）一次性代码（2）碎片式增长（3）为了让软件不出问题（4）Copy/paste导致问题转移（有问题的代码被复制到很多地方，不断蔓延）（5）缺少前期设计（6）应对需求变化过晚 在具体的项目开发之中，体会较深的就是一次性代码和缺少前期设计造成的大泥球。我们在设计软件时常常考虑不到软件代码的复用性，导致设计的代码仅供目前所在模块使用，而没有考虑到其它模块可能的调用，从而带来了代码复用时的泥球；前期接口设计不当也会造成大泥球的产生，当调用关系复杂起来后，调用深度越来越深，最后到写出来的代码自己都看不懂（我遇到这种情况的时候，常常注释都不知道怎么写才. 阅读全文

摘要：团队项目开发也进行了两周了，多少有些感想了，对于找“银弹”这个问题，还是计较赞同《No Silver Bullet: Essence and Accidents of Software Engineering》里的看法的，软件项目的复杂度增加真不是线性增加的，在我所在的团队里，是做网站的搜索部分和上传下载部分，比如我开始分配任务给各个组员的时候，每个任务都是很小的一部分，估计一天两天就能搞定的，但因为是分开几个小组一起做一个大的问答网站，各个小组都会随着自己的需求更改接口，或对别的小组提出别的要求，这样就面临了《No Silver Bullet: Essence and Accidents . 阅读全文

摘要：这篇文章主要是介绍了“瀑布模型”。作者总结了自己在软件开发中的经验，提出了一个软件项目的开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。他给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用，这也许就是我们后来人称之为“瀑布模型”的原因吧。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 每个阶. 阅读全文

摘要：这篇文章首先是介绍了软件工程要面临的固有的不可避免的问题，主要是复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。下面是对文章里这些问题观点的整理：（1）复杂性（complexity）。软件要增加规模不仅仅是简单地增加相同内容的规模，还要增加新的内容，这就使得随着软件规模的增加其复杂度的增加是非线性的，整体复杂性的增加可能比线性增加要大得多。软件的复杂性的这个特征给软件的开发带来了不少的困难，它会给软件项目组里的组员之间交流带来困难，从而导致产品的瑕疵、开支过多和时间耽搁；这样的复杂性给我们穷举所有软. 阅读全文