组长博客链接

https://www.cnblogs.com/147258369k/p/15573118.html

一、基本情况

1.1 现场答辩总结

  • PPT制作方面略显粗糙,对于产品描述的具体内容不太清晰,需要改进
  • 视频配音部分背景人声比较粗糙,讲解过程体验感并不尽如人意
  • 产品数据的解析需要更加完善,对于各部分内容需要稍加改动
  • 尽量删除不必要的,参考意义不大的数据展示
  • 可以考虑比较好的推广策略,提高产品知名度

1.2 全组讨论的照片

1.3工作流程

前端工作流程 后端工作流程 alpha 冲刺轮次
静态页面代码编写以及一些点击事件 代理池构建爬虫 alpha-1
学习了echarts,了解了需要开发的图表 完成数据操纵模块,成功爬取数据并存入数据库 alpha-2
学习css盒子模型和js的基本语法 初步完成数据清洗,完成部分数据处理任务,将经纬度逆编码为区域 alpha-3
学习Echarts应用部分内容 构建完成api基本框架,mvc架构,合并以及修改队友的pull requests alpha-4
学习Echarts应用部分内容 学习设计模式 alpha-5
学习Vue应用部分内容 逻辑上各种 bug 的修复 alpha-6

1.4组员分工及组员工作量比例

姓名 组员分工 工作量比例
童锦涛 数据爬取,数据清洗,数据处理,api架构设计编写,api编写,后端项目部署 25%
张梓晗 api编写,api文档编写,api测试 13%
叶超炜 提出建议 2%
蔡炜鑫 前端页面需求分析,页面编写,echarts图表代码编写,数据导入 17%
陈翁豪 auto.js辅助代码编写,前端页面部署,echarts资源查找 6%
侯钦凯 auto.js代码编写,文档、美工和博客 12%
吴杰 前端页面需求分析,echarts资源查找 3%
陈捷祥 前端页面需求分析echarts资源查找,echarts图表优化 5%
姚天一 文档、美工和博客 8.5%
杨开彬 文档、美工和博客 8.5%

二、总结思考

2.1 设想和目标(4分)

2.1.1我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述 ?

我们的软件“奶茶攻略”主要定位于从事奶茶行业的实体经营者,对于奶茶大数据有明确需求的数据分析开发人员,对全国各地奶茶的消费数据进行有效整合与合理化分析,进行较为简单明了的可视化呈现,并在此基础上为经营者用户推荐当前较为可行的营业方向。以提供可靠优质的数据服务为本产品的核心准则,该定义比较明确,典型用户属于从事奶茶行业的相关经营者,典型场景是对于对奶茶行业走向趋势有了解需求的时候提供该信息渠道。

2.1.2我们达到目标了么?(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)

可以算是达到了我们α冲刺的基本目标,原计划的功能几乎全部实现,剩下的部分就是前后端的精确对接任务,以及交互性的完善,交付时间相比原计划需要往后延时,尚未投入使用,所以还未确定既定用户数量。

2.1.3用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

在软件推出之前用户暂时为我们开发人员,所以和我们预先的设想一致,而我们团队一直都在朝着我们的目标前进,同时也确实离我们的目标更近了。

2.1.4有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

基本上需要总结反思的就是需求分析阶段问题,历史如果重来的话,我们想做的最大改进应该是那时候应该再明确些研发方向,之后在细化功能的时候才不会那么吃力。

2.2 计划(5分)

2.2.1是否有充足的时间来做计划?

我们团队有很充足的时间做计划,在学期初确定选题之后就制定了初步项目计划和分工,有充足的时间进行调度和进一步修改计划。

2.2.2团队在计划阶段是如何解决组员对于计划的不同意见的?

我们团队队内氛围友好,民主气氛浓厚,在有不同的意见时会提出,并在团队共同讨论商议。

2.2.3原计划的工作是否最后都做完了? 如果有没做完的,为什么?

前端和后端各自的原计划的内容大部分完成了,但是由于计划赶不上变化,解决一个问题时会衍生出新的问题,加之前后端对接难度较大,目前对接部分暂时未完成。

2.2.4有没有发现做了一些之后看来没必要或没多大价值的事?

由于组内分工得当,计划较为精确,所以并没有出现“做无用功”的情况。

2.2.5是否每一项任务都有清楚定义和衡量的交付件?

