画与软件项目

 　　这篇博客开始写很久了，都已经在我随笔列表的第三页了，然而因为各种原因一直拖着没有写完，所以下面可能出现的最近未必是真的最近。还有最喜欢的两幅画没放进来，有些遗憾，分别是现藏于中国美术馆的万山红遍层林尽染和常熟田。因为一个意外的契机开始，很长时间以来不断的去各种画展，有美术馆、画院，也会去私人的画廊。虽然看不懂，但是毕竟好看的不好看还是能看出来的、赏心悦目，懂不懂什么的……。艺术可以触动人的感性思维，我就属于感性思维有缺陷的，期望能被艺术品感染一下，弥补点这方面的缺陷，或许也能借他山之石在技术方面有所感悟也未可知……吧，总之既然能感受其中的美目前也就足够了，就像某个段子说的，喜欢吃冰淇淋并不需要先学会制冷。看的时间长了就会有一些与自己工作相关的感触。另外，在听一些数学、力学课的时候，偶尔会意外得听到一些关于艺术的认识，我觉得很适合先给大家看一下。

　　莱布尼茨：音乐，是人类精神通过无意识计算而获得的愉悦享受。

　　下面这张图是我听北理工力学课的时候，截下来的一张截图：

其实开始没什么感觉，只觉得是水边倒影，直到走到这个角度：

　　画名很多时候是核心概念的表达，相对于软件是系统的核心价值，业务方的表达倾向于描述现实他们需要的功能，而这可能并不是软件真正的需求，有时候在需求说明书的不起眼套路段落中，有时候甚至不会出现。他们的目的或许是加快工作效率，或许是限制职能权限，或许是调整业务方向，如果不确认好真正的目的，只按他们对现实的描述去做，绝大多数时候会导致后期大幅调整，这一点不只是业务，在技术理论中也是一样的，某一处差之毫厘，整个系统谬以千里。

　　这幅画也是在中国美术馆看到的，时间由点长了，没记错的话画名叫蓝天，作者是张立国先生。这幅画最重要的部分很显然左上角的一小块蓝天，能说明它是蓝天模型的也只有一小块云，或者还有它的位置，然而已经足够表现出它作为核心子领域的业务概念了；这幅画的架构清晰，表达出来的业务对象也非常明确，但并没有去逐渐贴近现实去建模；三面围墙（姑且认为是墙吧）和墙下之人以及一点蓝天就是整幅画，画中之人或许在望天或许是渴望轻松自然；墙的颜色不同，也或许是现代化的生活筑起的高墙隔开了人与人之间的关系，然而他们或许都是向往着同一片蓝天，当然三人也可能在同一件屋子中。至于究竟如何，或许不重要，每个人的触动或许也是如人饮水冷暖自知，看懂画家在画什么并不重要，只要对画有所触动，便也算没有白看，画的价值也在与此。清晰的架构和业务模型，更利于表达相对清晰的感情，至少我的感想被限定在了一个小范围内，而王先生那副画，有时看着像林间小路，有时候又觉得草树池塘，偶尔还会春绿秋黄，但一切都是为了最终目的，无题亦是主题，不能因为技术洁癖或对模型本身的最求而使目标有所偏差。一幅画要想感染人，我想画家并不是单纯的只想画得像，不然照照片就可以了；软件同样如此，我们开发软件目的并不是要让它做出现实人做的事，而是让用户借助它更好的完成工作。

　　刚刚提到了，好的模型一定是最简化的模型，大家都明白这个道理，但是做的时候，经常会不自觉的为了让模型看起来逻辑上更完整，更“合理”而增加些东西，例如群里曾经讨论过论坛帖子的回复是否要作为帖子聚合的对象，因为帖子删了，回复的存在可能就没有意义了，但是这个看起来逻辑上更完整的约束是否有价值就未必了。1+1=2，是因为抽象出了现实中的数量这一属性，但是如果一个1是男人，另外一个是女性，这1+1极有可能结果会是3，然而数学可不能这么算，所以业务模型的抽象与真实的现实，并不一定要统一。

　　到这可以先小结一下开篇的那个问题了，模型未必应该贴近现实，而是抽象出现实的某一部分，其实这也并不是很贴切，模型的目的是为了更好的实现整个系统，只是一般情况下这样更容易开发而已，关于部分抽象这事可以看一下下面的作品与现实的对比，我就不多说了，更何况一个完全不按现实去抽象的模型就一定不利于系统开发么，面向对象出现以前就没有好的软件系统么/p>

