软工 · 第十一次作业 - Alpha 事后诸葛亮(团队)

时间:2022-08-31 11:00:44

软工 · 第十一次作业 - Alpha 事后诸葛亮(团队)

组长本次作业链接


现代软件工程 项目Postmortem

  • 设想和目标

    • 1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
      • A:我们的软件要解决的是结对人的互相提醒的问题,对这个对这个问题定义的很清晰。主要是针对团队,研友,情侣或者亲子,要结对人都关闭闹钟,软件才会停止工作,以达到相互提醒的作用。例如相互约好去学习,设置闹钟,醒来的人可以根据软件的提示知道另一个人是否已经醒来,如果未醒,则可以根据软件设置的提醒方式来提醒对方。
    • 2.我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么?原计划达到的用户数量达到了么?)?
      • A:我们还未完全达成目标,原定的功能只实现了两个,未能按照原定计划交付。由于未完成整体软件,所以目前还没有任何用户。
    • 3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
      • A:由于未对软件进行发布,所以用户量和用户对功能的接受程度无法估计,所以我们并没有离目标更近。
    • 4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      • A:在交付软件之前,所有人都要有紧迫感,要有压力,有适当的压力才会有动力,才能更好的完成软件。如果历史重来,我们将制定严格的计划进程,将任务落实,给予所有人适当的压力,在deadline前完成软件。
  • 计划

    • 1.是否有充足的时间来做计划?
      • A:在Alpha冲刺开始之前,大家的大致分工任务便已分配下去,因此开始各自学习开发所要用到的技术、工具等。Alpha冲刺开始之后,会议讨论上大家一致达成在Alpha冲刺结束前实现基础功能的计划,转而进入了Learning by doing的状态。而后由于各自的任务不同,主要是各自制定个人的规划。
    • 2.团队在计划阶段是如何解决同事们对于计划的不同意见的?
      • A:少数服从多数。
    • 3.你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
      • A:
        有的完成了,有的暂未完成。
        时间上,在Alpha冲刺中后期有期末考试,一定程度上被剥削了一些时间,导致计划没有实现;
        技术上,团队成员之前并没有使用过相应的开发工具,开发语言也基本没有接触,心有余而力不足,技术不够导致一些问题难以解决,原定计划没有实现;
        经验上,缺少开发经验,不知先做什么再做什么,效率降低。
    • 4.有没有发现你做了一些事后看来没必要或没多大价值的事?
      • A:首先是Alpha冲刺初期,算法很多是靠自己设计,代码全程靠自己手写,又由于技术受限经常卡住导致浪费了很多时间,后来懂得借鉴前人的优秀作品,站在巨人的肩膀上,效率得到了提高;再者是缺少经验,提前学习了某些技术但在实际开发中并没有用到,对此次开发而言浪费了时间。
    • 5.是否每一项任务都有清楚定义和衡量的交付件?
      • A:一开始并没有仔细考虑这个问题,导致最后各部分整合的时候出了些问题。
    • 6.是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
      • A:并没有都按照计划,有的部分由于技术等原因暂未实现。
        没有估计到的风险是软件工程比想象中的困难,不管是时间上需要更长还是技术上需要更多。原因一是计划没有制定好,导致后期做的事情比前期多,先甜后苦;二是缺少开发经验,不能很好估计难度。
    • 7.在计划中有没有留下缓冲区,缓冲区有作用么?
      • A:没有留下,只是计划在Alpha冲刺结束前实现基础功能。
    • 8.将来的计划会做什么修改?(例如:缓冲区的定义,加班)
      • A:会计划提前一天或两天完成,以留下伸缩的余地,解决一些突发事件等。
        以及会更多考虑短期计划的制定,减少拖延症的发生。
    • 9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • A:
        制定计划不要刚刚好,应该要有缓冲的余地,否则遇到问题将会很头疼;同时也要考虑制定短期计划,否则容易拖延导致最终计划不能实现。如果历史重来一遍,我们会决定在Alpha冲刺结束前一天实现我们的计划,同时会细分计划,做短期计划制定,循序渐进。
  • 资源

    • 1.我们有足够的资源来完成各项任务么?
      • A:网上的安卓资源充足,我们有足够的资源来完成各项任务。
    • 2.各项任务所需的时间和其他资源是如何估计的,精度如何?
      • A:各项任务所需的时间和资源是根据大家公认的难度来进行估计的,精度一般。
    • 3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
      • A:测试时间,人力和软件/硬件的资源不够充分,对于不需要编程的资源并没有低估难度。
    • 4.你有没有感到你做的事情可以让别人来做(更有效率)?
      • A:因为组内大家都是萌新,所有东西都要新学,所以大家的效率应该都是差不多的。
    • 5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      • A:资源要充分的利用,要站在巨人的肩膀上来看世界。如果历史重来,我们要充分学习利用网上已有的项目资源应用到我们自己的项目上,这样会更具有效率,能更好的完成项目。
  • 变更管理

    • 1.每个相关的员工都及时知道了变更的消息?
      • A:我们会在群内进行通知,并确保每个人都能知道并正确理解
    • 2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
      • A:我们针对产品的核心定义进行筛选,分清核心功能和附带功能
    • 3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
      • A:我们产品的出口条件是:具备能够正常运作的核心功能
    • 4.对于可能的变更是否能制定应急计划?
      • A:若出现突发变更,我们会根据项目当前的状况和剩余时间制定应急计划
    • 5.员工是否能够有效地处理意料之外的工作请求?
      • A:若出现意料之外的工作请求,我们会制定应急计划,让员工尽可能有效地处理
    • 6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • A:这次alpha冲刺体验,具有重要意义,也收获颇丰,不管是技术方面,还是团队写作方面,但是我们也还有许多不足之处,如果历史重来一遍,我们就能多避免出错,并有更好的安排计划
  • 设计/实现

    • 1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
      • A:设计工作是在小组会议上不断讨论决定的。由组长牵头讨论,大家共同商讨,最后由组长决定。时间一般是晚上9点过后,这时候大家都在宿舍。
    • 2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?
      • A:有碰到过。早期关于关联闹钟的取消方式团队有过争议。最终采取少数服从多数的办法解决。
    • 3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
      • A:
        团队使用了UML来对需求和软件功能进行分析。使用单元测试,对已实现的函数进行测试。这些工具很有效。UML工具帮我们更加明确了需求,系统功能,类间关系等等,使我们对于软件的开发有更清晰的逻辑。单元测试帮助我们在开发过程中及时排错,更轻松地排错。
    • 4.比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
      • A:
        没有区别。项目开始后还未对UML文档进行过更新。
    • 5.什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
      • A:在用户交互的过程中产生的Bug最多。因为涉及到多个用户,每个用户有着不同的操作,控制复杂。系统发布后发现,用户只有在重新登录后才能收到新消息。这个原因在于我们在开发的过程中,没有考虑到两个用户同时在线的情况。
    • 6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
      • A:代码会由队长进行审核,主要要求规范命名和接口。
    • 7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • A:
        我们刚开始学习软件开发,要多花时间在学习编程上。如果历史重来一次,我们会在更加花时间在软件开发上,更完善地完成Alpha版本的设计。
  • 测试/发布

    • 1.团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?
      • A:有一个比较简单的测试计划,主要由于团队中也没有比较有经验的人,也没有进行比较完整的规划。
    • 2.团队是否有测试工具来帮助测试?
      • A:有试着用测试工具帮助测试,但基本都是靠自己研究探索,毕竟缺乏经验。没有进行正式的验收测试,就目前完成的软件来说,仍存在着一些小小的问题,也还没有达到令人满意的程度,因此还在尝试完善优化软件。
    • 3.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
      • A:测量效能主要有软件是否正常运行,运行速度是否高效率,运行效果是否令人满意等。从实际结果来看,测试工作还是有用的,在测试的过程中还是发现了一些开发时欠缺考虑的问题,改进主要还是从软件本身出发,争取能更优化下用户体验。
    • 4.在发布的过程中发现了哪些意外问题?
      • A:发布的过程中,也是因为网络的问题,没有统一规范的原因,导致了最终代码整合的时候出现了难以解决的困难,基本上每次遇到的困难都是新的困难,都是令人意外的,之前没出现过的问题。
    • 5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • A:软件的开发过程中,测试这一环节是必不可少的。一款软件即使测试完毕发布后,仍然会出现或多或少的问题,而这就体现了在测试环节你付出了多少,就决定了你最后遇到的问题是大是小。而测试也是需要有技巧性,有针对性的去测试你的软件,而不能照搬其他人的测试方式,软件都有各自独有的特点。如果历史重来一遍。我们会在测试的过程前,再进行更多的交流和讨论,争取考虑更多方面可能出现的问题,有针对性的提出一个详细的测试计划,并分配给多人重复测试,争取减少发布后遇到的问题。
  • 团队的角色,管理,合作

    • 1.团队的每个角色是如何确定的,是不是人尽其才?
      • A:有某方面基础的组员优先安排,有意愿做某方面的组员优先安排。由于团队基本处于零基础状态,所以是否人尽其才无法回答
    • 2.团队成员之间有互相帮助么?
      • A:团队成员注重交流,互帮互助,一直是我们的作风
    • 3.当出现项目管理、合作方面的问题时,团队成员如何解决问题?
      • A:当出现这方面的小问题时,我们会在群内交流,提出各自的看法,当问题较大时,我们会召集开会,商讨解决方案
    • 我感谢白晨曦对我的帮助, 因为某个具体的事情: 由于我之前去参加了一次比赛导致有一次软工作业没有参加,后面他将一些高分的任务分配给了我和另一个队员,可以说对我们很好了。
    • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 总结:

    • 1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
      • A:我觉得团队目前的状态还处于第一档次,即初始级。也是刚刚起步,正学会走路但是走的不快的状态。
    • 2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
      • A:我觉得团队现在刚刚要从磨合阶段跨出去,走向规范阶段。
    • 3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
      • A:相比于前一个里程碑,团队现在在队员沟通这方面做得更好了,基本上遇到难以独自解决的问题都会是多人一起合力解决,不再像当初自己一个人埋头苦干,独自探索了。
    • 4.你觉得目前最需要改进的一个方面是什么?
      • A:目前最需要改进的地方是,团队没有一个比较核心的人物,比如有丰富的开发软件的经历,能够很好的解析并安排工作的巨人,需要一个这样的巨人的肩膀。
    • 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
      • A:做得比较好的敏捷开发的原则有
        面对面交谈
        每隔一段时间反省自己,并作出相应调整
        围绕有积极性的个人构建项目,并且信任他们能够完成工作。
        主要在Alpha冲刺阶段,两天一次的站立会议会督促着每个人是否有积极完成自己的任务,而且本组成员基本上的基础都是比较少的,每个人都会遇到大大小小的问题,解决这些问题只有当面交流,现场调试修改的效率才是最高的。而在这个项目中,基本也是围绕着学习能力比较强的大佬们,辅助他们来完成主要的功能。当然除此之外,合作的部分也是占着很重的比例。

