软件基本设计原则
●友好、简洁的界面设计
●结构、导向清晰，符合国际标准
●强大的综合查询
●信息数据共享
●方便及时的信息交流板块
●准确、可逆的科技工作流模块支持
●良好的开放性和可扩展性
●方案生命周期长
设计原则：
设计时考虑的总体原则是：它必须满足设计目标中的要求，并充分考虑本网站的基本约定，建立完善的系统设计方案。
信息系统的实施作为信息化规划的实践和实现，必须遵循信息化规划方案的思想，对规划进行项目实施层面上的细化和实现。
首先必须遵循信息化规划“投资适度，快速见效，成熟稳定，总体最优”的总原则。具体细化到信息系统分析设计和软件系统工程上来。
●先进性
系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前
成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。
●实用性
实用性是指所设计的软件应符合需求方自身特点，满足需求方实际需要。在合法性的基础上，应根据需求方自身特点，设置符合需求方的设计需求。对于需求方的需求，在不违背使用原则的基础上，确定适合需求的设计，满足需求方内部管理的要求。
1)设计上充分考虑当前各业务层次、各环节管理中数据处理的便利和可行，
把满足管理需求作为第一要素进行考虑。
2)采取总体设计、分步实施的技术方案，在总体设计的前提下，系统实施
时先进行业务处理层及低层管理，稳步向中高层管理及全面自动化过渡。
这样做可以使系统始终与业务实际需求紧密连在一起，不但增加了系统
的实用性，而且可使系统建设保持很好的连贯性；
3)全部人机操作设计均充分考虑不同使用者的实际需要；
4)用户接口及界面设计充分考虑人体结构特征及视觉特征进行优化设计，
界面尽可能美观大方，操作简便实用。
●可靠性
在可靠性设计过程中应遵循以下原则：
（1）可靠性设计应有明确的可靠性指标和可靠性评估方案；
（2）可靠性设计必须贯穿于功能设计的各个环节，在满足基本功能的同
时，要全面考虑影响可靠性的各种因素；
（3）应针对故障模式（即系统故障或失效的表现形式）进行设计，最大限度地消除或控制产品在寿命周期内可能出现的故障（失效）模式；
（4）在设计时，应在继承以往成功经验的基础上，积极采用先进的设计原理和可靠性设计技术。但在采用新技术时必须经过试验，并严格论证
其对可靠性的影响；
（5）在进行产品可靠性的设计时，应对产品的性能、可靠性、费用、时间等各方面因素进行权衡，以便做出最佳设计方案。
●可操作性
系统在设计上要充分考虑用户界面应方便、友好、灵活，用户应能够方便地在权限范围内于各子系统之间切换。系统有良好的整体化设计，同时完善的帮助系统也是增强可操作性的必要辅助工具之一。
●灵活性
应用系统不依赖于特定硬件环境；在系统结构一致的前提下可选择实施各模块的应用；系统具有可实施性，各模块可单独实施并使用。
●开放性
系统采用开放性的平台，充分考虑本系统与其它系统的数据接口。
根据我们对系统需求和系统目标的分析，实现思路是：快速适应系统的业务需求，应用先进的软件设计思想，同时充分考虑系统长期发展的前瞻性要求，基
于J2EE的多层B/S架构体系之上实现系统的灵活性、安全性，并使系统具有良好的可管理性。重点考虑以下几点：
?最大限度保护用户现有投资
任何新体系的引进都必须保证不能影响原有业务系统的性能，保证关键业务系统的正常运转，这是引进新的信息技术的前提。本系统将充分考虑本系统的现状，最大程度地保护用户现有软硬件和网络投资。对准备弃用的原有系统中的数据完整地迁移到新系统中，对保留使用的原有系统进行全面整合，加以充分利用。
?总体规划、分步实施
系统必须本着“整体规划，统一组织，分步实施”的原则进行开发建设，系统建设应在建设之初的统一规划下，充分考虑以上多方的情况，有机的、分步骤的逐步完善。此外，系统的建设涉及众多新的和复杂的软硬件技术，工程实施环节复杂，应按照总体设计的规划来进行分步实施。
?标准化的开发与设计
系统开发与建设应做到工作标准统一、业务流程统一、服务程序统一。
在业务、软件产品、通信技术等各方面采用行业、国家和国际标准化组织制定的有关技术规范与标准。保证信息流传递快速顺畅，网络运行安全可靠。?完备的安全体系
系统安全性也是设计与开发应用系统的首要考虑因素，是整个过程中应当遵循的准则。应用系统在设计时制定一整套有效的安全措施以保证整个系统的安全性，能够满足本系统制定的安全管理需要，能够防止来自内、外部入侵的威胁。
●可扩展性
可扩展性指的是系统可以根据业务发展的需要，能够方便的升级，扩展系统的功能。由于本次采用了集中式系统架构，数据和应用的集成集中在中间件一级进行处理，所以，也就为日后的扩展打下了良好的基础。
同时保证系统能在各种操作系统和不同的中间件平台上移植。从本次采用的系统体系架构、开发语言到各平台服务器的选型我们都充分考虑到了移植性的要求。
●系统性原则
以系统的眼光作出整体规划，做到统一设计，逐步实施, 并制定统一的数据标准、网络标准和应用标准，形成决策层、调度层、操作层之间相互衔接的标准体系。
同时，由于信息化涉及面广、覆盖面宽，任务重，难度大，非一朝一夕所能够完成，因此，在实施过程中必须坚持远近结合、突出重点、急用先建、分步实施、逐步推进。在系统设计过程中考虑系统实施的分步性、阶段性，提供逐步实施的具体方法，先试点再推广与分阶段升级实施。快速见效，保证满足基本需求和规划方向结合。
●成熟性原则
系统设计和开发平台采用业界公认成熟并被广泛应用的技术，保证系统实施的进度和质量、保证系统的稳定可靠。系统技术成熟稳定和主流相结合。
坚持以安全、实用为前提，在实施中首选先进、成熟、可靠、适应行业特点的信息技术，同时又要体现信息系统的开放性、兼容性和可扩展性，做到既满足业务管理和安全保密的自身需要，又要满足与相关外部业务之间的开放对接之需要。
软件研发人员考核的基本原则 软件研发人员的考核一直是软件企业管理的难点，总结了进行软件研发人员考核的一些基本原则，整理出来与大家共享： ?要体现公司的价值观 公司的价值观体现了公司认可什么类型的人员？要挽留哪些人？提倡做什么？对这些人员的认可可以通过具体的考核办法落实下来。比如企业鼓励在某一个业务领域内积累丰富的领域经验，鼓励在某个技术方向上进行深入钻研等，对于提倡的这些行为，要有具体的奖励措施。所以在定义考核办法时，需要首先考虑清楚要体现企业的哪些价值观。 ?要体现多劳多得，质与量并重 不能让那些完成了大量艰苦工作的人员吃亏，否则就会打击真正努力工作的人员的积极性。多劳多得原则的实现，基于对工作量的计算。规范的管理都是“以人为本、以过程为核心、以度量为基础”的。要做到多劳多得就需要做好对工作量的度量，如果仅仅注重工作量而不关注工作质量，显然是不对的，而对于质量的考核，可以通过多个渠道来获得数据，如发现的缺陷个数、客户的反馈等等。 当然多劳多得的前提是团队的目标达成了，如果目标未完成，多劳未必多得。 ?要鼓励创新与规范管理 管理与创新是软件企业发展的2个轮子，通过规范管理可以确保企业的常规发展，通过创新实现企业的跳跃式发展，管理为创新提供了转化为生产力的基础，创新可以快速地提高企业的竞争能力，因此在考核办法中要体现出来对这2者的认可。有的企业设立了创新基金，专门用来奖励那些技术创新、管理创新等，有的企业在研发人员的考核指标中加入了对过程改进工作的支持等指标。 ?要鼓励技术复用 成功的软件企业必须在人员、技术、过程三个方面加大投入。软件复用是目前软件公司提高软件生产率的最有效的手段之一，为了在企业内建立组织级的技术复用体系，首先就要鼓励大家主动去提取可复用的各种构件，主动贡献可复用的构件。对于这种提取可复用构件的行为，应根据其可能带来的收益，适当给予奖励。 ?要因时而变，但要尽可能保持连续性 考核办法的制定都有一定的针对性，具有一定时限性，随着公司内外部环境的变化，随着公司文化的逐步稳定，对考核办法要逐步调整，在改变考核办法时，要注意保持考核办法的连续性，不要变化太大，否则就会让被考核人无所适从，产生观望的心态，或者在研究考核办法上花费很多时间，造成不必要的生产效率的下降。 ?要量化与非量化结合 如果没有量化的考核指标，全靠非量化的指标，对于开发人员来讲，很难体现多劳多得的原则，很容易走向“吃大锅饭”的模式，无法调动开发人员的积极性。如果全量化也很难，在开发过程中，有很多工作难以量化，比如需求开发的工作，就很难定量的计算工作量。因此在考核时，在尽可能量化的基础上，也允许有一些非量化的指标的存在。至于2者的比重，可以根据当前企业的管理水平来确定。对于管理比较规范的企业，成熟度比较高的企业，可以采用量化的指标多一些，量化的比重大一些。
软件基本设计原则 友好、简洁的界面设计 结构、导向清晰，符合国际标准 强大的综合查询 信息数据共享 方便及时的信息交流板块 准确、可逆的科技工作流模块支持 良好的开放性和可扩展性 方案生命周期长 设计原则： 设计时考虑的总体原则是：它必须满足设计目标中的要求，并充分考虑本网站的基本约定，建立完善的系统设计方案。 信息系统的实施作为信息化规划的实践和实现，必须遵循信息化规划方案的思想，对规划进行项目实施层面上的细化和实现。 首先必须遵循信息化规划“投资适度，快速见效，成熟稳定，总体最优”的总原则。具体细化到信息系统分析设计和软件系统工程上来。 先进性 系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前
成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。 ●实用性 实用性是指所设计的软件应符合需求方自身特点，满足需求方实际需要。在合法性的基础上，应根据需求方自身特点，设置符合需求方的设计需求。对于需求方的需求，在不违背使用原则的基础上，确定适合需求的设计，满足需求方内部管理的要求。 1)设计上充分考虑当前各业务层次、各环节管理中数据处理的便利和可行， 把满足管理需求作为第一要素进行考虑。 2)采取总体设计、分步实施的技术方案，在总体设计的前提下，系统实施 时先进行业务处理层及低层管理，稳步向中高层管理及全面自动化过 渡。这样做可以使系统始终与业务实际需求紧密连在一起，不但增加了 系统的实用性，而且可使系统建设保持很好的连贯性； 3)全部人机操作设计均充分考虑不同使用者的实际需要； 4)用户接口及界面设计充分考虑人体结构特征及视觉特征进行优化设计， 界面尽可能美观大方，操作简便实用。 ●可靠性 在可靠性设计过程中应遵循以下原则： （1）可靠性设计应有明确的可靠性指标和可靠性评估方案； （2）可靠性设计必须贯穿于功能设计的各个环节，在满足基本功能的同
1、设计程序时应遵循的基本原则： 此原则是由“Bertrand Meyer”原文是：“Software entities should be open for extension, but closed for modification”.就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原（是”原“，指原来的代码）代码的情况下进行扩展。 OO设计根本的指导原则是提高可维护性和可复用性。这些原则主要有： 1. 开闭原则 2. 依赖倒转原则 3. 里氏代换原则 4. 合成/聚合复用原则 5. 迪米特原则5. 6. 接口隔离原则 2、数据结构： 数据结构是计算机存储、组织数据的方式。数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。通常情况下，精心选择的数据结构可以带来更高的运行或者存储效率。数据结构往往同高效的检索算法和索引技术有关。 数据结构在计算机科学界至今没有标准的定义。个人根据各自的理解的不同而有不同的表述方法： Sartaj Sahni 在他的《数据结构、算法与应用》一书中称：“数据结构是数据对象，以及存在于该对象的实例和组成实 例的数据元素之间的各种联系。这些联系可以通过定义相关的函数来给出。”他将数据对象（data object）定义为“一个数据对象是实例或值的集合”。 Clifford A.Shaffer 在《数据结构与算法分析》一书中的定义是：“数据结构是 ADT （抽象数据类型 Abstract Data Type）的物理实现。” Lobert L.Kruse 在《数据结构与程序设计》一书中，将一个数据结构的设计过程分成抽象层、数据结构层和实现层。其中，抽象层是指抽象数据类型层，它讨论数据的逻辑结构及其运算，数据结构层和实现层讨论一个数据结构的表示和在计算机内的存储细节以及运算的实现。 3、算法的概念： 4、计算机语言的分类和特点 主要是从其抽象程度这个方面来考虑： 没有抽象：机器语言
设计组织架构需要遵循 基本原则 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
设计组织架构需要遵循基本原则西方管理学家总结的基本原则： 在长期的企业组织变革实践活动中，西方管理学家曾提出过一些组织设计基本原则，如管理学家厄威克曾比较系统地归纳了古典管理学派泰罗、法约尔、马克斯·韦伯等人的观点，提出了8条指导原则：目标原则、相符原则、职责原则、组织阶层原则、管理幅度原则、专业化原则、协调原则和明确性原则。 美国管理学家孔茨等人，在继承古典管理学派的基础上，提出了健全组织工作的l5条基本原则：目标一致原则、效率原则、管理幅度原则、分级原则、授权原则、职责的绝对性原则、职权和职责对等原则、统一指挥原则、职权等级原则、分工原则、职能明确性原则、检查职务与业务部门分设原则、平衡原则、灵活性原则和便于领导原则。 国内管理专家总结的基本原则： ①战略匹配原则 一方面，战略决定组织结构，有什么样的战略就有什么样的组织结构；另一方面，组织结构又支持战略实施，组织结构是实施战略的一项重要工具，一个好的企业战略要通过与企业相适应的组织结构去完成方能起作用。实践证明，一个不适宜的组织结构必将对企业战略产生巨大的损害作用，它会使良好的战略设计变得无济于事。因此，企业组织结构是随着战略而定的，它必须根据战略目标的变化而及时调整。通常情况下企业根据近期和中长期发展战略需要制订近期和中远期组织结构。
②顾客满意原则 顾客是企业赖以生存和发展的载体，企业设计的组织架构和业务流程必须是以提高产品和服务，满足顾客需求为中心的。要确保设计的组织架构和流程能够以最快捷的速度提供客户满意的产品的服务，组织中各部门的工作要优质、高效达到始于顾客需求，终于顾客满意的效果。 ③精简且全面原则 精简原则是为了避免组织在人力资源方面的过量投入，降低组织内部的信息传递、沟通协调成本和控制成本，提高组织应对外界环境变化的灵活性；对于非核心职能，可能的话应比较自建与外包的成本，选择成本最低的方案。全面原则则是体现麻雀虽小，五脏俱全的思想，即组织功能应当齐全，部门职责要明确、具体，这样即使出现一人顶多岗的情况，也能使员工明确认知自身的岗位职责。 ④分工协作原则 如果组织中的每一个人的工作最多只涉及到单个的独立职能，或者在可能的范围内由各部门人员担任单一或专业化分工的业务活动，就可提高工作效率，降低培训成本。分工协作原则不仅强调为了有效实现组织目标而使组织的各部门、各层次、各岗位有明确的分工。还强调分工之后的协调。因此在组织机构设计时，必须强调职能部门之间、分子公司之间的协调与配合，业务上存在互补性或上下游关系时，更需要保持高度的协调与配合，以实现公司的整体目标。 ⑤稳定与灵活结合原则
软件基本设计原则 ●友好、简洁的界面设计 ●结构、导向清晰，符合国际标准 ●强大的综合查询 ●信息数据共享 ●方便及时的信息交流板块 ●准确、可逆的科技工作流模块支持 ●良好的开放性和可扩展性 ●方案生命周期长 设计原则： 设计时考虑的总体原则是：它必须满足设计目标中的要求，并充分考虑本网站的基本约定，建立完善的系统设计方案。 信息系统的实施作为信息化规划的实践和实现，必须遵循信息化规划方案的思想，对规划进行项目实施层面上的细化和实现。 首先必须遵循信息化规划“投资适度，快速见效，成熟稳定，总体最优”的总原则。具体细化到信息系统分析设计和软件系统工程上来。 ●先进性 系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前
成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。 ●实用性 实用性是指所设计的软件应符合需求方自身特点，满足需求方实际需要。在合法性的基础上，应根据需求方自身特点，设置符合需求方的设计需求。对于需求方的需求，在不违背使用原则的基础上，确定适合需求的设计，满足需求方内部管理的要求。 1)设计上充分考虑当前各业务层次、各环节管理中数据处理的便利和可行， 把满足管理需求作为第一要素进行考虑。 2)采取总体设计、分步实施的技术方案，在总体设计的前提下，系统实施 时先进行业务处理层及低层管理，稳步向中高层管理及全面自动化过渡。 这样做可以使系统始终与业务实际需求紧密连在一起，不但增加了系统 的实用性，而且可使系统建设保持很好的连贯性； 3)全部人机操作设计均充分考虑不同使用者的实际需要； 4)用户接口及界面设计充分考虑人体结构特征及视觉特征进行优化设计， 界面尽可能美观大方，操作简便实用。 ●可靠性 在可靠性设计过程中应遵循以下原则： （1）可靠性设计应有明确的可靠性指标和可靠性评估方案； （2）可靠性设计必须贯穿于功能设计的各个环节，在满足基本功能的同
项目开发的基本原则 1 充分了解各方的设计需求，确定合适的解决方案 启动一个硬件开发项目，原始的推动力会来自于很多方面，比如市场的需要，基于整个系统架构的需要，应用软件部门的功能实现需要，提高系统某方面能力的需要等等，所以作为一个硬件系统的设计者，要主动的去了解各个方面的需求，并且综合起来，提出最合适的硬件解决方案。比如A项目的原始推动力来自于公司内部的一个高层软件小组，他们在实际当中发现原有的处理器板IP转发能力不能满足要求，从而对于系统的配置和使用都会造成很大的不便，所以他们提出了对新硬件的需求。根据这个目标，硬件方案中就针对性的选用了两个高性能网络处理器，然后还需要深入的和软件设计者交流，以确定内存大小，内部结构，对外接口和调试接口的数量及类型等等细节，比如软件人员喜欢将控制信令通路和数据通路完全分开来，这样在确定内部数据走向的时候要慎重考虑。项目开始之初是需要召开很多的讨论会议的，应该尽量邀请所有相关部门来参与，好处有三个，第一可以充分了解大家的需要，以免在系统设计上遗漏重要的功能，第二是可以让各个部门了解这个项目的情况，提早做好时间和人员上协作的准备，第三是从感情方面讲，在设计之初各个部门就参与了进来，这个项目就变成了大家共同的一个心血结晶，会得到大家的呵护和良好合作，对完成工作是很有帮助的。 2 原理图设计中要注意的问题 原理图设计中要有“拿来主义”，现在的芯片厂家一般都可以提供参考设计的原理图，所以要尽量的借助这些资源，在充分理解参考设计的基础上，做一些自己的发挥。当主要的芯片选定以后，最关键的外围设计包括了电源，时钟和芯片间的互连。 电源是保证硬件系统正常工作的基础，设计中要详细的分析：系统能够提供的电源输入；单板需要产生的电源输出；各个电源需要提供的电流大小；电源电路效率；各个电源能够允许的波动范围；整个电源系统需要的上电顺序等等。比如A项目中的网络处理器需要1.25V 作为核心电压，要求精度在＋5%- －3%之间，电流需要12A左右，根据这些要求，设计中采用5V的电源输入，利用Linear的开关电源控制器和IR的MOSFET搭建了合适的电源供应电路，精度要求决定了输出电容的ESR选择，并且为防止电流过大造成的电压跌落，加入了远端反馈的功能。 时钟电路的实现要考虑到目标电路的抖动等要求，A项目中用到了GE的PHY器件，刚开始的时候使用一个内部带锁相环的零延时时钟分配芯片提供100MHz时钟，结果GE链路上出现了丢包，后来换成简单的时钟Buffer器件就解决了丢包问题，分析起来就是内部的锁相环引入了抖动。 芯片之间的互连要保证数据的无误传输，在这方面，高速的差分信号线具有速率高，好布线，信号完整性好等特点，A项目中的多芯片间互连均采用了高速差分信号线，在调试和测试中没有出现问题。 3 PCB设计中要注意的问题
工艺设计的基本原则和程序 一、工艺设计的基本原则 水泥厂工艺设计的基本原则可归纳如下： (1)根据计划任务书规定的产品品种、质量、产量要求进行设计。 计划任务书规定的产品产量往往有一定范围，设计产量在该范围之内或略超出该范围，都应认为是合适的；但如限于设备选型，设计达到的产量略低干该范围，则应提出报告，说明原因，取得上级同意后，按此继续设计。 对于产品品种，如果设计考虑认为计划任务书的规定在技术上和经济上有不适当之处，也应提出报告，阐明理由，建议调整，并取得上级的同意。例如，某大型水泥厂计划任务书要求生产少量特种水泥，设计单位经过论证，认为大型窑改变生产品种，在技术上和经济上均不合理，建议将少量特种水泥安排给某中小型水泥厂生产，经上级批准后，改变了要求的品种。 窑、磨等主机的产量，除了参考设备说明和经验公式计算以外，还应根据国内同类型主机的生产数据并参考国内外近似规格的主机产量进行标定。在工厂建成后的较短时期内，主机应能达到标定的产量；同时，标定的主机产量应符合优质、高产、低消耗和设备长期安全运转的要求，既要发挥设备能力，但又不能过分追求强化操作。 (2)选择技术先进、经济合理的工艺流程和设备。 工厂的工艺流程和主要设备确定以后，整个工厂设计可谓大局已定。工厂建成后，再想改变其工艺流程和主要设备，将是十分困难的。例如，要把湿法厂改为干法厂，固然困难；要把旧干法厂改为新型干法厂，也非易事。例如，为了利用窑尾废气余热来烘干原料，生料磨系统也得迁移，输送设备等也得重新建设，诸如此类的情况，在某些条件下就不一定可行。 在选择生产工艺流程和设备时，应尽量考虑节省能源，采用国内较成熟的先进经验和先进技术；
软件基本设计原则 ??友好、简洁的界面设计 ??结构、导向清晰，符合国际标准 ??强大的综合查询 ??信息数据共享 ??方便及时的信息交流板块 ??准确、可逆的科技工作流模块支持 ??良好的开放性和可扩展性 ??方案生命周期长 设计原则： 设计时考虑的总体原则是：它必须满足设计目标中的要求，并充分考虑本网站的基本约定，建立完善的系统设计方案。 信息系统的实施作为信息化规划的实践和实现，必须遵循信息化规划方案的思想，对规划进行项目实施层面上的细化和实现。 首先必须遵循信息化规划“投资适度，快速见效，成熟稳定，总体最优”的总原则。具体细化到信息系统分析设计和软件系统工程上来。 ●先进性
系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。 ●实用性 实用性是指所设计的软件应符合需求方自身特点，满足需求方实际需要。在合法性的基础上，应根据需求方自身特点，设置符合需求方的设计需求。对于需求方的需求，在不违背使用原则的基础上，确定适合需求的设计，满足需求方内部管理的要求。 1)设计上充分考虑当前各业务层次、各环节管理中数据处理的 便利和可行，把满足管理需求作为第一要素进行考虑。 2)采取总体设计、分步实施的技术方案，在总体设计的前提下， 系统实施时先进行业务处理层及低层管理，稳步向中高层管 理及全面自动化过渡。这样做可以使系统始终与业务实际需 求紧密连在一起，不但增加了系统的实用性，而且可使系统建 设保持很好的连贯性； 3)全部人机操作设计均充分考虑不同使用者的实际需要； 4)用户接口及界面设计充分考虑人体结构特征及视觉特征进行 优化设计，界面尽可能美观大方，操作简便实用。 ●可靠性
软件开发基本原则（一）——策略和因素 概述 时间成本质量（或特性）是评价软件项目成败的三个关键指标，这三个指标之间相互影响和制约，形成了所谓的“项目管理三角形”。要提高质量或增加特性意味着成本和时间的增加，或两者都增加；要在时间不变的前提下缩减开发成本或成本不变的前提下缩减时间则意味着质量的下降或特性的削减。 图项目管理三角形 上述分析其实只是理论上的“理想平衡”状态。现实工作中往往出现的情形是：要么时间超过计划，要么成本超过预算，要么质量达不到要求，要么三个指标都达不到预期。 典型例子： 由于客户的压力需要尽量缩减开发时间，由于企业间的竞争和盈利压力需要尽量节约成本，因此需要一个人做两个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审和项目会议等活动。可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。更糟糕的还在后面：由于质量的低劣，构建阶段结束后对系统进行集成测试时，很多问题就会暴露出来：对某些需求的理解有误差，导致这部分功能要重新分析、设计、编码和测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的；沟通不畅顺导致模块接口不兼容……从而项目被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个项目谈虎色变。 软件开发项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。 策略和因素 总体策略 要避免混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发： 、避免典型错误
设计依据与原则 本项目涉及到系统必须以实用为原则。采用成熟的并且通过实践考验的先进技术和解决方案。 业务驱动 系统须基于长城华西银行业务特色、相关制度要求、规划阶段制定的概要需求进行客户化开发，须满足监管机构相关要求、并符合长城华西银行业务操作及管理规范。系统不仅要能够支持现行政策、组织架构及相关业务流程，还需具备良好的灵活性以支持未来业务的变化，从而达到业务可持续发展的目标。 规范性 系统的设计需符合业界标准，功能、界面、内容与业务需保持高度统一性和标准性，从而达到服务的规范化和管理的高效性。 开放性 系统应具备足够的开放性和灵活性，系统支持主流的标准或规范。 可扩展性 伴随贵公司业务的不断发展、管理水平的持续提升，对系统的要求也会随之变化，因此系统应具备良好的扩展性，在不影响系统已有业务功能的情况下易于扩展新的业务模块，持续支持业务发展。 安全性 系统应具备统一完善的安全管理机制，提供安全的身份认证机制和完善的加密机制，确保信息不被他人窃取。同时要有严格的权限控制机制，既要满足信息共享的要求，又要保障信息的安全性。
集成性 系统需要与行内系统对接，这就需要系统本身能够提供开放和标准的接口，一方面在项目实施过程中可以很好的与其他系统完成集成对接，另一方面在日后周边系统发生变化时也可做到快速灵活集成，实现不同应用系统的互联互通，并且充分考虑周边系统因为升级改造而产生的集成性要求。 易用性 系统能根据技术的更新和业务的创新方便地进行升级和维护，应具有良好的用户界面，容易学习和使用，提供专用的管理和维护平台，便于维护并能记录相关的日志。 经济性 系统须基于成熟平台的产品，能够根据长城华西银行相关需求进行配置或客户化开发，并且支持未来业务需求的扩展，可方便实现新功能的上线投产，缩短系统实施周期，降低实施成本，提高实施效率。 功能性 与一组功能及其指定的性质有关的一组属性，具体包括： 适合性：与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。 准确性：与能否得到正确或相符的结果或效果有关的软件属性。 互用性：与同其他指定系统进行交互的能力有关的软件属性。 依从性：使软件遵循有关的标准，约定，法规及类似规定的软件属性。 安全性：与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。
1 设计规范 这里主要摘取了OO设计原则的其中几条，其中开闭原则、里氏替换原则必须遵守，单一职责原则尽量要求遵守，接口分离、合成聚合、依赖倒置原则强烈推荐遵守，另外补充了一些其他规范。 1.1开闭原则(Open-Closed Principle, OCP) 这是最基本的原则，一个模块应当对扩展开放,对修改关闭。确切地说，模块的对外接口不能被修改，而只能被扩展，当某个开发者使用了你的接口，而却被你后期修改了这个接口，那对程序是一个灾难。 因此在进行设计时要尽量考虑接口封装机制、抽象机制和多态技术。 1.2单一职责原则SRP (Simple responsibility pinciple) 不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 很多人可能觉得它很简单，但在实际中，我们多有不遵守这条原则。即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。 比如：类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，也许是需求变更，也许是程序的设计者境界提高，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。（这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。） 遵循单一职责的优点有： 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
管理信息系统开发的原则 1、创新原则、整体性原则、相关性原则、动态适应性原则、工程化、标准化原则 简述各种开发方法的基本思想、优缺点和适用范围 常用的系统开发方法有：结构化开发方法、原型法、面向对象的方法和信息工程方法等。 A 结构化系统开发方法(Structured System Development Methodology)是目前应用得最普遍的一种开发方法,也叫做结构化生命周期法。[ 基本思想]系统分析员、软件工程师、程序员以及最终用户按照用户至上的原则，自顶向下分析与设计和自底向上逐步实施的建立计算机信息系统的一个过程，是组织、管理和控制信息系统开发过程的一种基本框架。[ 优点]：强调开发人员与用户的结合，强调开发过程的整体性。[ 缺点]：开发周期长、需要大量的文档和图表。适用范围[ 适用于]：大型系统、复杂系统。 B 原型法与原型法概念原型是一个可以实际运行、反复修改，可以不断完善的系统。[ 基本思想] 在管理信息系统开发的开始阶段，凭借系统开发人员对用户需求的理解与用户共同确定系统的基本要求和主要功能，在强有力的人、软件环境支持下，给出一个满足用户需求的初始系统原型，然后与用户反复协商修改，最终形成MIS系统。[ 优点] 1)改进了用户和系统设计者的沟通方式，解决了结构化方法中最难于解决的一环。2)开发风险降低。 3)充分利用最新的软件工具，摆脱了传统的方法，使系统开发的时间、费用大大地减少，效率、技术等方面都大大地提高[ 缺点] 1) 开发工具要求高2) 解决复杂系统和大系统困难[ 适用范围] 适合于：处理过程明确、简单系统；涉及面窄的小型系统。 C 面向对象方法(Object Oriented,简称OO方法)概念从面向对象的角度为人们认识事物和开发系统提供了一种全新的方法。[ 基本思想]客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态和运动规律，不同对象之间的相互作用和联系就构成了各种不同的系统。[ 缺点]面向对象开发大的信息系统时，一开始就采用自底向上的面向对象开发方法，容易造成系统结构的不合理，因此，面向对象开发方法一般和生命周期法结合应用。 基本思想：是分析和解决问题的新方法，其基本出发点就是尽可能按照人类认识世界的方法和思维方式来分析和解决问题。[ 优点]：1分析、设计中的对象和软件中的对象的一致性2实现软件复用，简化程序设计3系统易于维护4缩短开发周期[ 适用范围]：多媒体系统和复杂系统 三、常用的管理信息系统的开发方式有那些 1.自主开发方式：是组织依靠自身的力量独立开发管理信息系统的一种方式。 2.委托开发方式：是指使用单位（甲方）委托有丰富开发经验的机构或专业开发人员（乙方），按照用户的需求承担系统开发的任务。 3.合作开发方式：是指由使用单位（甲方）和有丰富开发经验的机构或专业开发人员（乙方）共同完成开发任务。 4.利用现成的软件包开发：软件的开发正在向专业化发展 5.信息系统外包
1.简述“开—闭”原则的基本思想。请举出一个使用了软件“开—闭”原则的软件设计模式，其中何处体现了“开—闭”原则。 答：“开—闭”原则：软件实体应当对扩展开放，而对修改关闭，“开-闭”原则要求软件系统能够在不需要修改原有类的基础上，通过增加类达到扩展功能的目的。 Abstract factory体现了这个原则，如果想增加一类新的products，只需在product类体系中增加各个products，然后在factory类体系结构中增加一个concrete factory就可以了，而不需要对现有类做任何修改，The Open-closed principle[ocp]在不改动过模块源代码的情况下扩展模块的行为。 软件实体（类模块函数等）应该是可以扩展的，但是不可以修改的。 2.简述依赖例转原则的基本思想。请举出一个使用了软件依赖原则的软件设计模式，其中何处体现了依赖原则。 答：依赖倒置原则的基本思想是：①高层模块不应该依赖于低层模块，二者都应该依赖于抽象。②抽象不应该依赖于细节，细节应该不依赖于抽象。Tomplate method就体现了这个原则，它定义了一个操作中的算法骨架，而将一些步骤延迟到子类中，template method使得子类不改变一个算法的结构，即可重定义该算法的某些特定步骤。 3.什么是单一职责原则？请举出一个使用了单一职责原则的软件设计模式，其中何处体现了单一职责原则。 答：基本思想：SRP使得一个类或一个模块承担的责任尽可能的少，使尽可能少的因素或动机影响该类或该模块，即增大类或模块的内聚性，减少其耦合度，SRP 是所有原则中最简单的之一，也是最难正确运用的之一。 COMMAND模式体现了SRP原则，大多数类都是一组方法和相应的一组变量的结合，而该模式只是封装了一个没有任何变量的函数，它对函数的关注超过了类，将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化。 4.软件复用可采用类的继承方式和类的聚合方式，比较两者的优缺点。 答：聚合：一个对象拥有另一个对象或对另一个对象负责（即一个对象包含另一个对象或是另一个对象的一部分）并且聚合对象和其所有具有相同的生命周期（即所谓的“同生共死”关系）。 聚合复用优点：①容器类仅能通过被包含对象的接口来对其进行访问。②“黑盒”复用，因为被包含对象的内部细节对外是不可见。③包装性好。④实现上的相互依赖性比较小。⑤每一个类只专注于一项任务。⑥通过获取指定其他的具有相同类型的对象的使用，可以在运行期间动态地定义（对象的）组合。 聚合的缺点：①导致系统中的对象过多②为了能将多个不同的对象作为组合块来使用，必须仔细地对接口进行定义。 类继承：是一种通过扩展（一个已有对象的）实现，从而获得新功能的复用方法。继承的优点：①容易进行新的实现，因为其大多数可继承而来②易于修改或扩展那些被复用的实现。 继承的缺点：①破坏了封装性，因为这会将父类的实现细节暴露给子类②“白盒”复用，因为父类的内部细节对于子类而言通常是可见的③当父类的实现更
完整交互设计的基本原则： 1.美学 1)美术设计应该留给那些受过正规训练的有足够技术能力的图形或视觉设计师 2)设计潮流应该先考虑可用性 3)像测试交互设计一样也要对视觉设计进行测试 4)保持一致性 5) 2.预知需求 1）在用户达成目标的每一步都把所有必要的信息和工具带给用户 3.用户自主 1）不管是硬件环境还是软件环境都应该属于用户，但是这不是说用户自主控制就意味着我们要放任这个规则 2）让人们自主做出决定，尽管有些用户没有好的审美或者行为并不高效 3）一步步实践来提供给用户恰当的控制 4） 4.链接的触发机制 1）设备状态让用户可知 2）让状态信息保持及时更新并且容易看到 3）确保状态信息是精确的 4） 5.颜色 1)在用户界面设计中你想通过颜色传达信息时，你应该也要使用第二个线索来给那些不能 准确看清楚颜色的用户传达清楚信息。 2)测试一下你的网站去看一看色盲用户眼中你的网站是什么样子 3)不要因为不是每个用户都能看清楚每个颜色而避免在界面中使用颜色 4)在用户界面中不要因为一时的时尚潮流完全不用颜色或者使用大量的颜色线索 6.一致性 1)按照等级的不同维持严格的一致性 2)平台一致性和内部产品的一致性 3)系列产品的一致性 4)应用的欢迎屏、首页等设计元素的总体的视觉一致性 5)小的可见的结构元素一致性 6)不可见的产品元素的一致性 7)用户行为的响应 7.不一致性 1)就像当元素行为一样时视觉一致一样当元素行为不同时保持视觉不一致也是极其重要 的 2) 8.连续性 1)经过一段时间，追求连续性而不是一致性 2) 9.用户期待的一致性 10.默认 1)输入框中字段的默认行为
软件设计的原则 这些原则，每一个程序员都应该了解。但是请不要教条主义，在使用的时候还是要多多考虑实际情况。其实，下面这些原则，不单单只是软件开发，可以推广到其它生产活动中，甚至我们的生活中。 AD： 以前本站向大家介绍过一些软件开发的原则，比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识，正如我在《再谈“我是怎么招聘程序”》中所说的，一个好的程序员通常由其操作技能、知识水平，经验层力和能力四个方面组成。在这里想和大家说说设计中的一些原则，我认为这些东西属于长期经验总结出来的知识。这些原则，每一个程序员都应该了解。但是请不要教条主义，在使用的时候还是要多多考虑实际情况。其实，下面这些原则，不单单只是软件开发，可以推广到其它生产活动中，甚至我们的生活中。 Don’t Repeat Yourself (DRY) DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。 参考：https://www.doczj.com/doc/3b15819369.html,/wiki/Don%27t_repeat_yourself Keep It Simple, Stupid (KISS) KISS原则在设计上可能最被推崇的，在家装设计，界面设计，操作设计上，复杂的东西越来越被众人所BS了，而简单的东西越来越被人所认可，比如这些UI的设计和我们中国网页（尤其是新浪的网页）者是负面的例子。“宜家”（IKEA）简约、效率的家居设计、生产思路；“微软”（Microsoft）“所见即所得”的理念；“谷歌”（Google) 简约、直接的商业风格，无一例外的遵循了“kiss”原则，也正是“kiss”原则，成就了这些看似神奇的商业经典。而苹果公司的iPhone/iPad 将这个原则实践到了极至。 把一个事情搞复杂是一件简单的事，但要把一个复杂的事变简单，这是一件复杂的事。 参考：https://www.doczj.com/doc/3b15819369.html,/wiki/KISS_principle Program to an interface, not an implementation 这是设计模式中最根本的哲学，注重接口，而不是实现，依赖接口，而不是实现。接口是抽象是稳定的，实现则是多种多样的。以后面我们会面向对象的SOLID原则中会提到我们的依赖倒置原则，就是这个原则的的另一种样子。还有一条原则叫 Composition over inheritance（喜欢组合而不是继承），这两条是那23个经典设计模式中的设计原则。 Command-Query Separation (CQS) –命令-查询分离原则
软件开发基本原则（一）—— 策略和因素 1 概述 时间 -- 成本 -- 质量（或特性）是评价软件项目成败的三个关键指标，这三个指标之间相互影响和制约，形成了所谓的“项目管理三角形”。要提高质量或增加特性意味着成本和时间的增加，或两者都增加；要在时间不变的前提下缩减开发成本或成本不变的前提下缩减时间则意味着质量的下降或特性的削减。 图 1-1 项目管理三角形 上述分析其实只是理论上的“理想平衡”状态。现实工作中往往出现的情形是：要么时间超过计划，要么成本超过预算，要么质量达不到要求，要么三个指标都达不到预期。 典型例子： 由于客户的压力需要尽量缩减开发时间，由于企业间的竞争和盈利压力需要尽量节约成本，因此需要一个人做两个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审和项目会议等活动。可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。更糟糕的还在后面：由于质量的低劣，构建阶段结束后对系统进行集成测试时，很多问题就会暴露出来：对某些需求的理解有误差，导致这部分功能要重新分析、设计、编码和测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的Bug；沟通不畅顺导致模块接口不兼容……从而项目被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个项目谈虎色变。 软件开发项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。 2 策略和因素 2.1 总体策略 要避免混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发： 1、避免典型错误
软件产品可以被看作是由一系列具有特定功能的组件组成，作为一个完整的系统也可以被分解成一系列功能模块，这些模块之间的相互作用就形成了系统的所有功能。 所谓模块是指可组成系统的、具有某种确定独立功能的半自律性的子系统，可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统。每个模块的研发和改进都独立于其他模块的研发和改进，每个模块所特有的信息处理过程都被包含在模块的内部，如同一个“黑箱”，但是有一个或数个通用的标准界面与系统或其他模块相互连接。 在软件的模块化开发过程中，把一个源代码的结构分割成一个元系统和一系列的模块。 元系统指的是一个能够保持系统运转的最小的系统。 模块是一个较大系统的独特的部件，它能够由设计者独立设计出来，同时又可以作为一个整体在系统中运转。 把一个大系统切割成互相独立的不同的小系统，可以使一些并不是经常见面的开发者减少必要的交流次数。
另外，一个旧版本的模块可以被新版的模块所替换，同时却又不影响整个系统的运转。 这样，在新模块中所增加的功能就可以及时在现存的系统中体现出来，同时也不需要更改系统中的其他模块。 高度模块化的源代码结构给软件开发者和使用者均带来了极大的好处。 开发者可以对具有某种特定功能的模块进行独立开发而不需要花时间去协调与其他模块之间的关系。 并且模块化开发不仅允许模块之间的水平开发，而且可以通过对类似模块之间的创新和竞争(开发新的模块或者对原有的模块进行改进)充分改善系统的功能。 另外，作为最终的用户来说，在安装系统的时候可以就个人的需求与偏好选择适合自己的模块。 模块化是复杂系统的一个共同特征，模块化的代码结构是由松散的组件构成的，是对一个系统完全意义上的分割，而不像完全集成的代码，各个组件之间存在很强的依赖关系，并不是完全通过界面来交换信息。 总结： 第一，把一个系统分解成各个不同的子模块，不同的开发者专注于对其中某一模块的开发，一方面实现了劳动的分工，另一方面也提高了自由软件开发的效率。基于模块化的性质，每个模块在开发出来以后都可以通过一个被称作是内核的原系统进行信息交流，发挥整个模块的功能，同时也并不会影响其他模块功能的发挥。而且在各个不同的模块整合在一起后，由于外部性的存在，会使整个系统增加的功能要超过该模块本身的功能。在此过程中实现了价值的分割与整合。
一、网络系统结构与设计的基本原则 1.1局域网（Local Area Network, LAN）按照采用的技术、应用的范围和协议标准不同分为共享局域网与交换局域网 1.2局域网特点： 1.覆盖有限的地理范围 2.提供高数据传输速率（10Mbps-10Gbps）、低误码率的高质量数据传输环境 3.成本低，易于建立、维护和扩展 1.3计算机网络从逻辑功能上分为：资源子网和通信子网 1.4主机（host）包括用户终端设备（个人计算机、数字设备）、服务器，是资源子网的主要组成单元 1.5资源子网： 组成：主计算机系统、终端、终端控制器、连网外部设备、各种软件资源、网络服务 功能：负责全网的数据处理业务、向网络用户提供各种网络资源和网络服务1.6通信子网： 组成：通信控制处理机、通信线路、其他通信设备 功能：完成网络数据传输、转发等通信处理任务 1.7通信控制处理机：在网络拓扑结构中成为网络结点 1.作为与资源子网的主机、终端的连接接口，将主机和终端连入网络 2.作为通信子网中的分组存储转发结点，完成分组的接收、校验、存储、转发等功能，实现将源主机报文准确发送到目的主机的作用 1.8通信线路：通信控制处理机与通信控制处理机、通信控制处理机与主机之间提供通信信道，计算机网路采用多种通信线路，如电话线、双绞线、同轴电缆、光纤、无线通信信道、微波与卫星通信信道等 1.9局域网与城域网（Metropolitan Area Network，MAN）、城域网与广域网（Wide Area Network，WAN）、广域网与广域网的互联是通过路由来实现的 1.10介入城域网方式：局域网、电话交换网（PSTN）、有线电视网（CATV）、无线城域网（WMAN）、无线局域网（WLAN） 1.11广域网的基本概念： 1.广域网建设投资大、管理困难，一般由电信运营商负责组建与维护 2.电信运营商提供接入广域网的服务与技术，为用户提供高质量的数据传输服务，因此广域网是一种公共数据网络（Public Date Network，PDN） 3.用户可以在公共数据网络商开发各种网络服务系统，用户使用广域网的服务必须向广域网运营商购买服务 1.12广域网技术主要研究的是远距离、宽带、高服务质量的核心交换技术 1.13广域网发展: 1.早期,人们利用电话交换网PSTN的模拟信道,使用调制解调器完成计算机与计算机之间的低速数据通信 2.1974年X．25分组交换网出现 3.随着光纤开始应用,一种简化的X．25协议的网络：帧中继（Frame Replay，FR）网得到广泛应用 4.数字数据网DDN是一种基于点-点连接的窄带公共数据网 5.异步传输模式（Asynchronous Transfer Mode，ATM）网将语音与数据的传输放在一个网络中完成，并且覆盖从局域网到广域网的整个领域，但这条路线是不
面向对象七大基本设计原则 面向对象设计原则是OOPS（Object-Oriented Programming System，面向对象的程序设计系统）编程的核心。在设计面向对象的程序的时，模式不是一定要套的，但是有一些原则最好是遵守。这些原则已知的有七个，包括：单一职责原则、开闭原则、里氏代换原则、依赖注入（倒转）原则、接口分离原则、迪米特原则、合成聚合复用原则。 原则一单一职责原则 单一职责原则（SRP：Single responsibility principle）又称单一功能原则 核心：解耦和增强内聚性（高内聚，低耦合）。 描述：类被修改的几率很大，因此应该专注于单一的功能。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题。 原则二里氏替换原则 里氏替换原则（LSP：Liskov Substitution Principle） 核心：在任何父类出现的地方都可以用他的子类来替代（子类应当可以替换父类并出现在父类能够出现的任何地方） 四层含义： （1）子类必须完全实现父类的方法。在类中调用其他类是务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。 （2）子类可以有自己的个性。子类当然可以有自己的行为和外观了，也就是方法和属性 （3）覆盖或实现父类的方法时输入参数可以被放大。即子类可以重载父类的方法，但输入参数应比父类方法中的大，这样在子类代替父类的时候，调用的仍然是父类的方法。即以子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松。 （4）覆盖或实现父类的方法时输出结果可以被缩小。 原则三依赖注入原则 依赖注入原则（DIP：Dependence Inversion Principle）别名：依赖倒置原则或依赖反转原则 核心：要依赖于抽象，不要依赖于具体的实现 三层含义： （1）高层模块不应该依赖低层模块，两者都应该依赖其抽象（抽象类或接口）；（2）抽象不应该依赖细节（具体实现）；