软件设计

软件设计:秀干繁枝

设计模式软件框架 ASP框架设计 CLASP FCS Rails ASPDotNet设计模式

PHP框架设计

1、silverlight 微软号称的下一代网络开发技术

思路是很好的 彻底将ui与路基层分开

silverlght是一个ie插件,可以做出许多绚丽的效果,并且可以和ms studio很好的结合开发,也有自己的设计工具ms expression blend2,但是我用过之后感觉不爽,也许他还不成熟,也许我们还不熟悉 ,哈哈

第一它是个插件,装机量是很有限的,再者,设计web页面并不方面,而且设计受到很大的限制(在blend 中设计windows ui 是很炫,但是在网页中好多不支持)

作为一个gis开发人员 感觉silverlight 也没什么好炫耀的 因为silverlight中shape要素 我们是多么的熟悉 svg早就做好了,重复性工作啊adobe的ie插件可以做到页面矢量图形绘制 并且受到arcgis等gis软件的很好支持。

2、javascript 设计界面 最实用(因为有了一些开发工具也最方便)

介绍一个牛的工具 大家一试就知道了

Aptana IDE 基于eclipse得开源 javascript 集成开发工具

支持 现有流行的js类库(jquery、ext) 代码提示等 和ms studio可以一比高下

性能不是很好 慢、占地方!

http://www.cnblogs.com/gishawk/archive/2007/09/21/901167.html

* 设计概念

o 设计的定义

o 基本设计问题

+ 持久数据

+ 存储管理

+ 例外

o 软件开发生命周期中的设计环境

o 设计原则

+ 信息隐藏

+ 内聚与耦合

o 设计和需求之间的交互

o 质量属性设计

+ 可靠性

+ 可用性

+ 性能

+ 可测试性

+ 容错

o 设计折衷

o 体系结构风格、模式、复用

  • 设计策略

o 面向功能的设计

o 面向对象的设计

o 以数据结构为中心的设计

o 面向方面的设计

  • 体系结构设计

o 体系结构风格

+ 管道与过滤器

+ 分层

+ 以事务为中心

+ 点对点

+ 出版-订阅架构

+ 基于事件

+ 客户-服务器

o 多属性中的体系结构折衷

o 软件体系结构中的硬件问题

o 软件体系结构中的需求可追踪性

o 特定领域的体系结构和产品线

o 体系结构表示

  • 详细设计

o 设计方法

+ SSA/SD

+ JSD

+ OOD

o 设计模式

o 组件设计

o 组件和系统接口设计

o 设计表示

  • 人机界面设计

o 通用人机界面设计原则

o 模式和导航的应用

o 编程技术与可视化设计

+ 颜色

+ 图标

+ 字体

+ 布局

o 响应时间和反馈

o 设计形式

+ 菜单驱动

+ 表单

+ 问答

o 本地化和国际化

o 人机界面设计方法

o 多媒体

o 隐喻和概念模型

o 人机界面心理学

  • 设计支持工具与评价

o 设计支持工具

o 设计属性度量

o 设计标准

o 形式化设计分析

参见

架构师书单(2010版)| 架构师书单 2nd Edition|

对大宋下一代系统软件架构师的七个期望|

信息架构新手完全指南| 信息架构策略——从CNN改版说起|

设计者的框架

把纷繁的对象融入关系数据库,就是OOP的目前最优解法? 就是用适合人理解的意群去划分适合机器理解的过程代码。 而把要让机器理解的部分整理成方便检索的数据库记录方式,机器很快,所以可以以快补拙。 而人的时间与精力有限,所以要整理出易理解的对象,且不断完善。

所以,可能可以参考现实世界的分类分纲法。 我比较喜欢动植物分类法。

为什么说语言重要也不重要,算法和数据结构重要也不重要。对要解决的问题的领域的理解很重要(即明白真正要做什么)。理解了,我们才可以用面向对象,用模式去套问题;可理解了,我们又不真的需要这些繁杂的抽象。-树结构的管理|

使用CSS开发时髦的导航栏(一) 使用CSS开发时髦的导航栏(二) 使用CSS开发时髦的导航栏(三) 使用CSS开发时髦的导航栏(四) 使用CSS开发时髦的导航栏(五)

摘:进行 Web 界面原型设计的一种方法

架构师核心技能养成计划【转载】

http://www.cnblogs.com/anytao/archive/2007/09/03/anytao_design_02.html 从架构到设计 第二回:对象的旅行---对象和人,两个世界,一样情怀

软件界面建模浅析

从MVC与三层架构谈到优化架构提高Web效率

设计架构优秀的 Framework - 兼谈 ORM Framework

园内ORM讨论的经典文章及评论

IBatisNet+Castle构架升级指南 SQlmap1.5+Castle2.0 MyGeneration模版

图形界面框架1:MVP模式

IT 架构之学习教材-WSSRA

