![](https://img-blog.csdnimg.cn/20201014180756925.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
架构设计
文章平均质量分 79
堂吉诃德Time
这个作者很懒,什么都没留下…
展开
-
架构师要善于管理整个开发团队
一直以来,开发团队的管理似乎都是项目经理的事情,从生命周期管理到人力资源的配置,从进度管理到客户关系管理。其实在开发团队中,还有另一位默默无闻的管理大师——架构师。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】管理被很多开发人视作“虚”的东西,平时程序员也不会去钻研管理的学问。身为程序员中的领路人,架构师一般也被认为依靠人格力量进行管控,更多的是以理服人转载 2014-10-24 00:13:51 · 1014 阅读 · 0 评论 -
设计模式六大原则(5):迪米特法则
定义:一个对象应该对其他对象保持最少的了解。问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。解决方案:尽量降低类与类之间的耦合。 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点不言而喻,但是怎么样编程才能做转载 2014-10-27 23:22:48 · 473 阅读 · 0 评论 -
设计模式六大原则(4):接口隔离原则
定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。举例来说明接口隔离原则:(图1 未遵循接口转载 2014-10-27 22:00:54 · 427 阅读 · 0 评论 -
设计模式六大原则(3):依赖倒置原则
定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接转载 2014-10-27 21:23:16 · 444 阅读 · 0 评论 -
设计模式六大原则(2):里氏替换原则
肯定有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的。定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型转载 2014-10-25 00:56:00 · 391 阅读 · 0 评论 -
设计模式六大原则(1):单一职责原则
定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也转载 2014-10-25 00:43:20 · 418 阅读 · 0 评论 -
掌握设计模式
IT职场的小菜经常有这样的疑问: 为什么一个相似的功能,大牛一会儿就搞定,然后悠闲地品着下午茶逛淘宝;而自己加班加点搞到天亮还做不完。 为什么用户提出需求变更后,大牛只需潇洒地敲敲键盘,改改配置;而自己将代码改了又改,删了又建,几乎晕厥,最后只能推翻重来。 为什么大牛写完的程序测试上线后,几乎完美运行,用户无懈可击;而自己的程序bug重重,改好转载 2014-10-24 11:03:10 · 363 阅读 · 0 评论 -
SVN 服务器+客户端搭建
一、引言 笔者曾经试图在网上搜索一篇关于SVN源代码服务器搭建方面的中文技术文章,可惜,所找到的,要么是不完整,要么就是对笔者没什么帮助的文章,TortoiseSvn的帮助文档固然强大,但因为是英文,不是很适合来作为入门者使用;毕竟,TortoiseSvn是一个客户端,服务器端的配置也很重要。 一年前,笔者刚刚毕业,初入公司,在进行开发时,由于没有进行软件代码版本管理,转载 2014-10-23 14:03:06 · 532 阅读 · 0 评论 -
每个好架构师都是一位出色的程序员
一个优秀的软件架构师,首先一定是一个出色的程序员,这是本篇文章的议题。从本文我们可以了解到一个架构师的工作是什么,他容易遇到的问题是什么,因此他为什么必须是一个出色的程序员。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】架构师,听起来是如此神秘的一个称号。尤其是在开发领域刚入门不久的菜鸟级程序员眼中,架构师都是高手,都是牛人,都是如此高高在上的存在。转载 2014-10-24 01:10:12 · 438 阅读 · 0 评论 -
女性架构师优先?驾驭概念的技能是最高潜力
人们往往发现优秀的数学家、物理学家以及软件架构师有着很多相似的素质,甚至往往能够一人精通这好几个领域,其中很重要的原因就是这个抽象思维的能力。架构师们潜意识中会觉得女性更适合做架构师?让我们看看这是为什么。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】在近日51CTO开发频道对数位架构师进行采访的时候,编辑观察到一个很有意思的现象,那就是他们在提起一个假转载 2014-10-24 01:04:09 · 721 阅读 · 0 评论 -
优美的系统与架构师的艺术气质
系统应当是优美的,而这优美体现在系统的伸缩性、安全性、可维护性、可靠性和可移植性等健康因素。如果没有对艺术的追求,那么架构师则往往会被商业需求迷住眼睛,放任系统被滥用而落入不健康的悲哀。因此,好的架构师需要有艺术气质,有对系统之美的追求。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】“系统是一个个有机的生命。跟企业一样,系统也需要施肥浇水,需要健康的成长转载 2014-10-24 00:08:38 · 536 阅读 · 0 评论 -
架构师:要成为百科全书式的智者
架构师是什么?它不是行政职务,也不简单的一种职称。对于一线程序员来说,拥有方方面面各种知识的架构师,是一位百科全书式的智者。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】通常来说我们将架构师分为系统架构师、软件架构师等等。虽然有分工不同,各自所处的层次也有不同,但是究其核心能力,跨领域知识的学习能力,是架构师的强项所在。51CTO开发频道年终巨献:架转载 2014-10-24 00:43:39 · 444 阅读 · 0 评论 -
架构师:每天要在鱼和熊掌之间做选择
架构师每天都需要做选择题。什么选择?怎么做选择?架构师需要进行怎样的学习、培训和锻炼来进行正确的选择?读了本篇文章,你会对架构师为什么会需要权衡取舍以及妥协的能力有一个更加深刻的印象,并对于如何锻炼这个能力有一个初步的认识。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】在访问聚聚呀项目总监梁远华先生时,梁先生说到“权衡取舍”是一个架构师在项目中最难把握的转载 2014-10-24 00:23:11 · 778 阅读 · 0 评论 -
架构师:站在技术的山顶向前眺望
IT开发技术的更新换代速度已经让人措手不及,今天很火热的技术,可能明天就被废弃在大马路上。此时,作为一个优秀的架构师,肯定要有更加敏锐的嗅觉。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】铁打的程序员,流水的技术。程序员的开发生涯可能长达几十年,但一门技术的平均寿命却不长。因此作为程序员们的技术领袖,架构师必须有很好的技术前瞻性,要先于大家了解到最新的技转载 2014-10-24 00:58:10 · 474 阅读 · 0 评论 -
架构师修炼课程:透过问题看本质
架构师的长处之一就是善于看到问题的本质。不过,什么是看到问题的本质?程序员应该如何修炼这个能力?本文从一位菜鸟程序员的编程生涯开始说起,介绍透过问题看本质这一能力的修炼过程。AD:2014WOT全球软件技术峰会北京站 课程视频发布【51CTO独家特稿】一个刚刚从学校毕业的、致力于投身编程事业的年轻人,在投递了n封简历之后,终于如愿以偿得到了第一份编程的工作。如果他在求学期间没有积累过项转载 2014-10-24 00:47:58 · 510 阅读 · 0 评论 -
Apache基于IP的虚拟主机本地配置
1,打开httpd.conf文件将Include conf/extra/httpd-vhosts.conf 前面的#号去掉2,打开extra目录下面的httpd-vhosts.conf文件,下面贴出源码:Conf代码 # # Virtual Hosts # # If you want to maintain multiple domains/hostna原创 2014-10-16 11:06:37 · 553 阅读 · 0 评论