在真正开始项目之前,我们对项目进行过程中将会遇到的各项任务不能够做到完全的估计和衡量,随着项目的推进,我们对于各项任务的认识愈发得清晰了起来,基本上对每一项的任务都做出了清楚的定义并制定了衡量的交付件。

2.2.6是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

大部分过程都按照计划进行了,项目的意外就是在最后要发布的时候发现了很多 bug,修了一整天。风险预估到了,所以修 bug 还是预料中。

2.2.7在计划中有没有留下缓冲区,缓冲区有作用么?

我们在计划上预留下了两天左右的时间缓冲区,这个预留的缓冲区对我们项目的最终完成起了很大的作用。

2.2.8将来的计划会做什么修改?(例如:缓冲区的定义,加班)

将来的计划中将会留下更多的时间缓冲区用以解决发生在意料之外的情况,以及更好地完善产品;进一步改善任务的分工安排,优化团队间的合作,提高团队的工作效率,避免不必要的“加班”。

2.2.9学到了什么? 如果历史重来一遍, 会做什么改进?

在这次团队冲刺中,我们团队协力完成了Alpha版本的发布,在这一过程中,我们不仅在各自研究的前后端领域学到了全新的知识,还认识到了好的计划调度和团队合作对整个项目进度的重要性。如果历史重来一遍,我们会事先做好更加完善的计划,可能会更早确定选题的方向和所要完成功能,这样能更好的协调组内分工细则,计划也会更加明确。

2.3 资源(3分)

2.3.1我们有足够的资源来完成各项任务么?

1.资源稍有不足。

2.在前端开发上大家还没有开发经验,开发人员全力以赴学习,但对于各方面的实现较为缓慢。

3.在后端开发上有较好的基础,对Python语言较为熟悉,但对后端数据获取一直没有找到较好的渠道,导致进度在一段时间内一直处于低迷状态

2.3.2各项任务所需的时间和其他资源是如何估计的,精度如何?

对于不同任务根据人员学习能力,编程能力估计时间、资源。精度不太准确,实际开发中,在前期的环境搭建上遇到一些问题耗费一定时间,导致部分功能实现缓慢。

2.3.3测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

1.测试的时间,人力和软件/硬件资源不足够。Alpha阶段的测试暂时由任务负责人员自行测试,还存在些bug需要花时间修缮。

2.没有低估难度,在不需要编程的资源 (美工设计/文案)上,有专门人员进行,同时文案设计上全组通力配合,进行顺利。

2.3.4你有没有感到你做的事情可以让别人来做(更有效率)?

没有,在任务分工上人员分配合理,各人员在负责任务上有效的发挥自己长处。

2.3.5有什么经验教训? 如果历史重来一遍, 会做什么改进?

经验教训:及时的线下技术交流、功能实现讨论能进一步有效推进开发的进度,同时提高开发的完成质量。

改进:任务开发人员及时进行讨论帮助,加快解决相互之间的一些问题,减少在相似问题上所耗费的时间。

2.4 变更管理(4分)

2.4.1每个相关的员工都及时知道了变更的消息?

每个相关组员都能够及时知道变更的消息。

2.4.2我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们根据产品完整性的需求来决定“必须实现”的功能,而将耗时长,且非核心的功能进行“推迟”。

2.4.3项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

我们项目的出口条件是否能够实现数据图表良好交互性,数据是否能比较明晰地呈现,能否给予用户较为直观的信息解读。

2.4.4对于可能的变更是否能制定应急计划?

对于可能的变更我们有制定应急计划,我们有先做出一个保底的成果,然后再在此基础上进行更进一步的学习与工作。

2.4.5组员是否能够有效地处理意料之外的工作请求?

我们组员能够及时补足自己的知识缺口去应对意料之外的工作请求。

2.4.6学到了什么? 如果历史重来一遍, 会做什么改进?

我们学到了如何将工作的轻重缓急给分配清楚,如果重来一遍,我们会更加及时的根据任务的重要性与难易程度来合理变更组员的工作任务。

2.5 设计/实现(4分)

2.5.1设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

由我,天一,钦凯三人合作完成,时间较为合适,人员也比较合适

2.5.2设计工作有没有碰到模棱两可的情况,团队是如何解决的?

