原创: 陈光剑 Kotlin 开发者社区 今天
起
好作品是改出来的,好的代码是不断重构打磨出来的, 心性是历经艰难困苦修炼出来的.
好作品是改出来的。初稿仅仅是将你的想法与灵感倾泻于纸上,而修改则是你对内容进行再次的思考与梳理的过程。你花费的精力越多,你的作品才越有机会成为一部好作品。修改不光指用词用句的讲究,它涉及到写作的方方面面,包括你的人物设计是否立得住、情节起承转合的安排是否合理、故事是否落入了俗套,等等。然后呢,我发现这写代码的道理是相通的。
"人" 这个大自然的伟大作品,是宇宙天道历经亿万年的演化/进化才打到今天的境界. 这其间有多少细节的打磨,只有天知道.
这在软件架构设计领域,道理也是相同的. 大师级程序员,那必须是积年累月地投入. 相信马克思说的: "量变引起质变".
创作过程
构思(idea) -> 实现(implementation) -> 交互(interaction)
a.将概念结构成定形
b.在实际的领域中实现
c.实际应用
无论是一首诗,一本书,一台计算机,还是一个程序, 一座建筑, 都源于一个"机灵",构思于时空之外.只在创作者头脑中完成.尔后,通过钢笔,墨水和纸, 或者硅和金属,在实际的时空中实例化.再然后, 有人读了这首诗,这本书,使用了这台计算机,运行了这个程序, 走近了这座建筑, 从而与创作者的思想产生了"灵魂"交互.
君不见,黄河之水天上来,奔流到海不复回。君不见,高堂明镜悲白发,朝如青丝暮成雪。人生得意须尽欢,莫使金樽空对月。天生我材必有用,千金散尽还复来。烹羊宰牛且为乐,会须一饮三百杯。岑夫子,丹丘生,将进酒,杯莫停。与君歌一曲,请君为我倾耳听。(倾耳听 一作:侧耳听) 钟鼓馔玉不足贵,但愿长醉不复醒。(不足贵 一作:何足贵;不复醒 一作:不愿醒/不用醒) 古来圣贤皆寂寞,惟有饮者留其名。(古来 一作:自古;惟 通:唯) 陈王昔时宴平乐,斗酒十千恣欢谑。主人何为言少钱,径须沽取对君酌。五花马,千金裘,呼儿将出换美酒,与尔同销万古愁。
datas segment
x dw 1234h
y dw 5678h
z dw ?
datas ends
codes segment
assume cs:codes,ds:datas
start:
mov ax,datas
mov ds,ax
mov ax,x
add ax,y
mov z,ax
mov ah,4ch
int 21h
codes ends
end start
柏拉图: 何为实在?
面向对象的编程思想, 追溯到源头, 得到柏拉图这里.
苏:那么下面我们还是用惯常的程序来开始讨论问题,好吗?在凡是我们能用同一名称称呼多数事物的场合,我认为我们总是假定它们只有一个形式或理念的。你明白吗?
格:我明白。
苏:那么现在让我们随便举出某一类的许多东西,例如说有许多的床或桌子。
格:当然可以。
苏:但是概括这许多家具的理念我看只有两个:一个是床的理念,一个是桌子的理念。
柏拉图,理想国,卷十
那么,这里的"床的理念","桌子的理念"是不是跟OOP 中的"类"(Class) 是一个道理?
设计树
人类大脑的思考过程分为理性的逻辑思考跟感性的直觉判断(我自己写的, 后来发现笛卡尔跟我讲过类似的话: 人类两种最基本的认知方法: 直觉与推理.).
逻辑思考过程是一棵决策树. 架构设计的过程就是最优遍历这课树,目标就是: 简单,经济的结构.
很多时候,问题就在于不知道问题在哪里.
认知局限性
很多时候,人们局限在自己的认知框架内,无法跳出. 要么概念认知不清晰,要么模型边界模糊.
设计中最难的部分, 就在于确定要设计什么(认识这个世界是最难的,当然,自己也是这个世界的一部分,所以认识自己最最难).
对于复杂的系统,复杂的结构,我们人脑不可能一下子就能全盘细致考虑好,设计出完美的方案来. 通常是: "一边设计,一边探索, 不断打磨."
这个过程,就像自动控制理论中的"负反馈"伺服系统一样. 在不断变化中享受乐趣. 人生的过程又何尝不是如此呢?
放眼到整个宇宙苍生,也是一样的道理.
例如, 在人体中正常的甲状腺激素调节机制就是负反馈调节:
协作与解耦
两人互动产生的思想是原来的两倍,原创性思想也是原来的两倍,同时增加了快乐, 加深了人与人之间的沟通和了解. 如果是一对俊男靓女,说不定还会造出下一代. "为人类繁衍生息之大业贡献力量."
"开会是为了逃避枯燥无味的工作和孤独的思考".
"婚姻"是人类了不起的发明,有说不完的故事.
"爱情"这个概念是更伟大的创造. 可见"协同"的重要.
大自然造物的时候,早就设计好了食物链, 雌雄争霸,相爱相杀, 秋月春花, 美人芳华.
设计制造一辆汽车,一架飞机, 一台计算机都是人类复杂工程.
领域模型: 宁错勿混淆
错误可以让我们很快接近真理,而混乱则不能
培根
如果没有定义明确的模型, 就会陷入一锅粥.
即使是错误的假设, 也比含糊不清的假设来的好.
错误的假设可以通过质疑来得到纠正,而含糊不清只能是越搞越糊.
国内第一Kotlin 开发者社区公众号,主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。