代码程序【代码程序流程图怎么画】 收藏 0

两个程序员的寓言：2500行代码的程序，一定比500行的好吗？

编者按：2500行代码的程序一定比500行代码的程序好吗？写出简洁、高效、高可用的程序的开发者黯然离场，搞出庞大、复杂又难用的程序的人倒能加薪升职？究竟开发者的工作应该如何进行评价？来看看下面两个程序员的故事吧。本文译自RealMensch，作者 Neil W. Rickert，原标题为“The Parable of the Two Programmers”。

两个程序员的寓言

很久以前，有两家公司，分别是\”Automated Accounting Applications Association \”和 \”Consolidated Computerized Capital Corporatio\”，他们决定，需要一个程序来执行自己公司的某项业务，但这两家公司并不知道，对于他们的业务需求来说，要开发的程序是完全一样的。

Automated雇用了一位程序员分析师Alan来解决他们的问题。

与此同时，Consolidated决定让他们新招聘的一名初级程序员Charles来负责这项工作，看看他是否真的那么优秀。

Alan曾经有过操刀艰难的编程项目的经验，所以他决定使用PQR结构化设计方法。考虑到这一点，他要求部门经理再指派三名程序员作为编程团队。然后，这个团队就开始工作了，扑到了铺天盖地的初步报告和问题分析上。

再看Consolidated这边，Charles没忙着动手开干，他花了一些时间思考这个问题。Charles的同事们注意到，他经常坐在桌前，把脚抬起来放在桌子上，喝着咖啡。偶尔也会看到他在电脑前忙活，但同事们从他敲击键盘的节奏就能看出，他其实是在玩《太空侵略者》的游戏。

这时，Automated的团队已经开始写代码了。程序员们大约用了一半的项目时间来编写和编译代码，其余的时间都在开会，讨论各种模块之间的接口问题。

而Charles的同事注意到，他终于不再沉迷《太空侵略者》了。他现在要么就是把脚架在办公桌上喝咖啡，要么在小纸片上乱涂乱画。他写在小纸片上的字迹很潦草，当然看起来不是在玩Tic Tac Toe（一种游戏），但也没有什么意义。

两个月过去了，Automated公司的团队终于发布了项目实施时间表。再过两个月，他们将发布一个测试版的程序。然后再经过两个月的测试和优化，便会得到一个完整的最终版程序。

另一头，Charles的经理一直看着Charles上班摸鱼，已经厌烦了，他对Charles失去了耐心，决定和他摊牌。但当他走进Charles的办公室时，却惊讶地看到他在电脑前忙着输入代码。他决定等等看会发生什么，所以打了个哈哈，然后离开了。他开始密切关注Charles，以便抓住机会当面好好教训他一番。但是预期中那令人不快的对话并没有出现，因为他很高兴地注意到，Charles似乎大部分时间都在忙碌，甚至有人看到Charles忙得连午餐都很晚去吃，而且一周有那么两三天，下班后他还会留下来加班。

三个月结束时，Charles宣布他已经完成了这个项目。他提交了一个包含500行代码的程序。程序似乎写得很清楚，经过测试，它可以满足项目既定的所有需求。事实上，它甚至还有一些额外的便利功能，可能会显著提高程序的可用性。该程序投入实际测试使用后，除了发现一个可以快速纠正的疏忽外，表现良好。

到这时，Automated的团队已经完成了项目所需的四个主要模块中的两个。这些模块目前正在进行测试，而其它模块已经完成。

又过了三周，Alan宣布，初级版比原计划提前一周完成。他提供了一份待纠正的缺陷列表。该程序开始进行实际测试使用。除了缺陷列表中列举的问题，用户还发现了一些其它的错误和缺陷。正如艾伦所解释的那样，这并不奇怪。毕竟这是一个初级版本嘛，有错误是意料之中的。