答辩总结

贡献比例

组员 工作比例 工作内容
白晨曦 0 答辩工作准备与前端制作
乐忠豪 0.12 数据库搭建与后端指导
蔡子阳 0.12 接口制作与前端对接
黄培鑫 0.12 前端制作
李麒 0.12 接口制作与服务器搭建
王焕仁 0.14 前端制作
陈德斌 0.11 前端制作
林志华 0.15 前端制作(主要功能的完成)
何裕捷 0.12 前端制作

工作流程

  • 我们组的情况挺特殊的,可能是所有组里面技术能力最差的一组(只是针对于本次作业),面对这个问题,我们并没有立马开工进行制作,而是先进行学习(当然是在分好大类前端后端之后),利用了2次的博客报告时间(四天)进行学习和讨论。具有一定基础之后,我们展开了细节商定大会,先进行自己的学习报告,前后端交流,商讨前端界面的一些细节,功能如何实现等等,之后根据个人的能力来领取任务,对前端后端进行详细分工。在基本确定所要制作的内容后,开始赶进度,期间经常一起出来肝软工,有的人在部分前端制作完成后,帮助其他有困难的人进行制作。在所有分工完成后,进行整合,测试。

本组的现场答辩得分

平均分:68.67

其他组对本组提出的问题及本组回答

  • 针对第一组问题:
    • 项目进度似乎落后于Alpha前制定的目标,是否考虑在beta前继续完善产品?
      • A:项目进度似乎落后于Alpha前制定的目标,对此我们感到十分抱歉,在beta冲刺前我们将会完成Alpha制定的目标。
    • 产品的UI似乎缺少必要的风格统一,是否考虑后期统一一下?
      • A:后期我们将会对页面经行一个统一的美化。
    • 后端如何保证同一时间提醒一个闹钟的各个关联用户,实现的原理是?
      • A:这个和普通的闹钟实现原理是一样的,相当于每一个关联用户都有一个这样的闹钟。
  • 针对第二组问题:
    • 计划界面中的黄底是存在计划吗?黑字和红字是什么意思?
      • A:黄底表示当天有团队计划,红字表示当天有个人计划,黑字表示当天无个人计划。这些在答辩过程中我们解释过了,请尊重演讲者。
    • 计划界面中的日历和2018年11月的日历不相同,是还没完成吗?
      • A:兄弟,你是在搞笑吗?哪里不一样了?
    • 计划是否也会响起闹钟?还是会弹出信息提示?
      • A:计划本身并没有附加提醒功能,只有当关联上闹钟后才会弹出信息提示。
  • 针对第三组问题:
    • 忘记密码这一块如果手机也换了有考虑怎么解决吗
      • A:我们的账户并不是绑定手机的,忘记密码的话可以通过邮箱找回或其他方法。
    • 有考虑过如何调动组内积极性吗?如果有考虑好的话也可以给我们组一些建议
      • A:请喝奶茶。
    • 进度似乎有些堪忧,接下来有没有具体的计划与任务分配呢?
      • A:接下来会完成Alpha定下的目标,其实我们的进度并没有落后很多。
  • 针对第四组问题:
    • 界面美观问题是如何解决的呢?
      • A: 后期将会对界面经行美化,可能会参考一些当前热门的界面风格。
    • 上次提到过的团队闹钟问题考虑如何解决吗?
      • A: 闹钟发起者会将闹钟传到数据库中,团队中的其他人可从数据库获取闹钟,以此实现团队闹钟
    • 无视频演示及现场演示,是否有动态可行式的演示视频?
      • A: 后期会补上视频。
  • 针对第六组问题:
    • 界面不够美观,颜色单调,怎么解决?
      • A:后期将会对界面经行美化,可能会参考一些当前热门的界面风格。
    • 如何处理闹钟之间关联的问题?
      • A:闹钟之间并没有关联,是闹钟关联计划。
    • 是否要重现面对打“0分”这一问题?
      • A: 没错我们要重现面对打0分的问题,这次就打了零分,我求你看一看。
  • 针对第七组问题:
    • 如果手机默认闹钟设置的时间和你们的APP闹钟冲突了,会出现什么情况,你们怎么解决
      • A: 举个例子,比如你在听歌的过程中上优酷看视频,歌曲播放器将会暂停,我们这个闹钟也是一样的,后出现的会顶掉先出现的。
    • ui设计的日期选择界面配色不够美观,考虑再优化一下吗?
      • A: 配色方面我们后期可能会去修改优化一下。
    • 演示时并未展示视频,项目进度似乎不太好,有考虑如何加快开发进度吗?
      • A: 我们这两天已经有在加快开发进度了。
  • 针对第八组问题:
    • 对于落下的进度准备如何弥补?
      • A: 在Beta冲刺开始前,我们将补完Alpha冲刺落下的任务。
    • 小组成员可能学习成本太高而在时间紧凑的情况下如何提升push到每一个人?
      • A: 每一个人尽量不学习到重复的知识,然后互相交各自会的部分。
    • 对于ui界面准备如何美化?
      • A: 可能会参考一些当前热门的界面风格来进行美化UI。
  • 针对第九组问题:
    • ui不够漂亮,是否有考虑过更简洁清楚的界面呢?
      • A:UI确实不够漂亮,我们的界面已经算是比较简介的了,没有多余的东西。
    • 有组员中途参加比赛,对于落下的进度,你们如何弥补?
      • A: 在Beta冲刺开始前,我们将补完Alpha冲刺落下的任务。
    • 对于目前实现的功能是否与做到了开始时想做的功能呢?
      • A: 还有些差距,但我们将在Beta冲刺倾尽我们所能完成它。
  • 针对关于零分的问题发起的对话
    • 在答辩现场,有人提出了这个问题,我也做出了相应的回应,我说过给出零分的理由,也给出了后续调整的方案,但是你们貌似并没有认真听讲。在提问环节只是为了怼而怼。对于你们看不出前面几次作业的分数微调,我只能在这里用这种极端的方法来让你们明白。就是酱紫,不是所有人都是为了分数来做这个实践课的,我也不是什么魔鬼,谢谢————白晨曦

