给我们回顾一下 这些条件。让咱们想起一下 这些标准。

     最近有人问我
系统规划之尺度,事实上无论今天逐一技术栈怎么演化,那些本质的基准以及法无会见变换,
让咱们回忆一下 这些规范:

Simplicity (KISS)

     The most important principle is keeping things simple.
简单是软件设计的目标,简单的代码占用时间掉,漏洞少,并且爱修改。Simplicity
should be your northern star, your compass, and your long-term
commitment. Keeping software simple is difficult because it is
inherently relative. There is no standardized measurement of
simplicity, so when you judge what is simpler, you need to first ask
yourself for whom and when. For example, is it simpler for you or for
your clients? Is it simpler for you to do now or maintain in the
future?

不及耦合原则(Minimize Coupling)

      
代码的旁一个片段该压缩对任何区域代码的指关系。尽量不要使用共享参数。低耦合往往是一揽子结构体系及可观设计的标志

Designing for scale      Designing for scale is a difficult art, and each technique
described in this section comes with some costs. As an engineer, you
need to make careful tradeoffs between endless scalability and the
practicality of each solution. To make sure you do not over engineer
by preparing for scale that you will never need, you should first
carefully estimate the most realistic scalability needs of your system
and design accordingly.
Design for Self-Healing
    
The final design principle in this chapter is designing
software for high availability and self-healing. A system is
considered to be available as long as it performs its functions as
expected from the client’s perspective. It does not matter if the
system is experiencing internal partial failure as long as it does not
affect the behavior that clients depend on. In other words, you want
to make your system appear as if all of its components were
functioning perfectly even when things break and during maintenance
times.
Designing For Failure
    
Each application component must be deployed across redundant
cloud components, ideally with minimal or no common points of
failure
      Each application component must make no assumptions about the
underlying infrastructure—it must be able to adapt to changes in the
infrastructure without downtime
      Each application component should be partition tolerant—in other
words, it should be able to survive network latency (or loss of
communication) among the nodes that support that component
      Automation tools must be in place to orchestrate application
responses to failures or other changes in the infrastructure

有心人回想现在个的系统平台,框架,组件,工程措施,都至少含有有地方的统筹思想以及规则。可能还有遗漏之,后续补。


可用性:
一个网站的健康运行时对群局的声望和运作都是关键的。对于有更怪之在线零售站点,几分钟的匪可用都见面导致数千或数百万美元的营收损失,因此系统规划得能够不断服务,并且会高效于故障中回复是技术和作业的极致核心要求。分布式系统中的高可用性需要密切考虑关键部件的冗余,从局部系统故障中快速复原,以及问题来时优雅降级。
性能:
对于多数站点而言,网站的性已化作一个关键的考虑要素。网站的进度影响在下和用户满意度,以及查找引擎排名,与营收和是否会留住用户直接相关。因此,创建一个对准高速响应和低顺延进行优化的网充分重要。
可靠性:
系统要是可靠的,这样平等数量要才见面尽返回相同的数码。数据易或更新之后,同样的求虽应当回到新的多寡。用户应明了一点:如果东西写副了系,或者抱存储,那么其见面持久化并且肯定保持无变换以便将来开展查找。
可扩展性:
对于另外大型分布式系统而言,大小(size)只是内需考虑的框框(scale)问题的一个面。同样要之是大力去增强处理又怪负荷的力量,这便给号称系统的只是扩展性。可扩展性以体系的重重例外参数为参考:能够处理多少额外流量?增加存储容量有差不多善?能够处理多少再多之业务?
可管理性:
系统规划得爱运维是另外一个着重之考虑要素。系统的可管理性等价于运维(维护及换代)的而是扩展性。对于可管理性需要考虑的是:问题产生常轻诊断及晓,便于更新或涂改,系统运维起来何等简单(例如:常规运维是否非见面掀起失败或生?)
成本:
成本是一个关键元素。很显著这包括硬件和软件成本,但也只要考虑系统安排及护卫这单。系统构建所花的开发者时间,系统运作所急需之运维工作量,以及培养工作都应当考虑进来。成本是有着系统的终究财力。

