[原创]SNOW未完全冥思录-1

SNOW项目已经启动7个月了，惭愧的是直到现在还是没有一个让我满意的构架，总是提出新的设计，又总是在编码过程中发现设计的缺陷，于是重新设计重新编码，由于没有什么时间限制项目就这样一直拖到了今天，也算是在软件设计和过程上的一个大的实验了，感觉上就是一个“小学期”，虽然大了点，难了点。

在这7个月里，充分体会到了软件开发的种种陷阱，总是不知不觉地犯了错，又在不知不觉中发现错误，才知道原来Coding乃至Programming仅仅是软件开发中的小脚色，冥冥中多少也有了点心得（虽然仅凭这些东东还远远不能拯救我可怜的SNOW）：

1. 理解设计
以前感觉的设计，就是坐在那里凭借自己的经验冥思苦想，颇有一番大虾的潇洒。实际试过之后才发现完全不是那么回事，还是老老实实找前人的设计（代码）先分析一番。看了Gimp之后有底了许多，信心百倍的做出设计，自觉完美，可是一到编码阶段就漏洞百出，重新思考之后调整设计，幸好Eclipse的重构功能不错，但再编码还是一样。一遍遍的重复这个过程之后终于有一天静下心来，删掉所有的代码，坐在书桌旁，带着对自我能力的强烈怀疑，好好读了几本书。

无法形容从《OOD启思录》上看到逻辑设计和物理设计的区别时的震惊，其实早就对这些东东，以及有关的东东很熟悉了，只是从来没有像现在这样将这一切看得那么清楚。设计必须要分成两个层面，逻辑层和物理层，按照《OOD》的说法存在逻辑层面的“类”，和物理层面的“类”。物理层会根据具体的情况对逻辑层的类进行调整，也许会加上一些辅助类，也许会将逻辑层的类变成某个类的成员，逻辑层的类在物理层必然有所体现，但是并不一定以类的形式出现。可以在《Agile Software Development》的保龄球程序中看到这样经典的例子，去除那些“might not really exist”的class是必要的，当然谁也不愿意写一个只有Getter&Setter的类，“Bad Smell！”，不是么？

震惊归震惊，但是我认为这两种类的用词还是太模糊了，“类”总是会让人直接想到有那些行为（习惯基于对象设计的人会想到数据吧！）。其实这种对设计的拆分和老牛的“概念驱动”是一回事，和UML的统一建模方法，和Booch方法都是一回事。甚至和数学建模也有密不可分的关系。我倾向于将“设计层面的类”称为概念（concept），而将“物理层面的类”称为类（class）。所谓设计实际上包含两个阶段：1. 根据需求抽象出所有的概念，找出概念之间的关系。2. 根据概念及其之间的关系设计出相应的类来体现其概念和关系。或者说第一个过程是“抽象”，第二个过程是“具现化”。在上面这两个过程中还需要引入“物理限制”（暂且忽略逻辑限制），在作概念抽象的时候一点都不考虑物理限制是不现实的，实际上物理限制主要还是对第二阶段产生影响。但我相信物理限制对概念抽象的影响符合80-20法则，必不可小看（在《OOD》的自动柜员机以及Gimp和xpdf中都可以看到为了顺应限制而作出的设计）。在物理设计（具现化）过程中处理物理限制不是难事，如果处理不了原因有：Coder素质不够、此限制不应该在物理设计中被处理（让我想到《程序员》上那个秋千的笑话）、可行性估计不足。除了人员问题外全部都是软件过程前期的问题（如何在前期避免还没有得出什么结论）。

设计不是一个向上的过程，也不是一个向下的过程，而是一个三角尖的形状，先向上抽象，再向下建模。从设计的行为上来讲应该类似于三角波吧。/\/\/\/\/\/\/\/

一樣正煩著呢。。。
系統設計
編碼。

但設計的前提是對具體實現非常熟悉
困難。 --------------------            [a=http://northlight.digital-pulse.net/]寻找失落的路灯 @ North.Light[/a]
   有沒有事比死更容易? 有沒有事比活更難?
               ~     幸福是一雙溫暖的紅唇    ~

但設計的前提是對具體實現非常熟悉困難。

我认为熟悉有熟悉的方法（一般设计方法），不熟悉有不熟悉的办法（敏捷开发，XP，XXXP），非常熟悉有非常熟悉的办法（Unix），但困难的事认为非常熟悉，实际过程中才发现不熟悉和非常熟悉。

-2呢?

追求完美的设计是没什么错误,但应该容忍不完美的设计
写的真不错:)
我做程序很世故,呵呵,你也看到了,作一个眼皮,就能把狗的眼睛安到羊的身上.
概念设计是保障质量和效率的前提,xpdf设计上是主题不清晰,结构没有进行分离,开始的时候就是认为是个文档的处理程序,所以虽然是用C++写的,却没有OOD的设计的影子,原因不是他不会建模,是一开始就想错了.Gimp的初始目标就是小的图像处理软件,用于艺术设计和网页小图像的处理,在建立模型的时候,没有进行很好的抽象,概念抽象上的不完整,造成结构的缺陷,但是,如果不违背初忠的话,他也没问题.
我认为物理上的限止不应该对抽象起那么大的影响,而往往是对物理限制想的太多,使得概念抽象上做出让步,或加入不必要的概念,以保证实现的方便,但这是错误的.
抽象的时候确实和数学上很多东西很相似,有定义,定理,引理,在设计的时候,不要把引理当定理看待,这是常犯的错误.