有碰到模棱两可的情况,团队一起商量一步一步统一想法进行解决。前端组讨论以后,决定页面调整以简洁清晰美观便捷为开发方向。后端组的成员也通过交流和讨论确定了数据展示类型、数据获取渠道及数据库设计方向并进行了明确的分工。

2.5.3团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?

使用了uml来帮助设计和实现,效果不错。

2.5.4比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

目前还是有一些区别的。在项目开发过程中,我们希望将项目更好的制作与呈现,所以对制作的成功进行初步优化,故需要进行更新,以更好的辅助开发。

2.5.5什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

生产和开发的环境有些许不同而导致。

2.5.6代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

在pull requsts先粗略阅读判断,不合要求的退回,merge后测试新加入部分的功能,若有bug先roll,对产生bug的代码修改后再合并。

采用下划线型命名规范,遵循单一职责原则,开闭原则,具有良好的可维护性和可拓展性。

2.5.7学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到了许多东西,团队成员对于项目开发的流程有了更深的理解与感悟,学到了很多从未接触过的知识,对于一个项目开发所需的人员、工具和分工情况都有了一定的认识,还有大家的团队协作以及氛围都是很好的。如果历史重来一遍,我们会花更多时间提前学习新的知识,以避免模糊不清的情况影响项目开发进度。

2.6 测试/发布(3分)

2.6.1团队是否有一个测试计划?为什么没有? 是否进行了正式的验收测试?

有测试计划,每两天冲刺后都会进行前端页面交互性评估,后端具体是对于数据的请求返回测试,还没有进行正式的验收测试,项目还没有开发完成,前后端尚未对接好。

2.6.2团队是否有测试工具来帮助测试?

对于api的编写使用了测试工具runapi和postman,利用Google的network查看请求返回时间。

2.6.3团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?

在完成一个阶段的时候,会进行功能试用评估,以此跟踪软件效能,测试工作的作用总体而言帮助很大,明确了开发过程中需要加以完善和可以简略设计的内容,主要需要改进的地方便是对于数据呈现后的分点介绍

2.6.4在发布的过程中发现了哪些意外问题?

有时会出现一些请求时延

2.6.5学到了什么? 如果历史重来一遍, 会做什么改进?

学到了主要用echarts做可视化数据分析的呈现开发,如果能重来,我们会重新分配好分工,安排更合理的开发与测试计划,不造成“资源浪费”。

2.7 团队的角色,管理,合作(3分)

2.7.1团队的每个角色是如何确定的,是不是人尽其才?

1.项目经理这个角色是认为自己有管理能力并且能够积极督促团队成员的,有良好的与团队成员沟通的能力。

2.前端开发是根据成员的兴趣意愿、以及团队需求来确定的。

3.后端开发也是根据学习兴趣以及能力来确定的。

4.可以说是团队成员都是人尽其才,分配得体。

2.7.2团队成员之间有互相帮助么?

互帮互助的情况经常出现,因为都是第一次学习web开发, 大家共同学习,互相分享经验、教程,一起解决了很多安装、写代码上的问题。

2.7.3当出现项目管理、合作方面的问题时,团队成员如何解决问题? 每个成员明确公开地表示对成员帮助的感谢 (汇总至组长博客):

<姓名>:我感谢 ___<姓名>__对我的帮助,因为某个具体的事情: _________。