大规模web系统规划之有些为主标准:

软件设计 中 SOLID原则

Keep design patterns consistent within each layer. Within a
logical layer, where possible, the design of components should be
consistent for a particular operation. For example, if you choose to
use the Table Data Gateway pattern to create an object that acts as a
gateway to tables or views in a database, you should not include
another pattern such as Repository, which uses a different paradigm
for accessing data and initializing business entities. However, you
may need to use different patterns for tasks in a layer that have a
large variation in requirements, such as an application that contains
business transaction and reporting functionality.
Do not duplicate functionality within an application. There should
be only one component providing a specific functionality—this
functionality should not be duplicated in any other component. This
makes your components cohesive and makes it easier to optimize the
components if a specific feature or functionality changes. Duplication
of functionality within an application can make it difficult to
implement changes, decrease clarity, and introduce potential
inconsistencies.
Prefer composition to inheritance. Wherever possible, use
composition over inheritance when reusing functionality because
inheritance increases the dependency between parent and child classes,
thereby limiting the reuse of child classes. This also reduces the
inheritance hierarchies, which can become very difficult to deal
with.
Establish a coding style and naming convention for development.
Check to see if the organization has established coding style and
naming standards. If not, you should establish common standards. This
provides a consistent model that makes it easier for team members to
review code they did not write, which leads to better
maintainability.
Maintain system quality using automated QA techniques during
development.
Use unit testing and other automated Quality Analysis
techniques, such as dependency analysis and static code analysis,
during development. Define clear behavioral and performance metrics
for components and sub-systems, and use automated QA tools during the
build process to ensure that local design or implementation decisions
do not adversely affect the overall system quality.
Consider the operation of your application. Determine what metrics
and operational data are required by the IT infrastructure to ensure
the efficient deployment and operation of your application. Designing
your application’s components and sub-systems with a clear
understanding of their individual operational requirements will
significantly ease overall deployment and operation. Use automated QA
tools during development to ensure that the correct operational data
is provided by your application’s components and sub-systems.

而发思打听又多软件设计与架构, 系统IT,企业信息化, 团队保管
资讯,请关注本身之微信订阅号:

遗留下来 就可以围绕 ISO 9126色型:软件质量型的6深特征和27只子特性
来展开系统规划及分析,度量, 他们是:

密切回想现在各的体系平台,框架,组件,工程措施,都至少含有有上面的计划思想及规则。可能还有遗漏之,后续补。

剩下来 就足以绕 ISO 9126质地型:软件质量模型的6百般特色以及27只子特性
来进行系统规划以及析,度量, 他们是:

•分散关注 Separation of concerns. Divide your application into
distinct features with as little overlap in functionality as possible.
The important factor is minimization of interaction points to achieve
high cohesion and low coupling. However, separating functionality at
the wrong boundaries can result in high coupling and complexity
between features even though the contained functionality within a
feature does not significantly overlap.
不同领域的功效,应该由不同的代码和最好小重迭的模块组成。

•单一任务,功能强内聚 Single Responsibility principle. Each
component or module should be responsible for only a specific feature
or functionality, or aggregation of cohesive functionality.

•一个模块不待理解其他一个模块的里边细节 Principle of Least Knowledge
(also known as the Law of Demeter or LoD).
A component or object
should not know about internal details of other components or
objects.

•Don’t repeat yourself (DRY). You should only need to specify
intent in one place. For example, in terms of application design,
specific functionality should be implemented in only one component;
the functionality should not be duplicated in any other component.

•不要过度设计过多模块 Minimize upfront design. Only design what is
necessary. In some cases, you may require upfront comprehensive design
and testing if the cost of development or a failure in the design is
very high. In other cases, especially for agile development, you can
avoid big design upfront (BDUF). If your application requirements are
unclear, or if there is a possibility of the design evolving over
time, avoid making a large design effort prematurely. This principle
is sometimes known as YAGNI (“You ain’t gonna need it”).

