太原网站制作维护,网易云网站开发,net开发的网站开发网站,行业网站模版上了大学之后其实就没有很多时间去读书了#xff0c;与其说软工作业时给我们布置了一些任务#xff0c;但是也是在另一方面让我们得到了更多的知识的填补#xff0c;因为平常能够接触的书籍很少#xff0c;平常自己也是一个很不爱看书的人#xff0c;所以我觉得这样的作业… 上了大学之后其实就没有很多时间去读书了与其说软工作业时给我们布置了一些任务但是也是在另一方面让我们得到了更多的知识的填补因为平常能够接触的书籍很少平常自己也是一个很不爱看书的人所以我觉得这样的作业对我来说还是有所收益尽管很多东西要去斟酌阅读但是也好比呆呆的编程好得多啦。在阅读这些内容的过程中也能逐渐明白书中看到的一句话代码首先是为了人而写并不是为了机器。 好了那我来谈谈我的阅读感受吧当然我也会认真的面对自己的情况去面对这次作业。 A. 关于 — 银弹 我的理解呢如果没有银弹那么就是意味着现在情况下没有任何一种技术还有方法可以使得软件工程生产力可以在十年内等同的提高十倍。我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构而不是对概念进行表达和对实现逼真程度进行验证。当然我们还是会犯一些语法错误但是和绝大多数系统中的概念错误相比它们是微不足道的。如果这是事实那么软件开发总是非常困难的天生就没有银弹。 其实在团队分工的开始我们确实是有了比较好的团队分配最后也基本达到了软件当初的一些主要需求但是在开发的过程中来说没有想象的那么容易因为我们每个人都是在互相的摸索如何合作更默契并且自己也是出于一个摸索软件的过程中我们不断的在面临问题解决问题达到最后要求。对于障碍这种问题我们并不能期待出现银弹为我们打平障碍一路畅通就像是我们学习变成从面相过程到面相对象一样这一路的荆棘我们都是一路斩过走过有过积累有过自己的学习才能够在程序设计或者学习的过程中更快的完成自己的目标这些都是我们必须要去做的和经历的。 所以对于项目本身而言我们需要踏踏实实完成我们的工作对于学习而言我们应当稳扎稳打着重基础没有任何捷径可走。 B — 大泥球问题 大泥球单从字面上去理解就可以提现到混乱邋遢事实上呢这也是象征了代码的一种情况代码的前期的设计不完全缺乏开发经验以及技巧都是造成我们混乱邋遢有缺陷的一切原因所以可以把大泥球发生的原因归结为一次性代码碎片式增长为了让软件有正确性Copy过程导致问题移植缺少前期设计应对需求变化过晚。在团队项目中我最近负责的部分很少因为我最近一直也是在跑医院这也是属于我们大泥球的一部分原因吧因为团队合作的缺陷也会导致很多不可避免的问题。 不过我相信团队合作就应该是这样会有自己的任务也会有自己的失误往往尽量减少自己IDE失误会给团队带来最大的收益这也是我自己本身所追求的我也会尽力在之后的工作中完成我自己的这个愿景吧。但是文章里提到“大泥球”似乎仍然是最常见的软件设计很难避免。尽管涌现出各种鼓励、促进良好结构代码的开发方法软件技艺运动也在不断成长但是“大泥球”仍然是最常见的软件设计即使人们已经从过去恶劣的设计中学到了东西但在新的开发过程中大泥球仍未消失。 C — CatB – Cathedral and the Bazaa 我们在开发项目的过程中采用的是大教堂的开发模式我们将所有源代码都放到github上去我们可以分享我们的代码我们可以一起阅读其他人写的代码。我觉得我们的项目现在是在不断分配需求然后实现任务的过程中前进的。但是我们缺少了很多的项目跟踪我自己也是这段期间参加项目比较少可能也是跟我个人情况比较特殊一些吧。不过我们的项目也是在具体的需求上做到了基本的要求。 不论是市集模式还是大教堂模式都有其优缺点所在这在上文中已经可以看出关键是找到其适用的场景。这个观点虽然中庸不过确实是实话。我以为大教堂模式适用于小的项目或者是团队中有一个技术大牛带领不需要过多的人来指点。而市集模式则是那种涉及的方面比较广泛的项目且不论如何应该有一个几个人的团体对于项目的整体走向、代码有绝对的控制力否则会造成Kamp所说的那种混乱局面。 我们当前的项目学霸系统的UI之用户管理部分可以说是类似于大教堂模式。之所以说类似是我们的源码并非在互联网上公开的只是相像而已。一来因为项目比较小如果非要应用市集模式可能会有意见无法统一浪费资源的问题。 D — Worse is Better 我认为这个文章主要讲的是简单的暴力的往往可以压制一切我们通常都会追求简单的设计实现结果也要简单成就我们需求的简单性。为了简单性正确性一致性完整性都会做出一些牺牲。有时候完整性和程序的一些绝对正确性会给程序带来很大的结构复杂并且因为复杂也会相对的付出一些代价。 E — 瀑布 严格把软件项目的开发分隔成各个开发阶段需求分析要件定义基本设计详细设计编码单体测试结合测试系统测试等。 使用里程碑的方式严格定义了各开发阶段的输入和输出。如果达不到要求的输出下一阶段的工作就不展开。 强调文档在开发的后期才会看到软件的模样。在这种情况下文档的重要性仿佛已经超过了代码的重要性。 瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西所以对客户需求的理解程度高低不等。对于客户需求变更编码人员会比设计人员更容易产生很强的抵触情绪。 在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道本意是为了提到效率但实际上有时候产生的是互相的理解偏差。 瀑布模型产生的管理文档(计划书进度表)等能让不太了解该项目的人也能看懂项目的进度情况只有能看懂百分比就行很适合向领导汇报用。所以管理人员比较喜欢瀑布模型但是开发人员不喜欢因为它束缚了开发人员的创造性。 既然叫做瀑布就意味着不应该走回头路。否则如果出现返工付出的代价会很大。 软件生命周期前期造成的Bug的影响比后期的大的多。 F — 敏捷开发 而软件存在的意义就是与现实相适应。敏捷开发的核心即符合现实的软件。一个符合现实的软件才能够可持续地与现实共同发展。一旦软件与现实背离软件的生命周期也就到了结束的时候了。 现实的世界是动态变化的人类造出来的东西往往是落后于世界的变化的。如地图造出来之后可能又多修了几条路几个建筑刚买了一款高配置的计算机几个月后自己的机器配置又处于被甩的地位了……这些变化人是被迫要去接受。因为这些东西属于硬件人在目前还无法轻易地改变硬件。 而与此不同的软件则是另外一种现象了。改变软件的代价是相当低廉的。改变软件实际上只是改变硬盘上的磁性。改变软件的容易性带来的结果是 一、软件开发者容易以自己的想象来决定软件怎么做。 开发出一个无用的软件比起因为出错而要毁掉待出售的10万张地图比起因为工艺漏洞而要招回已经出售的计算机来讲代价太低廉了。 二、软件更加具备符合现实的条件。 开发者让软件与现实相适应所要付出的代价非常低廉当然对于敏捷开发我们也会有一些相应的办法Scrum meeting 以及 个人学习团队互助的编程。 在Scrum meeting 上 每天都会进行scum meeting汇报包括今天自己完成了什么任务明天的计划是什么。并生成每天的燃尽图显示整体项目进度。这样的做法可以监督每一个成员每天按时按量完成自己的任务保证项目的整体进度。 在个人学习和团队互助的编程过程中 我们都会自己有阶段性的学习然后在学习之后我们会进行交流分享不懂不会的地方最后进行一个汇总交给编程能力或者对语言比较熟悉的同学对这些我们收集到的问题进行解答。 所以敏捷开发的核心就是符合现实的软件。为了造出符合现实的软件才有了进一步的价值观及方法论。 G — 团队项目 我们的团队项目是BUAAMOOC“我负责的部分是PM和测试但是我觉得我在个人的工作完成上十分不满意也是因为我前段时间的身体情况耽误了太久不过我希望在之后的团队项目的工作中自己可以打起精神吧不希望自己因为自己的不足而感到失落我应该投入到团队的合作中去发挥更大的力量才是我应该继续要做的事情。转载于:https://www.cnblogs.com/Cocky/p/4965950.html