　　这个问题我的看法大概就是这样了，似乎这个结并不怎么小，不过就不要在意这些细节了。

　　开篇就是一张抽象画可能不是很容易找到方向欣赏画。其实小学就学过，万物都是有联系的。画和程序都是人创作出来的，既然不懂美术，可以试着从软件的角度来欣赏一副画，即使和原作者想表达的不同，只要能有所得就不算白看了，就像nginx，本来是个静态服务器，但是有几个人真是从静态服务器的角度用的。

　　最容易看明白的画当属素描了（其他如静物画和油画也多包涵浓重的感情色彩），我之所以觉得素描的传达的感情色彩少，主要是因为它多是一种记录写实，是真正作品创作前的一个标记，用来引导艺术家回忆起当时的感觉（不算学生练笔的），毕竟直接在荒山野岭画出成品来即使有素描版，多半也不会展出，我反正是没见过。也不是说素描一点感情色彩都没有，当然是有一定倾向的，但是我看不出来（极个别除外），手里画的图片太多了，常见的铅笔素描没翻到，但是找到了几张水墨写生：

　　先有一个大体方向，然后从主要部分开始，一点一点的丰满，再细化迭代。我试验过一些建模和落地的理论，其中在项目中最成功的应该属于测试驱动+T型功能导向集成（在功能构建中描述过）。比如人像，脸当然是最重要的部分，于是先构造出头部轮廓，再以头部轮廓为基础，逐渐延展开来。对于开发，我们就先开发最核心、稳定的模型和功能，以此为基础，逐渐开展相关的模型和功能，并根据实际情况逐渐调整，比如今天碳…不够…黑，就多图两笔…什么的。测试驱动开发也是一个非常好的实践，很适合辅助功能导向的集成。以单元测试组成业务的结构，也就是画的轮廓组成，最初的被测试方法内部可能只是返回了个伪造的结果，过程中也不一定时时刻刻都是完善的，脸第一次上色的第四幅看上去并不怎么好看，集成测试开始后，结合整个画面也可以看出到了第五幅脸似乎颜色有些过重了，就根据当时的具体情况对功能做一定的调整，为了项目的顺利完成，对需求和功能甚至于模型进行适当的删减调整也是必要的。当集成测试完成，色彩填充画的各部分的精神被联结起来，被单元测试过的代码内部实现丰满连通，画就完成了。

　　其实，我本来是想用齐白石老先生的草稿来着，那一系列草稿更明显更丰富，然而我没找到，那些草稿在画院，偶尔会展出，碰到的时候再说吧。对于上面这画，人像应该就属于核心子域，但是只有一个核心是不成的，其实经常也能看到一些不错的话，但是画面不够丰满，给人的感觉总想缺了什么的。 对这幅画来说，画面上的题字恰到好处。软件架构通常也是围绕着业务核心，延展出各个通用子领域，各部分相互独立，但并不能缺少。一旦某部分的业务膨胀，也可以将其独立为一个上下文，它对于原有系统是一个支持子域，对于自身也是一个核心子域。也有遇到过这种情况，一幅画上的题字特别漂亮，大家都不去关心主要部分的画，而是看字了，而既然被展出了，就说明了其艺术价值。这种情况也并不是坏事，比如互联网企业本身就是随着市场发展而变化，比如只去京东和亚马逊自营买东西，大家也少不了用支付宝。

　　核心子域和非核心子域在开发中投入的比重也未必一定是核心最重，比如上面的乾坤一草堂。我们在做项目的时候，每一层面都是在找一个平衡，因为平衡并不是有固定规律的，所以很多书才会说，软件是门艺术。我在网上听清华大学数学建模课程的时候，姜启源教授曾讲过，技术大致有章可循，而艺术无法归纳成普遍使用的准则。虽然姜教授是在讲数学建模，但我认为贯穿整个项目的每一个部分都是这样的，无论是需求与开发团队资源之间的平衡、模型距离现实远近之间的平衡，还是开发时实现的优雅与性能之间的平衡（当然，个别时候未必不可兼得）。这些平衡并无一定之规。比如下面这幅环保题材的画，小姑娘、彩色的气球、小狗、后面的烟囱、以及看不清后面是工厂还是废墟的影影绰绰，无处不是模糊与清晰之间平衡的体现，清晰一点或再模糊一些都未必能有如此效果。

——————————————————————————————————

公众号：

转载于:https://www.cnblogs.com/saaav/p/6486532.html

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92214 人正在系统学习中 相关资源：聚会喝酒看美女必备APP_秀人网-Android其他资源-CSDN文库

来源：weixin_30562507