1.总结:html
通过了软工M1和M2阶段的历练,我提高了对软件工程的认知,在对一个工程的分层解耦,架构和接口设计上提高到了一个新的高度。另外在代码规范和团队合做上,我也有了更明确的认识。学习了这门课程, 还有老师们的多元化教课,不但让我从理论上掌握软件工程,还有从不一样的实例,让理论和实践获得了很好的结合。整一个学期下来,总的来讲仍是学到了不少东西 的,有不少地方是值得确定的,其实在我看来,软件工程与其说是一门课程,不如说是一门思想。是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止 局限于该门课程,成为了一个综合的一个可以解决问题的思想集合。前端
2.之前问题的博客:web
http://www.cnblogs.com/hoerwing/p/4830486.html数据库
3.解决的问题:后端
(1)软件开发时,好比web2.0的rest风格架构,先后端彻底分离,然而其交接时,极可能出现问题,而且由于彻底分离,因此有可能出现开发不一样步的问题,先后端的交互耦合,开发同步的问题该如何解决。安全
这种大前端式的开发,很是重要的一点就是要在前期作好接口文档,而且在开发过程当中严格按照接口文档进行编码,若是接口有修改,要及时让各个部分的开发人员同步最新的文档。这样在最后的对接阶段才能迅速对接,并减小bug。服务器
(2)数据操做,和逻辑操做,实体操做等如何分离解耦。这和架构
(3)若是有效果的分层解耦,三层框架是什么。其实差很少是一个问题:并发
三层架构(3-tier application) 一般意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。app
a.表现层(UI):通俗讲就是展示给用户的界面,即用户在使用一个系统的时候他的所见所得。(负责展现而已)
b.业务逻辑层(BLL):针对具体问题的操做,也能够说是对数据层的操做,对数据业务逻辑处理。(关键在于由原始数据抽象出逻辑数据)可以提供interface\API层次上全部的功能。,“中间业务层”的实际目的是将“数据访问层”的最基础的存储逻辑组合起来,造成一种业务规则
c.数据访问层(DAL):该层所作事务直接操做数据库,针对数据的增添、删除、修改、查找等。(关键在于粒度的把握)要保证“数据访问层”的中的函数功能的原子性!即最小性和不可再分。“数据访问层”只管负责存储或读取数据就能够了。
(4)过分解耦,或者大规模模块化开发时遇到的依赖冗余问题如何解决。
这就要把握一个度,模块化粒度的度。这是在初期架构时就决定的,咱们要对各个功能的开发成本,复用频度,效率问题等作一下评测,以后再决定在架构中的模块如何划分,粒度是怎样的,这种划分形成的依赖冗余会形成多大成本和影响,综合考虑,将其影响降到最低。
(5)如何在开发成本和收益之间权衡需求,如何判断刚性需求,伪需求。
(6)如何在开发过程当中设计框架和预留接口使得迭代更加高效,维护更加轻松。
这要考验项目之初对用户需求的分析程度和架构师对架构的理解和对将来功能的展望。对我本身来讲,我一般是考虑到后来跟这个功能有关的扩展时才会考虑这个问题,我以为这样仍是不够的,我但愿能找到一套工程化的通用规范或者方法来高效的解决这个问题。
5.产生了哪些新的问题,请提出:
(1)如何进行高效的测试,自动化测试,黑盒测试,产品的安全性应该如何保证。
6.同时咱们还读了8篇软件工程相关的论文或博客,你回头再看看这些文章,有没有新的体会?
没有。。。。。满篇英文再读仍是那么费劲【捂脸】
7.知识点:
(1)需求:要从用户出发,作好用户定位,用户需求调查,市场调查,而且分析用户究竟想要什么,而不是他说他想要什么。
(2)设计:框架搭建时要注意分层解耦,又要注意依赖冗余,必定要作好接口文档和代码规范。
(3)实现:源代码管理要作好各个版本的迭代,各个模块之间对接时尤为要注意代码管理。还要注意为之后的开发迭代预留好接口。
(4)测试:回归测试和单元测试都要进行。压力测试要和日志相结合,解决并发效能问题。
(5)发布:要作好宣传工做,要从用户获得反馈。
(6)维护:要作好日志监控和数据备份。服务器的性能信息也要作好监控。