有的设计的尽


每当互联网系下发出的一对尺度

1.避免单点故障:任何事物还使产生个别个。这多了血本与复杂度,但却能够当可用性和负载性能及收入。而且,这促进设计者采用相同种植分布式优先的思量。可(异地)部署及就地路由于连接,破除单点故障;可分布,可调度的标准

2.横往扩展,而未是纵向扩展:升级服务器(纵向)的财力是指数提高的,而充实其它一样高商用服务器(横向)的资产是线性增长的。
3.尽量减少应用程序核心所用完成的劳作。

4.API优先:将应用程序视为一个供API的服务,而且,不若服务之客户端类型(手机应用、Web站点、桌面应用程序)。

5.提供尽可能新的多少:用户可能无欲立即看到最新的数据,最终一致性可以带动重新胜之可用性。
6.规划时假如考虑保护及自动化:不要低估应用程序维护所待的日子以及工作量。软件首次等公开宣布是一个值得称赞的里程碑,但也表明在真正的行事而从头了。
7.吧故障做好准备:将故障对顶用户的熏陶最为小化。
8.数据报告及监理平台;
用户作为数据,系统性能监控数据,系统特别和事务有关数据等之举报
9.数据分级存储原则:单内存cache存储,内存cache+异步更新,内存cache+同步更新;
从今三只纬度分析用户作为模型,决定有关数据的蕴藏策略:1),能忍受用户数量的不见为?2),能经得住多少的无及时性吗?
3),数据的读写比例分布如何?
10.状况分离原则;
会静态化尽量静态化,在代码和经过部署达成,在DNS层上搞活气象分离的体系规划准备
11.轻重别离原则;
维持衔接和事情处理的分开,接入尽量轻量化,使得系统所有特别好之吞吐量,处理尽量异步化,使得可以平滑扩展
12.
脱服务因原则:同一IDC的其余服务对网的震慑,第三正值调用系统接口的隔断和过载保护,依赖第三在服务之督查以及安康维护标准等。
13.柔性可用原则;
拍卖好异常情况下之灰度体验,区分好要处理途径和未要路径,而系统规划而硬着头皮将重大路径转换成为不重点路径
14.异步化,能异步的尽心异步原则;
由此内存管道,操作流水等技巧拓展拼接各个处理模块
15.灰度尺码;
灰度发布政策是根据用户号码段,用户ip段,还是用户vip等级,用户所在城市等进行灰度升级,保证系统的坦迭代
16.分外的敏捷响应与一键切换原则;
IDC断电?系统切换到正常的血本是略?时间吧?需要几只人操作?牛的体系可以一个总人口以治本后台按一个按钮就可以切换,再遵照一下即便得切换回来
17.出重伤服务标准化;
从而没有本钱提供海量的劳动条件
18.充分利用DNS层做好系统的可分布设计
19.区分开网作为及用户作为并各自展开设计,甚至在关键时刻可以进行转换。
20.努力实现无状态:状态信息若保存在尽可能少的地方,而且要保留于专门计划的组件中。坚持app_server设计的任状态统筹基准,转变用户作为为系统作为,使得app_server具有不管状态的特性
21.多层cache设计及各个cache的路由设计
22.“大系统小开”原则  
23.强工作型到终极一致性事务型的转换原则
24.尽可能拆分
25.劳动架构“去中心化”
26.数据化运营
27.尽可能使用成熟组件
28.尽可能自动化

Simplicity (KISS)

     The most important principle is keeping things simple.
简单是软件设计的对象,简单的代码占用时间掉,漏洞少,并且爱修改。Simplicity
should be your northern star, your compass, and your long-term
commitment. Keeping software simple is difficult because it is
inherently relative. There is no standardized measurement of
simplicity, so when you judge what is simpler, you need to first ask
yourself for whom and when. For example, is it simpler for you or for
your clients? Is it simpler for you to do now or maintain in the
future?

