软件设计
文章平均质量分 87
华仔爱技术
精通C++、Java开语言,精通Linux平台相关开发技术,MySQL、Sphinx,熟悉各种互联网开源产品,如Nginx、Redis等,对系统分析和设计有丰富的经验
展开
-
为什么我说“设计模式”的设计理念是误人子弟?
很多人都学过设计模式,但是大部分人却被设计模式带偏了,乱用设计模式、滥用设计模式、炫技式的应用设计模式,把代码写的更乱了,原因不是23个设计模式本身有问题,而是设计模式背后的设计理念有问题。原创 2021-12-30 09:00:53 · 1119 阅读 · 1 评论 -
MTTR、MTBF、MTTF、可用性、可靠性傻傻分不清楚?
MTTR、MTBF、MTTF、可用性、可靠性的正确理解原创 2021-12-02 12:41:49 · 42043 阅读 · 8 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(18) - 用例分析
很多人在分析需求的时候,采用的是东扯葫芦西扯瓢的方式,列出了很多的需求点,但当你看完后,你还是不知道到底要干嘛!! ---- 写在前面原创 2014-03-17 10:17:48 · 5468 阅读 · 4 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(37) - 设计模式:瑞士军刀 or 锤子?
“设计模式”这个词几乎成为了软件设计的代名词,很多人非常天真的以为掌握了设计模式就掌握了软件设计,但实际上如果只是握了设计模式,软件设计的门都还没摸到!========================================================谈起设计模式,那是几乎无人不知,无人不晓,大名鼎鼎的“GOF”(中文有的翻译为“四人帮”)惊世之作,真是“平生不识GOF,学尽设计也枉然原创 2014-07-25 10:02:21 · 4664 阅读 · 2 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(32) - LSP原则
LSP,Liskov substitution principle,中文翻译为“里氏替换原则”。 这是面向对象原则中唯一一个以人名命名的原则,虽然Liskov在中国的知名度没有UNIX的几位巨匠(Kenneth Thompson、Dennis Ritchie)、GOF四人帮那么响亮,但查一下资料,你会发现其实Liskov也是非常牛的:2008年图灵奖获得者,历史上第一个女性计算机博士学位获得者。其原创 2014-05-24 09:43:46 · 4449 阅读 · 4 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(33) - ISP原则
ISP,Interface Segregation Principle,中文翻译为“接口隔离原则”。和DIP原则一样,ISP原则也是大名鼎鼎的Martin大师提出来的,他在1996年的C++ Reporter发表“ The Interface Segregation Principle”的文章详细阐述了ISP原则,并且在他的经典著作《 Agile Software Development, Pri原创 2014-05-30 17:37:05 · 4162 阅读 · 7 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(34) - DIP原则
DIP,dependency inversion principle,中文翻译为“依赖倒置原则”。 DIP是大名鼎鼎的Martin大师提出来的,他在1996 5月的C++ Reporter发表“ The Dependency Inversion Principle”的文章详细阐述了DIP原则,并且在他的经典著作《 Agile Software Development, Principles, Pa原创 2014-06-14 15:51:27 · 5185 阅读 · 2 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(35) - NOP原则
NOP,No Overdesign Priciple,不要过度设计原则。 这应该是你第一次看到这个原则,而且你也不用上网查了,因为这个不是大师们创造的,而是我创造的:) 之所以提出这个原则,是我自己吃过苦头,也在工作中见很多人吃过类似的苦头。 你可能也见过这样的场景:产品提出了一个需求,设计师眼光非常长远,他甚至把5年后可能的业务变化都提出来并且加以设计了,让你不得不佩服设计师的高瞻远瞩的眼光,并原创 2014-06-29 09:52:53 · 4079 阅读 · 2 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(36) - 设计原则如何用?
经过前面深入的阐述,SOLID的原则我们已经基本上讲清楚了,但如果想熟练的应用SOLID原则,仅仅知道SOLID是什么(what)还不够,我们还需要知道SOLID原则在什么时候和什么场景应用(when或where)。原创 2014-07-17 09:36:38 · 4099 阅读 · 0 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(40) - DECORATOR模式
掌握了设计模式之道后,我们将以全新的方法来理解设计模式,这个方法更简单、更直观,不信?看几个样例就知道了=====================================================================【业务】假设你进入了一个信息安全管理非常严格的公司,这家公司不允许员工自行打印文档,所有的文档打印都需要交给文档打印系统统一管理。文档打印系统会记录每次打印的原创 2014-08-27 10:10:05 · 4856 阅读 · 0 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(31) - OCP原则
OCP,Open-Closed Principle,中文翻译为“开闭原则”。 当我第一次看到OCP原则时,我的感觉就是这原则也太抽象了吧,什么开,什么闭呢? 然后我去寻找更加详细的答案,最经典也是最常见的解释就是维基百科了:http://en.wikipedia.org/wiki/Open/closed_principle "software entities (classes, modules,原创 2014-05-14 09:36:01 · 4393 阅读 · 4 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(29) - 高内聚低耦合
高内聚低耦合,可以说是每个程序猿,甚至是编过程序,或者仅仅只是在大学里面学过计算机,都知道的一个简单的设计原则。虽然如此流行和人所众知,但其实真正理解的人并不多,很多时候都是人云亦云。===============================================================要想真正理解“高内聚低耦合”,需要回答两个问题:1)为什么要高内聚低耦合?2)高内聚低耦合原创 2014-05-05 19:57:46 · 5730 阅读 · 0 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(24) - 设计模型
完成领域类到软件类的转换,这就是面向对象领域设计阶段的主要任务。经过领域模型的分析后,面向对象已经初具雏形,但领域类并不能指导我们进行编码工作,因为领域类只是从用例模型中提炼出来的反应业务领域的概念,而并不是真正意义上的软件类。 “革命尚未成功,同志还需努力”,我们需要再进一步,完成领域类到软件类的转换,这就是面向对象领域设计阶段的主要任务。 设计阶段是整个面向对象分析和设计的高潮阶段。在设计阶段原创 2014-04-10 16:01:52 · 5207 阅读 · 3 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(21) - SSD
用例图是用来描述系统的,而SSD(系统序列图)又是来描述用例的,oh my god,这不是在玩我们么?System Sequence Diagram,缩写为SSD(注意不要与SSD硬盘混淆),中文翻译为“系统顺序图”,主要用于描述某个用例的某个分支场景下,外部参与者与系统的交互过程。简单来说:SSD就是用例的可视化描述。 细心的朋友可能会发现,前面我们在介绍“用例方法”的时候说不需要画图,这里又说原创 2014-03-21 16:49:24 · 5208 阅读 · 10 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(27) - 动态模型设计
类模型指导我们如何声明类,动态模型指导我们如何实现类!动态模型设计一般都是在类模型设计完成后才开始,因为动态模型设计的时候一般都需要用到类模型中的类。相对类模型来说,动态模型要相对简单一些,主要原因在于动态模型设计的时候没有什么设计原则和设计模式需要应用,只需要对照用例模型,根据用例模型的特点,选取一个合适的动态模型将其表述出来即可。动态模型在实际开发过程中有非常重要的作用,简单来说,如果没有动态原创 2014-04-22 17:19:28 · 5464 阅读 · 19 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(30) - SRP原则
前面详细阐述了“高内聚低耦合”的总体设计原则,但如何让设计满足这个原则,并不是一件简单的事情,幸好各位前辈和大牛已经帮我们归纳总结出来了,这就是“设计原则”和“设计模式”。毫不夸张的说,只要你吃透这些原则和模式并熟练应用,就能够做出很好的设计。==================================================================【SRP原则详解】SRP原创 2014-05-08 09:55:40 · 4770 阅读 · 4 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(22) - 领域模型
领域模型是面向对象分析和设计的第一步!!完成了需求分析之后,我们已经有了一个良好的开端,但我们的主角“面向对象”还不见踪影。前面我们提到,需求分析和面向对象是没有直接关系的,需求分析阶段是不区分是面向对象还是面向过程,那么什么时候才真正开始面向对象的工作呢? 答案就在本章:领域建模。从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 领原创 2014-03-24 18:02:46 · 5632 阅读 · 3 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(25) - 类模型
面向对象设计和弹吉他差不多,有很多成熟的理论和技巧,学会弹吉他并不难,但要成为吉他高手或者大师,还是要靠个人天分!【师傅领进门,修行在个人】“类模型”是整个面向对象设计模型的核心,是面向对象设计阶段的主要输出,也是设计师们最能够发挥自己才能的地方。 虽然“类模型”如此重要,但面向对象设计技术经过几十年的发展后,目前已经形成了很成熟的一套体系,因此真正在进行“类模型”设计的时候,其实难度并不高,这也原创 2014-04-11 16:52:36 · 4771 阅读 · 9 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(28) - 设计原则:内聚&耦合
前面通过实例讲解了一个一环扣一环的面向对象的开发流程:用例模型 -> 领域模型 -> 设计模型(类模型 + 动态模型),解答了面向对象如何做的问题。接下来我们就要讲“如何做好面向对象设计”的技巧了===================================================================参考维基百科的解释,内聚的含义如下:cohesion refers t原创 2014-04-25 16:35:39 · 4795 阅读 · 2 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(23) - 领域建模三字经
看起来有点不可思议,需求阶段“白纸黑字”的用例文档,经过我们一步一步的操作,逐步就得到了“图形化”的领域模型,面向对象初具雏形。领域建模的三字经方法:找名词、加属性、连关系。 我们接下来以一个样例看看领域模型具体如何建模。1.1. 找名词我们以POS机买单的用例来看看具体如何建领域模型。 首先,将用例中所有的名词挑选出来(如下用例文档中蓝色加粗的词组):【用例名称】买单【场景】Who:顾客、收银员原创 2014-04-02 13:55:47 · 9820 阅读 · 13 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(39) - 设计原则 vs 设计模式
又是设计原则,又是设计模式,到底该用哪个呢? =============================================================================在“设计模型”一章中,我们提到设计原则和设计模式是互补的,设计原则和设计模式互补体现在:设计原则主要用于指导“类的定义”的设计,而设计模式主要用于指导“类的行为”的设计。 举一个很简单的例子:假设我们原创 2014-08-18 09:50:45 · 4750 阅读 · 1 评论 -
十年磨一剑之架构设计
浓缩10年工作经历精华,结合电信领域和互联网领域的经验,剥去架构设计高大上的神秘外衣,提炼架构设计的终极大法,菜鸟也能做架构设计,架构设计不过如此。 主要内容包括:1)什么是架构设计2)架构设计的终极大法3)架构设计的基本原则4)如何提升架构设计能力详细请点击下载:十年磨一剑之架构设计原创 2014-12-24 10:12:14 · 6482 阅读 · 1 评论 -
BAT解密:互联网技术发展之路(6)- 服务层技术剖析
在系列文章的第2篇“BAT解密:互联网技术发展之路(2)- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点:复杂性越来越高。复杂性增加的典型现象就是系统越来越多,当系统的数量增加到一定的程度,就由复杂度量变带来了复杂度的质变,主要体现在系统间相互依赖程度加深:比如说为了完成A业务系统,可能需要B、C、D、E等十几个其它系统进行合作。从数学的角度进行评估,可以发现系统间的依赖是指数级原创 2015-10-13 15:51:51 · 21167 阅读 · 16 评论 -
异地多活有哪些Impossible Mission?
《碟中谍》系列电影中,汤姆克鲁斯主演的亨特特工,无论什么情况,什么环境下都能够有惊无险的完成那些看似不可能的任务。对于技术人员来说,如果也能像汤姆克鲁斯那样,不管什么mission impossible最后都能解决,那迎娶白富美,当上CTO,走向人生巅峰都不是问题!“异地多活”看起来就是这样一个万能的大杀器,很多人理想中认为只要实现了“异地多活”,不管是新奥尔良水灾,美加大停电,蓝翔挖掘机。。。。...原创 2016-11-25 17:09:31 · 5387 阅读 · 0 评论 -
异地多活设计辣么难?其实是你想多了!
有幸参与了阿里游戏的一个高可用方案的设计,并且在网上发表了方案(面向业务的立体化高可用架构设计),后来参加GOPS全球运维大会深圳站,与众多行业高手交流,发现大家对“异地多活”这个方案设计非常感兴趣,毕竟“异地多活”的方案价值非常大,尤其是互联网行业,规模稍微大一点几乎都必须是标配;但同时大家都觉得“异地多活”的方案设计又很难,网络、数据、事务等各种问题混杂在一起,很多问题看似是无法解决原创 2016-08-01 09:51:40 · 5215 阅读 · 0 评论 -
BAT解密:互联网技术发展之路(10)- 运维平台技术
本来想自己写一篇运维体系的文章的,但毕竟不是专业运维人员出身,担心讲的太肤浅,因此转载我的好朋友王金银(江湖人称老王)同学发表在InfoQ的运维体系介绍。老王的牛逼相信很多同学已经领教过了,全球运维技术大会深圳站一个人专场讲运维能讲3个小时,而且会场还爆满,更多老王的介绍可以参考文章的最后,也可以关注老王的微信公众号:互联网运维杂谈。转载 2016-08-01 12:36:09 · 6479 阅读 · 0 评论 -
面向业务的立体化高可用架构设计
为了实现阿里九游游戏接入系统的业务高可用,技术人员跳出传统的面向系统的高可用的思路,转而从业务的角度来整体考虑高可用,最终实现了一套立体化的高可用架构,本文逐一展示这套立体化高可用架构的一些具体实践。原创 2015-11-16 15:59:47 · 7132 阅读 · 1 评论 -
BAT解密:互联网技术发展之路(9)- 业务层技术剖析
互联网的业务千差万别,不同的业务分解下来有不同的系统,所以业务层没有办法提炼一些公共的系统或者组件,但抛开业务的差异,各个互联网业务发展最终面临的问题都是类似的:就是复杂度越来越高,也就是说,业务层面对的主要技术挑战是“复杂性”。幸运的是,面对业务层的技术挑战,我们有一把屠龙宝刀,神挡杀神,佛挡杀佛,不管什么业务难题,用上屠龙宝刀一试都迎刃而解。这把屠龙宝刀就是“拆”。复杂性的一个主要原因就是系统原创 2016-04-29 19:22:52 · 17503 阅读 · 0 评论 -
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(4)—— 文武双全
【文武双全】前面讲了那么多,看起来都是和项目管理相关的的,例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。架构师怎么变成了项目经理了,说好的技术呢? 真正的架构师,当然必须具备一定的项目经理技能,但更重要的还是技术能力,道理很简单:再好的饼,最后实现不了,都是扯淡!我将“项目管理能力”称之为“文”的能力,“技术能力”称之为“武”的能力,架构师必须文武双全,才能最终把事情搞定!原创 2016-06-02 09:31:37 · 7596 阅读 · 2 评论 -
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(1)——有的放矢
序言对一个程序员来说,世界上最痛苦的事情是什么呢?有的人会说:编码的时候产品改需求!有的人会说:看别人不知所云的代码!有的人会说:定位一个百年不遇千年难寻的线上不定时偶尔出现的bug!有的人会说:找不到女(男)朋友!。。。。。。。。。。。。。。。。。。。。。。。。。。但我要说,这些痛苦其实都不算什么,要么是多花点时间去解决(比如说改需求、看代码),要么是多花点心思(比如说找另一半、定位疑难bug)原创 2016-05-18 10:15:00 · 6231 阅读 · 0 评论 -
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(3)—— 运筹帷幄
【运筹帷幄】一般来说,需要架构重构的系统,基本上都是因为各种历史原因和历史问题没有及时处理,遗留下来逐渐积累,然后到了一个临界点,各种问题开始互相作用,集中爆发!到了真正要开始重构的时候,我们可能会发现千头万绪,感觉无法下手,随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。 可以想象一下,假如我们拿到一个架构问题列表,其中有50个问题,那我们应该怎么去原创 2016-05-27 15:25:44 · 7355 阅读 · 0 评论 -
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(2)—— 合纵连横
【合纵连横】【合纵】架构重构是大动作,持续时间比较长,而且会占用一定的研发资源,包括开发和测试,因此不可避免的会影响业务功能的开发。因此,要想真正推动一个架构重构项目启动,需要花费大量的精力进行游说和沟通。注意这里我不是指要谈办公室政治,而是指要和利益相关方沟通好,让大家对于重构能够达成一致共识,避免重构过程中不必要的反复和争执。 道理很简单,但如何做才是关键!一般的技术同学谈到架构重构的时候,就原创 2016-05-24 20:24:04 · 7102 阅读 · 0 评论 -
BAT解密:互联网技术发展之路(2)- 业务如何驱动技术发展
互联网技术发展之路(2)- 业务如何驱动技术发展在《互联网技术发展之路(1) - 技术发展的驱动力》一文中,我们详细阐述了对于服务类的业务来说,业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何驱动技术发展的。 互联网业务千差万别,但由于他们具有“规模决定一切”的相同点,其发展路径也基本上是一致的。互联网业务发展一般分为几个时期:初创期、快速发展期、竞争期、成熟期。不同时期的差别主要体现原创 2015-04-14 10:08:11 · 8524 阅读 · 3 评论 -
BAT解密:互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范
大部分人对于BAT的技术有一种莫名的崇拜感,觉得只有非常牛逼和天才才能做出现在的这些系统,但经过前面两篇博文的分析,我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面,而是业务的不断发展推动技术的不断发展,一步一个脚印,持续几年甚至10几年的发展,才能达到当前技术复杂度、先进性、牛逼度。抛开BAT各自差异很大的业务,站在技术的角度来看,其实BAT的技术架构基本是一样的,牛逼的公司技术都是这个范原创 2015-05-27 11:15:46 · 10320 阅读 · 5 评论 -
BAT解密:互联网技术发展之路(4)- 存储层技术剖析
剖析互联网技术存储层典型的做法和方案,包括SQL数据、NoSQL数据、小文件、大文件原创 2015-05-29 17:48:40 · 7941 阅读 · 3 评论 -
BAT解密:互联网技术发展之路(5)- 开发层技术剖析
剖析互联网技术开发层相关技术和主流的做法,包括开发框架、web服务器、容器技术原创 2015-06-02 15:20:58 · 7800 阅读 · 4 评论 -
BAT解密:互联网技术发展之路(7)- 网络层技术剖析
上一篇博文《BAT解密:互联网技术发展之路(6)- 服务层技术剖析》中,介绍了互联网业务发展特点的中的“复杂性”的应对方式,本文介绍互联网业务发展特点的另外两个方面“高性能”、“高可用”。一般人提到高性能时第一想到的就是优化,提到高可用时第一反应就是双机或者备份,但是对于互联网这种超大容量和访问量的业务来说,这两个手段都是雕虫小技,无法应对互联网业务的高性能和高可用需求,互联网业务的高可用和高性能原创 2015-11-11 15:14:00 · 7105 阅读 · 3 评论 -
BAT解密:互联网技术发展之路(8)- 用户层技术剖析
互联网业务用户层技术主要包括:用户管理、消息推送、存储云、图片云。用户管理互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来,因此用户管理是互联网业务必不可少的一部分。稍微大一点的互联网业务,肯定会涉及到多个子系统,这些子系统不可能每个都自己来管理这么庞大的用户,由此引申出用户管理的第一个目标:SSO,单点登录,又叫统一登录。单点登录的技术实现手段较多,例如cookie、token等,原创 2015-12-31 17:04:42 · 5413 阅读 · 0 评论 -
使用开源项目的正确姿势,都是血和泪的总结!
软件开发领域有一个流行的原则DRYDon’t repeat yourself我们翻译过来更形象通俗不要重复造轮子。开源项目主要目的是共享其实就是为了让大家不要重复造轮子尤其是在互联网这样一个快速发展的领域速度就是生命引入开源项目可以节省大量的人力和时间大大加快业务的发展速度何乐而不为呢 然而原创 2016-03-03 10:07:11 · 10718 阅读 · 9 评论 -
连载:面向对象葵花宝典:思想、技巧与实践(16) - 需求分析终极目的
需求分析有三种级别,你自认为属于哪一级呢 ?需求分析的目的是什么? 你可能会毫不犹豫的回答:需求分析的目的当然是了解客户需要什么! 这个回答看起来是毫无疑问的,我们当然要了解客户需要什么,我们才能给他们做出他们想要的。但只做到这样就可以了么? 我们来看一个简单的需求,客户找到你说:“我要一只羊!”这个需求够简单吧?那你是不是毫不犹豫的就抓一只羊给客户呢?原创 2014-03-06 19:17:21 · 5742 阅读 · 4 评论