问题清单
- 首先就要获得完整的需求，在需求分析阶段做了大量的工作与客户各个环节的代表性用户进行沟通，充分了解和熟悉客户的业务。
并且从需求到设计阶段都保持与用户的沟通和交流。让用户的业务专家一直参与我们的需求，分析和设计工作。 其次我们会在需求分析
后就编写测试计划，在开发的每个阶段都进行相应的测试来保证代码是乎合相应需求的。在代码编写过程中，每完成一个类都由程序进行
单元测试，每完成一个功能点或模块都要进行集成测试，每一次集成测试都对上一次的已经测试通过的产品进行迭代, 也就是以前测试成功的
都会加入到本次测试中来。使得每个完成的功能和模块完成后都是一个可以运行的，可以看得到的产品；同时也欢迎用户来见证我们的集成测试结果。
代码编写完成后进行最后一次集成测试，然后交由独立的测试小组对项目进行系统测试
- 开闭原则（OCP）
1988年，勃兰特·梅耶（Bertrand Meyer）在他的著作《面向对象软件构造（Object Oriented Software Construction）》中提出了开闭原则，它的原文
是这样：“Software entities should be open for extension,but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。
这句话说得略微有点专业，我们把它讲得更通俗一点，也就是：软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）
等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，
是指对于原有代码的修改是封闭的，即不应该修改原有的代码。
- 里氏代换原则（LSP）
是对“开-闭”原则的补充。
（多态）
- 依赖倒转原则（DIP）
降低了客户与实现模块间的耦合。面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提
高了开发的成本。面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断
变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。（面向抽象编程、面向接口编程），父控制子，子不要控制父。依赖倒转
也可以叫做控制反转。
- 接口隔离原则（ISP）
接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类
层次结构。”不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
- 合成/聚合复用原则
成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是；要尽量使用合成/聚合，尽量不要使用继承。
- 迪米特法则（松耦合）
简写为: LoD迪米特法则可以简单说成：talk only to your immediate friends。 对于OOD来说一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对
其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很
容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系
- python经常被用于web开发
- 系统管理、服务器运维的自动化脚本
- PyQt、PySide、wxPython、PyGTK是Python快速开发桌面应用程序的利器
- 服务器软件（网络软件
- 网络爬虫
- 数据分析、人工智能
- Q.Python的命名空间？
- Python使用叫做命名空间的东西来记录变量的轨迹。命名空间是一个 字典（dictionary）,
它的键就是变量名，它的值就是那些变量的值。在一个 Python 程序中的任何一个地方，都存在几个可用的命名空间。 - 每个函数都有着自已的命名空间，叫做局部命名空间，它记录了函数的变量，包括函数的参数和局部定义的变量。
- 每个模块拥有它自已的命名空间，叫做全局命名空间，它记录了模块的变量，包括函数、类、其它导入的模块、模块级的变量和常量。
- 还有就是内置命名空间，任何模块均可访问它，它存放着内置的函数和异常
- Q.代码优化需要考虑的几个问题？
- 你到底为了什么而优化？
- 小心对待优化的衡量标准
- 优化且只优化关键部分
- 高层次优化更好
- 不要过早优化
- 依靠性能分析数据，而不是直觉
- 不能指望优化解决所有问题
- 详细介绍
- Q.软件会逐渐退化而不会磨损的原因？
- A.不断的变更使组件接口之间引起错误
- Q.软件工程的方法
- 结构化开发方法
- 面向数据结构的软件开发方法
- 面向问题的分析法
- 原型化方法
- Q.怎么样做到模块化设计
- 什么是模块化设计
- 模块化设计的原则
- 模块化设计的关键
- Q.代码审查如何保证软件质量
- Q.基本路径测试方法
- 以详细设计或源代码作为基础，导出程序的控制流图
- 计算得到的控制流图G的环路复杂性V(G)
- 确定线性无关的路径的基本集
- 生成测试用例，确保基本路径集中每条路径的执行
- Q.在单元测试中，各个模块的作用？
- 驱动模块：
- 桩模块：
- Q.黑盒测试与白盒测试区别？
- 黑盒测试
- 白盒测试
- Q.软件开发模型及其特点
- 瀑布模型
- 迭代模型
- 增量模型
- 喷泉模型
- 演化模型
- 快速原型模型
- 螺旋模型
- Q.软件过程与软件工程方法有何关系？ 软件过程是指为了获得高质量软件产品，在软件工具支持下，由软件人员完成的一系列软件工程活动的框架。 软件过程与软件工程方法学的关系： 软件过程：是一个为了获得高质量软件所需完成的任务的框架，也就是说软件过程规定了软件产品开发时完成各项任务的一系列工作步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。 软件工程方法学：通常把在软件生命周期的全过程中的一整套技术方法的集合称为方法学，也称范型。软件工程方法学包含三个要素：方法、工具和过程。 从这些两个定义可以看出，软件过程是软件工程方法学的一个要素而已！软件过程是软件工程方法学的3个重要组成部分之一
- Q.动态测试与静态测试区别？ 根据程序是否允许，测试可分为静态测试与动态测试。
- 静态测试
- 动态测试
- Q.敏捷开发的特点
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
- Q.敏捷开发的原则
- 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
- 即使到了开发的后期，也欢迎改变需求。
- 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
- 围绕被激励起来的个人来构建项目。
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
- 工作的软件是首要的进度度量标准。
- 敏捷过程提倡可持续的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力。
- 简单使未完成的工作最大化。
- 最好的构架、需求和设计出自于自组织的团队。
- 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
- Q.Scrum与极限编程(XP)的区别？
- 迭代长度的不同
- 在迭代中, 是否允许修改需求
- 在迭代中，User Story是否严格按照优先级别来实现
- 软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
- Q.面向对象与面向过程的本质的区别？
- 面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了；面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。
- 面向过程
- 面向对象
- Q.用力点估算？
- Q.BBS是什么？
- BBS是“电子公告板”。BBS在国内一般称作网络论坛，早期的BBS与一般街头和校园内的公告板性质相同，只不过是通过电脑来传播或获得消息而已 BBS系统最初是为了给计算机爱好者提供一个互相交流的地方。70年代后期，计算 bbs 机用户数目很少且用户之间相距很远。因此，BBS系统(当时全世界一共不到一百个站点)提供了一个简单方便的交流方式，用户通过 BBS可以交换软件和信息。到了今天，BBS的用户已经扩展到各行各业，除原先的计算机爱好者们外，商用BBS操作者、环境组织、宗教组织及其它利益团体也加入了这个行列。只要浏览一下世界各地的BBS系统，你就会发现它几乎就象地方电视台一样，花样非常多。 编辑本段BBS系统 起初的BBS系统是报文处理系统。系统的唯一目的是在用户之间提供电子报文。随着时间的推移，BBS系统的功能有了扩充，增加了文件共享功能。因此，目前的BBS用户还可以相互之间交换各种文件。只需简单地把文件置于BBS系统，其它用户就可以极其方便地下载这些文件。 早期的BBS系统是一台配有调制解调器的普通PC机，上面运行了一个BBS程序。BBS程序有各种版本，包括单线路的简单系统到支持十几甚至上百条电话线路的复杂系统。最早的BBS系统系统把全部报文存放在一个地方，可现在的BBS软件却允许操作人员根据报文内容来组织报文。比方说，基于PC的 BBS软件很可能包括有专用于DOS、OS/2和Windows的报文部分。 编辑本段BBS管理 BBS(论坛)一般由站长(创始人，超级管理员，administrator)创建，并设立各级管理人员对论坛进行管理，包括论坛管理员(Administrator)、超级版主(Super Moderator，有的称“总版主”)、版主(Moderator，俗称“斑猪”、“斑竹”)。 超级版主是低于站长(创始人)的第二权限(不过站长本身也是超级版主，超级管理员，administrator) 一般来说超级版主可以管理所有的论坛版块(普通版主只能管理特定的版块)。
- Q.如何提高开发效率与质量？
- 提高软件项目开发效率和质量的关键是人才储备。
- 提高代码的规范性。编码规范 可以提高代码的可读性，并且在代码修改的时候很容易。
- 对功能进行分类，并拆分。分析出几种处理逻辑。编写代码时，部分代码可以copy。可以提编码速度。
- 对功能进行分类，并合并。提出共通类。
- Q.需求获取技术包含哪些？
- 组织人员 组织人员，建立分析小组，其中包括领域专家：主角，也就是用户方面的问题专家，了解软件所解决问题的领域知识。系统分析员：导演，软件开发人员方面的人 ，其主要分析 ，抽象领域专家的知识，形成软件模型。
- 客户访谈 客户访谈，也就是获取用户需求，其主要方法是调查研究。其主要内容包括：
- Q.需求分析阶段动作？
- 需求获取
- 需求分析
- 编写需求规格说明书
- 需求评审
- Q.A/B测试？ A/B测试是一种新兴的网页优化方法，可以用于增加转化率注册率等网页指标。AB测试本质上是个分离式组间实验，以前进行AB测试的技术成本和资源成本相对较高，但现在一系列专业的可视化实验工具的出现，AB测试已越来越成为网站优化常用的方法。
- 包含关系、关联关系、依赖关系、扩展关系的区别？
- 包含关系 包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。表示符号：<
- 关联关系 企鹅和气候有关联. student与course。
- 依赖关系 凡是动物，生存都需要水和空气，这种必须的需求，我们称之为依赖关系。用虚线一端带箭头表示，箭头指向依赖物。
- 泛化关系 会员注册时可以采用电话和邮件两种方式。用例“会员注册”和“电话注册”、“邮件注册”之间是泛化关系。本质都是一样的，都是注册，而且一样大。
- 扩展关系 用一个用例（可选）扩展另一个用例（基本例）的功能，将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。表示符号：<
- 用例建模？ 详细请看
- 用例建模中，如何确定系统的理想行为？
- 面向对象与面向服务的关联与区别？
- 面向对象编程(Object-Oreinted Programming) 是一种编程范式。指在设计程序时大量运用类实例对象的方式。OOP一旦在项目中被运用，就成了时刻要考虑的东西。
- 面向服务架构(Service-Oreinted Architecture) 是将软件设计成一组可互操作的服务的一套原则或方法论。通常在考虑系统架构时才会触及SOA。
- 基 于组件开发(Component-Based Development) 是一种软件工程实践，设计时通常要求组件之间高内聚，松耦合。其接口可能是OO的，调用方式可能是以Service的方式。基于组件开发关注系统层次、子 系统边界和子系统间通讯的的设计，处于代码层面但不像OOP的一样是时刻需要运用的东西。
- 详细请看
- 面向对象分析法？ 面向对象分析采用人们认识客观事物和理解现实世界过程中常用的基本法则:
- CRC卡片？
- 详细请看
- 系统顺序图和用例实现顺序图的区别 用例图基于用例，通过角色来描述系统中的信息，是从系统外部来观察系统中的功能，也就是说角色将使用该系统的哪些功能（即用例）。顺序图（序列图）是基于用例图的，它具体描述用例实例之间的交互情况，反映用例实例间消息传递的先后顺序，以及在某一方面该位置将要发生的事情。
- UML顺序图
- 详细请看
- 顺序图的建立有哪些步骤？
- 确定交互的上下文。
- 找出参与交互的对象类角色，把他们横向排列在顺序图的顶部，最重要的对象安置在最左边，交互密切的对象尽可能相邻。在交互中创建的对象在垂直方向应安置在其被创建的时间点处。
- 对每一个对象设置一条垂直的向下的生命线。
- 从初始化交互的信息开始，自顶向下在对象的生命线之间安置信息。注意用箭头的形式区别同步消息和异步消息。根据顺序图是属于说明层还是属于实例层，给出消息标签的内容，以及必要的构造型与约束。
- 在生命线上绘出对象的激活期，以及对象创建或销毁的构造型和标记。
- 更具消息之间的关系，确定循环结构及循环参数和出口条件。
- 三层架构与MVC模式？
- 详细请看
- B/S与C/S的区别、和优势
- 详细请看
- 什么是观察者模式？
- 详细请看
- 详细请看
结构化开发方法是由E.Yourdon 和 L.L.Constantine 提出的，即所谓的SASD方法，也可称为面向功能的软件开发方法或面向数据流的软件开发方法。
Yourdon方法是80年代 使用最广泛的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，
最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。
Jackson方法是最典型的面向数据结构的软件开发方法，Jackson方法把问题分解为可由三种基本结构形式表示的各部分的层次结构。三种基本的结构形式
就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其
它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，
用于模块的详细设计。
PAM（Problem Analysis Method）是80年代末由日立公司提出的一种软件开发方法。 它的基本思想是考虑到输入、输出数据结构，指导系统的分解，
在系统分析指导下逐步综 合。这一方法的具体步骤是：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，
直到画出整个系统的PAD图。这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据
结构。PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一。当然由于在输入、输出数据结构与整个系统之间
同样存在着鸿沟，这一方法仍只适用于中小型问题
产生原型化方法的原因很多，主要随着我们系统开发经验的增多，我们也发现并非所有的需求都能够预先定义而且反复修改是不可避免的。当然能够采用原型化方
法是因为开发工具的快速发展，比如用VB，DELPHI等工具我们可以迅速的开发出一个可以让用户看的见、摸的着的系统框架，这样，对于计算机不是很熟悉的用户就
可以根据这个样板提出自己的需求。
构成不同的产品，以满足市场的不同需求的设计方法。
②模块的系列化，其目的在于用有限的产品品种和规格来最大限度又经济合理地满足用户的要求。
它是指模块结构标准化，尤其是模块接口标准化。模块化设计所依赖的是模块的组合，即联接或啮合，又称为接口。显然，为了保证不同功能模块的组合和相同功能模块的互换，模块应具有可组合性和可互换性两个特征，而这两个特征主要体现在接口上，必须提高其标准化、通用化、规格化的程度。例如，具有相同功能、不同性能的单元一定要具有相同的安装基面和相同的安装尺寸，才能保证模块的有效组合。在计算机行业中，由于采用了标准的总线结构，来自不同国家和地区厂家的模块均能组成计算机系统并协调工作，使这些厂家可以集中精力，大量生产某些特定的模块，并不断进行精心改进和研究，促使计算机技术达到空前的发展。相比之下，机械行业针对模块化设计所做的标准化工作就逊色一些。机械产品中模块化设计仅应用于为数不多的机床行业。
2.模块的划分
模块化设计的原则是力求以少数模块组成尽可能多的产品，并在满足要求的基础上使产品精度高、性能稳定、结构简单、成本低廉，且模块结构应尽量简单、规范，模块间的联系尽可能简单。因此，如何科学地、有节制地划分模块，是模块化设计中很具有艺术性的一项工作，既要照顾制造管理方便，具有较大的灵活性，避免组合时产生混乱，又要考虑到该模块系列将来的扩展和向专用、变型产品的辐射。划分的好坏直接影响到模块系列设计的成功与否。总的说来，划分前必须对系统进行仔细的、系统的功能分析和结构分析，并要注意以下各点：
l)模块在整个系统中的作用及其更换的可能性和必要性。
2)保持模块在功能及结构方面有一定的独立性和完整性。
3)模块间的接合要素要便于联接与分离。
4)模块的划分不能影响系统的主要功能。
按照软件生命期划分成六个部分顺序进行。但是这其中也会带来问题，相较于快速原型模型和增量模型，瀑布模型要求用户在最初就提出一套清晰完整的需求，在软件编程之前必须先撰写出详细的需求说明书。用瀑布模型开发的软件系统可能不满足客户的需求。
每次迭代就会产生一个可发布的产品，也就是把一个大项目拆成若干个小项目，分步实施。适合于分多期实施的项目，第二期的程序代码会完全替换第一期的代码。缺点是项目风险高。
将软件产品作为一系列的增量构件来设计、编码的。这样既可以快速的向用户提交可完成部分功能的产品，有能让用户有较充裕的时间适应新系统。这样的开发模型需要开放式的体系结构，同时可能会导致开发的软件设计差、效率低。
软件开发过程的各个阶段是相互迭代的、无间歇的。软件的某个部分常常被重复工作多次，相关对象在每次迭代中加入渐近的软件成分。适合于面向对象的软件开发，开发效率相对较高。缺点是常规的项目管理方法不适用。
通过一些快速原型语言先构建出软件产品的原型系统，这样可快速的和用户交互，用户通过该原型系统具体的了解该款软件，并通过原型发现用户需求的遗漏，同时用户参与度相较于瀑布模型加大了不少，弥补了瀑布模型的不足。但可能导致系统设计差、效率低，难于维护。
使用原型及其他方法来尽可能降低风险。在软件开发的每个阶段，都增加一个风险分析过程。螺旋模型结合了快速原型模型的迭代性质和瀑布模型的系统性和可控性特点，适用于内部开发的大规模软件项目。
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队收到干扰
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。因此，原作者认为， 这点上，XP的做法值得认同的，但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念，结合敏捷模式，表达给团队的信息是“你是一个完全自我管理的组织， 但你必须要实现TDD, 结对编程, ...等等”
（1） 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。
（2） 市场调查。了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统。如果有，在功能上、性能上、价格上情况如何。
（3） 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分析；访问用户领域的专家所得到的信息将有助于对用户需求的理解。
（4） 考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。
A/B测试其实是一种"先验"的实验体系，属于预测型结论，与"后验"的归纳性结论差别巨大。A/B测试的目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信。
A/B测试如同GitHub、Docker、APM一样在美国市场已经被各类企业逐渐采用，相信在中国也能被广大开发者所接纳，其测试范围也不仅仅局限于网页优化，目前移动端的A/B测试需要同时支持前端(Web/H5、iOS、Android)及后端(Node.js、PHP、Java)，相对于Web端的A/B测试，移动端的技术难度与复杂度都要高得多。
1. 认识对象及其属性;
2. 认识对象的整体及其组成部分;
3. 对象的形成及类的区分;
4. 对问题空间进行理解并抽象成模型.
面向对象分析有五个阶段:标识对象、标识结构、标识主题、定义属性、定义服务，即分五个层次建立面向对象分析的模型.面向对象分析的优点是使功能分析与数据分析使用统一的概念和方法，克服了结构化分析中两者之间的不一致性和不协调性.