又经过大约两个多月的时间，程序的正式版本开发完毕。它由大约2500行代码组成。测试时，它似乎满足了大部分项目需求。但是它削减了一两个功能，而且对输入数据的格式非常挑剔。然而，公司还是决定上马该程序了。他们可以随时对数据录入人员进行培训，让他们严格按照要求的格式输入数据。此后该程序移交给了一些负责维护的程序员去补全缺失的功能。

后记：

起初，Charles的上司对他在这个项目上的表现还是比较满意的。但当他通读程序源代码的时候，他发现这个项目真的比他最初想象的要简单得多。现在看来，即使是对一个初学编程的人来说，这显然也不是什么难事。

Charles每天确实产出了大约5行代码，这或许是略高于业内平均水平。然而，基于程序是这么简单，他的表现也就并没有什么特别了，而且他的上司还记得他那两个月的“摸鱼劣迹”。

在下一次薪酬调整时，Charles得到了加薪，加薪幅度约为这一时期通货膨胀率的一半（很可怜吧），公司没有给他升职。大约一年后，他变得心灰意冷，离开了Consolidated。

在Automated公司，Alan因如期完成了项目而受到嘉奖。他的上级看了看他们编写的程序，他浏览了几分钟，恩，是遵守公司关于结构化编程的标准的。然后他很快就不再继续尝试往下看了，这程序看起来似乎很难理解。这时他意识到，这个项目确实比他原先设想的要复杂得多，他再次对Alan的成就表示祝贺。

Alan团队的每个程序员每天产出3行多的代码。这在业内大约是平均水平，但考虑到这个项目所要解决的问题的复杂性，可以说是很不错的产出啦。Alan因此获得了丰厚的加薪，并被提升为系统分析师，以表彰他的成就。

来自Tim Mensch的评论：

我曾经是一名年轻但是聪明的程序员，这个故事令我产生了强烈的共鸣。即使在我还是个职场新人的时候，我也能做到令很多资深开发人员都感到有挑战的事情。在我的第一份工作中（作为游戏开发者），我的经理说我在几天内创建的代码，感觉比一个更有经验的开发者经过几个月的推敲后完成的代码都要好（从物理意义上讲）。在我的第二份工作中，我对一个有十年以上经验的高级开发人员编写的工具程序进行了优化，使其只需几分之一秒就能完成一个任务，而不用花费几分钟。我的整个职业生涯充斥了这样一连串的奇闻轶事。

在我从事编程以来的多年开发和学习经历中，我意识到经验确实很重要。但是，底层技能也同样重要。实际上，就像上面讲到的两个程序员的寓言一样，底层技能可能比经验更重要，我认为这个事实已经被许多当代的开发者忽略了。

话虽如此，我也曾经踩过坑，跟上文提到的第二个开发者类似，创建了一个比实际所需要的复杂得多的系统。我知道一个复杂的解决方案，并且知道自己可以实现它，但这并不意味着它就是最好的解决方案，我需要时不时地提醒自己这个事实。

于是，我尝试做出妥协，甚至质疑我自己的解决方案，持续寻找能够改进和简化的方法。我曾遭到指责：因为我倾向于花费更多的时间去思考一个问题，而不是仅仅用显而易见的方法去解决它；我希望能找到更简洁的方法去解决问题。因为花了很多时间思考，看起来好像不务正业，但是充分地思考可以让我产出更好的结果—-代码量更少，更健壮、更可扩展而且更容易阅读。

这就是为什么我认为上面这个寓言如此重要的原因。开发经验固然重要，但在项目设计和实施上的技能都可以完胜经验，如果你同时具备经验和技能，就可以实现相当的奇迹。只要你持续质疑自己的想法并持续思考如何更好地完善它，而不要一味地认为自己的第一个设计构思就是足够完美的。

译者：张茉茉

如何将你的代码可视化？

本文最初发布于 Alex Ellis 的个人博客。

有一天，我正在阅读关于个人电脑和桌面 GUI 发展的内容，我就想，我们都已经非常习惯个人电脑“桌面“这个类比。我们把文件放在文件夹里，并把它们放在桌面上。这个过程有很多物理动作发生。

