code craft_软件,美学和Craft.io:Java,Lisp和敏捷如何塑造和反映其文化

code craft

重要要点

  • 软件行业在建筑和构造上标榜自己的风格,但很少讨论美学
  • 美学不仅关注事物的外观以及它们是否取悦我们:它还可以关注社会的基本方面以及它们的表达方式,就像约翰·鲁斯金(John Ruskin)对建筑风格所做的那样
  • 与建筑物一样,我们使用的工具和方法也充分说明了使用建筑物的人以及他们的生活
  • 通过考虑工具和方法论对使用工具和方法的工匠的立场,我们可以扩大我们对工具和方法的优缺点的争论。
  • 当以这种方式考虑时,可以以一种新的视角看待关于编程语言,敏捷性和用户体验等主题的辩论,从而使工程师和用户处于中心位置。

软件业充斥着从建筑和构造中借来的隐喻。 我们甚至称自己为建筑师和工程师,拥有项目计划和可交付成果,就开发方法和项目治理进行辩论,就像建造者一样,在时间和材料工作与零碎工作之间进行争论。

尽管有大量关于建筑美学的文献,但是很少讨论软件的美学。 在这里,我不是在谈论网站或移动应用程序的设计,有关它们的讨论已经很多。 在本文中,我想介绍维多利亚思想家约翰·鲁斯金(John Ruskin)的体系结构理论,并将其应用到软件中,以浮出水面我们无形地接受的基本哲学,并从此出发,就我们所用的语言提出质疑。使用和敏捷运动。

首先,让我们尝试了解两个基本体系结构概念之间的区别。 听起来可能很简单,但是很快就充满了烦恼。

哥特与古典—快速入门

如果要求您用两个字描述下图所示的两座建筑物,则可以分别选择“古典”和“哥特式”。

宽松地说,古典建筑看起来“整洁”,“有序”,“简单”

而哥特式建筑看起来“华丽”,“繁忙”,“复杂”。

因此,可以肯定,要为古典建筑和哥特式建筑提出清晰的正式定义不是很难,不是吗?

事实证明,这非常困难。 例如,您可能认为古典建筑是对称的,而哥特式建筑是不对称的。 不过,找到不对称的古典建筑的反例并不难,而且许多哥特式建筑都是对称的。 您可以争辩说,空中扶梯是哥特式建筑的主要特征,但是伦敦的圣保罗大教堂有空中扶梯,并且该建筑物被普遍视为古典传统(特别是英式巴洛克式),等等。

但是,您不必查看表面细节即可确定某件东西是否是哥特式的。 这是约翰·鲁斯金(John Ruskin)进来的地方。

约翰·罗斯金

约翰·拉斯金(John Ruskin)是维多利亚时代有影响力的思想家。 如今,几乎没有人听说过他,但是他的艺术作品在当时很受欢迎,他因影响托尔斯泰,普鲁斯特,甘地,工党和福利国家而受到赞誉。

在整个艺术史研究中,罗斯金认为建筑的外在形式并不是使它们成为哥特式或古典主义的原因。 相反,他认为,它们的不同形式与创造它们的社会息息相关,其社会质量应作为判断其美学的依据。

为此,拉斯金确定了几个更基本的配对元素,这些元素加在一起构成了他所认为的哥特式和古典美学。

哥特 古典
有机 “理想”
React灵敏 柏拉图式的
历时性(随时间变化) 同步(固定的“快照”)
个人 集体
人规模 企业规模

关于建筑的讨论,“有机的”与“理想的”,以及“响应式”与“柏拉图式”,可能会引起一些从事技术工作的读者的钟声,因为它接近埃里克·雷蒙德(Eric Raymond)的《大教堂和集市》中的中心隐喻。

在那本书中,雷蒙德将大教堂的“自上而下”(古典)设计与集市的“自下而上”(哥特式)设计进行了对比,并将它们用作不同类型软件开发的隐喻。 他谈论了各种自由软件开发,特别是集中控制的贡献和发行与Linux风格的分布式贡献和发行。 在这里,我想将其扩展到任何类型的技术,无论是物理还是虚拟的,开放的或封闭的。

