软件设计 中 SOLID原则

     近日有人问笔者系统规划的规范,事实上无论明天相继技术栈怎么演变,那几个本质的条件与情势不会变,
让我们回想一下 这一个标准:

•分散关心 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 德姆eter 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

软件设计 中 SOLID原则

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?

低耦合原则(迷你mize 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

一对统一筹划的实施

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.

在互连网系统下发出的局地标准

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.尽只怕自动化

周围web系统规划的一些中坚标准:

可用性:
多少个网址的健康运营时刻对于众多商家的声誉与运转皆以任重(英文名:rèn zhòng)而道远的。对于部分越来越大的在线零售站点,几分钟的不可用都会导致数千或数百万英镑的营业收入损失,因而系统规划得能够不断服务,并且能快速从故障中平复是本领和工作的最基本要求。分布式系统中的高可用性必要留神想念关键部件的冗余,从部分系统故障中飞速恢复生机,以及难点发出时优雅降级。
性能:
对于大多数站点来说,网址的习性已成为三个入眼的虚拟要素。网址的快慢影响着使用和用户满足度,以及查找引擎排行,与营收和是不是能留给用户一向有关。因而,制造一个对准高速响应与低顺延进行优化的系列丰硕关键。
可靠性:
系统必须是牢靠的,那样平等数量要求才会一贯重临一样的多少。数据调换或更新之后,一样的伸手则应该回到新的数据。用户应该清楚一点:假若东西写入了系统,只怕获得存储,那么它会漫长化並且分明保持不改变以便未来张开寻找。
可扩大性:
对于另外大型布满式系统来说,大小(size)只是亟需记挂的框框(scale)难题的一个方面。一样任重先生而道远的是竭力去巩固管理更加大负荷的力量,那常常被称作系统的可扩展性。可扩张性以类别的成都百货上千不一参数为参谋:能够管理多少额外流量?扩大存款和储蓄体积有多轻便?能够管理多少更加多的事情?
可管理性:
系统规划得轻松运行是另贰个重大的设想因素。系统的可处理性等价于运转(维护和翻新)的可扩张性。对于可管理性须要思量的是:难题发出时轻松会诊与明白,便于更新或修改,系统运行起来何等简单(比如:常规运转是不是不会抓住失利或特别?)
成本:
花费是多个第一成分。很驾驭那富含硬件和软件开销,但也要考虑系统布局和掩护这一边。系统营造所开销的开辟者时间,系统运作所急需的运转工作量,以及陶铸职业都应当考虑进来。开销是怀有系统的总财力。

剩下来 就足以围绕 ISO 9126材料模型:软件品质模型的6大特色和贰十七个子性情来进展系统规划与深入分析,衡量, 他们是:

一、功能性:
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
集团应用之性质实时衡量系统演化

如有想询问愈来愈多软件设计与架构, 系统IT,集团消息化, 团队保管
资源消息,请关心自身的微信订阅号:

图片 2

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和搜狐共有,迎接转载,但未经笔者同意必须保留此段注脚,且在文章页面显明地方给出原来的作品连接,不然保留追究法律义务的职分。
该作品也还要揭露在笔者的单独博客中-Petter Liu
Blog

相关文章