个人部分

PSP表格

PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
Planning 计划 180 190
· Estimate · 估计这个任务需要多少时间 5 5
Development 开发 90 120
· Analysis · 需求分析 (包括学习新技术) 60 60
· Design Spec · 生成设计文档 30 60
· Design Review · 设计复审 (和同事审核设计文档) 0 0
· Coding Standard · 代码规范 (为目前的开发制定合适的规范) 0 0
· Design · 具体设计 60 70
· Coding · 具体编码 60 80
· Code Review · 代码复审 10 10
· Test · 测试(自我测试,修改代码,提交修改) 10 10
Reporting 报告 30 30
· Test Report · 测试报告 0 0
· Size Measurement · 计算工作量 20 20
· Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 30 30
合计 300 330

学习进度条

第N周 新增代码(行) 累计代码(行) 本周学习耗时 重要成长
第0周 500 500 25 学会性能分析,单元测试,查看代码覆盖率
第1周 0 500 8 学习Axure Rp 的使用
第2周 300 800 5 JAVA爬虫及语法学习
第3周 300 1200 15 JAVA爬虫及语法学习
第4周 0 1200 8 了解需求规格说明书的格式及UML的设计
第5周 0 1200 8 学习思维导图制作
第6周 100 1300 8 学习前端知识及尝试编写
第7周 500 1800 8 AS前端编写