HFSoft FrameWork应用案例(1)

设计模式总结-设计原则

界面设计的探索

Windows Workflow Foundation 今天开张

为想了解WWF,但还没有上手的朋友写了一个简单的例子

Domain Model:业务流程

SOA在一个典型企业应用案例中的应用构想

NBear类库结构

在C#程序中实现插件架构

开发“插件式”检验联机接口框架

本人作为一位web工程师,着眼最多之处莫过于 性能与架构,本次幸得参与sd2.0大会,得以与同行广泛交流,于此二方面,有些心得,不敢独享,与众博友分享,本文是这次参会与众同撩交流的心得,有兴趣者可以查看视频

架构设计的几个心得:

一,不要过设计:never over design 这是一个常常被提及的话题,但是只要想想你的架构里有多少功能是根本没有用到,或者最后废弃的,就能明白其重要性了,初涉架构设计,往往倾向于设计大而化 一的架构,希望设计出具有无比扩展性,能适应一切需求的增加架构,web开发领域是个非常动态的过程,我们很难预测下个星期的变化,而又需要对变化做出最 快最有效的响应。。

ebay的工程师说过,他们的架构设计从来都不能满足系统的增长,所以他们的系统永远都在推翻重做。请注意,不是ebay架构师的能力有问题,他们 设计的架构总是建立旧版本的瓶颈上,希望通过新的架构带来突破,然而新架构带来的突破总是在很短的时间内就被新增需求淹没,于是他们不得不又使用新的架构 web开发,是个非常敏捷的过程,变化随时都在产生,用户需求千变万化,许多方面偶然性非常高,较之软件开发,希望用一个架构规划以后的所有设计,是不现实的

二,web架构生命周期:web architecture‘s life cycle

既然要杜绝过设计,又要保证一定的前瞻性,那么怎么才能找到其中的平衡呢?希望下面的web架构生命周期能够帮到你

http://www.cnblogs.com/images/cnblogs_com/yizhu2000/WindowsLiveWriter/web_8D00/architecture_life_cycle.gif所设计的架构需要在1-10倍的增长下,通过简单的增加硬件容量就能够胜任,而在5-10倍的增长期间,请着手下一个版本的架构设计,使之能承受下一个10倍间的增长

google之所以能够称霸,不完全是因为搜索技术和排序技术有多先进,其实包括baidu和yahoo,所使用的技术现在也已经大同小异,然而,google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的

,缓存:Cache

空间换取时间,缓存永远计算机设计的重中之重,从cpu到io,到处都可以看到缓存的身影,web架构设计重,缓存设计必不可少,关于怎样设计合理的缓 存,jbosscache的创始人,淘宝的创始人是这样说的:其实设计web缓存和企业级缓存是非常不同的,企业级缓存偏重于逻辑,而web缓存,简单快 速为好。。

缓存带来的问题是什么?是程序的复杂度上升,因为数据散布在多个进程,所以同步就是一个麻烦的问题,加上集群,复杂度会进一步提高,在实际运用中,采用怎样的同步策略常常需要和业务绑定

老钱为搜狐设计的帖子设计了链表缓存,这样既可以满足灵活插入的需要,又能够快速阅读,而其他一些大型社区也经常采用类此的结构来优化帖子列表,memcache也是一个常常用到的工具

钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

Cache的常用的策略是:让数据在内存中,而不是在比较耗时的磁盘上。从这个角度讲,mysql提供的heap引擎(存储方式)也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存,其实还有一种写缓存,在以内容为主的社区里比较少用到,因为这样的社区最主要需要解决的问题是读问题,但是在处理 能力低于请求能力时,或者单个希望请求先被缓存形成块,然后批量处理时,写缓存就出现了,在交互性很强的社区设计里我们很容易找到这样的缓存

五,合理选择数据存储方式:reasonable data storage

我们一定要使用数据库吗,不一定,雷鸣告诉我们搜索不一定需要数据库,云风告诉我们,游戏不一定需要数据库,那么什么时候我们才需要数据库呢,为什么不干脆用文件来代替他呢? 首先我们需要先承认,数据库也是对文件进行操作。我们需要数据库,主要是使用下面这几个功能,一个是数据存储,一个是数据检索,在关系数据库中,我们其实非常在乎数据库的复杂搜索的能力,看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….

我们可以看出需要数据库关联,排序的能力,这个能力在某些情况下非常重要,但是如果你的网站的常规操作,全是这样复杂的逻辑,那效率一定 是非常低的,所以我们常常在数据库里加入许多冗余字段,来减小简单查询时关联等操作带来的压力,我们看看下面这张图,可以看到数据库的设计重心,和网站 (指内容型社区)需要面对的问题实际是有一些偏差的

http://www.cnblogs.com/images/cnblogs_com/yizhu2000/WindowsLiveWriter/web_8D00/database.gif同样其他一些软件产品也遇到同样的问题所以具我了解,有许多特殊的运用都有自己设计的特殊数据存储结构与方法,比如有的大型服务程序采取树形数据存储结构,lucene使用文件来存储索引和文件