亚耦合原则(Minimize Coupling)

      
代码的旁一个局部该压缩对其它区域代码的指关系。尽量不要使用共享参数。低耦合往往是一揽子结构体系及良设计的标志

Designing for scale      Designing for scale is a difficult art, and each technique
described in this section comes with some costs. As an engineer, you
need to make careful tradeoffs between endless scalability and the
practicality of each solution. To make sure you do not over engineer
by preparing for scale that you will never need, you should first
carefully estimate the most realistic scalability needs of your system
and design accordingly.
Design for Self-Healing
    
The final design principle in this chapter is designing
software for high availability and self-healing. A system is
considered to be available as long as it performs its functions as
expected from the client’s perspective. It does not matter if the
system is experiencing internal partial failure as long as it does not
affect the behavior that clients depend on. In other words, you want
to make your system appear as if all of its components were
functioning perfectly even when things break and during maintenance
times.
Designing For Failure
    
Each application component must be deployed across redundant
cloud components, ideally with minimal or no common points of
failure
      Each application component must make no assumptions about the
underlying infrastructure—it must be able to adapt to changes in the
infrastructure without downtime
      Each application component should be partition tolerant—in other
words, it should be able to survive network latency (or loss of
communication) among the nodes that support that component
      Automation tools must be in place to orchestrate application
responses to failures or other changes in the infrastructure

•分散关注 Separation of concerns. Divide your application into
distinct features with as little overlap in functionality as possible.
The important factor is minimization of interaction points to achieve
high cohesion and low coupling. However, separating functionality at
the wrong boundaries can result in high coupling and complexity
between features even though the contained functionality within a
feature does not significantly overlap.
不同世界的职能,应该由不同的代码和极小重迭的模块组合。

•单一任务,功能强内聚 Single Responsibility principle. Each
component or module should be responsible for only a specific feature
or functionality, or aggregation of cohesive functionality.

•一个模块不欲了解其他一个模块的里边细节 Principle of Least Knowledge
(also known as the Law of Demeter or LoD).
A component or object
should not know about internal details of other components or
objects.

•Don’t repeat yourself (DRY). You should only need to specify
intent in one place. For example, in terms of application design,
specific functionality should be implemented in only one component;
the functionality should not be duplicated in any other component.

•不要过分设计了多模块 Minimize upfront design. Only design what is
necessary. In some cases, you may require upfront comprehensive design
and testing if the cost of development or a failure in the design is
very high. In other cases, especially for agile development, you can
avoid big design upfront (BDUF). If your application requirements are
unclear, or if there is a possibility of the design evolving over
time, avoid making a large design effort prematurely. This principle
is sometimes known as YAGNI (“You ain’t gonna need it”).

Keep design patterns consistent within each layer. Within a
logical layer, where possible, the design of components should be
consistent for a particular operation. For example, if you choose to
use the Table Data Gateway pattern to create an object that acts as a
gateway to tables or views in a database, you should not include
another pattern such as Repository, which uses a different paradigm
for accessing data and initializing business entities. However, you
may need to use different patterns for tasks in a layer that have a
large variation in requirements, such as an application that contains
business transaction and reporting functionality.
Do not duplicate functionality within an application. There should
be only one component providing a specific functionality—this
functionality should not be duplicated in any other component. This
makes your components cohesive and makes it easier to optimize the
components if a specific feature or functionality changes. Duplication
of functionality within an application can make it difficult to
implement changes, decrease clarity, and introduce potential
inconsistencies.
Prefer composition to inheritance. Wherever possible, use
composition over inheritance when reusing functionality because
inheritance increases the dependency between parent and child classes,
thereby limiting the reuse of child classes. This also reduces the
inheritance hierarchies, which can become very difficult to deal
with.
Establish a coding style and naming convention for development.
Check to see if the organization has established coding style and
naming standards. If not, you should establish common standards. This
provides a consistent model that makes it easier for team members to
review code they did not write, which leads to better
maintainability.
Maintain system quality using automated QA techniques during
development.
Use unit testing and other automated Quality Analysis
techniques, such as dependency analysis and static code analysis,
during development. Define clear behavioral and performance metrics
for components and sub-systems, and use automated QA tools during the
build process to ensure that local design or implementation decisions
do not adversely affect the overall system quality.
Consider the operation of your application. Determine what metrics
and operational data are required by the IT infrastructure to ensure
the efficient deployment and operation of your application. Designing
your application’s components and sub-systems with a clear
understanding of their individual operational requirements will
significantly ease overall deployment and operation. Use automated QA
tools during development to ensure that the correct operational data
is provided by your application’s components and sub-systems.