有趣的是,雷蒙德称集市为“革命性的”,因为罗斯金用这个词来形容他偏爱哪种建筑风格(或称“装饰品”)。 他将装饰物分为三类:

  1. 奴隶装饰品,其中下等工人的处决权或权力完全受上级政府的管辖
  2. 行政劣势在某种程度上是解放和独立的,具有自己的意志,但承认其自卑并服从上级权力的宪政装饰
  3. 革命性的装饰品,绝不承认自卑

对于Ruskin来说,物体最终看起来像什么,或者它本身是否令您满意并不重要。 重要的是工匠在制造时有多少自由度。 工匠拥有的自由越多,他得到更高权威的奴隶就越少,而产生这种自由的社会就越人道。

拉斯金的分析和看法影响深远。 例如,二十世纪的极权主义国家热爱古典建筑(及其自然继承人现代主义建筑)并非偶然。 在这些州,每个人的贡献都必须服从于整体,这反映了所有人对更高事业的服从,而体系结构则反映了这一点。 更多的民主国家倾向于避开纳粹德国斯大林主义俄罗斯的极端古典主义 。 特朗普政权最近关于建筑风格的指令是对这些政权口味的有趣回响。

编程语言

这和软件有什么关系? 就像架构一样,关于“最佳”编程语言是什么的争论也不少。 但是我认为我从未听过关于语言的辩论,辩论围绕语言所鼓励或支持的文化。

让我们以Java之类的主流语言为例。 Java是相对限制性的,并且对应如何使用它有自己的见解。 它的原始设计旨在鼓励工程师将问题的解决方案推迟到其他类别的对象。 语言的整个哲学并不是为了鼓励个人创造力或表达能力。 当我想到一个大型Java项目时,我想到的是团队要按照集中定义的规范工作,并且要在集中定义的框架内交付符合规范的代码。 Java从一开始就设计为倾向于简化,甚至在Java语言规范中都有说明:“它设计得足够简单,以使许多程序员都能熟练使用该语言……它旨在成为一种生产语言,而不是一种研究语言,因此,正如CAR Hoare在其有关语言设计的经典论文中所建议的那样,该设计避免了包含新的和未经测试的功能。”

相比之下,以前流行的语言Perl的中心宗旨是“有不止一种方法可以做到这一点”,它是一种积极鼓励和庆祝个人创造力的哲学。 这不能使代码可读,因此经常开玩笑说Perl是“只写”语言。

同样,在这种规模上,您还可以使用Lisp和TCL之类的语言,这些语言可以赋予个人贡献者自由和权力,让他们按自己的意愿去做疯狂的事情,例如自我修改代码或重新定义语言本身的基本组成部分

但是,Java胜过了其他更具创造力的语言。 为什么? 因为,尽管给个体软件自由以手艺的人可以实现伟大的工程和美感,但是当您试图将大量不同的工程师团队聚集在一起进行协作时,这付出了巨大的开销。 在所有其他条件相同的情况下,由于Java在其核心中强调简单性,因此大多数工程师可能希望承担一个庞大的Java项目而不是一个庞大的Perl项目。 换句话说,软件的美观和复杂性不利于工业生产。 使用更具限制性的工具并为问题创建不太美观的解决方案更便宜,更容易。

我并不是要说Perl很棒而Java太糟糕了。 我想表明,我们的喜好不是无辜的,它反映了我们应该反思和意识到的更深层次的信念。

我发现有趣的是(考虑到它的时代和广泛采用),Java并不是GitHub上使用的编程语言的失控领导者,而Python,Javascript和Go项目比比皆是。 我忍不住想,因为在我们的业余时间里,我们想开发一种语言,使我们可以自由地发挥创造力(尽管Go在其限制方面类似于Java,但它仍然具有大量的创造力“绿色领域” ”)。 相比之下,Lisp几乎没有在GitHub上注册。 您可能会有太多的自由,而没有某种中央设计的集市通常是一团糟。 人们通常发现Lisp相当困难。

