说话吐字不清怎么训练:[转]关于设计思维的落实 -- 自问自答

来源:百度文库 编辑:九乡新闻网 时间:2024/07/14 03:26:04
关于设计思维的落实 -- 自问自答
Q1.为什么程序设计师不太重视设计(Design)?
A1.
• 传统 "Top/Down" 分析->设计->实做 的迫害,使得程序设计师根本就不相信设计图与程序代码是一体两面;设计图是空谈、设计图是文件、设计图是造假(严重了!)
• 太麻烦,无法看到立即可执行的产出(应用程序)。人们往往要 "眼见为凭",尤其是 PM、老板。
• 不知该如何表达,用 UML?觉得好像是要去学另外一种语言,粉累... @$~
• 传统的包袱、本位主义,认为程序设计师就是该用原始程序代码来沟通。
Q2.是否应该把想法表达出来在设计图上?
A2.
• 当然,用嘴巴讲不清楚、用程序代码除了 "同类" 的看得懂(要看懂别人写的也要花很多时间滴~),PM/SA/SD,怎么看得懂?
• 用图来沟通最简单了,只要不要画得太过抽象画,大约解释一下为什么这么画,应该可以让团队成员很快就看懂你的 "涂鸦"。
• 往事用图来回味是最轻松愉快的了~,若是用程序代码,嘿嘿,光自己三个月前写的,自己都已经看不懂了,更何况别人?
Q3.那么,该如何将脑海里的想法表达出来?
A3.心中先有个标的:
1. 你要表达什么(What)?
2. 你要表达给谁看(Who)?
3. 为什么(Why)是这样表达?
4. 你该如何(How)表达?
例如,Client/Server,画两个圈圈,一个圈圈代表 "UI Form";另一个圈圈代表 "Database"。"UI Form" 圈圈画一个箭头指向 "Database"。如此从图就可以看到,两个组件(Component)的相依性(Dependency)关系:"UI Form" 圈圈组件相依于 "Database" 圈圈组件。
同样,你有几个 "Class"、"Class" 之间又是怎样的呼叫来、呼叫去的,如何表达?
就把每个 Class 画一个圈圈,然后再用箭头连起来;若是要呼叫的 Class 是在另外一个系统上,那么,被呼叫的 Class 就是小圈圈 -- 被框在该系统大圈圈内啰~
用什么工具来画图比较理想?
用 VISIO? WORD? 干脆直接一点,画在纸上,应该够简单了吧?
担心语法表达的问题?
唉呀,先把图画出来吧,就像小朋友那样...
我想到什么,我就画出来,你看不懂?我来说给你听,或是我再来把图修正一下吧。慢慢的,你就能看得懂我想表达什么啰~
UML 的问题?
慢慢的,一点点的学习、一点点的修正,一点点的尝试,慢慢会搞通的啦(搞不懂 UML 也无所谓,自家人都看得懂,又不外包的话,"Who Care?")。
将想法用简单的设计、简单的方式来表达在图上。
一个人开发的话,可以慢慢反思自己的设计... ; 团队开发的话,成员之间可以分享彼此的想法、集思广益。
不需要花超过一天,有初步的共识后,就直接写程序来落实印证,然后再回馈(feedback)结果回来,做一些修正、加一点功能。如此循环 "简单设计" 、"马上落实" ...
这样不是很好吗?