假定发生想念打听再多软件设计与架构, 系统IT,企业信息化, 团队保管
资讯,请关注自己的微信订阅号:

     最近有人提问我
系统规划之条件,事实上无论今天逐一技术栈怎么演化,那些本质的尺度以及措施无会见转移,
让我们回忆一下 这些极:

于互联网系下起的片法

可用性:
一个网站的常规运转时对群店的声誉和运作都是要的。对于有些还甚之在线零售站点,几分钟的免可用都见面造成数千或者数百万美元的营收损失,因此系统规划得会不断服务,并且能快速于故障被恢复是技术和工作的太核心要求。分布式系统中的高可用性需要细致考虑关键部件的冗余,从部分系统故障中疾复原,以及问题发出时优雅降级。
性能:
对于大多数站点而言,网站的习性已经成一个重要之考虑要素。网站的快慢影响在以以及用户满意度,以及查找引擎排名,与营收和是否能留给用户直接相关。因此,创建一个针对性速响应和没有顺延进行优化的系颇重大。
可靠性:
系统要是保险的,这样平等数量要才会一直返回相同的数。数据易或更新之后,同样的呼吁虽应该回到新的数额。用户应懂得一点:如果东西写副了系统,或者抱存储,那么它们见面持久化并且肯定保持无换以便将来进展搜。
可扩展性:
对于其它大型分布式系统而言,大小(size)只是待考虑的范畴(scale)问题的一个地方。同样至关重要之是努力去增强处理又甚负荷的能力,这通常为号称系统的而是扩展性。可扩展性以体系的洋洋不等参数为参考:能够处理多少额外流量?增加存储容量有差不多爱?能够处理多少再多之事体?
可管理性:
系统规划得好运维是其余一个首要之考虑要素。系统的可管理性等价于运维(维护与翻新)的而扩展性。对于可管理性需要考虑的是:问题时有发生时好诊断与领悟,便于更新或改动,系统运维起来何等简单(例如:常规运维是否非见面吸引失败或很?)
成本:
成本是一个主要元素。很肯定这包括硬件及软件成本,但也使考虑系统布局和维护这一边。系统构建所花费的开发者时间,系统运行所要的运维工作量,以及陶铸工作还应考虑进来。成本是怀有系统的究竟财力。

一、功能性:
1、适合性:提供了对应的功能
2、准确性:正确(用户用的)
3、互操作性:产品跟活里面相数据的能力
4、保密安全性:允许通过授权的用户与体系能健康的顾相应的数量和消息,禁止未授权的用户访问…….
5、功能性的依从性:国际/国家/行业/企业 标准规范一致性

第二、可靠性:产品于确定之法下,在规定之工夫外成功规定职能的力量
1、成熟性:防止内部错误导致软件失效的力量
2、容错性:软件出现故障,自我处理能力
3、易恢复性:失效情况下之过来能力
4、可靠性的依从性

老三、易用性:在指定使用条件下,产品被清楚、
学习、使用以及引发用户的能力
1、易理解性:
2、易学性:
3、易操作性:
4、吸引性:
5、易用性的依从性:

季、效率性:在确定台标准下,相对于所用资源的数据,软件出品而提供适当性的能力
1、时间特性:平均事务应时间,吞吐率,TPS(每秒事务数)
2、资源利用性:CPU 内存 磁盘 IO 网络带来宽 队列 共享内存
3、效率依从性:

五、软件维护性:”四规”,
在确定极下,规定的流年外,使用规定之工具或艺术修复规定职能的力
1、易分析性:分析定位问题的难易程度
2、易改变性:软件出品如果指定的改动得让实现之力
3、稳定性:防止意外修改导致程序失效
4、易 测试性:使曾经改软件会叫认可的力量
5、维护性的依从性

六、软件可移植性:从平种环境迁移到其它一样种植环境之能力
1、适应性:适应不同平台
2、易安装性:被设置之力量
3、共存性:
4、易替换性
5、可移植性的依从性:

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
正文版权归作者和博客园共有,欢迎转载,但未经作者同意要保留这个段子声明,且以篇章页面明显位置被起原文连接,否则保留追究法律责任的权。
欠篇也罢还要发布以自身的独立博客中-Petter Liu
Blog。

软件设计 中 SOLID原则

1.幸免单点故障:任何东西还设发出点儿独。这多了资产和复杂度,但可会于可用性和负载性能达到收入。而且,这有助于设计者采用同样栽分布式优先的构思。可(异地)部署与就地路由于连接,破除单点故障;可分布,可调度的规范

2.横向扩展,而未是纵向扩展:升级服务器(纵向)的本钱是指数提高的,而充实其它一样华商用服务器(横向)的本是线性增长之。
3.尽量减少应用程序核心所急需就的工作。

4.API优先:将应用程序视为一个资API的劳动,而且,不若服务的客户端类型(手机应用、Web站点、桌面应用程序)。

5.供尽可能新的数额:用户可能不欲及时看到最新的数据,最终一致性可以带动更胜似的可用性。
6.统筹时如考虑保护与自动化:不要低估应用程序维护所急需的时间和工作量。软件首蹩脚公开宣布是一个值得称赞的里程碑,但也表明在真正的劳作一经开始了。
7.为故障做好准备:将故障对极用户之影响最为小化。
8.数目报告与监察平台;
用户作为数据,系统性能监控数据,系统十分以及事情有关数据等之汇报
9.数目分级存储原则:单内存cache存储,内存cache+异步更新,内存cache+同步更新;
自三只纬度分析用户作为模型,决定有关数据的蕴藏策略:1),能经得住用户数量的少为?2),能经受多少的免及时性吗?
3),数据的读写比例分布如何?
10.情形分离原则;
克静态化尽量静态化,在代码和进程部署及,在DNS层上抓好气象分离的体系规划准备
11.轻重别离原则;
维持衔接和工作处理的诀别,接入尽量轻量化,使得系统具有十分好之吞吐量,处理尽量异步化,使得可以平滑扩展
12.
散服务因原则:同一IDC的旁服务对系统的熏陶,第三正调用系统接口的隔断和过载保护,依赖第三着服务的监控以及安康维护标准等。
13.柔性可用原则;
拍卖好异常情况下之灰度体验,区分好第一处理途径和免关键路径,而系统规划而尽可能将重大路径转换成为不要路径
14.异步化,能异步的玩命异步原则;
通过内存管道,操作流水等技能拓展拼接各个处理模块
15.灰度尺度;
灰度发布政策是依据用户号码段,用户ip段,还是用户vip等级,用户所在城市等开展灰度升级,保证系统的平迭代
16.可怜的神速响应和一键切换原则;
IDC断电?系统切换到正规的本金是稍稍?时间为?需要几单人操作?牛之体系可以一个人数当治本后台按一个按钮就足以切换,再以一下就得切换回来
17.闹重伤服务标准化;
从而没有本钱提供海量的服务条件
18.充分利用DNS层做好系统的不过分布设计
19.区瓜分网作为以及用户作为并分别开展统筹,甚至以关键时刻可以进行更换。
20.努力实现无状态:状态信息若保存在尽可能少的地方,而且要保存于特别规划之零件中。坚持app_server设计的凭状态统筹基准,转变用户作为呢系统作为,使得app_server具有无状态的风味
21.基本上级cache设计与各个cache的路由设计
22.“大体系小开”原则  
23.强作业型到最终一致性事务型的易原则
24.尽可能拆分
25.服务架构“去中心化”
26.数据化运营
27.尽可能使用成熟组件
28.尽可能自动化

