包阅导读总结
1.
关键词：编程、版本控制、测试、抽象、持久性程序
2.
总结：作者分享了从 2015 年到 2024 年编程思想的变化，包括对抽象、测试、版本控制的态度转变，认为构建持久性程序很难，应专注简单、依赖少且不自动更新的软件，还提到面向数据的设计在高级别有用。
3.
主要内容：
– 作者经常在个人博客谈论计算机相关内容，并构建基础设施。
– 曾花时间重写程序核心部分，编程思想发生很大变化。
– 2015 年对抽象持怀疑态度，重视测试和版本控制。
– 2017 年重构 Mu1 为 Mu，逐渐不再使用相关新想法。
– 2022 年开发 Freewheeling Apps，从无测试到有测试再到删除测试。
– 作者认为构建持久性程序太难，不必尝试，应专注简单、依赖少且不自动更新的软件。
– 上下文微小变化会极大改变程序契合度，新程序易进入未知领域。
– 类型、抽象等是工具，会过度使用产生技术债务，理解稳定时可抛弃重做。
– 达到第 9 级时，面向数据的设计有用。
思维导图：
文章地址：https://mp.weixin.qq.com/s/wCOP6Rj0MHHSUjrMhkAJKg
文章来源：mp.weixin.qq.com
作者：CSDN
发布时间：2024/8/14 5:00
语言：中文
总字数：2556字
预计阅读时间：11分钟
评分：87分
标签：编程思维,软件开发,测试与版本控制,抽象,持久性软件
以下为原文内容
本内容来源于用户推荐转载，旨在分享知识与观点，如有侵权请联系删除 联系邮箱 media@ilingban.com
编写程序时，你有哪些特别关注的事项？随着时间的推移，编程思维是否会有变化？本文作者从其自身开发经验出发，分享他在编程时不同阶段的不同感悟，以下是他的思考。
原文链接：https://akkartik.name/post/programming-2024
我经常在我的个人博客上谈论如何自由地使用计算机、如何选择要使用的程序、如何判断一个程序是否是我们可以长期安全依赖的基础设施。我也花时间去构建这样的基础设施，因为外面这样的东西并不多。在此过程中，我时刻清楚地意识到自己并不擅长此事。充其量我只能说，我试图用良好且透明的意图来弥补自身能力的不足。
我刚刚花了一个月的空闲时间，断断续续地重写了一个我已经使用并逐步修改了两年的程序核心部分。从那以后，我就陷入了停滞状态。部分原因是我的潜意识在反思过去发生的事情，思考我从中学到了什么，并花点时间决定接下来该怎么做。但我也开始意识到，这一次，我的编程思想已经发生了很大的变化：
-
早在 2015 年，我对「抽象」（Abstraction）持怀疑态度，并对测试和版本控制非常感兴趣。当时总觉得代码中充斥着抽象真的是太糟糕了，而测试和版本控制似乎是 2000 年代程序进步的关键。我认为我们当时的程序代码有很多问题，这些主要源于不良的激励机制、过度使用抽象，而没有完全使用测试和版本控制。Mu1（https://github.com/akkartik/mu1）是我尝试设计的一个平台，旨在将测试和层（更像是版本，而不是抽象）作为基础约束，从而影响其他所有东西。
-
到 2017 年，我开始将 Mu1 重构为现在的 Mu（https://github.com/akkartik/mu）。一开始，我应用了所有关于测试（test）和层（layer）的新想法。但随着时间的推移，我逐渐不再使用它们。如今的 Mu 有大量的测试，但它们都是常规测试，我也一直没有移植我为层设计的基础设施。
-
到了 2022 年，我开始开发 Freewheeling Apps（https://akkartik.name/freewheeling-apps）。一开始，我没有做任何测试，但后来还是感觉不妥，于是我为一个核心部分——文本编辑器——写了详尽的测试。但我发现很难找到测试其他部分的方法，而且发现即使没有测试也能很好地运作。
-
现在是 2024 年，一个月前我删除了所有测试。我还开始彻底重构我的文本编辑器，这种做法在过去会让我担心与其他 Freewheeling Apps 的合并冲突。实际上，我不再考虑版本控制。放弃了测试和版本控制后，我最终得到了一款更好的程序。
经过几天的思考，我认为我对构建持久性程序的当前看法是：
-
对很多人而言，构建持久性程序太难了，根本不必尝试。以你熟悉的事物、熟悉的人以及邓巴数（又称 150 定律，指能与某个人维持紧密人际关系的人数上限，通常人们认为是 150）为准则行事。
-
大多数现有的软件在开发过程中受到一种“短期内为许多人服务”的激励机制的影响，导致它们很难具备长期的稳定性和持久性。为了避免这种情况，你应该专注于那些没有大公司或大量品牌标志的软件，这些软件通常更加简单，依赖性较少，并且不会自动更新。一旦你以这些标准筛选软件，你会发现人类到目前为止创建的真正持久的软件其实非常少。
-
上下文的微小变化（你想支持的人、地点、功能）常常会极大地改变一个程序与其上下文的契合度。我们主导的短期主义环境并未为我们做好面对这一事实的准备。
-
鉴于过去工作量很小，而且每个程序的覆盖率很低，任何你决定构建的新程序都很可能以某种方式进入未知领域。你经常会发现自己在某些方向上并不完全知道自己在做什么。（在我上面的例子中，我试图在文本编辑器中插入特殊的“绘图线”。这引发了一些问题：光标能否位于绘图上？我能否在光标位于另一条线上时尝试绘图？绘图比文本行高。绘图能否在屏幕顶部部分可见？我能否在部分可见的绘图上作画？我对这些问题的回答长期以来都不够理想，导致了层层叠叠的临时解决方案。）
-
类型、抽象、测试、版本、状态机、不变性、形式分析，这些都是我们在陌生领域中可以使用的工具。根据需求使用它们。
-
你不可避免地会过度使用其中一些你偏爱的工具。然而，过度使用会产生技术债务，使我们无法注意到一个程序本不必要这么复杂、不如它本该有的持久性强，以及在上下文变化时更难以更改。
-
当你对上下文的理解稳定下来时，抛弃程序中的大部分内容并从头开始重做是有价值的。
-
在你着手重写之前，你需要花些时间将所有内容同时导入你的大脑。你希望从程序中获得的一切，程序必须满足的所有场景。这样做很难。目标是达到一个点，你可以基于这个点一次构建所有东西。
-
一次性构建所有内容。
就我而言，测试和版本控制实际上阻碍了这个演变的完成。测试让我忘记了需要关注的问题，版本控制则让我固守过去。两者都是适得其反的。经过一次重大的重新定位，我才放弃了它们。
我这一生写的所有软件——包括我目前为止开发的所有 Freewheeling Apps——都处于这个发展轨迹的第 6 级。只有过去一个月的成果让我感觉可能达到了第 9 级。我们拭目以待。
程序可能会随着时间推移变得复杂，这似乎是当前大多数软件的现状。即使是我这个小巧的文本编辑器，也复杂到让我花了大部分时间准备面对这份恐惧。
并不是所有软件都需要达到第 9 级。我认为我的许多 Freewheeling Apps 足够简单，且进化速度足够慢，以至于无论我最初的设计选择如何，它们都可以在只有少数几个人使用的情况下稳定到无错误状态。特别是现在我知道如何简化它们核心中的一个复杂部分。不过，了解如何在有价值的情况下改进事物仍然是件好事。
在达到第 9 级时，感觉绝对有用的一件事是面向数据的设计。这不是一个你可以盲目应用的工具，而是一种你必须成长的思维方式，从你的程序如何访问数据的大局来看，超越直接的数据结构选择。只是不要让 ECS 这样的工具蒙蔽了你的基本智力活动。
以上，我所说的这些级别可能并不完全准确。我可能低估了我没有多少经验的工具。但这是我在 2024 年关于编程的一些思考。
▶引发全球Windows蓝屏，CrowdStrike获“史诗级失败”奖！
▶核心 Python 开发者被停职三个月
▶黑客声称窃取海量腾讯数据，高达14亿条记录、500GB；美国司法部考虑推动分拆谷歌；Go 1.23版本正式发布 | 极客头条
能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。