当出现项目管理、合作方面的问题时,团队也会积极组织开会讨论,发表各自的看法,通过投票或其他方式确定最终的解决方案。

  • 成员感谢:

    • 叶超炜:我感谢吴杰对我的帮助,因为某个具体的事情:经常会监督我的学习情况,很多时候处于摸鱼状态时他会及时把我拉回状态,督促我学习新的内容,非常感谢他对我学习效率的帮助。

    • 吴杰:谢谢我们前端的组长蔡炜鑫在前端学习中给我的帮助,比如安装vue框架之类的,还有一些方面不懂就问,也得到了解决

    • 童锦涛:我感谢张梓晗同学对我的帮助,展示前一天晚上由于我有别的科目要忙,临时给他布置了一个任务,他很好的完成了。

    • 张梓晗:我感谢童锦涛对我的帮助,因为某个具体事情:由于我是第一次接触flask的web后端开发,不管是在各种技术方面还是在一些代码规范方面都很糟糕,锦涛给了我很多代码技术上帮助,也纠正了我的一些代码不规范的地方。从他身上学到了很多新东西。

    • 侯钦凯:我感谢锦涛对我的帮助,在选题的时候我们遇到了困难,很多选题都被否决,最后是锦涛提出了一个合适的选题。

    • 陈翁豪:我感谢蔡炜鑫和童锦涛对我的帮助,因为他们在我遇到困难时给了我鼓励。

    • 蔡炜鑫:我感谢侯钦凯对我的帮助,因为冲刺之前有个auto.js的团队编程,作为前端人员,这件事我们本应去做的,但由于时间紧迫vue框架还没学习完,实在没时间去学习auto.js所以钦凯作为我们的队长,他就站出来去学了auto.js。

    • 姚天一:我感谢杨开彬对我的帮助,因为某个具体的事情; 我们在产品需求与功能上,UI设计中有大量的交流讨论,开彬给了我很多具体思路和实践方法

    • 陈捷祥:我感谢蔡炜鑫对我的帮助,因为某个具体的事情:在制作图表部分时,因为我当时要复习搜索引擎准备考试没有时间,他就把分配给我的任务独自做完了

    • 杨开彬:我感谢姚天一对我的帮助,因为某个具体的事情; 在产品美工上,很多内容需要和天一合作完成,对于美工定位不太明确的我,很多时候都是在他的帮助下慢慢进步的

2.7.4学到了什么? 如果历史重来一遍, 会做什么改进?

我们学到了一些团队协作的精神,如果历史重来一遍,我们会在一开始动员更早一些,让彼此了解更快。

2.8 总结(4分)