照片

软工 · 第十一次作业 - Alpha 事后诸葛亮(团队)

软工 · 第十一次作业 - Alpha 事后诸葛亮(团队)的更多相关文章

  1. 福大软工 · 第十一次作业 - Alpha 事后诸葛亮(团队)

    福大软工·第十一次作业-Alpha事后诸葛亮 组长博客链接 本次作业博客链接 项目Postmortem 模板 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描 ...

  2. 福大软工·第十一次作业-Alpha事后诸葛亮

    福大软工·第十一次作业-Alpha事后诸葛亮 组长博客链接 本次作业博客链接 项目Postmortem 模板 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描 ...

  3. 福大软工 · 第十一次作业 - Alpha 事后诸葛亮

    拖鞋旅游队团队事后诸葛亮会议 前言 队名:拖鞋旅游队 组长博客:https://www.cnblogs.com/Sulumer/p/10054510.html 时间:2018-12-1 20:00 地 ...

  4. 第十一次作业 - Alpha 事后诸葛亮(团队)

    软工 · 第十一次作业 - Alpha 事后诸葛亮(团队) 组长本次作业链接 现代软件工程 项目Postmortem 设想和目标 1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场 ...

  5. FZU软工第十一次作业-软件产品案例分析

    目录 前言: 第一部分.调研,评测: 1.1.初次感觉: 1.2.企业号bug: 1.3.你觉得为什么这个产品组的人没有发现这些bug: 1.4.假设你们团队需要开发这套系统,需要注意哪些方面: 2. ...

  6. 第十一次作业 - Alpha 事后诸葛亮

    拖鞋旅游队团队事后诸葛亮会议 前言 队名:拖鞋旅游队 组长博客:https://www.cnblogs.com/Sulumer/p/10054510.html 时间:2018-12-1 20:00 地 ...

  7. 软工实践 - 第九次作业 Alpha 冲刺 (1 / 10)

    队名:起床一起肝活队 组长博客:https://www.cnblogs.com/dawnduck/p/9949350.html 作业博客:(班级博客本次作业的链接) 组员情况 组员1(队长):白晨曦 ...

  8. 软工实践 - 第十次作业 Alpha 冲刺 (2 / 10)

    队名:起床一起肝活队 组长博客:https://www.cnblogs.com/dawnduck/p/9960710.html 作业博客:班级博客本次作业的链接 组员情况 组员1(队长):白晨曦 过去 ...

  9. 软工网络15个人作业4——alpha阶段个人总结

    软工网络15个人作业4--alpha阶段个人总结 一.个人总结 用自我评价表:http://www.cnblogs.com/xinz/p/3852177.html 总结Alpha冲刺过程. 由于直接用 ...

