少就是多

rails A
cd A
rake db:create:all
ruby ruby script\generate scaffold A B:string C:text
rake db:migrate

你认为我刚才做了什么？

没有了名称的提示，只有A、B、C这样的变量名似的东西，那么这个程序就没意义了吗？

给大家充分的讨论时间，然后我说我的看法。做个提示，这个讨论是关于产品化设计，程序结构与需求，也许还可以包括平台设计。可以将这个帖子看作我在最近参加的几个讨论挖的坑，现在开始种树了。

就谈谈鄙人对产品化设计的观点。
产品化设计问题的对象是客户。对客户要分析，产生自己的意图，依据意图去设计。在程序这边，把程序员也要分层次。当然对客户(这个是重中之重)，更要分层。我认为要把重点放在对客户上。至于对于程序员这边怎么分层次,要有一套固定的东西。这边固定下来，把程序员的重点也迁移到客户这里。分析面对的是什么层次的客户。对各个层次的客户做程序。
程序员这边的代码，什么风格,倒不是很重要，要紧的是大家都能摸得清棱角。从习惯出发？从简约出发？不同的团队都有一套固定的东西，去摸索，一但形成固定的东西，就要保留下来。

看看没什么人回就知道，06z 这个关子卖得太那个了。

玄之又玄，太玄啦~~
就我来说，我还是会比较详细的采集需求，根据应用抽象出业务框架，开始设计，我目前也无法判断我的设计的东西是多是少，只能把想到的情况拿出来印证，实际上往往少于实际的需求，一般我会再去抽象出一些对象，保证框架的灵活性，由于经验和能力限制，我也无法提炼出有效的通用框架，只是借鉴已有的系统而已，并且尽可能的多考虑，防止设计的不完备导致“不断打丑陋的补丁”这种情况发生。

mkdir A
cd A
copy "rals from 'B:string C:test'" then paste to A
make A persistable