2.8.1列出组内所有人的心得。

  • 叶超炜:

    首次接触后端编写,很多操作都处于盲目阶段,再加上自身代码能力较弱,在本次编程中未能帮上太大的忙,但是对于自己的学习进度却有着较好的规划,会在自己给自己规定的时间内学完需要学的内容。总体来说,虽然在alpha冲刺阶段自己没有给团队做出太大的贡献,但是对于我自身来说,我已经达到了既定的目标,收获还是挺丰盛的。

  • 吴杰:

    在alpha冲刺中,学到了很多有用的知识,前端三件套的学习,vue框架和echarts的使用,虽然感觉学的还不够充分,但比起啥都不会好多了,软工作业真是贯穿整个学期,两天一次的博客也确实带来了很大的压力,不过也因此没有落下软工的学习,希望在beta冲刺中能学会更多的东西吧。

  • 童锦涛:

    团队项目中理论上要在一定程度上平均工作量,但是由于能力和效率的不同还是无法避免的分配失衡,在分配时没有站在他人的能力和效率的角度考虑,是自己考虑不周

  • 张梓晗:

    这次Alpha冲刺,我是做后端API编写工作的。在接触这门课程之前,我对前端后端都不了解。从最开始不知道如何导入队友搭建好的数据库、自己测试写的代码跑都跑不起来,到后面把bug改完能正常运行,在自己本地能完成相应API的编写的那一刻,我总算是感觉自己真正成为了一名菜鸟后端工程师。但是在第一次和队友通过github合作的时候,把队友搭建好的API框架克隆到本地,却看不懂,跑不起来,修改代码pull requests的时候给队友造成了不少麻烦;到后面掌握蓝图的原理,能正常运行代码并帮助队友编写API接口,自己编写的API接口能被前端正常调用,能返回正确的数据……感觉自己还是成长了许多的。也希望自己beta冲刺的时候能继续保持干劲,和队友一起完成好这个项目。

  • 侯钦凯:

    这次的alpha冲刺完成度整体是很高的,从中也学到了很多东西,前端知识,管理和协调团队的能力都有了进步,但是最后答辩的时候做得不是很好,ppt和其他组的有点差距,然后我们由于是第一个上场,我们用视频介绍了我们的产品,其他组都用的腾讯会议现场介绍,明显效果好了很多,感觉有点可惜,我们的产品完成度应该是比较高的,但我的失误导致了答辩结果不是很理想,下一次我会把视频和ppt都弄得好一点。还有一点是我们组进度稳定,没有集体熬夜赶项目,这个还不错。

  • 陈翁豪:

    通过本轮冲刺,我了解并学习前端的许多知识,包括js,vue框架和echarts,在小组成员的帮助下我完成了前端网页的发布。虽然许多时候还是难以学以致用但是努力过了也不后悔,还是觉得收获满满。现在我更能理解一个项目需要大家的共同努力去实现,对前后端的分工协作有了更深入的了解

  • 蔡炜鑫:

    这次冲刺还是收获比较大的,学习了vue2以及echarts,虽然vue2就用到了很小的一部分,然后我也感觉到了去B站看视频讲解不如到官网查看文档来得快速以及有效。然后的话就是应该在做项目之前得充分了解我们的需求是什么,这一次我应该做得挺失败的,给大家指了条错误的路,让每个人都先去学习vue2导致大家也都没学完,然后我也仅仅是潦草的看了。然后的话就是分工方面,没有分好,没有充分的了解组员的情况,挺对不起捷祥同学的,他学了挺多但由于我的分工问题没有让他得到好的发挥。

  • 姚天一:

    计算机的学科不是孤立的,而是相互依赖。在软工作业中,用到了不少从前学的知识,在作业中巩固了知识,同时也让我意识到,目前掌握的知识还是太少,要多学习。在项目开始前,先作计划可以更好地利用时间,之前做事情时,总是这做一点,那做一点,大大浪费了时间。

    • 新的知识总是有用处的,所谓技多不压身。在Alpha冲刺中用到的AE,PR等知识之前有过粗浅了解,在冲刺中有了使用机会,但限于水平,质量堪忧,后续会继续提升
    • 实践出真知。在网上看过后的学习视频和资料如果自己不实操永远不会真正掌握,还是要多多进行练习
  • 陈捷祥:

    这个实践作业可以说是我参与的第一个这么多人合作完成的项目,因此我在过程当中也遇到不少困难,不知道怎么和组内其他人沟通,不知道怎么配合别人的工作,面对从未涉足的知识领域感到不知所措,不过好在组内的大家都很友好,期间我也努力学习必要的知识技能,虽然实力不足贡献不多,但也是贡献自己的微薄之力,在团队的共同努力下,产品如今已经实现了大部分的功能,离顺利完成的时刻也不会太久了,在这里,我想感谢团队所有人为此的付出,特别感谢前端负责人蔡炜鑫,在我们都缺乏基础的情况下,他投入了很多时间,完成了前端大部分功能的开发,保证了整体的开发进度。

  • 杨开彬:

    在这次Alpha阶段冲刺中,我始终把学习作为获得新知识、掌握方法、提高能力、解决问题的一条重要途径和方法,本着认真负责的态度去对待每项工作。虽然开始由于经验不足和认识不够,觉得在小组产品研发工作中对自身定位模糊不清,之后迅速从自身出发寻找原因,和组内成员交流,认识到自己的不足,以至于迅速的转变自己的角色和工作定位。为使自己尽快熟悉工作,进入角色,我一方面抓紧时间查看相关资料,熟悉自己的工作职责,根据工作的实际情况,结合自身的优势,把握工作的重点和难点,尽心尽力完成工作的任务。