一、功能性:
1、适合性:提供了相应的功力
2、准确性:正确(用户用之)
3、互操作性:产品与制品间交互数据的力
4、保密安全性:允许通过授权的用户以及系会正常的拜会相应的数码以及信息,禁止非授权的用户访问…….
5、功能性的依从性:国际/国家/行业/企业 标准规范一致性

次、可靠性:产品以规定之条件下,在规定的年华内就规定职能的能力
1、成熟性:防止内部错误致软件失效的力
2、容错性:软件出现故障,自我处理能力
3、易恢复性:失效情况下之复能力
4、可靠性的依从性

其三、易用性:在指定使用口径下,产品被清楚、
学习、使用及诱惑用户之力量
1、易理解性:
2、易学性:
3、易操作性:
4、吸引性:
5、易用性的依从性:

季、效率性:在规定台标准下,相对于所用资源的数目,软件出品只是资适当性的力量
1、时间特性:平均事务应时间,吞吐率,TPS(每秒事务数)
2、资源利用性:CPU 内存 磁盘 IO 网络带来宽 队列 共享内存
3、效率依从性:

五、软件维护性:”四规”,
在规定标准下,规定之辰内,使用规定之家伙要措施修复规定职能的能力
1、易分析性:分析定位问题的难易程度
2、易改变性:软件出品要指定的改好让实现的能力
3、稳定性:防止意外修改导致程序失效
4、易 测试性:使已经修改软件会叫确认之能力
5、维护性的依从性

六、软件可移植性:从同种植环境迁移至其他一样种环境的力
1、适应性:适应不同平台
2、易安装性:被设置的力
3、共存性:
4、易替换性
5、可移植性的依从性:

今日预到这时,希望对君于网架构设计与评估,团队管理, 项目管理, 产品管理
有参照作用 , 您可能感兴趣的文章:
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
信息网架构设计演进
互联网电商搜索架构演化之一
柜信息化以及软件工程的迷思
公司项目化管理介绍
软件项目成功的要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织及合作社
企业更新知识及等级观念
集团目标与个人目标
初创公司人才招聘和管理
浓眉大眼公司环境以及公司文化
庄文化、团队文化与学识共享
愈功能的团队建设
种类管理关系计划
构建便捷之研发及自动化运维
有大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络体系规划)
餐饮行业解决方案的客户分析流程
餐饮行业解决方案的贾战略制定以及实施流程
餐饮行业解决方案的务设计流程
供应链需求调研CheckList
企业应用之性质实时度量系统演化

有企划之实行

周边web系统规划之局部基本标准:

今先期到这,希望对您于系架构设计与评估,团队管理, 项目管理, 产品管理
有参照作用 , 您可能感兴趣的篇章:
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
消息网架构设计演进
互联网电商搜索架构演化之一
合作社信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织及商店
号更新文化与品级观念
社目标和个体目标
初创公司人才招聘和管理
红颜公司环境和商家文化
商厦文化、团队文化和知识共享
高功能的组织建设
类型管理挂钩计划
构建快捷的研发和自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络体系规划)
餐饮行业解决方案的客户分析流程
餐饮行业解决方案的贾战略制定与实践流程
餐饮行业解决方案的务设计流程
供应链需求调研CheckList
企业应用之性质实时度量系统演化

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
正文版权归作者和博客园共有,欢迎转载,但未经作者同意要保留这个段子声明,且当篇章页面明显位置于来原文连接,否则保留追究法律责任的权利。
拖欠篇为以发表在自我之单独博客中-Petter Liu
Blog。

相关文章