从另外一个角度上看,使用数据库,意味着数据和表现是完全分离的(这当然是经典的设计思路),也就是说当需要展示数据时,不得不需要一个转 换的过程,也可以说是绑定的过程,当网站具备一定规模的时候,数据库往往成为效率的瓶颈,所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑 定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫,而是我们在设计数据的持久化时,需要根据实际情况来选择存储方式,而数据库不过是其中一个选项

六,搞清楚谁是最重要的人:who's the most important guy

在用例需求分析的时候常常讲到涉众,就是和你的设计息息相关的人,在web中我们一定以为最重要的涉众莫过于用户了。,在一个传统 的互动社区开发中,最重要的东西是内容,用户产生内容,所以用户就是上帝,至于内容挑选工具,不就是给坐我后面三排的妹妹们用的吗?凑或行了,实在有问题 我就在数据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题:实际上网站每天产生的内容非常 的多,普通人是不可能看完的,而编辑负责把精华的内容推荐到首页上,所以很多用户读到的内容其实都依赖于编辑的推荐,所以设计让编辑工作方便的工具也是非 常重要,有时甚至是最重要的。

七,不要执着于文档:don't be crazy about document

web开发的文档重要吗?什么文档最重要?我的看法是web开发中交流文档,

现在大的软件公司比较流行的做法是: 注重产品设计文档,在这种方法里,产品文档非常详尽,并且没有歧义,开发人员基于设计文档开发,测试人员基于设计文档制定测试方案,任何新人都可以通过阅读产品设计文档来了解项目的概况

而web项目从概念到实现的时间是非常短的,而且越短越好,并且由于变化迅速,要想写出完整的产品和需求文档是几乎不可能的,大多数情况是 等你写出完备的文档,项目早就是另外一个样子,但是没有文档的问题是,如果团队发生变化,添加新成员怎样才能了解软件的结构和概念呢,一种是每个人都了解 软件的整个结构,除非你的团队整体消失,否则任何一个人都能够担当培养新人的责任,这种face2face交流比文档有效率很多。

于是就有了前office开发者,现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差,他说,我们的项目是吵出来的,我听完会心一笑

八,团队:team

不要专家团队,而要外科手术式的团队,你的团队里一定要有清道夫,需要有弓箭手,让他们和项目一起成长,才是项目负责人的最大成就

总结:

0)架构是一种权衡

http://www.cnblogs.com/images/cnblogs_com/yizhu2000/WindowsLiveWriter/web_8D00/architecture.gif1)web开发的特点是是:没有太复杂的技术难点,一切在于迅速的把握需求,其实这正式敏捷开发的要旨所在,一切都可以非常快速的建立,非常快速的重构,我们的开发工具,底层库和框架,包括搜索引擎和web文档提供的帮助,都提我们供给了敏捷的能力。

2)此外,相应的,最有效率的交流方式必须留给web开发,那就是face2face(面对面),不要太担心你的设计不能被完备的文档所保留下来,他们会以交流,代码和小卡片的方式保存下来

3)人的因素会更加重要,无论是对用户的需求,还是开发人员的素质。

另:有关web效率,有著名的14条规则,由yahoo性能效率小组所总结,并广为流传。业已出现相关插件(YSlow),针对具体网页按彼规则评分,这次该小组负责人Tenni Theurer也受邀来到此次大会,我把Tenni小姐(之前真的没有想到她是个女孩,并且如此年轻)和她的团队的14 rules列在下面

Make Fewer HTTP Requests

Use a Content Delivery Network

Add an Expires Header

Gzip Components

Put CSS at the Top

Move Scripts to the Bottom

Avoid CSS Expressions

Make JavaScript and CSS External

Reduce DNS Lookups

Minify JavaScript

Avoid Redirects

Remove Duplicate Scripts

Configure ETags

Make Ajax Cacheable

通过安装firebugYSlow这两个firefox插件(请注意要先安装firebug再安装yslow,下载后拖动到firefox里即可)我们可以看到你的网页根据下面的规则的评分,这是我在博客园博客首页的评分截图,上面D表示总分,下面是单项评分,A最好F最差,不知道还有没有G :)

http://www.cnblogs.com/images/cnblogs_com/yizhu2000/WindowsLiveWriter/web_8D00/YSlow.gif相关连接

yahoo性能团队:http://developer.yahoo.com/performance/

[从设计到架构]第四回:依赖的哲学(上) WCF从理论到实践系列文章索引

参见

【PDF分享】豆瓣网技术架构的发展历程.pdf|

大型网站技术架构|

微博架构与平台安全|

架构设计之性能设计经验

web架构设计经验分享

主界面源码.rar 593k

完美模式设计指南--微软程序员.rar 241k