12组-Alpha冲刺-总结的更多相关文章

  1. 第12组 Alpha冲刺(3/6)

    Header 队名:To Be Done 组长博客 作业博客 团队项目进行情况 燃尽图(组内共享) 展示Git当日代码/文档签入记录(组内共享) 注: 由于GitHub的免费范围内对多人开发存在较多限 ...

  2. 12组-Alpha冲刺-3/6

    一.基本情况 队名:字节不跳动 组长博客:https://www.cnblogs.com/147258369k/p/15546442.html 小组人数:10人 二.冲刺概况汇报 侯钦凯 过去两天完成 ...

  3. 12组-Alpha冲刺-2/6

    一.基本情况 队名:字节不跳动 组长博客:https://www.cnblogs.com/147258369k/p/15535639.html 小组人数:10人 二.冲刺概况汇报 侯钦凯 过去两天完成 ...

  4. 第12组 Alpha冲刺(6/6)

    Header 队名:To Be Done 组长博客 作业博客 团队项目进行情况 燃尽图(组内共享) 展示Git当日代码/文档签入记录(组内共享) 注: 由于GitHub的免费范围内对多人开发存在较多限 ...

  5. 第12组 Alpha冲刺(5/6)

    Header 队名:To Be Done 组长博客 作业博客 团队项目进行情况 燃尽图(组内共享) 展示Git当日代码/文档签入记录(组内共享) 注: 由于GitHub的免费范围内对多人开发存在较多限 ...

  6. 第12组 Alpha冲刺(4/6)

    Header 队名:To Be Done 组长博客 作业博客 团队项目进行情况 燃尽图(组内共享) 由于这两天在修bug,燃尽图没有下降 展示Git当日代码/文档签入记录(组内共享) 注: 由于Git ...

  7. 第12组 Alpha冲刺(2/6)

    Header 队名:To Be Done 组长博客 作业博客 团队项目进行情况 燃尽图(组内共享) 展示Git当日代码/文档签入记录(组内共享) 注: 由于GitHub的免费范围内对多人开发存在较多限 ...

  8. 12组-Alpha冲刺-1/6

    一.基本情况 队名:字节不跳动 组长博客:https://www.cnblogs.com/147258369k/p/15526363.html 小组人数:10人 二.冲刺概况汇报 侯钦凯 过去两天完成 ...

  9. 第12组 Alpha冲刺(1/6)

    Header 队名:To Be Done 组长博客 作业博客 团队项目进行情况 燃尽图(组内共享) 展示Git当日代码/文档签入记录(组内共享) 注: 由于GitHub的免费范围内对多人开发存在较多限 ...

  10. 12组-Alpha冲刺-4/6

    侯钦凯 过去两天完成了哪些任务 完善UI界面,复习考试 展示GitHub当日代码/文档签入记录 接下来的计划 复习考试,准备答辩 还剩下哪些任务 博客和答辩 燃尽图(团队整体) 遇到了哪些困难 在部分 ...

随机推荐

  1. Solon2 开发之插件,二、插件扩展机制(Spi)

    插件扩展机制,是基于 "插件" + "配置申明" 实现的解耦的扩展机制(类似 Spring Factories.Java Spi):简单.弹性.自由.它的核心作 ...

  2. Thymeleaf的内置对象、SpringBoot整合Thymeleaf和JDBC

    Thymeleaf的对象 Thymeleaf是直接支持访问Servlet web的原生资源,HttpServletRequest HttpServletResponse HttpSession Ser ...

  3. 【TS】函数和函数类型

    在使用函数的时候,通常会给函数传值,或者给函数一个返回值调用,这个时候就会涉及到函数类型. 函数类型分为两个方面: 1.函数参数 2.函数返回值 语法: function 函数名( 参数 : 参数类型 ...

  4. RocketMQ - 生产者最佳实践总结

    相对消费者而言,生产者的使用更加简单,一般关注消息类型.消息发送方法和发送参数,即可正常使用RocketMQ发送消息 常用消息类型 消息类型 优点 缺 点 备注 普通消息(并发消息) 性能最好.单机T ...

  5. 首个比较研究表明维持期强柱患者减量续用TNFi疗效尚佳且药费省

    首个比较研究表明维持期强柱患者减量续用TNFi疗效尚佳且药费省 Zavada J, et al. Ann Rheum Dis. 2016,75: 96-102. 电邮发布日期: 2016年5月4日 关 ...

  6. 解决veture和eslint冲突的问题

    vscoder自带的veture和eslint存在冲突,主要表现在 末尾逗号,分号,单双引号的不一致.解决办法:1.npm install --save-dev prettier2.在根目录新建.pr ...

  7. nginx编译安装以及常用参数详解

    1 基于ansible role实现编译安装nginx 利用ansible控制端10.0.0.8机器,在被控制端10.0.0.18上部署nginx 首先打通ansible控制端与被控制端的基于key验 ...

  8. LeetCode-851 喧嚣与富有

    来源:力扣(LeetCode)链接:https://leetcode-cn.com/problems/loud-and-rich 题目描述 有一组 n 个人作为实验对象,从 0 到 n - 1 编号, ...

  9. CSS3,线性渐变(适用标题背景)

    .test{ margin:200px auto; height:30px; border:1px #D4D4D4 solid; box-shadow:0 -1px 10px rgba(0,0,0,0 ...

  10. dismount ASM磁盘组,影响未使用的其它ASM磁盘组

    # 问题概述登录数据库,查看活动会话,发现大量library cache lock ,log file switch (archiving needed),归档失败,redo log无法重用.# 问题 ...