国内创意网站案例,国外wordpress模板下载,抖音小程序电脑上怎么打开,wordpress怎么给产品编号一、软件工程M1/M2总结 1、M1阶段总结#xff1a; 我们团队的软件工程开发是按照前后端来分别开发的#xff0c;我是负责后端的。我们的项目是做一个北航的社团平台#xff0c;是一个网站。在后端我们使用的是ruby on rails。一开始对于ruby是没有什么经验的#xff0c;因为…一、软件工程M1/M2总结 1、M1阶段总结 我们团队的软件工程开发是按照前后端来分别开发的我是负责后端的。我们的项目是做一个北航的社团平台是一个网站。在后端我们使用的是ruby on rails。一开始对于ruby是没有什么经验的因为之前没有过什么接触之前只是接触过Python。刚开始的时候我有去图书馆借书不过后来发现书中的内容已经有些旧了稍微有点过时了。后来在网上找了一些教程以及一个叫做《Web开发敏捷之道_应用Rails进行敏捷Web开发》的PDF然后才慢慢开始熟悉。我比较喜欢从整体去了解然后再开始关注细节所以在M1阶段我的开发进度是比较慢的之前一直在学习整个工程构建然后各个层次之间的关系等。之后就对于rails的体系有了一定的理解然后才效率高了起来。在M1我们的进度总体上是很顺利的没有遇到什么大的问题整体项目的进程和我们的预想和安排基本一致。在第一轮我们的整体项目是按照API文档来实现的项目PM先拿出了一份简版的API文档设计然后后端和前端分别按照API文档的设计开始实现。然后在我们都熟悉了这样的开发模式以后设计API文档的工作就交给了后端补充在一轮我记得我大概是实现了设计到用户状态信息验证的部分API以及活动名单等API的实现。总体而言在一轮的收获我觉得主要是这些吧首先单单从技术上来说我学习并了解了ruby语言和rails了解了什么是BS架构程序什么是web开发。另外我觉得我对于软件工程的敏捷开发有了一点点的理解吧因为rails很方便地提供了一种敏捷开发的方式。不过我们的开发实际上不能完全算是敏捷开发就是不能说我们是完全做到随时跟随需求改变程序然后就很快拿出来demo那种我们的开发和敏捷开发是有一定区别的。不过对于rails的理解对于我对敏捷开发的理解有许多帮助。 2、M2阶段总结 在M2阶段可能所有人都会提到就是任务量时间的安排吧。我当然也不例外...因为在M2阶段说实话真的和M1比起来学习到的知识上的东西并不是很多主要的都是在学习如何应对各种各样的压力各种各样的事情接踵而来如何在这些事情权衡。对于软工来说我觉得就是学习了如何在各种事情打断对于你的节奏不连贯的情况下调整自己的节奏来面对这种随时会被打断的情况。在M2的开始时候我实际上是有转过去前端来帮忙我自己也是希望能够学习了解更多的知识。在第一轮的时候我们就发现实际上前端压力远比后端大所以第二轮的时候我们是认为应该对于前端更重视的所以当时我们的设想就是从后端拿一个人去前端。然后刚好我有想学习前端的想法我就转去前端了。在M2开发阶段我们的第一周是用来学习第二轮用到的各种新的东西的。在我们最开始的设计中M2开发中前端会学习使用Vue.js和React的后端是需要学习一下learncloud还有对于rails服务器的模式的调整。然后我在这一周的时间是需要去了解前端开发的基本知识的当时我一直在看html5css等当时的感觉就是实在是太杂了。感觉看了那么多收获也不是很大然后那两个框架我也看的不是很明白。那一周对我来说收获是比较小的也没有取得什么成果。然后这周过去我们正式开始准备开发以后当时我们经过讨论发现我们所面临的问题和我们之前的设想差的很远。因为在十二月我们开发软工的这两周需要面对数据库大作业数据库答辩数学建模大作业编译实验等。这些东西全都挤在十二月直接和我们的软工开发是凑在一起的。然后我们当时汇报之前一周的学习状况的时候大家状况都不是很好所以我们经过讨论还是沿用了第一轮的开发方式就是还是按照原来的方式实现。然后我也就转回了后端还是继续实现后端的功能。然后就正式开始开发前两天我主要负责后端数据库的设计和API文档的设计。哦对了在第二轮我们相比于第一轮还引入了github的成分。在M2阶段我们的文档是以markdown然后发送到github项目的wiki中的。当然代码同步等等。然后当时那一周的开发还算比较连续然后就开始断断续续了尤其是编译的第一次测试然后还有就是数据库大作业到了不能再拖的时候...软工当时的进度真的是断续的特别厉害前端负责开发的一些同学实在是没办法继续下去就是我们的PM还在继续开发前端的用户界面。当时那段时间过的比较艰苦好吧其实一直到今天答辩之前这一整段的时间我们过的都十分艰苦......软工的开发都是掺杂在这些考试和大作业deadline中的。中间也不知道刷过多少夜了。总的说起来在M2轮的话技术上的收获可能就是对于github的使用了吧。对于git的clonecommitbranch操作还有就是当时使用的时候造成了很大困扰的merge这些都有了一定的了解。不过我还是觉得这轮开发最大的收获还是在面对压力上的。就是这种苦熬的感觉在面对各种事情接踵而来感觉没有一个时候是头的感觉但是还是得继续坚持的感觉我觉得这种坚持对我来说是一个很有意义的经历。 二、《构建之法》阅读作业以及相关问题分析 1、《构建之法》阅读作业链接 http://www.cnblogs.com/wk1216123/p/4831004.html 2、理解的问题 关于代码维护的重要性 当时的那个说代码维护不重要然后还不如推翻了重写的是来自我们上个学期的一门课叫做oo然后当时我们就是因为被各种注释和规范折磨的特别厉害然后在一个论坛还是什么地方看到的然后当时在对于代码注释和规范十分厌倦的时候对于那个观点是比较支持的。不过经过这么多的开发显然这个问题也没有什么好回答的显然代码维护是十分重要的代码的注释和规范对于一个项目的开发效率尤其是多人合作的项目影响当然是很大的。 关于团队中想法不统一造成效率低的问题 其实说实话现在再回头看当时的那些问题很多都不是什么问题。好多都感觉可能是当时为了想出问题而想出的问题吧...就拿这个来说团队中想法不统一是肯定存在的不过我个人觉得这种情况是积极的。因为想法不统一就说明大家对于问题都有自己的思考这是一方面另一方面将这些想法都考虑清楚然后再统一想法然后开始对于整个项目的理解会有很大的帮助然后也会利于少犯错误等等。当然在一个团队中每个成员都是要学会理解互相的不能说性格很强然后就持着自己的想法死不放手这样还是要学会权衡和接受吧。 怎么样的软件是一个好的软件 在现在看来经过这段时间的开发我觉得一个好的软件是会有这样的一些特点功能强大效率高代价小。这三个我觉得都是很重要的一个真正好的软件是肯定需要权衡各种因素使得这三个都在一个很良好的位置上。然后如果再区分的话个人会觉得功能会更重要一点。 3、仍然不理解的问题 关于如何衡量开发成本和收益的问题 这个问题我觉得我觉得主要问题在于现在所学习的知识还是不够吧。个人觉得在有了一定开发经验的情况下应该以比较妥当地判断出来开发成本吧。不过对于收益而言就完全不是很明白了。我觉得还是得接触更多的知识才能解决这个问题吧。 关于客户要求如果是错误的是否还是第一位的 这个问题我不是很明白。我个人觉得可能比较合适的做法是尽量去和用户解释然后说明情况然后如果实在不行还是得按照客户的要求来吧。不过我并不是很了解因为我没有足够知识来理解客户要求的重要性到底到了什么地步。 三、8篇论文博客阅读作业及相关体会 链接http://www.cnblogs.com/wk1216123/p/4962653.html 对于银弹问题我的理解和之前还是差不多吧不过可能稍微有一点点的变动。我之前一直单方面地认为附加性问题的影响是要大于本质性问题的不过后来我觉得本质问题和附加性问题这两个之间是需要在一定程度上考量的。对于大量程序而言就是不处于科研前沿的程序就是只是平时的应用或者是平时这些普通应用而言我觉得附加性问题的影响是要大于本质性问题的。但是对于科研前沿的问题比如人工智能等等在这些领域中本质性问题当然是最难以解决的方面。所以这两个概念是要结合起来看的。我觉得在论文里面作者所指出的情况应当是指的是科研前沿而言的吧所以站在作者角度是会有这么个东西影响很大的那就是本质性问题。 大泥球问题在经过了软工两轮的开发对于这个问题的理解和体会还是比较深的。在我们的项目中大泥球问题是存在的尤其在第一轮的代码中一些大泥球问题延续了下来。一个最简单的例子当时我们对于rails的render理解的不是很清楚当时我们的理解是render和普通函数的return是一个意思但是实际上这两个东西是完全不同的。render是一个方法是去渲染一个返回的表单或者是其他成分可以是页面等然后实际上不是return。对于一个API是不可以渲染多次的然后我们当时就将render理解成了return然后就会可能导致多次渲染的问题。然后这个问题在第二轮的时候才被发现当时我们在测试的时候发现一些API出现了两次渲染的问题然后经过研究才发现了这个问题。但是这个错误已经随着一轮代码的四处拷贝复制等已经到处都是了。然后改的很费劲。这只是一个简单的例子。我觉得对于大泥球问题一方面我们需要提升自己的知识水平对于很多错误需要能够识别然后我们需要改变很多不良的代码习惯就是要多考虑代码重用的问题。我在二轮的时候有注意这个然后将很多我觉得会重复的方法都写成了代码块在一个主类中然后在分类中就可以直接调用代码块达到目的。 关于大教堂问题我觉得这个的话我们还是会选择大教堂模式的。就拿我们现在的项目来说我们中间有做实名认证功能然后这个功能是在教务的支持下完成的。我们是通过token来控制调用另外的API实现的。如果这个token泄露了那么教务的数据就会泄露了。而这个token是作为代码的一部分的是不可以公开的 。所以实际上我们是不可能使用市集模式的。不过当然市集模式和大教堂模式的区别本质当然不是指保密性不过我觉得保密性实际上是我们应该考虑的部分。 关于开源在我们的项目中是没有使用任何的开源项目或者别的开发框架的就是指比如开发论坛关注这样系统的框架等我们当时的考虑就是一方面我们希望能够自己手动来写这样可以提升我们的能力。另一方面如果使用了框架项目就会受到框架的制约对于项目的兼容响应效率等然后对于一个项目的上限和今后开发都会有影响的。 关于简洁最好的话没有太多特别的体会...... 关于瀑布模型我觉得其实在我们这个开发中并不是很合适的。因为很多情况下我们需要随时修改我们的设计所以如果是瀑布模型的话之前错了我们还要倒退回去我觉得就不是很合适了 关于敏捷开发比如我们的API文档是随时随着需求的变化而变化的然后我们后端的实现就需要随着API文档的变化而变化。 软件工程的方法我觉得是需要我们去体会的。对于软件工程的方法有了足够的了解自然会起到一个引导的作用。 四、项目的 需求/设计/实现/测试/发布/维护 等6个阶段中的学习体会 需求 在需求阶段主要学习了一些了解用户需求的方法比如调查问卷面谈啊等等。对于需求的详细描述主要就学到了NABC方法。 设计 在设计阶段我们应用过ER图的方法另外还有做过数据流图。 实现 在实现阶段主要学习了代码规范和注释等另外就是一些实现的方法比如结对编程等。 测试 在测试阶段主要学习使用了单元测试黑盒测试兼容性测试压力测试的方法。 发布 在发布阶段主要就是有一个事后分析。 维护 我们并没有经历维护阶段不过个人觉得维护阶段可能需要学会如何合理的解决bug的能力。转载于:https://www.cnblogs.com/wk1216123/p/5118910.html