出于类似原因,建筑中的古典主义一直存在。 在英国,其统一性和明确的规则使那些追随开拓者的建筑师( Inigo JonesChristopher Wren )能够创作出价格低廉的作品,看起来足够时髦。

甚至还有“ 设计模式”之类的古典建筑书籍。 Vitrivius Britannicus ,出版于1715年,为建筑师提供了一本易于遵循的实例的抄本,用于在英国(以及后来的美国)建造遵循相同样式公式的豪宅。

这种风格被称为Palladianism,由于无所适从,只要您了解基本知识:保持事物对称,多条直线和具有单调特征的墙壁,就变得无处不在。 这种样式体现在建筑物中,是Java而不是Perl:相对容易构建且足够令人愉悦的外观,但并不丰富多样。

不过,看起来建造者并不觉得很有趣。 您可以想象,泥瓦匠将檐口逐个击落,几乎都是一样的,而一个孤独的雕刻家不得不将她的一些作品放在建筑物的顶部,很少有人能欣赏它们。

维多利亚时代的哥特式建筑也采用了类似的技巧。 通过以统一且廉价的图案书方式复制哥特式装饰的图案,他们激怒了Ruskin,Ruskin感到自己错过了哥特式的要点,将表面装饰特征误认为美的基本原理。 我长大后去东伦敦的教堂看起来像这样:

这些本质上是古典建筑,带有一些尖拱形窗户和彩色砖块,而不是圆柱和大理石,以使它们成为“哥特式”。 那里“个人工匠”的创造力没有太多出口。

敏捷和哥特式

这带给我敏捷。 就像罗斯金(Ruskin)偏爱哥特式(Gothic)一样,敏捷的最初陈述意图只是从第一条原则得出的:

我们正在探索通过开发软件并帮助他人开发软件的更好方法。
通过这项工作,我们开始重视:
个人与流程和工具之间的互动
通过全面的文档工作软件
客户合作而非合同谈判
响应计划变更
也就是说,尽管右侧的项目有价值,但我们更重视左侧的项目。 ( 敏捷软件开发宣言

这些原则紧随Ruskin的思想,认为良好的工作来自有机的,人类的基础:

  • 2- “拥抱变化”几乎是在接受有机变化,而不是坚持理想
  • 4 –创意的构建过程需要与赞助者紧密合作:要求也是有机的
  • 5-强调个人对整体产品做出贡献的重要性
  • 8,11,12 -强调整体产品的个人关系的重要性

这些原则中有许多与难以自动化,定义,工业化或模式化的事物有关。 这是一种鼓励使用便利贴或大张纸的哲学,如果需要正确的前进方向,则鼓励只喝啤酒。 在没有规则和监督的情况下,它更接近自下而上的哥特式,“集市”,“革命”和协作的工作方式,而不是自上而下的极权主义古典主义,“大教堂”式的工业服从风格。

您如何回答最喜欢的高科技水冷式对话:您的团队敏捷度如何? 我建议这个问题:团队可以自由地做出认为完成工作所必需的任何决定?

现在,自由与事业并没有齐头并进。 这就是为什么最终使用企业敏捷的原因:

在每个方面,企业必须满足公司,法规和法律的要求,以减轻个人为整体做出不完美贡献的能力。 所以别再尝试了,该死! 最终,您将颠覆整个话题 ,正如敏捷创始人Dave Thomas所 讲的那样。

我想在这里说明的要点之一是,如果您要实现的目标是死记硬背可以完成的事情,或者您需要命令和控制来交付商品,那么不敏捷就没有错。 如果个人的成就,创造力或创新能力不是主要问题,那么就拥有它,并确保整个项目是人们可以理解的,例如Palladian建筑。 仅仅为了它而放弃尝试变得敏捷。

现在说实话:有多少人可以现实地理解这一点?

味道,人性和不完整的片段

我认为这是一栋美丽的建筑,即使它可能是古典和“理想”的:

布拉曼特的诱惑

我认为这是因为,尽管不破坏它的设计就不能动弹,而且可以说没有人可以表达自己对主题的理解,但是建筑物的规模仍然是人类的:它是为人们设计的并考虑其他人的灭亡。

与大英博物馆比较:

大英博物馆:这栋建筑物说:“我们有您的东西,我们不会退还。”

这是我一直讨厌的建筑物。 与庞大,不人道的规模相比,它的设计旨在使您感到渺小和不完美。 这也很无聊。 列,列,列,列一直到处。 顶部的雕塑可能很有趣,但似乎并不是为了让您仔细观察而设计的。

我不能说比拉斯金更好:

“哥特式建筑学派的主要令人钦佩之处在于,他们因此获得了卑鄙的思想的成果;并摆脱了充满缺陷的碎片,并在每一次接触中都背叛了缺陷,因此沉迷于一个庄严而不可指责的整体。”

如果我们不是一味地遵循曾经曾经在其他地方为其他人工作过的模式手册和货运培训开发方法,而是我们创造性地-并且不完美地-将我们的知识和经验运用到了我们的当地人身上,这是否会创造一个更好的社会和更好的软件?和独特的情况,创造出新颖,美观的解决方案,不仅可以“增值”,还可以为我们带来乐趣? 毕竟,如果我们是任何人,那我们就是“缺陷的片段”。

翻译自: https://www.infoq.com/articles/software-aesthetics-craft/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

code craft

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SELECT bs.report_no, bs.sample_id, bs.test_id, bs.service_type, bs.sample_name, bs.total_fee, bs.receivable_fee, bs.sample_no, bs.ranges, bs.grade, bs.sample_remark AS remark, bs.factory, bs.item_name, bs.apply_dept, bs.specification, bs.factory_number, bs.calibrat_point, bs.mandatory_flag, bs.inspection_type, bs.report_org_name, bs.plan_complete_date, bs.standard_instrument_name, bs.bleeding_site_name, bs.arrive_date, DATEDIFF( bs.plan_complete_date, NOW()) AS surplus_days, bs.order_no, bs.order_type, bs.customer_name, bs.order_id, bs.business_type, bs.group_id, bs.group_name, bs.item_id, bs.is_merge, bs.pass_time, bs.audit_time, bs.report_id, bs.compile_time, bs.generate_time, bs.pass_user_name, bs.audit_user_name, bs.compile_user_name, bs.report_state, bs.is_just_certificate, bs.label_price, bs.labor_cost, bs.product_type, bs.batch_number, bs.original_number, bs.type_no, bs.template_id, bs.template_version, bs.standard_instrument_id, bs.standard_instrument_name, bs.report_query_code, bs.test_user_id, bs.test_user_name, bs.test_time, bs.review_user_id, bs.review_user_name, bs.review_time, bs.or_number, bs.test_result, bs.test_result_text, bs.test_date, bs.test_address, bs.result_value, bs.unit, bs.test_dept_id, bs.test_dept_name, bs.sample_mass, bs.form, bs.color, bs.clarity, bs.amplification_detection, bs.precious_metal, bs.remarks, bs.photo, bs.identifying_code, bs.diamond_quality, bs.hand_ring, bs.craft, bs.instrument_photo, bs.customer_item_basis, bs.quality_photo, bs.check_point, bs.check_code, bs.mass_unit, bs.manufacturer_name, bs.manufacturer_addr, bs.result_sample_describe AS sampleDescribe, bs.test_rule AS metalRuleIdsStr, bsa.attach_id FROM view_sample_info bs JOIN bus_sample_report bsr ON bs.report_id = bsr.id JOIN bus_sample sa ON bsr.sample_id = sa.id JOIN bus_sample_attr bsa ON sa.id = bsa.id 需要按照bs.report_no 的整数来从小到大进行排序
07-15

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值