人类非常善于理解空间，尤其是在记忆物理空间的时候，这让我联想到了我们通常如何将代码可视化。在思考和可视化代码的时候，有没有什么好的方法可以利用这一点？

这让我想到了我往往如何可视化代码，有点难以描述。我认为，它通常以不同的方式存在于我的脑海中，这取决于抽象和特殊性水平，而且同时存在若干不同方式的组合。根据需要，我可以很好地在它们之间切换，特别是当我对代码库非常熟悉的时候。例如，当我想象各种微服务之间的交互时，在每个服务的周围画个大方框是很有帮助的，把每个服务视为一个大的工作单元，彼此之间通过 RPC 交互。

一个简单的面向微服务的汽车租赁服务架构图，以及代表一条执行路径的分布式跟踪。

另一方面，如果对于计算机如何读取我给它的东西，我想知道微末的细节，那么把所有东西放大到物理内存表示是有帮助的。

我曾经做过的一个 Google Sheets 页的截图，上面有内存地址和汇编指令。这对于非常仔细地了解整个过程很有帮助。

幸运的是，我把大部分时间都花在了中间的某个地方，在阅读实际的代码（比汇编高级），把大块的代码作为一个个大的单元来思考，和研究架构图及系统间通信之间做一些平衡。即使是代码本身也已经有了很多物理关系；想想目录路径、命名空间、行缩进以及代码行的线性排序。

对于这个问题，我考虑了一些不同的可视化技术，每一种技术都有不同的应用场景。考虑一下下面这个不完全的清单：

• 架构图
• 依赖图
• 分布式跟踪
• 序列图
• 类图
• 打印语句
• 火焰图
• 阅读源代码

怎么对它们进行比较呢？首先，似乎有一个天然的抽象等级轴线，从低级的代码阅读到高级的架构图。似乎还有一些其他的轴线，我们也可以对它们进行排序。

也许我们可以根据它们在多大程度上代表了更大的系统来对它们进行排名？架构图在这方面做得很好，但火焰图只能代表单个执行路径。也许是变化的频率？这是一个有趣的问题，虽然源代码经常变，但架构图（有望）保持稳定。

让我们想一下，可视化如何很好地表示整个系统实际的代码执行情况呢？在这种情况下，高级的架构图得分也许不会很高，因为它抽象掉了服务框内的许多细节。分布式跟踪可以做得更好，不过具体程度取决于有多少个跟踪点。类图虽然有助于可视化类之间的关系，但可能并不表示实际的路径。火焰图可以显示清晰的执行路径，但只能显示单条代码路径，而不能为更大的系统提供可见性。

画到图上可能会像下面这样，不过上面的这些点表示为一个范围可能更好：

这让我思考，右上角的部分会是什么样子。一个能让我们洞察细节的、有用的可视化该是什么样子？有没有一种方法可以在较低的层次上，将整个系统的路径可视化？

看图的感觉仍然像看地图。在那一刻，你把在代码中看到的东西在空间上转化为图表，就像你在一个不熟悉的地方用地图确定方向。就像电脑上的东西，我们用了桌面隐喻一样，我想知道是否有另一种方式将代码可视化为实际存在的东西，以便让翻译过程变得更容易。

如果我们用“玩具型可视化（toy visualization）”在物理空间中表示代码，会怎么样？

看下面这个基本的例子，我们有一个 Counter 类，它有一个私有的 count_ 变量并提供了各种访问方法。也许它会在一个简单的 main 函数中被访问，做一些计数。

如果我们把代码的不同部分表示为三维结构，会怎么样？如果我们把 Counter 类表示为一个大房间，墙上写着咒语，会怎么样？你可以想象代码的可能路径，变量和它们所代表的事物之间的联系，就像下图中的粉红线：

我们可以从中看到什么？首先，作为私有变量，count_ 的用法显然没有什么不当，因为没有任何粉红线从它那里离开房间。公共方法也很清楚，它们与房间外的事物有粉红色的连接。