随机推荐

  1. nginx error_log 错误日志配置说明

    nginx的error_log类型如下(从左到右:debug最详细 crit最少): [ debug | info | notice | warn | error | crit ] 例如:error_ ...

  2. excel手机号码归属地批量公式查询 vlookup函数

    Excel手机号码归属地 批量公式查询 vlookup函数 xls 手机号码 添加一列 地区归属地 使用      公式:=(VLOOKUP(LEFT(B2,7),号段数据库!B:D,2,0)&amp ...

  3. C#中容易被忽视的细节整理

    (有空更新系列) 1.params可变长度参数,默认值是长度为0的数组,而不是空 2.事件和委托默认值都是null 3.bool返回值的事件调用之后,其内部的合并方式是取最后一个合并对象的返回值

  4. 5.7 cm server-agent 会出现无法启动

    异常信息如下: 离线安装cloudera-scm-agent5.7的Unable to create the pidfile问题 在离线安装Cloudera Manager启动agent出现了如下异常 ...

  5. okhttp +fastJson 在UI层的回调封装

    一直使用OkHttp 经常烦人的地方是回调方法  数据解析后必须通过handler 在主线程做操作 网上找了很多资料 发现有些都是基于Gson做的解析 fastJson 在封装时 泛型传入会有很多不方 ...

  6. 怎么样刷新frameset的整个页面

    <a href="main.html?a=2" target="_parent">?  设置a链接的target属性值为_parent即可

  7. Mac上好用的视频播放器有哪些?

    首页发现话题 提问 登录加入知乎 Mac 上好用的视频播放器有哪些? 关注问题写回答 OS X 应用 多媒体播放器(软件) Mac 上好用的视频播放器有哪些? 关注者 2680 被浏览 981770 ...

  8. 20160216&period;CCPP体系详解&lpar;0026天&rpar;

    程序片段(01):01.MemCpy.c 内容概要:内存拷贝 #include <stdio.h> #include <stdlib.h> #include <memor ...

  9. 别忽视UIImage中的方向属性&comma; imageOrientation-转

    转 : 别忽视UIImage中的方向属性, imageOrientation

  10. JQuery学习---JQuery基础知识

    JQuery介绍: [官网]http://jquery.com [参考API]http://jquery.cuishifeng.cn/ JQuery的低版本支持IE低版本,JQuery的2版本不太支持 ...