我感觉有时候往往出现这种情况,代码越美观,结构越好,或者用了更多的设计模式,会大大的增加人对业务逻辑的学习和接收难度,这是怎么回事?
fucktwice · 2013-08-20 09:40:34 +08:00 · 3079 次点击这是一个创建于 3895 天前的主题，其中的信息可能已经有所发展或是发生改变。
也就是说,好的代码容易会把业务逻辑分散开来,在不断进化过程中.
我有点好奇和郁闷
我有点好奇和郁闷
 |
1
ipconfiger 2013-08-20 09:58:21 +08:00  3
这个时候说明你已经被“设计模式”带沟里去了，哈哈。
|
 |
2
fangzhzh 2013-08-20 10:32:00 +08:00 via Android
设计模式一般就是把易变的东西抽象出来 抽象一层复杂一层
|
 |
3
luikore 2013-08-20 10:53:01 +08:00
"美观", "好" 是因人而异的主观概念
抽象必然导致难懂, 设计模式, 是给不懂抽象的人来装懂用的 |
 |
4
otakustay 2013-08-20 11:43:10 +08:00 1
学习和接受难度是一回事，学完了以后的工程效率是另一回事
学习曲线陡峭不代表完成学习后依旧要艰难地进行开发 工程师最终负责的应当是整个系统、产品的生产效率，而学习只是其中的一部分，并不是全部 |
|
6
otakustay 2013-08-20 15:42:43 +08:00
@fucktwice 结论我已经表达了啊，代码美观、结构好，代码的仅仅是“学习难度有所提升”，但学习完成后，开发的效率是有非常大的优势的
比如不美观结构一条线的代码，学习只要10天可以上手，以后一个功能开发5天 而美观结构好的代码，学习用了40天，以后一个功能只要2天 这么一算，10个功能是一个转折点 所以我还是更倾向于代码美观和结构合理，除非你们想当临时工 |
 |
7
levn 2013-08-20 16:14:22 +08:00
应该有结构好同时也更容易理解的吧。
|
 |
8
chisj 2013-08-21 12:38:21 +08:00
模式就是为了让代码更好理解和维护的，不然就是耍流氓。
|
|
11
luikore 2013-08-21 13:51:54 +08:00
@ksc010 模式和 vim 完全相反: 用了模式后, 总代码量会增加, 但用了 vim, 总按键量会减少.
如果一个模式可以重用, 它就是个 api call 而不是模式了. 模式说白了就是复制粘贴一坨东西然后改改名字调个顺序, 这就违反了软件设计的三原则(DRY, KISS, YAGNI)之一: don't repeat yourself. 随着编程语言不断添加特性和库的增强, 需要用到模式的场景会越来越少. 语言的特性需要学习去理解, 模式就是个类比根本就不存在学习这回事(个别名字起得很晦涩的模式除外)... 模式在不会模板元编程的 C++ 程序员和不会函数式编程的 java 程序员中特别流行. 就 java 说, 很多模式要做的事情现在直接加个 annotation 就可以了, 不需要一遍又一遍的重复拷贝那些错漏百出的实现... |
 |
12
fucktwice OP @luikore 模板元编程 这个本来就需要花很大功夫去学习的, 你说的是把代码的重复用语言特性去减少,但是大多数的语言在OO方面都是类似的.
这个.... |
|
13
otakustay 2013-08-21 14:36:08 +08:00
@luikore 赞同“难学就容易维护升级就错了”，但这并不代表“难学就一定不易维护升级”，一定的学习代价确实能换来未来维护升级的优势，我个人也并没有针对楼主单个案例来表明“一定是后续易维护所以你要忍受着”这样的态度，可能是信息传递有些问题。
另外，如果说模式就是“复制粘贴一坨东西然后改改名字调个顺序”，只能说对模式的理解还只限于照着书抄Design Pattern的程度，尚为肤浅。 语言和库的增强，只是将模式变得更容易使用（通过语言特性等解决，比如事件之于观察者），但并不代码就不用模式。如果没有对观察者模式的理解，一个工程师可以设计出使用事件的系统？总之我不这么认为。 |
|
14
luikore 2013-08-21 15:02:07 +08:00
@otakustay 反了, 是先有工程师设计出了使用事件的系统, 然后才被人总结成设计模式...
在表达力比较弱的语言里, 用设计模式写的 XxxSingleton, 就得自己写 getInstance. 抄/背诵/IDE生成和拷贝粘贴是一回事. 用元编程实现的 XxxSingleton, 你不用自己写 getInstance, 它实际上就是个 API call 了, 叫不叫设计模式都没影响, 也避免了无谓的重复. |
|
15
otakustay 2013-08-21 15:06:39 +08:00
@luikore 设计模式和模式是两回事，事件系统的出现就代表了“观察、订阅、分发”这一模式，随后被总结为“设计”模式，仅仅是挂了个名字并总结出一个共性
我们一直在谈的，是“模式”，而不是“设计模式”，这两者有很大的区别。无论是架构、设计还是开发过程，模式是始终贯穿的，而设计模式仅仅是对模式的一种常见的表达方法，取其优而去其粗即可。 所以我才说对“模式”理解成“复制粘贴一坨东西然后改改名字调个顺序”，那就等同于把“模式”和“设计模式”混为一谈，并不是一个值得推广的思路吧 |
 |
16
msg7086 2013-08-21 15:32:21 +08:00
比如说吧，RoR，之前我学习的时候感觉非常累。但是做开发的时候用PHP写很久的代码，RoR很快就能写完了，各种框架包办。大概就是类似的感觉吧。
|
|
17
luikore 2013-08-21 15:41:54 +08:00
@otakustay 我一直指的设计模式. 广义的"模式", 含义太广泛, 不是 well-defined 的概念没什么好讨论的...
一种是正常人的思路, 看到问题去想怎么解决, 然后自然形成的代码结构和项目结构, 容易看懂容易改. 一种是架构太空人的思路, 先套用各种模式作出结构来, 再把问题交给别人解决, 太空人的理解(我们常常把"习惯"当"理解"用)和一般人区别越大, 就越难看懂和修改. |
|
18
luikore 2013-08-21 16:15:02 +08:00
@otakustay “观察、订阅、分发”模式 也是一个类比的设计模式(有人会把它升华到"夹沟模式"), 除此之外什么都没有说, 看到的人可能以为自己"理解"了, 但其实最后看代码才知道是什么回事. 两个人脱离实际讨论一个假大空设计模式, 很可能说的完全不是一回事, "这类概念可以交流"是个错觉而已.
光就 pattern 这个词来说, 在 "设计模式", "代码模式", "模式识别", "模式匹配", "正则模式" 语境下意思各不相同. 还有博大精深语把 mode 也翻译成 "模式", 进一步把浆糊搅得更浑, 造成微妙的"深刻"的错觉. 你说的"模式"如果不是设计模式, 那到底是什么? 如果没有一个人人都同意的准确定义, 那这个概念就是不值得讨论的, 也无法对我们的代码产生有意义的影响. |
Select Language