17
回答
哈,喷下设计的方法
华为云实践训练营,热门技术免费实践!>>>   

这几年一直在学习和研究,设计方法的方法。哈,搞的很多小朋友说我没水平。刚又看了篇领域模型设计方面的文章。觉得作者也是有点糊涂。里面用了很多,“最好”,“不应该”,“不好”,“建议”的单词,这就和菜谱里面“少许”一样。哈。

信息化系统设计,其实有三个阶段,论证阶段,设计阶段,开发/部署的实施阶段。

我曾经对个搞管理咨询的“大叔”30岁上下,比我小,说了一句话,it系统的设计现在不再是围绕功能自行展开,而是和企业管理,目标价值紧密结合的,更多是管理手段和业务操作流程的信息化。所以大家要融合。结果,他大眼瞪我的小眯眼,没搞懂。当然他们公司老总是很清楚的。

我如果反过来,对这里搞技术的人也说一句,你怎么实现是小事,该实现什么是大事,模型构造远比代码敲敲重要的多,代码的输入错误这种bug好查,结构性的逻辑错误,这种错误很难查找和纠正,而且结构性的错误会随设计的具体化的深入才逐步体现。估计也会被喷“这丫水货一个,整天没点干货”。

uml是个好东西不知道这里有多少团队在从这个起点开始。@gvim 一直坚持的oo思想,从模型设计角度,我是支持和认同的。相反,不从模型分析入手就用oo语言的,真心想不出能折腾出什么好东西。

哈,设计本身是个工作,应用各种方法按照步骤,实现目标。不过设计本身也存在对应方法。这个方法恐怕就要各个团队针对自己的业务领域进行构造和优化了。有点象流程的流程,标准的标准,数据的数据,一样的东西。


<无标签>
举报
中山野鬼
发帖于4年前 17回/948阅
共有17个回帖 最后回答: 4年前
uml是个好东西 -- 两个凡是不同意, 必须改
--- 共有 2 条评论 ---
乌龟壳只不过崇尚完全的面向对象,把uml用走样了而已。 4年前 回复
乌龟壳uml只是一个规范,统一大家的表达方式,用不用没有强制力,只要能把设计说清楚就行了。至于uml组织那只是个学术组织而已。 4年前 回复

引用来自“宏哥”的答案

uml是个好东西 -- 两个凡是不同意, 必须改
哈,关键看是形而上学,还是学以致用了。。

说的对,很多团队或个人虽然号称是构架师,设计师,其实根本就不懂什么是真的设计,混个头衔罢了(包括我)。

学校、师傅、培训等老师也不会教,各种工具用的也是盗版自然也不会有培训。试问用VS的码农有多少能说对visual studio的各项功能十分熟悉?有多少搞设计的真的了解EA,Rational,PowerDesigner的各种功能?有多少人能说清楚UML的优劣,适用那种问题建模?有多少号称做设计的能说清UML各种元素的含义和应用场景。因此最多见的就是半桶水的人天天嚷嚷这不行那不行,无知者自然无谓。

这是技能背景,领域背景不表。

>>>觉得作者也是有点糊涂。里面用了很多,“最好”,“不应该”,“不好”,“建议”的单词,这就和菜谱里面“少许”一样。哈。

个人觉得不是糊涂的表现。老外不像大部分中国人,很多半灌水的码农最喜欢到处喷你这样不对,那样垃圾,相反他们没有绝对把握或不是做出规定的情况下,不会轻易给出一个墙裂的语气词。很多时候确实无法定性的给个量词或动词来说某一设计或过程就应该怎么样。设计活动不仅仅是单纯的领域+技能,同时团队水平,业务水平,核心人员的设计水平,工具熟练程度,工期,造价,团队和谐,客户关系,等等,甚至你预期不到会不会某一天某领导被双规这项目换了领导需求全变,甚至抵触。很多时候不得不平衡。没有需求就不会有设计,我看来设计和需求一样:唯一不变的就是变化,而设计师要做的是尽量保持变化在各种因素间的平衡、扩展。。。盐放多了,自然就明白“少些”了。。。

设计无非就是

1.可扩展性,会适应未来一段时间内的需求

2.把不变与变的尽量分开

3.代码的模块化,看起来功能清晰

4.同时要综合人力,资源,钱等等外部因素。

主要还是看设计人员的技术素养与积累,一个好的架构,在后续的开发中会很轻松,如果遇到一个垃圾的设计,那么后续的一系列问题就是打补丁,去不断的弥补以前的错,是个坑。。。曾经掉进坑里过。。

对于目前的客户水平,动不动就要求2个月上线;一个月内需求变800遍的当下状况,我只能说,设计已死!

如今若想提高客户满意度,年底的时候指望客户的满意度打分不要过低而影响奖金的唯一的、可行的、靠谱的做法是,拉出来 往死了喝。

--- 共有 1 条评论 ---
爆炸+1 4年前 回复

引用来自“恺哥”的答案

对于目前的客户水平,动不动就要求2个月上线;一个月内需求变800遍的当下状况,我只能说,设计已死!

如今若想提高客户满意度,年底的时候指望客户的满意度打分不要过低而影响奖金的唯一的、可行的、靠谱的做法是,拉出来 往死了喝。

每个团队都要做自己擅长的事情。哈。很多连贯性的工作,在不同的项目里是相通的。
顶部