更有趣的是，这个房间与另一个房间相连，会是什么样子？main 函数可以是另一个房间，其符咒线也做了相应的连接：

现在，我们可以跨房间对话了；在 main 函数调用 counter.reset() 的地方，我们可以有一个从调用者 main 到被调用者 Counter 类的连接。你甚至可以想象有一个调试器单步遍历这个过程，观察这条线路上的参数和返回值。想象一下，我们可以放大不同的区域来查看本地状态和数值，然后沿着调用路径返回到活动区域。

这有用吗？

像这样的东西有用吗？我不确定。用这样的方式走查一个熟悉的代码库会很有趣，特别是当你能在 3D 表示（或是 VR 环境）中做空间探索，并可以根据需要缩小和放大时。当第一次探索一个新的代码库，查看事物之间的连接关系时，不知道它是否会特别有用。不过，我确实处理过一些代码库，如果这样看会非常吓人。我很想看看这样看会有什么不同，每新引入一个类，这儿那儿就会引入新的连接。

话虽如此，我认为在制作这样的东西时，你至少会遇到以下问题：

• 复杂的代码很难推理。把意大利面代码中的意大利面可视化可谓大快人心，但是对于非常复杂的代码来说，这样做不知道会有多繁琐？
• 如何表示出像线程同时执行这样的东西？
• 如何表示是引用传递而不是值传递？
• 如何表示异步工作？如何表示递归？房间一直嵌套下去？
• 如何防止里面的东西变得陈旧和过时？至少，这个需要能够自动生成。

问题

有几个考量因素使这个问题变得棘手。一个是物理位置的变化比代码的变化耗时通常长得多。使用熟悉的物理位置作为记忆宫殿，一部分原因是它在你的记忆中每次出现都是一样的。如果你在记忆一副扑克牌，你可以把梅花 A 暂时存放在橱柜门后面，下次你需要存放扑克牌时，橱柜门仍然在那。

如果你的代码库经常变化，反映事物空间布局的地图就可能会发生变化，不管这些地图是 3D 生成的还是纯意识的。这就像回到一个你曾经熟悉的地方，想象一下，不只是地标变了，路也改道了。即使我们天生具有记忆空间事物的天赋，如果那个空间发生了变化，如果我们不得不重新学习，我们还能从空间可视化受益吗？

看看这样的东西对于探索一个新代码库（就像使用地图探索一座新的城市），以及随着时间推移再次回到该代码库（就像离开很长时间后回到自己的家乡），有多大帮助，这会很有趣。

我对这一领域的数据可视化不是很熟悉（其他领域的也不熟悉），但经过简单的搜索（也就是 30 分钟的 Google 搜索），我发现有几个项目似乎在做类似的事情：

• SoftVis3D：其中的“代码城市”视图提供了项目层次结构的可视化。
• Code Park：一款新的 3D 代码可视化工具（2017），“在类似三维游戏的环境中可视化代码库”，其中，代码被表示为 \”代码室\”，代码在墙上（现在读到这个，感觉和我的想法非常类似）。
• 使用 3D-Flythrough 实现代码结构可视化（2016），提供空间隐喻和第一人称代码探索。
• Primitive：一家 VR 合作初创公司，拥有矩阵式的“沉浸式开发环境”，包括“面向 3D 视觉分析软件的新工具”。

下面是读者指出的一些项目：

• AppMap：一个自动化代码分析工具，包括依赖关系图和跟踪视图。
• plurid：一个用于在三维可探索结构中可视化和调试代码的框架。
• fsn（文件管理器）：一个实验性的应用程序，支持以 3D 方式查看文件系统（出现在 Jurassic Park 中）。

如果你了解到其他类似的项目，欢迎和我联系，我非常乐意听到更多这样的项目！

显然，这个概念并不是什么突破性的东西，但我认为，对于我们使用的工具，这是一个有趣的思考方式，重要的是，我们如何做得更好。一定有更好的方法存在，设想下它们可能的样子会很有趣。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com