Adobe Reader 7.0的Linux中文版出来了:)

我的想法还没有完全的，离让自己满意都还差得很多，感觉没有理论基础（当然实践就更不足了），所以才会有SNOW这个项目，也是对自己的一个挑战，但现在分析过后发现，就是因为是练习程序才会使项目做这么久（当然这还是后话）。

王Sir的设计方法成熟多了（就是没有方法），看过一些之后只能用“犀利”来形容了，回头再看一些其他的项目，例如“Unix...”等，同样是犀利的。我受到 java （特别是J2EE，或者说 Framework）的影响过大了，设计总是很臃肿复杂度甚至超过HMVC。

SNOW还在总结中，项目一定会完，总结也一定会完。

之后的内容大概是：
2 软件过程
3 功能蔓延
4 认知失调
5 生活态度
6 推倒重来
7 全都没必要！

记得有n次跟同学们聊天的时候很悲哀的说过：“程序员的必要品质之一就是世故，可我现在还做不到”，当然我指的是在工作时，从没有被了解过，但我相信随着时间的推移（当然还有努力），在“达到完美”和“放弃完美”之间必然会做出选择。

APH  的帖子就是这么耐看,虽然我看不太懂,但是,还是忍不住摸索那种概念.
我不懂传说中的大软件编程,但我会是一个非常好的软件使用家, 等你的冥思录划上句号的时候,给我用用哦

还有阿,我说最近恁怎么回事,原来是在干这个, 如果要考研的话,赶快努力吧
有空翻翻我的BLOG，我刚做好，也要开始写文章了

to KMWANG：

Adobe Reader 7.0的Linux中文版出来了:)

早就出来了 ftp://ftp.adobe.com 上能搞到

顶 --------------------
http://evita.512j.com

什么是好的设计?

我不太会抽象概念,只是觉得能够为实现提供方便的设计,就是好的设计.

Unix是完美的设计吗?

APH君,请熬夜把2-7写出来.

我们大家总结一下,当作8.

引理与定理有什么区别？ -------------------- I like running

mumu的意见很中啃呢，我也认为能让我顺利开发的设计就是好设计了，其实最重要的就是解耦了，以我的性格（心重）总是容易钻牛角尖的，而且总是在编程中考虑太多的旁枝末节，导致抽象去适应物理，SNOW实际上就是一个针对心理和实践的训练，坦白说我觉得自己做的很不好。

Unix不完美，但是很优美。

编程真的与心理无关么？我不这么认为。


另外熬夜写嘛，痛苦了一点吧：）
[ 2005-06-02 00:32:13 ApH 修改 ]

引理与定理有什么区别？--------------------I like running

我是这么想的，引理（或称推论）是定理为了在某种具体情况下方便使用而做出的变体，并不是定理本质（因为为了迁就具体情况，导致抽象层次不足）。

可以认为定理是软件中的逻辑设计，而引理是软件中的物理设计。

另外在学习数学的时候总是会觉得引理比定理在解题的时候好用，就是因为比较具体吧，但是发现在建模的时候引理基本上就见不到了，这时候抽象就显出好处了。

心中尚有剑.

是不是这阵子书看多了,消化不良?

快把2写出来,要不大家就打板子了:)

是不是这阵子书看多了,消化不良?

确实消化不良，觉不觉得我廷迂腐的？

确实消化不良，觉不觉得我廷迂腐的？

建议找工作的同学背背我的文章，面试或者毕设一顿狂砍，绝对没问题：）

引理是道可道,定理是非常道:)

快把2写出来,要不大家就打板子了:)

一还没完呢。

引理是道可道,定理是非常道:)

真经典，真经典，真经典，真经典，真经典，真经典，真经典，真经典，真经典，真经典！

想说的就是这个意思，废话一大堆，还是道德经管用呀！
[ 2005-06-02 01:16:01 ApH 修改 ]

要是听我分解老子所说的"道在屎尿之中"的意思,估计就晕了.

屎尿当中谓之道.

嘻:)古人不余欺也!

建议找工作的同学背背我的文章，面试或者毕设一顿狂砍，绝对没问题：）

先拿来蒙老师好了～
工作是必须的～ -------------------- There are Pretenders among us.Geniuses with the ability to become anyone they want to be.

前天買了本蔡學鏞的《JAVA夜未眠》。
程式師的胡言亂語罷。因為版稅都有眷顾捐給兒童基金，買就買了。 --------------------            [a=http://northlight.digital-pulse.net/]寻找失落的路灯 @ North.Light[/a]
   有沒有事比死更容易? 有沒有事比活更難?
               ~     幸福是一雙溫暖的紅唇    ~

APH  你的文章赶快全部都帖出来，我也来做个index， 这个可是面试 毕设 狂喷的料子 哈哈 --------------------
http://evita.512j.com

再次顶起！

受人之托再来找APH的SNOW, 不知道现在进行得怎样了~

再次想到设计的问题, 现在呆的单位根本不谈什么设计架构之类的, 就是手工作坊, 是刚出了虎穴又进了狼窝啊~~

最近做的东西也很没水平~~经常以"产品(部门)需求不明确"为由赖帐~~

结构乱得可以, 就算是通讯这件事在不同的阶段都用了不同的方法来实现, 如果要更改是要头晕死人的~~

又有多少人掉进设计的陷阱了.