62,254
社区成员
发帖
与我相关
我的任务
分享了解开发模式的请进--200分周日晚结贴
1，希望给点这方面的介绍。
2，希望给点学习建议。
3，根据自己的学习经验，给我几句话。
4，不要单单录入几个字“帮顶” “接分”之类的。
谢谢，周日晚上结贴
2，希望给点学习建议。
3，根据自己的学习经验，给我几句话。
4，不要单单录入几个字“帮顶” “接分”之类的。
谢谢，周日晚上结贴
...全文
请发表友善的回复…
发表回复
CODE163 2010-06-20
- 打赏
- 举报
[Quote=引用 46 楼 amandag 的回复:]
代码级的容易，设计级的困难
[/Quote]
友情蹭分
代码级的容易，设计级的困难
[/Quote]
友情蹭分
amandag 2010-06-20
- 打赏
- 举报
代码级的容易，设计级的困难
porschev 2010-06-20
- 打赏
- 举报
占楼。。。。。。
S_trance 2010-06-20
- 打赏
- 举报
我写项目的时候首先都是先分析之类的了，这肯定都是越全面越好，每个大大肯定都是，
我也有一些自己的一个必做的环节，就是
在写之前，先设计下模板，说简单的就是 先弄静态页面，把项目设计到的，需要的页面都先“画”出来，
这个不需要没关，哪怕标签都不用，只用空格和回车也行，
之后写的时候根据写的然后开始任务。
我感觉这样有好多好处，：
一：首先就是你坐简单静态页面时候，肯定会把所有死点都心中有数的，在真正开始项目的时候也有思路
二：就是这样如果是团队的话也比较容易分配任务。。
。。。。
呵呵，一些小经验，其他的都差不多。
我也有一些自己的一个必做的环节，就是
在写之前，先设计下模板，说简单的就是 先弄静态页面，把项目设计到的，需要的页面都先“画”出来，
这个不需要没关，哪怕标签都不用，只用空格和回车也行，
之后写的时候根据写的然后开始任务。
我感觉这样有好多好处，：
一：首先就是你坐简单静态页面时候，肯定会把所有死点都心中有数的，在真正开始项目的时候也有思路
二：就是这样如果是团队的话也比较容易分配任务。。
。。。。
呵呵，一些小经验，其他的都差不多。
足球中国 2010-06-20
- 打赏
- 举报
到少会了解如何入手重构，不然啥也不知道。
足球中国 2010-06-20
- 打赏
- 举报
二十三种开发，真的挺不错。但实际用到的不太可能是全部。里面的二十三种开发模式。根据 大话开发模式，那本书看了几遍。
感觉很不错。
对现在我要重构我的小框架，有一定的帮助。
感觉很不错。
对现在我要重构我的小框架，有一定的帮助。
jianshao810 2010-06-20
- 打赏
- 举报
这可是难点啊，我找了本大话设计模式看
xsxsljy 2010-06-20
- 打赏
- 举报
设计模式，我觉得还是一个很好的东西。如果能在实际开发过程正确使用模式，程序结构会很清晰，复用性很强以为你重复做的事情会很少，使得你的系统应对不断变化的需求能力就很强，但真正深入理解模式，知道在什么场合使用使用什么模式，我觉得需要很长一段时间实践学习。刚买了人民邮电出版社 出版的 《易学设计模式》，觉得不错。
段传涛 2010-06-20
- 打赏
- 举报
结贴 谢谢各位
wuyq11 2010-06-19
- 打赏
- 举报
多看看软件工程如实践者的研究方法和敏捷编程的相关知识
设计模式是编程时常用的
瀑布和XP都是迭代
设计模式是编程时常用的
瀑布和XP都是迭代
段传涛 2010-06-19
- 打赏
- 举报
[Quote=引用 16 楼 maomao90 的回复:]
楼主应该改改标题为：理解开发模式的请进
说了解，一般是最基础一点知道而已的呀，是个人都知道模式是初是由建筑中提取出来的，
[/Quote]
学习嘛 知道点就行 愿意分享就好
楼主应该改改标题为：理解开发模式的请进
说了解，一般是最基础一点知道而已的呀，是个人都知道模式是初是由建筑中提取出来的，
[/Quote]
学习嘛 知道点就行 愿意分享就好
maomao90 2010-06-19
- 打赏
- 举报
楼主应该改改标题为：理解开发模式的请进
说了解，一般是最基础一点知道而已的呀，是个人都知道模式是初是由建筑中提取出来的，
说了解，一般是最基础一点知道而已的呀，是个人都知道模式是初是由建筑中提取出来的，
永生天地 2010-06-19
- 打赏
- 举报
软件开发模式有哪些?
快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）
快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能
（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）
优点：
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
缺点：
A、 所选用的开发技术和工具不一定符合主流的发展
B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下
增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）
与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代
与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）
优点：
1、 人员分配灵活，一开始不需要投入大量人力资源
2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）
3、 增量能够有计划的管理技术风险
缺点：
1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
注：
这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
原型模型：（样品模型，采用逐步求精的方法完善原型）
主要思想：
先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，
采用方法：
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应
优点：
(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
缺点：
1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：
喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）
它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性
相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分
无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间<由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系>）
优点：
1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程
不便之处：
1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况
螺旋模型：（适合用于需求经常变化的项目<适合于大型复杂的系统>）
它主要是风险分析与评估，沿着螺线进行若干次迭代，
过程：
1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
2、 风险分析：分析评估所选方案，考虑如何识别和消除风险
3、 实施工程：实施软件开发和验证；
4、 客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：
1、 它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中
缺点：
1、 难以让用户确信这种烟花方法的结果是可以控制的
2、 建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）
3、 除非软件开发人员擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险
瀑布模型：（从本质来讲，瀑布模型是一个软件开发架构,重复应用）
（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序<如同瀑布流水逐级下落>）
缺点：
1、 在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量
2、 用户只有在项目生命周期的后期才能看到结果，增加了开发的风险
3、 需要过多的强制完成日期和里程碑来跟踪各个项目的阶段
4、 在每个阶段都会产生循环反馈
（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段<甚至更前面的活动>并进行适当的修改,只有当上一阶段都被确认后才进行下一阶段）
5、 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
优点：
1、 为项目提供了按阶段分的检查点
2、 当完成一个阶段后，只需要去关注后续阶段
3、 可在迭代模型中应用瀑布模型
按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试
注：由于每个阶段都会产生循环反馈，对于经常变化的项目而言，瀑布模型毫无价值，这种模型的线性过程太理想化，已不适合现代的软件开发模式
快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）
快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能
（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）
优点：
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
缺点：
A、 所选用的开发技术和工具不一定符合主流的发展
B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下
增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）
与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代
与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）
优点：
1、 人员分配灵活，一开始不需要投入大量人力资源
2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）
3、 增量能够有计划的管理技术风险
缺点：
1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
注：
这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
原型模型：（样品模型，采用逐步求精的方法完善原型）
主要思想：
先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，
采用方法：
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应
优点：
(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
缺点：
1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：
喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）
它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性
相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分
无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间<由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系>）
优点：
1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程
不便之处：
1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况
螺旋模型：（适合用于需求经常变化的项目<适合于大型复杂的系统>）
它主要是风险分析与评估，沿着螺线进行若干次迭代，
过程：
1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
2、 风险分析：分析评估所选方案，考虑如何识别和消除风险
3、 实施工程：实施软件开发和验证；
4、 客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：
1、 它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中
缺点：
1、 难以让用户确信这种烟花方法的结果是可以控制的
2、 建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）
3、 除非软件开发人员擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险
瀑布模型：（从本质来讲，瀑布模型是一个软件开发架构,重复应用）
（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序<如同瀑布流水逐级下落>）
缺点：
1、 在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量
2、 用户只有在项目生命周期的后期才能看到结果，增加了开发的风险
3、 需要过多的强制完成日期和里程碑来跟踪各个项目的阶段
4、 在每个阶段都会产生循环反馈
（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段<甚至更前面的活动>并进行适当的修改,只有当上一阶段都被确认后才进行下一阶段）
5、 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
优点：
1、 为项目提供了按阶段分的检查点
2、 当完成一个阶段后，只需要去关注后续阶段
3、 可在迭代模型中应用瀑布模型
按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试
注：由于每个阶段都会产生循环反馈，对于经常变化的项目而言，瀑布模型毫无价值，这种模型的线性过程太理想化，已不适合现代的软件开发模式
glgxw 2010-06-19
- 打赏
- 举报
模式不见得能重要到哪里？
随着人性化的改善，模式也在不断改变。
关键是对流程的理解，把握，控制。
随着人性化的改善，模式也在不断改变。
关键是对流程的理解，把握，控制。
段传涛 2010-06-19
- 打赏
- 举报
[Quote=引用 13 楼 sp1234 的回复:]
模式这个词真是比城市牛皮癣还多啊。
[/Quote]
没有办法，领导喜欢，面试官喜欢。。。。。。
周末学习 学习 了解点东西 没有错啊
模式这个词真是比城市牛皮癣还多啊。
[/Quote]
没有办法，领导喜欢，面试官喜欢。。。。。。
周末学习 学习 了解点东西 没有错啊
段传涛 2010-06-19
- 打赏
- 举报
[Quote=引用 11 楼 flyingyinjun 的回复:]
友情帮顶，顺带学习，不过我觉得做任何事情都要有直觉
想的到，一般就解决的了
想不到，别人告诉的要打折扣
[/Quote]
那就说说吧 ， 说出来大家分享
友情帮顶，顺带学习，不过我觉得做任何事情都要有直觉
想的到，一般就解决的了
想不到，别人告诉的要打折扣
[/Quote]
那就说说吧 ， 说出来大家分享
以专业开发人员为伍 2010-06-19
- 打赏
- 举报
模式这个词真是比城市牛皮癣还多啊。
yanzhiyong 2010-06-19
- 打赏
- 举报
我也来看下，设计模式倒是懂点点，但是开发模式不是很清楚。。。
希望高手来解答。。
希望高手来解答。。
flyingyinjun 2010-06-19
- 打赏
- 举报
友情帮顶，顺带学习，不过我觉得做任何事情都要有直觉
想的到，一般就解决的了
想不到，别人告诉的要打折扣
想的到，一般就解决的了
想不到，别人告诉的要打折扣
wanghui0380 2010-06-19
- 打赏
- 举报
<领域驱动设计与模式实战> 可以看看
博客园某些人觉着这本书太散了点，我觉得还好；可以一看。至少这本书是从“实战”角度出发，横向联系了开发模式，设计模式，TDD，DDD等多个方面，属于“截拳道”那种实战型的东西（当然你也别指望他就是一招毙命，以一当百独孤九剑式的东西，以目前的情况来说“银弹”这种东西还真的不存在）
不过建议去看原版，中文版翻译的太----
博客园某些人觉着这本书太散了点，我觉得还好；可以一看。至少这本书是从“实战”角度出发，横向联系了开发模式，设计模式，TDD，DDD等多个方面，属于“截拳道”那种实战型的东西（当然你也别指望他就是一招毙命，以一当百独孤九剑式的东西，以目前的情况来说“银弹”这种东西还真的不存在）
不过建议去看原版，中文版翻译的太----
加载更多回复（28）
